OK, I've figured out the answer to my own question, and it's kind of
disturbing. It's an issue with the default value for flow_depth in
http_inspect_server. The default value is 300. 300 bytes is barely enough to
cover a reasonably standard http header. That means that after the first 300
bytes of server response are processed, none of the payload of the http
response is processed through snort. This seems to effectively almost
disable a fairly large number of rules. The ones that I've looked at that
seem like they wouldn't work with a flow_depth of 300 would be:
http://www.snort.org/snort-db/sid.html?sid=494 -> ATTACK-RESPONSES command
completed
http://www.snort.org/snort-db/sid.html?sid=495 -> ATTACK-RESPONSES command
error
http://www.snort.org/snort-db/sid.html?sid=497 -> ATTACK-RESPONSES file
copied ok
http://www.snort.org/snort-db/sid.html?sid=1666 -> ATTACK-RESPONSES index of
/cgi-bin/ response
http://www.snort.org/snort-db/sid.html?sid=496 -> ATTACK RESPONSES directory
listing
http://www.snort.org/snort-db/sid.html?sid=1883 -> ATTACK-RESPONSES id check
returned nobody
http://www.snort.org/snort-db/sid.html?sid=1884 -> ATTACK-RESPONSES id check
returned web
http://www.snort.org/snort-db/sid.html?sid=1885 -> ATTACK-RESPONSES id check
returned http
http://www.snort.org/snort-db/sid.html?sid=1886 -> ATTACK-RESPONSES id check
returned apache
http://www.snort.org/snort-db/sid.html?sid=2123 -> ATTACK-RESPONSES
Microsoft cmd.exe banner
http://www.snort.org/snort-db/sid.html?sid=1882 -> ATTACK-RESPONSES id check
returned userid
http://www.snort.org/snort-db/sid.html?sid=498 -> ATTACK-RESPONSES id check
returned root
http://www.snort.org/snort-db/sid.html?sid=1292 -> ATTACK-RESPONSES
directory listing
http://www.snort.org/snort-db/sid.html?sid=1735 -> WEB-CLIENT XMLHttpRequest
attempt
http://www.snort.org/snort-db/sid.html?sid=1290 -> WEB-CLIENT readme.eml
autoload attempt
http://www.snort.org/snort-db/sid.html?sid=1840 -> WEB-CLIENT Javascript
document.domain attempt
http://www.snort.org/snort-db/sid.html?sid=1841 -> WEB-CLIENT Javascript URL
host spoofing attempt
http://www.snort.org/snort-db/sid.html?sid=2437 -> WEB-CLIENT RealPlayer
arbitrary javascript command attempt
http://www.snort.org/snort-db/sid.html?sid=2438 -> WEB-CLIENT RealPlayer
playlist file URL overflow attempt
http://www.snort.org/snort-db/sid.html?sid=2439 -> WEB-CLIENT RealPlayer
playlist http URL overflow attempt
http://www.snort.org/snort-db/sid.html?sid=2440 -> WEB-CLIENT RealPlayer
playlist rtsp URL overflow attempt
http://www.snort.org/snort-db/sid.html?sid=2485 -> WEB-CLIENT Nortan
antivirus sysmspam.dll load attempt
I'm sure there are others, but does it seem like 300 is *way too low* a
value for flow_depth? Anyone else have an opinion on this?
-Joe
-----Original Message-----
From: snort-sigs-admin@lists.sourceforge.net
[mailto:snort-sigs-admin@lists.sourceforge.net]On Behalf Of Joe
Patterson
Sent: Monday, November 22, 2004 4:47 PM
To: snort-sigs@lists.sourceforge.net
Subject: [Snort-sigs] Strange behavior with http_inspect_server
I'm playing around with some snort rules, and I've been noticing some odd
interaction between http_inspect_server and some of the snort rules. I
created a capture which *should* match two rules. I created a snort.conf
that is extremely basic (it contains those two rules and the supporting
variables and preprocessors to make them both work) The two rules are:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-MISC
Cisco IOS HTTP configuration attempt"; flow:to_server,established;
uricontent:"/level/"; uricontent:"/exec/"; reference:bugtraq,2936;
reference:cve,2001-0537; classtype:web-application-attack; sid:1250;
rev:11;)
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES
directory listing"; flow:from_server,established; content:"Volume Serial
Number"; classtype:bad-unknown; sid:1292; rev:8;)
The rest of the config is:
var HOME_NET any
var HTTP_SERVERS $HOME_NET
var EXTERNAL_NET any
var HTTP_PORTS 80
var RULE_PATH /etc/snort
include $RULE_PATH/classification.config
include $RULE_PATH/reference.config
preprocessor flow: stats_interval 0 hash 2
preprocessor http_inspect: global iis_unicode_map /etc/snort/unicode.map
1252
preprocessor http_inspect_server: server default profile all
ports { 80 8080
8180 } oversize_dir_length 500
I run the command:
snort -c ./mysnort.conf -l /root/log/ -r ./mydata.pcap -A full -k none
If I comment out the http_inspect_server line, then I see an
alert from the
second rule. If I don't, then I see an alert from the first
rule. I would
really like to see both, and I can't figure out why that
preprocessor would
suppress the second alert. Well, also, I can't figure out why the absence
of that preprocessor would suppress the first alert (isn't uricontent
handled by http_inspect, not http_inspect_server?)
I'm just a tad confused. Anyone have any insight as to what I'm doing
wrong? (FYI, Snort Version 2.2.0 (Build 30), on a 2.6.5 kernel Gentoo
system)
thanks,
-Joe Patterson, CCNP, CISSP
Senior Security Engineer
SteelCloud, Inc.
(954)318-3200x105
jpatterson@asgardgroup.com
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
