Re: New Trend: Intrusion Prevention

[Frank Knobbe <fknobbe () knobbeits com>]

On Sun, 2002-12-15 at 12:58, Kevin Black wrote:
> One thing I have not seen mentioned is the danger 
> associated with the IPS. Most of the time when I hear 
> people talking about IPS they refer to "shunning" the 
> address associated with the alert or the activity.
> [...]


Kevin,

I believe you may be misunderstanding what an Intrusion Prevention
Device is. It's absolutely normal that everyone has a different idea
what makes an IPS since that is a pretty bad term, and the marketing
droid that dreamed this word up deserves a public flogging.

I think what you are talking about is not an IPS, but just a reactive
IDS (like Snort and SnortSam, or Snort and Guardian). I believe this
thread has been about things like Snort Inline or Hogwash. Those
devices, which as also referred to as Intrusion Prevention Devices [1]
have at their heart a signature or anomaly based engine similar to an
IDS, but they don't use it to alert. Instead the engine is used to make
the decision whether to pass the inspected traffic or not. In essence,
IPS devices behave like firewalls, except that the pass/block decision
is not based on a static access control list, or access policy, but on
signatures.

I agree that (static ACL based) firewalls don't go away, nor are
threatened by IPS'. But those two are indeed starting to merge, and in a
couple years we don't have a 'firewall' or 'intrusion prevention device'
per se, but a hybrid. What we are going to call it remains to be seen.
Perhaps an intrusion wall? The merged device will be able to check
traffic based on a static policy, and in addition filter selected
traffic through a signature engine. A typical policy may look like this:

any -> dns-server | 53/udp | accept
any -> web-server | 80/tcp | inspect (<- signature check)
any -> any        | any    | deny

   
> IPS has its place and can be very useful but in a *very* 
> limited capacity IMHO. The setup needs to be carefully 
> thoughtout and the repurcussions need to be fully 
> understood before it is installed.

I agree, but at the same I'm more optimistic. A lot of people see
security in black and white, but it is not that way at all. We can let
the computer make some decisions, but we have to be careful. For
example, above firewall policy could inspect web server traffic and deny
and packets that contain IIS double-decodes or Unicode attempts. Any
other traffic would be passed. Although we let the IPS part of this
firewall make a decision on it's own, it seems that this is a situation
where we can put this level of trust into the box.

But you are right. The *current* state of IPS' is a bit sorry. We're are
definetly not 'there yet' (Although all IPS vendors would like us to
believe it).

Regards,
Frank


[1] So many other things are marketed as Intrusion Prevention Devices,
it is becoming redicioulous. But as long as the customer eats the
marketing slur and buys the devices without asking questions, nothing
will change.




--
And finally a personal gripe.
You said:

> This is 
> done by modifying the firewall or adding to the 
> hosts.deny, (such as in portsentries case). etc. Suppose 
> you are running IIS and I fired out a few packets at your 
> business that would trigger IIS overflow alerts or scan 
> alerts. The source address is spoofed as one of your 
> remote sites. Maybe your mail is relayed and I use that 
> address or even worse I spoof your downstream router or 
> ISP's DNS server. 


In discussions about the viability and risks of SnortSam and other
programs like it, the issue of spoofs is always brought up. A valid
point that is always answered with white-lists. And DNS servers are
always used as examples.

However, the 'downstream router' play absolutely no part in this
equation. So what if you block your default gateway, or some other
router downstream?! You don't send packets to the IP address of the
router anyway. You don't receive packets from the IP address of the
router either. It's not like it's acting as a reverse proxy or
something. We're blocking on the IP level, not MAC level.

Attachment: signature.asc
Description: This is a digitally signed message part