[Snort-users] Snort-1.9.0 not generating required alerts

Erek Adams erek at ...577...
Tue Oct 15 11:50:03 EDT 2002

On Tue, 15 Oct 2002, archana rao wrote:

> Thanks for the reply.

No problem.  :)

>  The alert that I expect to be generated has sid:981.

Ok, lets have a look at the rules:

 alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS File
 permission canonicalization"; uricontent:"/scripts/..%c0%af../"; flags:A+;
 nocase; classtype:web-application-attack; sid:981;  rev:5;)

 web-iis.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
 (msg:"WEB-IIS File permission canonicalization";
 uricontent:"/scripts/..%c0%af../"; flow:to_server,established; nocase;
 classtype:web-application-attack; sid:981;  rev:5;)

Note that on 1.8.7 it uses the 'flags:A+' setup.  That used to be prone to a
lot of false postives and so 'flow' was added.

> It does look for the "flow:to_server, established", but I am establishing a
> session before sending the packets. I am doing tcpdump of the traffic
> between my attacking machine and the machine being attacked.I am writing the
> output of tcpdump into a file and using this tcpdump formatted file as input
> to Snort.These were the same steps that I followed in Snort-1.8.7. Am I
> missing out something?As I mentioned earlier, I am establishing a session
> before firing the packets.

One thing that you might be getting the problem from is that the snaplen of
tcpdump is 64bytes where snort's is 1514bytes.  Usually, w/tcpdump you only
get the headers and a small bit of the data, unless you explicitly change the

Try recording the session using a bigger snaplen or with snort.  Fire the
exploit and see if you can get a capture.  Once you get that try running the
newcapture thru snort and see what you are getting.  Something like 'snort -b
<options> "host <victim>" ' should get the capture you need.  Then 'snort
-vader <logfile>' would run the data on the screen.

Good luck!

Erek Adams

More information about the Snort-users mailing list