I think this is why you want server-based IDS, as well as network-
based....
(But this might also be a good reason to consider putting an SSL
"accelerator" box in front of your web server, so you can interpose a
network-based IDS between the two.)
David Gillett
On 5 Jun 2001, at 15:57, Steve Riley (MCS) 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? 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 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. Now the attacker has 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?
>
> ___________________________________________________________
> 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.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
