On Jun 07, 2013, Jeremiah Rothschild wrote:

> On Thu, Jun 06, 2013 at 11:30:50PM -0400, Michael Rash wrote:
> > > ENABLE_AUTO_IDS             Y;
> > > AUTO_IDS_DANGER_LEVEL       4;
> > > AUTO_BLOCK_TIMEOUT          86400;
> > > AUTO_BLOCK_REGEX            SID;  ### from fwsnort logging prefixes
> > > 
> > > I cannot get psad to initiate any banning action (unless I explicitly
> > > add an entry to snort_rule_dl (which is not how I wish to handle
> > > management)).
> > > 
> > > Any thoughts on what might be going on would be greatly appreciated!
> > 
> > I believe the issue is that the AUTO_IDS_DANGER_LEVEL is too high for
> > what you want here.  The scan log message above shows that psad has
> > assigned a danger level of 2 as a result of the Snort rule match.  But,
> > the AUTO_IDS_DANGER_LEVEL variable provides a way for you to set the
> > minimum danger level that a scan or attack must reach before the source
> > IP is blocked.  If you set this variable to 2, then I think it should
> > work.
> You are right -- I was interpretting these, and hoping to use them, as
> two independent features rather than not.
> A "blanket banning" ability seems useful since the correct danger
> levels of a port scan don't necessarily reflect the nature or correct
> levels of an attack. The snort_rule_dl functionality does help close
> this gap (since you can then effectively say "This didn't trigger
> a danger level since it's only 1 or 2 packets, but it sure is
> worrisome so let's make sure it gets elevated + banned"), however,
> as your ruleset grows, it becomes less practical to add and manage
> one-to-one mappings.
> I wonder, then, what sort of best practice or sweet spot exists.
> fwsnort, for example, ships with over 2800 snort rules and the
> emergingthreats ruleset is crazy at over 12000. Of course, only
> 60-70% of these will translate, and perhaps there's some (or a lot)
> of overkill in these, but still.
> Any thoughts or advice?

Enabling auto-blocking is a mode that always tends to highlight
tradeoffs in a way that other modes don't.  Usually I find that enabling
auto-blocking is best reserved for the worst fwsnort signature matches,
and only then for those that must travel over established TCP
connections (so attack traffic cannot reasonably be spoofed in order to
fool the detection mechanism).  This is why the default value for the
AUTO_BLOCK_REGEX variable in the psad.conf file is "ESTAB" since fwsnort

On the other hand, by also setting the minimum danger level that a scan
must reach before a blocking action is taken, psad is also able to take
into account scanning activity that preceeds a more malicious
application layer exploit that fwsnort may detect.   The aggregrate of
these two activities (well, more important for a port sweep vs. a port
scan) can be an important indicator of malicious intent.



How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
psad-discuss mailing list

Reply via email to