Re: HTTP preprocesor

[Eugenio Perez <eugenio () redborder org>]

Hi James and Lewis.

You both are right, what a dumb failure! Checksum offloading cheated me.

Thanks for your help!

2015-01-26 19:05 GMT+01:00 Al Lewis (allewi) <allewi () cisco com>:
> Try running with the "-k none" option. The pcap you have has bad checksums.
>
>
> Without -k
>
> ===============================================================================
> HTTP Inspect - encodings (Note: stream-reassembled packets included):
>     POST methods:                         0
>     GET methods:                          0
>     HTTP Request Headers extracted:       0
>     HTTP Request Cookies extracted:       0
>     Post parameters extracted:            0
>     HTTP response Headers extracted:      0
>     HTTP Response Cookies extracted:      0
>     Unicode:                              0
>     Double unicode:                       0
>     Non-ASCII representable:              0
>     Directory traversals:                 0
>     Extra slashes ("//"):                 0
>     Self-referencing paths ("./"):        0
>     HTTP Response Gzip packets extracted: 0
>     Gzip Compressed Data Processed:       n/a
>     Gzip Decompressed Data Processed:     n/a
>     Total packets processed:              1
> ===============================================================================
>
>
> Ignoring checksums:
>
> ===============================================================================
> HTTP Inspect - encodings (Note: stream-reassembled packets included):
>     POST methods:                         0
>     GET methods:                          1
>     HTTP Request Headers extracted:       1
>     HTTP Request Cookies extracted:       0
>     Post parameters extracted:            0
>     HTTP response Headers extracted:      1
>     HTTP Response Cookies extracted:      0
>     Unicode:                              0
>     Double unicode:                       0
>     Non-ASCII representable:              0
>     Directory traversals:                 0
>     Extra slashes ("//"):                 0
>     Self-referencing paths ("./"):        0
>     HTTP Response Gzip packets extracted: 0
>     Gzip Compressed Data Processed:       n/a
>     Gzip Decompressed Data Processed:     n/a
>     Total packets processed:              4
> ===============================================================================
>
>
>
> As you can see more packets are processed and snort actually sees the "Get".
>
>
> Hope this helps.
>
>
> Albert Lewis
> QA Software Engineer
> SOURCEfire, Inc. now part of Cisco
> 9780 Patuxent Woods Drive
> Columbia, MD 21046
> Phone: (office) 443.430.7112
> Email: allewi () cisco com
>
>
> -----Original Message-----
> From: Eugenio Perez [mailto:eugenio () redborder org]
> Sent: Monday, January 26, 2015 12:24 PM
> To: snort-users () lists sourceforge net
> Subject: [Snort-users] HTTP preprocesor
>
> Hi Everyone.
>
> I don't know if HTTP preprocesor is working properly. Using Snort
> 2.9.7.0 and the attached pcap, and the next line to run snort:
>
>     snort -v -e --pid-path /var/run -r 80.pcap -c /etc/snort/snort.conf -l /var/log/snort/ --perfmon-file /dev/null 
> --treat-drop-as-alert --daq dump --daq-var load-mode=read-file -Q
>
> I'm not able to see the HTTP response in the stats:
> ===============================================================================
> HTTP Inspect - encodings (Note: stream-reassembled packets included):
>     POST methods:                         0
>     GET methods:                          0
>     HTTP Request Headers extracted:       0
>     Avg Request Header length:            n/a
>     HTTP Request Cookies extracted:       0
>     Avg Request Cookie length:            n/a
>     Post parameters extracted:            0
>     HTTP response Headers extracted:      0
>     Avg Response Header length:           0.00
>     HTTP Response Cookies extracted:      0
>     Avg Response Cookie length:           n/a
>     Unicode:                              0
>     Double unicode:                       0
>     Non-ASCII representable:              0
>     Directory traversals:                 0
>     Extra slashes ("//"):                 0
>     Self-referencing paths ("./"):        0
>     HTTP Response Gzip packets extracted: 0
>     Gzip Compressed Data Processed:       n/a
>     Gzip Decompressed Data Processed:     n/a
>     Total packets processed:              1
> ===============================================================================
>
> Following "http://seclists.org/snort/2013/q2/905";, if I enable inline mode operation (adding --daq dump --daq-var 
> load-mode=read-file -Q), I see that HTTP preprocesor can extract more info:
>
> ===============================================================================
> HTTP Inspect - encodings (Note: stream-reassembled packets included):
>     POST methods:                         0
>     GET methods:                          0
>     HTTP Request Headers extracted:       0
>     Avg Request Header length:            n/a
>     HTTP Request Cookies extracted:       0
>     Avg Request Cookie length:            n/a
>     Post parameters extracted:            0
>     HTTP response Headers extracted:      1
>     Avg Response Header length:           0.00
>     HTTP Response Cookies extracted:      0
>     Avg Response Cookie length:           n/a
>     Unicode:                              0
>     Double unicode:                       0
>     Non-ASCII representable:              0
>     Directory traversals:                 0
>     Extra slashes ("//"):                 0
>     Self-referencing paths ("./"):        0
>     HTTP Response Gzip packets extracted: 0
>     Gzip Compressed Data Processed:       n/a
>     Gzip Decompressed Data Processed:     n/a
>     Total packets processed:              2
> ===============================================================================
>
> However, my pcap is a full one (it includes syn, ack, fin, and all packets needed to establish the TCP connection). 
> Why HTTP preprocesor is able to see more information in inline mode?
>
> Thanks in advance, regards.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
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://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!