<html><body><div style="color:#000; background-color:#fff; font-family:tahoma, new york, times, serif;font-size:10pt"><div><span><font><div style="font-size: 13px;">Exact command I am using is:</div><div style="font-size: 13px;"><span class="Apple-tab-span" style="white-space:pre">        </span>snort --daq dump --daq-var load-mode=read-file -Q -i eth0 -c etc/snort.conf </div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color: transparent; font-style: normal;">Fails to start with following error</div><div style="background-color: transparent;"><span style="font-size: 13px;"><span class="Apple-tab-span" style="white-space:pre">        </span>Can't initialize DAQ dump (-1) - eth0: No such file or directory</span><br></div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color: transparent; font-style: normal;">No typo issue as such, but its
 perhaps just that I am trying to run it from a device instead of a pcap file.</div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color: transparent; font-style: normal;"><span style="background-color: transparent;"><br></span></div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color: transparent; font-style: normal;"><span style="background-color: transparent;">Following works for me as desired:</span><br></div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color: transparent; font-style: normal;"><span class="Apple-tab-span" style="white-space:pre">      </span>snort --daq dump --daq-var load-mode=passive -Q -i eth0 -c etc/snort.conf<br></div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color: transparent;
 font-style: normal;"><br></div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color: transparent; font-style: normal;">Thanks file=/dev/null takes care of the dump file and disk saturation.</div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color: transparent; font-style: normal;"><br></div><div style="font-size: 13px;">I do get why normalization in general makes more sense for inline mode, but putting reassembly "first" seems to be something just not exclusive to inline mode.</div><div style="font-size: 13px;">Would be great if there was a config hook to enable/disable this in NIDS mode.</div><div style="font-size: 13px;">I guess its more of a matter of opinion :)</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color:
 transparent; font-style: normal;">Thanks for the help. </div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color: transparent; font-style: normal;">The promptness here is impressive and motivates me more to go the snort route for my current IDS and n/w traffic analysis needs.</div><div style="font-size: 13px;"><br></div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color: transparent; font-style: normal;">Thanks</div><div style="font-size: 13px; color: rgb(0, 0, 0); font-family: tahoma, 'new york', times, serif; background-color: transparent; font-style: normal;">Parmendra</div></font></span></div><div style="font-family: tahoma, 'new york', times, serif; font-size: 10pt;"><br></div>  <div style="font-family: tahoma, 'new york', times, serif; font-size: 10pt;"> <div style="font-family: 'times new roman', 'new york', times,
 serif; font-size: 12pt;"> <div dir="ltr"> <font size="2" face="Arial"> <hr size="1">  <b><span style="font-weight:bold;">From:</span></b> Russ Combs <rcombs@...402...><br> <b><span style="font-weight: bold;">To:</span></b> Parmendra Pratap <parmendra.pratap@...398...> <br><b><span style="font-weight: bold;">Cc:</span></b> "snort-devel@...424...eforge.net" <snort-devel@lists.sourceforge.net> <br> <b><span style="font-weight: bold;">Sent:</span></b> Monday, 8 April 2013 6:33 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [Snort-devel] HTTP Reassembly issue PAF enabled<br> </font> </div> <br>On Mon, Apr 8, 2013 at 12:51 PM, Parmendra Pratap<br><<a ymailto="mailto:parmendra.pratap@...398..." href="mailto:parmendra.pratap@...398...">parmendra.pratap@...1066....398...</a>> wrote:<br>> Instead of --daq dump --daq-var load-mode=read-file , I used --daq dump<br>> --daq-var load-mode=passive, as load_mode=read_file
 was not starting and<br>> looking for a file path.<br><br>Maybe just a typo, but that should be "load-mode=read-file" ( '-' not '_' ).<br>><br>> I can see its functionally working for sure as far as TCP headers and HTTP<br>> PDU reassembly is concerned.<br>><br>> There are couple of issues though - it creates a dump file, namely<br>> inline-pcap.out file which keeps growing until I run out of disk space.<br>> Isn't there a way to turn tcp normalization ON on without needing to dump<br>> pcap to file system.<br>> Performance seems to be OK but would defeinitely be desirable from my end to<br>> be able to do TCP normalization without needing to dump to the filesystem.<br>><br>> Is there a reason behind deactivating TCP Normalization in IDS mode?<br>><br>Yes - normalizations require inline operation.  No point changing a<br>packet if isn't being forwarded.  Also, stream5 tries to reassemble<br>the way the
 receiving host does.  This won't be the case if not<br>inline.<br><br>You can try something like --daq-var file=/dev/null if you don't want<br>to write the file.<br><br>> Regards<br>> Parmendra<br>><br>><br>> From: Russ Combs <<a ymailto="mailto:rcombs@...402..." href="mailto:rcombs@...402...">rcombs@...402...</a>><br>> To: Parmendra Pratap <<a ymailto="mailto:parmendra.pratap@...398..." href="mailto:parmendra.pratap@...398...">parmendra.pratap@...398...</a>><br>> Cc: "<a ymailto="mailto:snort-devel@lists.sourceforge.net" href="mailto:snort-devel@lists.sourceforge.net">snort-devel@lists.sourceforge.net</a>" <<a ymailto="mailto:snort-devel@lists.sourceforge.net" href="mailto:snort-devel@lists.sourceforge.net">snort-devel@lists.sourceforge.net</a>><br>> Sent: Monday, 8 April 2013 3:36 PM<br>><br>> Subject: Re: [Snort-devel] HTTP Reassembly issue PAF enabled<br>><br>> On Fri, Apr 5,
 2013 at 7:14 PM, Parmendra Pratap<br>> <<a ymailto="mailto:parmendra.pratap@...398..." href="mailto:parmendra.pratap@...398...">parmendra.pratap@...398...</a>> wrote:<br>>> Brilliant - Thanks Russ normalization on tcp sorts this out.<br>>> Just a a small note - I used load_mode=passive.<br>><br>> Not clear what you did but glad it works for you.<br>><br>>><br>>> So if I go it right with normalization on , reverse Ack is not awaited for<br>>> in S5 prior to flushing , rest is same and PAF still works as expected to<br>>> for supported protocols/preprocessors ?<br>><br>> Yes<br>>><br>>> Also , is there at all a flip side to running snort in "forced" inline<br>>> mode<br>>> on top pcap like this, performance wise may be?<br>><br>> --daq dump --daq-var load-mode=read-file will be slower than straight<br>> readback because it also writes to file all packets that
 weren't<br>> blocked as well as any injected packets.  Hopefully performance isn't<br>> the major concern in readback mode.<br>><br>>><br>>> Thanks<br>>> Parmendra<br>>><br>>> ________________________________<br>>> From: Russ Combs <<a ymailto="mailto:rcombs@...402..." href="mailto:rcombs@...402...">rcombs@...402...</a>><br>>> To: Parmendra Pratap <<a ymailto="mailto:parmendra.pratap@...398..." href="mailto:parmendra.pratap@...398...">parmendra.pratap@...398...</a>><br>>> Cc: "<a ymailto="mailto:snort-devel@...2859...sts.sourceforge.net" href="mailto:snort-devel@lists.sourceforge.net">snort-devel@lists.sourceforge.net</a>"<br>>> <<a ymailto="mailto:snort-devel@lists.sourceforge.net" href="mailto:snort-devel@...3137...e.net">snort-devel@lists.sourceforge.net</a>><br>>> Sent: Friday, 5 April 2013 5:15 PM<br>>> Subject: Re: [Snort-devel] HTTP
 Reassembly issue PAF enabled<br>>><br>>> On Fri, Apr 5, 2013 at 11:56 AM, Parmendra Pratap<br>>> <<a ymailto="mailto:parmendra.pratap@...398..." href="mailto:parmendra.pratap@...398...">parmendra.pratap@...398...</a>> wrote:<br>>>> Hi Hui<br>>>><br>>>> Thanks again for a quick response.<br>>>><br>>>> Have tried -Q flag , but since I am using Pcap DAQ it fails to start with<br>>>> -Q<br>>>> set.<br>>>> However it does start wiith --test-inline mode , which I assume works no<br>>>> different from -Q except that drops are not enabled.<br>>><br>>> Actually, normalizations are not enabled in that case.  You should see<br>>> something like this in your startup output:<br>>><br>>> WARNING: tcp normalizations disabled because not inline.<br>>><br>>> Try running with:<br>>><br>>> --daq dump --daq-var
 load-mode=read-file -Q<br>>><br>>>> My snort.conf does have preprocessor normalize_tcp: ips have set.<br>>>><br>>>> But even with the above set up I can still replicate the same issue<br>>>> related<br>>>> to incorrect tcp flags.<br>>>> As I said before , I think it seems like a matter of setting the tcp<br>>>> header<br>>>> of the last packet that completes the PDU inside Packet->tcph->th_flags<br>>>> in<br>>>> the s5 preprocessor when doing a PAF based flushing.<br>>>> I can see that the direction i.e. sourceIP/port and destIP/port being<br>>>> reversed for the same reason in the Packet struct when doing a reassembly<br>>>> based flushing from s5.<br>>>><br>>>> Thanks<br>>>> Parmendra<br>>>><br>>>><br>>>>
 __________________________________________________________________________<br>>>><br>>>> Hi Parmendra,<br>>>><br>>>> To be clear, you must use IPS mode to get what you want, so you need to<br>>>> 1) use -Q  when you run snort<br>>>> 2) Enable Normalization for TCP:<br>>>><br>>>> preprocessor normalize_tcp: ips<br>>>><br>>>> Best,<br>>>> Hui.<br>>>> On 04/04/2013 08:25 AM, Parmendra Pratap wrote:<br>>>>> Hi Hui<br>>>>> Thanks for a quick reply.<br>>>>> I tried the use case with Snort 2.9.4.5.<br>>>>> Does not make a difference.<br>>>>> Issue is still replicable with the steps outlined in my root email.<br>>>>> This is what I think is going on , based on few tests and source<br>>>>> lookups <excuse my newbieness if it reflects anywhere below :)
 >-<br>>>>> Stream5 reassembly does not tag a packet as complete PDU until it<br>>>>> recieves subsequent ack gainst the packet no matter wheter or not the<br>>>>> packet actually holds complete PDU  (in this case HTTP) or not.<br>>>>> With PAF enabled this prevents the URI Bufs from being created and<br>>>>> inspected in HTTP inspect module until the next packet arrives (ie ack<br>>>>> against the original packet that contained the HTTP req).<br>>>>> When the HTTP inspect URI Bufs based match fires, with PAF ON,  its<br>>>>> always(mostly?) when the ack on reverse direction is received.<br>>>>> The spo_alert* modules simply uses the header data provided in the<br>>>>> Packet->tcph which holds the header from the current packet ie ack<br>>>>> packet from the server ... and hence the incorrect TCP header
 display<br>>>>> with PAF on.<br>>>>> There is no way curently to get the correct TCP headers unless Stream<br>>>>> 5 is queried to give the original raw packet <spo_log_tcp_dump.c does<br>>>>> that>.<br>>>>> Realworld issue arising from the above is incorrect TCP header data in<br>>>>> alerts. TCP dumps are OK though for reason mentioned above.<br>>>>> There seems multiple ways to get around this:<br>>>>> Generate TCP dump on all alerts and assume the alerts will have<br>>>>> incorrect TCP headers<br>>>>> Write an alert output plugin that inspects the raw packet for correct<br>>>>> TCP headers etc<br>>>>> Add more metadata to Packet struct which can provide the correct TCP<br>>>>> headers at least for the last packet that completed the PDU in the<br>>>>> alert output
 plugins.<br>>>>> Last option looks the most organic and least sub optimal one to me.<br>>>>> Given my little experience with snort so far , I wont be surprised if<br>>>>> any of the above stated flow is incorrect.<br>>>>> I will more than appreciate if someone can correct me above and<br>>>>> enlighten me more about the internals :) .<br>>>>> Thanks<br>>>>> Parmendra<br>>>>><br>>>><br>>>><br>>>><br>>>><br>>>> ------------------------------------------------------------------------------<br>>>> Minimize network downtime and maximize team effectiveness.<br>>>> Reduce network management and security costs.Learn how to hire<br>>>> the most talented Cisco Certified professionals. Visit the<br>>>> Employer Resources Portal<br>>>> <a
 href="http://www.cisco.com/web/learning/employer_resources/index.html" target="_blank">http://www.cisco.com/web/learning/employer_resources/index.html</a><br>>>> _______________________________________________<br>>>> Snort-devel mailing list<br>>>> <a ymailto="mailto:Snort-devel@lists.sourceforge.net" href="mailto:Snort-devel@...424...eforge.net">Snort-devel@lists.sourceforge.net</a><br>>>> <a href="https://lists.sourceforge.net/lists/listinfo/snort-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-devel</a><br>>>> Archive:<br>>>> <a href="http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel" target="_blank">http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel</a><br>>>><br>>>> Please visit <a href="http://blog.snort.org/" target="_blank">http://blog.snort.org/</a> for the latest news about
 Snort!<br>>><br>>><br>><br>><br><br><br> </div> </div>  </div></body></html>