No subject

Thu Nov 23 16:36:19 EST 2017

your firewall.  If that's the case, be prepared to see all sorts of things.
Many times these things are harmless, but in some cases, Speedera ping comes
to mind, some tools actually use that same ping content to bypass the rule.

And along that same vein:  Why do you care about pings?  Will a ping ruin your
day?  :)  If they bother you that much, drop'em at the gateway router and/or
firewall and turn off the entire ruleset.  IIRC, that ruleset is turned off be

> Any suggestions on the best way to do this? What happens if I change the
> rules from alert to pass.

Don't just blindly change the rule from alert to pass.  First, you'll have to
use -o to make the pass rules work as you expect.  Then if you do just change
alert into pass, you're also forcing a check if you leave any of the rule
options there.  The simpler a pass rule is, the better off you are:

	pass <somehost> 80 -> $HOME_NET any (msg: "Passed traffic";)

is about the simplest you can get.

If it _REALLY_ is a pain, build a BPF filter and use that.  The BPF acts at
the pcap level (pre-snort) and stops packets from ever getting to snort.  And
yes, you can specify type.

As someone else suggested:  LARGE COFFEE, some free time, and a notebook will
help in finding the rules you really care about.  If you do decide to change a
rule, I suggest copying it to a 'custom.rules' with comments stating why it
was changed.  That way you can simply comment out the original rule from the
rules file, simplifing updates from the rulesets.  Note:  Don't use
'local.rules'.  :)  There's a _blank_ local.rules in the dristro, so a 'cp
*.rules /<snort_rules_path>/ would overwrite it.  :)

Have a look at 'oinkmaster' to help you do rule management.  From what I've
seen its rather helpful in cases like this.

Good luck!

Erek Adams

More information about the Snort-users mailing list