Snort mailing list archives
Re: Stream5 issue
From: Emiliano Fausto <emiliano.fausto () gmail com>
Date: Sat, 28 Mar 2015 10:29:51 -0300
Hello Arun, I'd suggest you to read this article: http://blog.securityonion.net/2011/10/when-is-full-packet-capture-not-full.html I had similar troubles too some time ago because of it. Also depending on what you are trying to capture, this option could also be influencing the capture: -k *checksum-mode* Controls which packet checksums Snort computes and verifies. Valid checksum modes include all, noip, notcp, noudp, noicmp, and none. This can be used to eliminate packets that fail their checksums - caused either by network faults or IDS evasion attempts Maybe if your checksum is known to fail, you may put: "-k none" Hope it helps!! Regards, Emiliano. On Sat, Mar 28, 2015 at 1:34 AM, Arun Koshal <akoshal04 () gmail com> wrote:
Hi, I have written a dynamic preprocessor for inspecting some custom application. This dynamic preprocessor depends on stream5 preprocessor from getting the TCP stream. I am using snort in PCAP mode. I am facing following very strange problems - 1. The data in the rebuilt stream given by stream5 does not match with the TCP sequence number. For example - for a given TCP packet the sequence number in packet (pkt->tcp_header->sequence) is 507351850, but the data in pkt->payload is actually same as that of some old packet, having TCP sequence number 507343162. This scenario happens in case there are lot of packets getting dropped. I confirmed this with wireshark packet capture and I have observed multiple such instances. I also noticed that I am getting all the packets in the same buffer (pkt->payload remains same for all packets). So it seems like that I am getting a new packet with new header but old data. If I configure the pcap buffer_size as 512MB, the packets do not drop and this problem does not happen. 2. The second problem that I faced was with the pcap snap_len. In my setup, I had snort running with default pcap snap_len. I noticed that snort was not receiving packets having 1448 bytes data (1500 bytes, excluding Ethernet header). On reducing the MTU of the traffic generator from 1500 to 1484, Snort started receiving those packets. As a workaround, I increased the snap_len in sfdaq.c to 1546. Is this behaviour correct? It would be really great if someone can provide some inputs on these issues. Thanks and regards. Arun ------------------------------------------------------------------------------ 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-devel mailing list Snort-devel () lists sourceforge net https://lists.sourceforge.net/lists/listinfo/snort-devel Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel Please visit http://blog.snort.org for the latest news about Snort!
------------------------------------------------------------------------------ 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-devel mailing list Snort-devel () lists sourceforge net https://lists.sourceforge.net/lists/listinfo/snort-devel Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel Please visit http://blog.snort.org for the latest news about Snort!
Current thread:
- Stream5 issue Arun Koshal (Mar 27)
- Re: Stream5 issue Emiliano Fausto (Mar 28)
- Re: Stream5 issue Arun Koshal (Mar 30)
- Re: Stream5 issue Emiliano Fausto (Mar 30)
- Re: Stream5 issue Arun Koshal (Mar 31)
- Re: Stream5 issue Arun Koshal (Mar 30)
- Re: Stream5 issue Emiliano Fausto (Mar 28)