Re: RE: problem with suppress...

[sekure <sekure () gmail com>]

Graeme,

Let's leave the http_inspect alone for a second, it has its own
issues.  I heard it was fixed (FPs a LOT less), but i haven't had a
chance to try it yet myself.  If you are sure that you don't want to
receive ANY alerts from the http_inspect preprocessor itself, just add
no_alerts to the config parameters.

Anyways, suppress and pass work in two very different yet similar
ways.  It really depends on you which you want to use.  Let me just
say that if you use suppress incorrectly, at the very worst you might
miss one type of alert.  If you use pass incorrectly, you might miss
all alerts.  So be careful.

Given your scenario, if you don't want to be alerted on any traffic
coming from your partners, then go ahead and use "pass" or better yet
define a BPF filter to completely ignore it before snort even takes a
look at it.  If on the other hand you do want to analyze traffic from
your partners, use suppress for most things, unless you run into an
issue that can't be solved with it, then use "pass".

Let me give you an example: I have a few internal proxies set up
listening on ports 1080 and 8080.  This was generating a lot of alerts
of "SCAN Socks Proxy" type whenever a client tried to connect (SYN
packet).  I could have set up a pass rule to ignore all traffice to
port 1080 or 8080, but that would have missed a LOT of other stuff
that i wasn't willing to give up.  Instead I set up a suppress
statement that suppresses that particular alert to those particular
proxy servers.  Nice and neat.

Another scenario is where I know I have a lot of ICMP traffic flying
around on the inside of my network.  And Snort has a LOT of ICMP
signatures, even for just ECHO (a subset of ICMP).  I think there are
32 different signatures to identify the many different ICMP
requests/replies.  I could have set up 32 individual suppress
statements, or I just set up a pass rule to pass all ICMP traffic with
itype of 8 (ECHO).

You see what i am saying?  Suppress is for suppressing individual
rules, pass CAN be used for that as well, but it's much better for
suppressing broader types of traffic. I hope this makes it clearer.

If you have more specific questions, please post a sample of traffic
you are trying to ignore, and what suppress or pass rules you are
currently using.

HTH

On Fri, 16 Jul 2004 08:42:34 +1000, Graeme Rider
<graeme.rider () colesmyer com au> wrote:
> Sekure,
>        what we have are connections to external trading partners coming
> over ipsec vpn's..these addresses are not part of $HOME_NET so l am trying
> to suppress alerts on the traffic that l would not to be classed as an
> attack or recce. type but still be alerted on other types...if l used a pass
> rule then l may miss a genuine alert..
> l have also tried the suppress rule http_inspect (gen_id 119) and still
> recieve the alerts...obviously from what l have read and what others are
> saying it is something l am doing or not doing..
> regards
> graeme
>
>
>
> -----Original Message-----
> From: sekure [mailto:sekure () gmail com]
> Sent: Thursday, 15 July 2004 11:04 PM
> To: Graeme Rider
> Cc: Tobias Rice; snort-users () lists sourceforge net
> Subject: Re: [Snort-users] RE: problem with suppress...
>
> Graeme,
>
> You don't need the -o flag for suppression to work.  -o is used for
> when you have "pass" rules.  Suppression and thresholding should work
> without it.
>
> Rule 384 is a very generic "ICMP Ping".  Is this the rule that keeps
> triggering or are you trying to supperss ALL Ping events with that
> statement?  The reason I ask is that there are many many ICMP Ping
> signatures.  Are you absolutely sure that it is sig id 384 that keeps
> showing and not other ping signatures?
>
> On Thu, 15 Jul 2004 08:43:02 +1000, Graeme Rider
> <graeme.rider () colesmyer com au> wrote:
> > Tobias,
> >        yes...l was not initially but then saw a reference to this flag in
> > the 'pass' requirements...
> > the suppress rule that l am using is in the local.rules file:
> >        suppress gen_id 1,sig_id 384
> > regards
> > graeme
>
> This email and any attachments may contain privileged and confidential information and are intended for the named 
> addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail 
> immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to 
> you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made 
> that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this 
> material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the 
> material.


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
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