[Snort-users] Snort-1.9.0 not generating required alerts
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.
More information about the Snort-users