Stephen JT Bourike wrote:
In response to Eugeniu Patrascu's post:
SecureClient can easily be installed to prevent a user from having access to
the policy unload options. SC and the SSL Network Extender/Connectra also
integrate directly with the Check Point Integrity product, allowing the same
kind of checks and quarantining to be performed.
This implies that you control the end point client, which is not always
the case (even with company provided ones).
More Generally:
The original question was about security of SSL VPNs - and I doubt there is
truly much to chose.
Yes, the transport is more flexible, and that's no doubt why SR/SC provide a
"Visitor Mode" allowing the client to traverse networks and proxies using
SSL rather than IPSEC. That doesn't change the function of the client
itself, the firewalling policy for SC remains intact just the same.
True. From experience this also helps with encryption domain
overlapping, but doesn't work every time.
In terms of pure security, both SSL and IPSEC provide an encrypted channel,
and the traffic passing through them is controlled (primarily) at the
gateway - so the security is really NOTHING to do with the transport, and
EVERYTHING to do with the rules configured by the administrator of the
firewall that is terminating the connection. This is true whether you are
talking about Check Point or any other firewall.
A pure SSL VPN solution acts in some cases as an ALG providing even more
security than with a traditional IPSec connection
on which based on the client you allow or deny access to some ports.
In fact, if I'm being a pedant, using SecureClient properly, you have more
security than you would with say a Cisco VPN client or many of the other
generic IPSEC clients, and certainly more than you would with an SSL VPN.
This is because, when configured properly, there are actually TWO firewalls
controlling traffic into and out of the VPN, in a similar way to a full
gateway<>gateway VPN. The client rules, which if you follow the
(horrendous) CP knowledgebase or courseware examples are so slack as to be
useless, SHOULD be configured in just the same way as a gateway rule SHOULD
be (don't get me started on that one).
i.e.
[EMAIL PROTECTED] -> IntranetServers -> HTTP/HTTPS -> Encrypt ....
This allows any user in the IntranetUsers group to access any of the
intranet servers for JUST the protocols needed to visit the corporate
intranet. A very common error is to use one rule for all remote users to
the whole encryption domain (a la CP documentation) which turns SC into SR
or any other rubbishy VPN client.
In your example you assume that the web applications that you allow your
users access to are secure and they cannot be
manipulated by the client.
Conclusion ?
Bolting a red/grey/blue box into your comms rack and sticking a label on it
saying "firewall" does NOT make you secure. Using SSL instead of IPSEC or
vice versa is the same.
Sure, there are some very clever bolt-ons from some vendors, including SSL
session sandboxing and the like, but that's not part of the SSL VPN per se,
that's additional value-add from a specific vendor and doesn't apply to
every SSL product on the market. The job of the security consultant or
network security officer is to evaluate the business need, review the
technologies, consider the risks, evaluate the cost of mitigation and select
technologies and products that suit the requirement. If one size truly
fitted all, we would all be wearing grey jumpsuits and using Windows for
everything.
This is why for firewalls people chose a vendor and for SSL VPNs they
choose other vendors ;)
Steve Bourike (assorted industry qualifications and experience)
http://www.appliedsecurity.co.uk
Blue polo shirt, jeans, grey trainers and assorted OS's (including Windows
*sigh*).
/me with also assorted industry qualifications and experience ;)
Scanned by Check Point Total Security Gateway.
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to [EMAIL PROTECTED]
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
[EMAIL PROTECTED]
=================================================
