Re: New Trend: Intrusion Prevention

["Kevin Black" <snort_lists () mbsecuresolutions com>]

Ok, I will respond once then we should take this offline 
:) 

I believe you are right in everything you said, I think 
you are saying the same thing I am in most cases. IPS is 
the future and will become a major "feature" in most 
firewalls and possibly IDS's just like signature based 
IDS's will merge with anomaly based IDS's. Both Hogwash 
and Guardian were referred to in this thread a few times 
as IPS so it was fair of me to refer to them as well. 
Cisco also talks about "shunning" in their PIX 
IDS...etc.etc. I dont know enough about host based IPS to 
state a position so this does not include host IPS. 
Any auto response is what I am talking about. Let me put 
forth a few examples using Snort sigs since this is a 
Snort mailing list:

- POP3 PASS overflow attempt  SID:1634
I have seen a rash of these over the last few weeks. What 
I have determined is that all the sources for this alert 
are using an updated Outlook or Outlook express.
Essentially what would have happened if the firewall had 
this signature and did not allow packets to pass is that 
none of the normal users would have been able to get their 
mail.

- SMTP HELO overflow attempt  SID:1549
If you run Exchange 2k you will be very familiar with this 
sig as it would have flooded your db, alert file, etc, 
when you enabled it.
The IPS if built into the firewall making decisions would 
have blocked most if not all of your sites email until you 
determined what the problem was.

When I am talking about this I am not referring to a site 
where the admin and the net engineer and the sec analyst 
are the same person or sit next to each other. I am 
talking more about the larger environments where they may 
not even know each others faces. Companies like this are 
the commercial target, not the small shops. In 
environments like this "white-lists" would be very hard to 
maintain in my experience and they would not cover things 
such as Google, Yahoo, AOL, etc. Imagine your helpdesk who 
supports the 1.5-2k ppl on the site getting calls from 
everyone saying that they cannot get to Yahoo :) In your 
IIS double decode example you need to be really careful. 
What happens if the security analyst doesnt know that the 
Web devs just added an "upload a picture" page? That jpg 
or gif could easily contain the characters that would 
trigger the alert so this would have to be taken into 
account when the rule is written or it could waste 
valuable time.

Your personal issue with the router statement:

In most cases your firewall or your IDS are not a router. 
This means that the next hop is your router, not your 
ISP's. Who cares if this dest gets blocked? In ordinary 
circumstances nobody does. Imagine this though. Your users 
begin complaining that several things are not accessable 
on the Internet. The first thing you would check was your 
firewall to ensure it is up. The second thing would 
probably be your router. You would then waste time 
thinking that the issue is possibly a faulty router, you 
would then contact the network engineer as you do not have 
access to it. Not exactly a dangerous situation but it 
would again waste time. I did not say anything about mac 
blocking as that would, in every case, be useless.

I hate to get into specific examples. I was just stating 
the case that *at this point and time* the technology is 
young and is *not there yet*. It does not threaten IDS nor 
does it threaten firewalls it is more of a *feature*. *At 
this point and time* it is very necessary to be cautious 
of the setup as it could waste many peoples time. Of 
course in a small one web server 100 person environment 
this would probably not be the case but they are *not* the 
main commercial target.

Thanks,
   Kevin Black
   kblack () mbsecuresolutions com


On 15 Dec 2002 16:09:26 -0600
 Frank Knobbe <fknobbe () knobbeits com> wrote:
> 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. 



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users