<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 15, 2012, at 12:53 PM, Victor Julien wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 02/15/2012 10:26 AM, Nikolay Denev wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Feb 15, 2012, at 10:07 AM, Victor Julien wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On 02/15/2012 06:42 AM, Nikolay Denev wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi,<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I'm wondering how suricata decides which packet to capture and dump<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">in the unified2 log file and which not to.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I'm running Snorby to collect the alerts, and I've noticed that<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">sometimes for a single rule, some of the alerts have<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">the packet dump present and some not.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">That is odd. There should always be a packet. Is this happening with<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">specific rules and / or traffic?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">I've checked now. Some of the alerts without packet dump are packets<br></blockquote><blockquote type="cite">with only headers and no payload, <br></blockquote><blockquote type="cite">for example syn packets from RBN listed IPs. Which should be normal. But<br></blockquote><blockquote type="cite">I have also alert from this rule:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ETPRO TROJAN<br></blockquote><blockquote type="cite">Win32/Chir.B@mm User-Agent (KPeerUpdater)"; flow:to_server,established;<br></blockquote><blockquote type="cite">content:"User-Agent|3a| KPeerUpdater|0d 0a|"; http_header;<br></blockquote><blockquote type="cite">reference:url,<a href="http://www.threatexpert.com/report.aspx?md5=5ca614132b183b2812cb69112879237f">www.threatexpert.com/report.aspx?md5=5ca614132b183b2812cb69112879237f</a><br></blockquote><blockquote type="cite"><<a href="http://www.threatexpert.com/report.aspx?md5=5ca614132b183b2812cb69112879237f">http://www.threatexpert.com/report.aspx?md5=5ca614132b183b2812cb69112879237f</a>>;<br></blockquote><blockquote type="cite">reference:url,<a href="http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Worm%3AWin32%2FChir.B%40mm">www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Worm%3AWin32%2FChir.B%40mm</a><br></blockquote><blockquote type="cite"><<a href="http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Worm%3AWin32%2FChir.B%40mm">http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Worm%3AWin32%2FChir.B%40mm</a>>;<br></blockquote><blockquote type="cite">classtype:trojan-activity; sid:2803871; rev:2;)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">And in snorby I see no packet dump, and packet len is 40?<br></blockquote><br>Might be the ACK packet triggering the reassembly. Still should have<br>logged the packet I think.<br><br>Can you enable the alert-debug.log in Suricata for a while? When you see<br>this issue again, see what it logs.<br><br>Btw, in your screen shot the SEQ and ACK values are the same. That seems<br>unusual as well.<br><br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">I can also look in the unified2.alert file to make sure it's not snorby<br></blockquote><blockquote type="cite">problem. (if I can find some tool to check it :) )<br></blockquote><blockquote type="cite"><br></blockquote><br>Let's focus on what Suricata does right now. We've had issues with<br>unified2 in the past.<br><br>-- <br>---------------------------------------------<br>Victor Julien<br><a href="http://www.inliniac.net/">http://www.inliniac.net/</a><br>PGP: http://www.inliniac.net/victorjulien.asc<br>---------------------------------------------<br><br></div></blockquote><br></div><div>Here's one such alert, but there is packet data in the alert-debug file : (also packet len differs, maybe snorby issue?)</div><div><br></div><div><div>+================</div><div>TIME: 02/15/2012-13:18:15.459170</div><div>SRC IP: X.X.X.X</div><div>DST IP: Y.Y.Y.Y</div><div>PROTO: 6</div><div>SRC PORT: 55192</div><div>DST PORT: 80</div><div>TCP SEQ: 1360766462</div><div>TCP ACK: 1891794325</div><div>FLOW: to_server: TRUE, to_client: FALSE</div><div>FLOW Start TS: 02/15/2012-13:18:15.017736</div><div>FLOW IPONLY SET: TOSERVER: TRUE, TOCLIENT: TRUE</div><div>FLOW ACTION: DROP: FALSE, PASS FALSE</div><div>FLOW NOINSPECTION: PACKET: FALSE, PAYLOAD: FALSE, APP_LAYER: FALSE</div><div>FLOW APP_LAYER: DETECTED: TRUE, PROTO 1</div><div>PACKET LEN: 68</div><div>PACKET:</div><div> 0000 02 04 96 37 53 8D F0 DE F1 95 DF F7 81 00 00 00 ...7S... ........</div><div> 0010 81 00 00 70 08 00 45 00 00 28 1E 3B 40 00 80 06 ...p..E. .(.;@...</div><div> 0020 AF 37 0A 81 15 24 6B 14 A2 A4 D7 98 00 50 51 1B .7...$k. .....PQ.</div><div> 0030 A5 FE 70 C2 7D 95 50 10 01 00 C4 1C 00 00 00 00 ..p.}.P. ........</div><div> 0040 00 00 00 00 ....</div><div>ALERT CNT: 1</div><div>ALERT MSG [00]: ETPRO POLICY dl.dropbox Download</div><div>ALERT GID [00]: 1</div><div>ALERT SID [00]: 2804233</div><div>ALERT REV [00]: 3</div><div>ALERT CLASS [00]: Potential Corporate Privacy Violation</div><div>ALERT PRIO [00]: 1</div><div>ALERT FOUND IN [00]: OTHER</div><div><br></div><div><br></div><div><img id="4021075a-60ab-452f-9eee-9fe1fef026b5" height="539" width="982" apple-width="yes" apple-height="yes" src="cid:8D4DAB9C-4F5A-4288-B6EB-5AA4FFE49C6B@moneybookers.net"></div></div><br></body></html>