[Snort-sigs] Suggestions for new attack response rules

Jason security at ...704...
Mon Dec 6 21:25:06 EST 2004

I certainly appreciate the discussion over the regular how-to mails and 
the like. It is good to see that someone besides me is thinking about 
how to do some different things with rules...

Joe Patterson wrote:
> I assume by shell header you mean something along the lines of signature
> 2123, the Microsoft cmd.exe banner.  That doesn't quite work.  It's a great
> rule, and I'm glad to have it, but it's even more trivially evaded than my
> rules.  Of course, the cynic in me feels that if my suggestions are as
> ineffective as bmc and Jason seem to feel, then perhaps all of the trivially
> evaded attack response rules, which would be pretty much all of them, should
> be deleted since they generate so many false negatives... But that would be
> mean, so I won't say it.  :)

I agree. The attack-responses rules should be re-visited and updated 
where appropriate. In any case the attack-response rules are a last 
resort set and serve little value unless you have the staff to analyze 
and customize IMHO.

> But back to the point at hand, first take a look at a recent post of mine
> about http_inspect_server.  It applies in what I feel are somewhat
> disturbing ways to several attack response rules.

This is not disturbing at all, in general an IDS is looking for attacks 
against your servers, are you concerned about your servers attacking 

> But more importantly, signature 2123 only fires if the attacker doesn't pass
> anything to cmd.exe via /c or similar.  Certainly some attackers will do
> this, but not all.

It seems you have done a little research in this area... any updates you 
would like to share ;-)

> To my mind, it's a progression of making life harder and harder for an
> attacker.  2123 is a good rule, IMHO, and will catch some successful
> attacks.  It *is* trivially evaded, but will catch successful attacks by
> attackers who don't put forth that trivial effort.  

These ppl are weak in the mind and will most likely get caught attacking 
  before a successful attack is likely to set off a response rule. But...

> Signature 1292
> (ATTACK-RESPONSES directory listing) will catch the strangely common case of
> attacks that try and find a cmd shell using "/c dir", but is trivially
> evaded by attacks that instead send "/c echo moo".  

it is not intended to find /c echo moo so this is not surprising. Rule 
1:1002 should catch cmd.exe /c echo moo, success or not.

> Likewise, it will catch
> some things, but will miss attacks that put forth the effort to evade it.
> The next step in the evolution, as I see it, is my initial suggestion of
> looking for [23]?? http response codes.  This *should* catch even more
> things than either 2123 or 1292.  It will catch the attackers who are smart
> enough to evade those signatures, but not quite clever enough to make sure
> that all of their commands terminate with a false exit status, or some other
> method for avoiding the generation of a non-error status code.  

cat /var/log/httpd/httpd_access_log?

> The next
> step is my refined suggestion to have a rule which logs *some* context in
> the response to every attack.  This requires the attacker to craft his
> attacks in such a way that the response is indistinguishable *to an
> intelligent human analyst* from normal traffic.  This is certainly possible
> also, but it makes life harder for the attacker, and I am strongly in favor
> of making life very very hard for attackers.

This ultimately makes life easier for the attacker since the mind allows 
us to easily discard things that do not confirm to an established norm. 
See my other mail for some reasons why I think this approach is not 


More information about the Snort-sigs mailing list