[sorry, all, if this comes through twice - I've sent something since which
has arrived, but haven't seen this one come through]
> -----Original Message-----
> From: Steve Riley (MCS) [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 06, 2001 8:28 AM
> To: [EMAIL PROTECTED]
> Subject: Encryption vs. inspection.
>
>
> I think we all here agree that encryption is a good thing.
Yay!
> But what about when
> encryption prevents legitimate inspection?
My point of view is that that is kind of impossible. Either users are
allowed to use encryption for their traffic, and thus no inspection of
encrypted payloads is legit for privacy reasons, or they're not, in which
case there shouldn't be any encrypted traffic to inspect.
[...]
> Consider a web server. Normally, the site can be quite well
> secured with
> various combinations of firewalls, intrusion detection, and content
> inspection.
I'll take your word for it. I thought that was why they put webservers in
DMZs.
> ISA Server's HTTP filter is quite good at this.
*LOL*
> 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.
That's an issue, yes, but you still have some options. You can run host
based security that takes action when the web server does something weird -
NAI used to make a product that would "keep an eye" on IIS servers and take
drastic action if certain things changed (files in certain directories etc).
That would pick up many simple exploits and stop them cold.
You can also train your IDS to know that some traffic patterns are bad - the
WWW server should never be trying to connect _in_ through the firewall to
the Internal network - even if the traffic is encrypted.
> 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.
That's all possible, yup.
> 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.
Not with any decent IDS they can't. As soon as the compromised box starts
doing weird stuff it will annoy the network IDS which will then start
squealing.
> 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?
Vital, IMHO, and under-used.
> Is it best to put SSL web servers
> in a separate subnet, kept apart from the rest of the DMZ by
> yet another
> firewall?
I don't see the need for it. Webservers should only be talking among
themselves (if at all) in certain ways. SSL is probably not one of those
ways.
> 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?
That's not correct. The end user will know that the traffic is being
inspected on the way, since they would have to accept a bogus certificate
for the site they want to look at. You can make this policy, but you can't
do it without your users knowing (unless they're trained to click "OK" at
every opportunity.
> Does the desire to "know everything going in and out of my
> network" mean that I should block all IPSec?
Incoming IPSec should terminate at the network border, in most cases -
before the start of the zone the N-IDS is patrolling. Outgoing IPSec from
the inside is a policy decision. It could be used for tunneling, but so
could a lot of other stuff which would be easier - SSL being one of them.
> ___________________________________________________________
> Steve Riley
> Microsoft Telecommunications Consulting in Denver, Colorado
Just, as they say, my $0.02 (that's US$0.0005, I think. ;)
--
Ben Nagy
Network Security Specialist
Marconi Services Australia Pty Ltd
Mb: +61 414 411 520 PGP Key ID: 0x1A86E304
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
