--- "Steve Riley (MCS)" <[EMAIL PROTECTED]>
wrote:
> I think we all here agree that encryption is a good
> thing. I won't
> preach to the choir by enumerating the reasons. But
> what about when
> encryption prevents legitimate inspection?
If you are speaking of a VPN, encryption and
authentication typically are first in a firewalls rule
base which means that arriving packets are first
decrypted and then inspected by the firewall just like
any other packet.
This has
> been on my mind
> lately, and I'll admit that I haven't really figured
> out yet where I
> stand, if indeed it's even possible to choose sides.
>
> Consider a web server. Normally, the site can be
> quite well secured with
> various combinations of firewalls, intrusion
> detection, and content
> inspection. ISA Server's HTTP filter is quite good
> at this. The site can
> know what's coming in and going out, and take
> appropriate action based
> on what it sees. But what if, instead of regular
> in-the-clear HTTP, the
> traffic is SSL?
Now you've just gotten around the
firewall and the IDS:
there's no way to know what's passing through.
The firewall may be set to allow port 443 but will
probably also be set for port 80 HTTP. This is a non
issue. If someone develops an exploit that attacks
web servers through port 80 or 443 and the webservers
have to have these ports open to function what
difference would it make if the traffic was encrypted
or not. The latest round of F usa hacks had nothing to
do with firewalls or IDS's it had to do with lazy
administrators and servers that had to allow this
inbound traffic to do their job. Even if the firewall
inspected the hell out of the traffic it still would
have let it through because when it passed the
firewall it was nothing more than a HTTP request. If
the box wasn't patched it wouldn't matter if you
detected the attack the damage was immediate.
And you would certainly be able to determine what is
passing through. The holder of the private cert key
is YOU, the public key is what is used by those
visiting the sight. Wouldn't all traffic become
diciphered through the use of the two keys
(public,private).
Hackers will always find a way but atleast with the
IDS and firewall you can begin to track and understand
the nature of successfull hacks.
The
> server accepts the
> traffic and does whatever its told.
>
> Would the following not-entirely-well-considered
> rumination be a
> possible scenario? An attacker uses an SSL-enabled
> tool to compromise a
> web server. This tool just happens to exploit the
> latest discovered
> vulnerability. The server, unfortunately, hasn't yet
> been patched.
The
> tool uses SSL to get past firewalls and IDSs, and
> that's the key, since
> the site's network has an IDS that would have been
> triggered had the
> tool used clear-text HTTP.
But if the servers were not patched, you may have
seen it happen but it still happened!!
It would not have been detected until the signatures
for this exploit (IIS) were defined. Before that it
would have passed through like a cool breeze. If
someone develops a successfull exploit using SSL then
the IDS signature will soon reflect this fact and the
IDS will detect the hack, not stop it. Until it is a
known vunerabilty the IDS will not help, unless a
great analyst is at the wheel.
> control of one box, and
> can use it to compromise the entire network -- all
> over SSL and
> practically invisible to the watchers.
>
> I'm curious to know how others have approached the
> intersection of the
> seemingly incompatible technologies of encryption
> and inspection. Is IDS
> really all that useful, for example? Is it best to
> put SSL web servers
> in a separate subnet, kept apart from the rest of
> the DMZ by yet another
> firewall? Hardware accelerators (and even ISA) can
> decrypt then
> re-encrypt traffic, but wouldn't this appear to
> break the chain of
> trust, since I as a user don't know that an
> intermediate device --
> rather than the destination web server -- is
> actually decrypting the
> traffic? Does the desire to "know everything going
> in and out of my
> network" mean that I should block all IPSec?
NO!
IPSEC traffic is decrypted then inspected!!
>
>
___________________________________________________________
> Steve Riley
> Microsoft Telecommunications Consulting in Denver,
> Colorado
> [EMAIL PROTECTED] +1 303 521-4129
> (mobile)
> [EMAIL PROTECTED] (MSN Messenger)
> www.microsoft.com/ISN/tech_columnists.asp
> <www.microsoft.com/ISN/tech_columnists.asp>
> Applying computer technology is simply finding the
> right wrench to pound
> in the correct screw.
>
> -
> [To unsubscribe, send mail to
> [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
