Snort mailing list archives
http_inspect's Configuration Effect on Signatures
From: Eoin Miller <eoin.miller () trojanedbinaries com>
Date: Fri, 16 Jul 2010 21:12:09 +0000
So it appears that when you use the VRT version of the snort.conf that comes with the rule kit, it will REALLY change how your signatures for HTTP are going to work due to the differences in the http_inspect preprocessor. After beginning to use the VRT version of snort.conf, I noticed several of our own in house signatures stopped working all together. After a bit of testing and hair pulling, I have some guesses as to why this is occuring. We are going to stick to just the enable_cookie option and how it will effect signatures. Below is the VRT version of the snort.conf file as it pertains to the http_inspect preprocessor: ======================================================================== # HTTP normalization and anomaly detection. For more information, see README.http_inspect preprocessor http_inspect: global iis_unicode_map unicode.map 1252 compress_depth 20480 decompress_depth 20480 preprocessor http_inspect_server: server default \ chunk_length 500000 \ server_flow_depth 0 \ client_flow_depth 0 \ post_depth 65495 \ oversize_dir_length 500 \ max_header_length 750 \ max_headers 100 \ ports { 80 1220 2301 3128 7777 7779 8000 8008 8028 8080 8180 8888 9999 } \ non_rfc_char { 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 } \ enable_cookie \ extended_response_inspection \ inspect_gzip \ apache_whitespace no \ ascii no \ bare_byte no \ directory no \ double_decode no \ iis_backslash no \ iis_delimiter no \ iis_unicode no \ multi_slash no \ non_strict \ u_encode yes \ webroot no ======================================================================== Specifically, please note the enable_cookie option. Below is the decoded packet content we are attempting to perform matching against: ======================================================================== HTTP/1.1 200 OK Server: nginx/0.6.39 Date: Thu, 15 Jul 2010 20:58:46 GMT Content-Type: text/html Connection: keep-alive X-Powered-By: PHP/5.1.6 Set-Cookie: bmb=1279227526; expires=Thu, 22-Jul-2010 20:58:46 GMT; path=/; domain=ssladdon.in Content-Length: 10507 Content-Disposition: inline; filename=index.html ======================================================================== Here is our original rule that we had working just fine using the snort.conf that comes with the sourcecode of Snort 2.8.6. This below signature will *NOT* fire on the same pcap we are reading offline when using the VRT version of the snort.conf file: ======================================================================== alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET MALVERTISING drive by kit encountered - bmb cookie"; flow:established,to_client; content:"HTTP/1"; depth:8; content:"Set-Cookie: bmb="; classtype:bad-unknown; sid:5600064; rev:1;) ======================================================================== However, if we use the VRT snort conf version (which include the above posted http_inspect configuration options) we must rewrite the rule to be as follows in order for it to trigger: ======================================================================== alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"EID MALVERTISING drive by kit encountered - bmb cookie"; content:"bmb="; http_cookie; classtype:bad-unknown; sid:5600064; rev:1;) ======================================================================== Now, if we remove the "enable_cookie" line from the http_inspect configuration file, then both of the above signatures will not fire and we must rewrite the signature again for it to work appropriately. Please note that we have swapped from using http_cookie to using http_header to have the content string match against: ======================================================================== alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"EID MALVERTISING drive by kit encountered - bmb cookie"; content:"Set-Cookie: bmb="; http_header; classtype:bad-unknown; sid:5600064; rev:1;) ======================================================================== We also tried removing the http_header option for the content string and found that it will not fire off. It appears that once you use enable_cookie and max_header(s) options within the http_inspect configuration, seperate and very specific buffers are created for those chunks of information. If your rule does not specifically check those buffers with appropriate keywords (http_cookie,http_header,etc) after specifying content:"foo" then it appears to not match and not trigger. I am guessing that it will look through the rest of the packets content instead of the portions that have been split out (cookie, header, uri, etc) and attempt to pattern match against that. Has anyone else ran into this? I know I am pretty inexperienced at writing signatures and I am probably just doing it wrong/with bad form, but this appears to be a gotcha that may be causing a bunch of other signatures to not function depending on which options you have enabled in your http_inspect configuration. -- Eoin ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
Current thread:
- http_inspect's Configuration Effect on Signatures Eoin Miller (Jul 16)