<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 16, 2012, at 4:10 PM, Nikolay Denev wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 16, 2012, at 3:51 PM, Peter Manev wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br>
<div class="gmail_quote">On Thu, Feb 16, 2012 at 2:40 PM, Nikolay Denev <span dir="ltr"><<a href="mailto:ndenev@gmail.com">ndenev@gmail.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div class="im"><br>On Feb 15, 2012, at 5:03 PM, Peter Manev wrote:<br><br>><br>> Ok,<br>> Just a couple of suggestions:<br>> 1. Make the MTU on the suricata box equal the MTU on the switch port where it is connected to.<br>
<br></div>I don't think this is an issue, as all of the other ports are not jumbo frames enabled, and I don't have frames bigger than 1522 bytes.<br>
<div class="im"><br></div></blockquote>
<div> </div>
<div>Ok, I thought you have frames bigger than that...</div>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">
<div class="im">> 2. The interface that Suricata listens on (ex. eth0) , does it have all the VLANs untagged there? Or some are tagged and some untagged? Because if not - that might a problem.<br>><br><br></div>I was wrong, there are some untagged packets, but they are mirrored LACP and LLDP frames.<br>
All the IP traffic from the mirrored ports is QinQ tagged, with the outer tag with VLAN 0 and the inner with the actual vlan being mirrored (all the ports that I mirror have only VLAN tagged traffic)<br>Suricata seems to handle this OK, probably ignores the vlan tag?<br>
<div class="HOEnZb">
<div class="h5"><br><br></div></div></blockquote>
<div> </div>
<div>In that case the only discrepancy I see is the reported length of the packet in Suricata and Snorby - to me it looks like Suri reports it correctly (debug log), but Snorby does not. I can not be sure because from what I saw as a screen shot of Snorby , the packet has the same SEQ and ACK number - kind of strange, and the SEQ or ACK number there does not much the one in debug log.... can you please confirm that?</div>
<div> </div></div></blockquote><div><br></div><div>Yep, this is what I'm seeing too. I have to probably see what exactly is in the unified2 log. Cause after suricata logs it, then it is touched by barnyard2 and then imported into the snorby mysql db, then snorby displays the alert, so there are other places that can break things.</div><div><br></div><div>Speaking of this, does anybody know a tool to display unified2 logs? I've found a perl module but it seems to not properly display the packet dump.</div><br><blockquote type="cite"><div class="gmail_quote">
<blockquote style="border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; padding-left: 1ex; position: static; z-index: auto; " class="gmail_quote">
<div class="HOEnZb">
<div class="h5">> and if you could check that these two have any different effect ? ...<br>><br>> thanks<br>><br>> --<br>> Regards,<br>> Peter Manev<br>><br><br></div></div></blockquote></div><br>
<br clear="all"><br>-- <br>
<div>Regards,</div>
<div>Peter Manev</div><br>
</blockquote></div><br></div></blockquote></div><br><div>Here are a few more alerts without payload :</div><div><br></div><div><div>+================</div><div>TIME: 02/20/2012-16:04:34.004598</div><div>SRC IP: X.X.X.X</div><div>DST IP: Y.Y.Y.Y</div><div>PROTO: 6</div><div>SRC PORT: 56946</div><div>DST PORT: 80</div><div>TCP SEQ: 3549381042</div><div>TCP ACK: 3077078161</div><div>FLOW: to_server: TRUE, to_client: FALSE</div><div>FLOW Start TS: 02/20/2012-15:03:00.216065</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: 0</div><div>PACKET:</div><div><br></div><div>ALERT CNT: 1</div><div>ALERT MSG [00]: ET CURRENT_EVENTS HTTP Request to a *.co.cc domain</div><div>ALERT GID [00]: 1</div><div>ALERT SID [00]: 2011374</div><div>ALERT REV [00]: 5</div><div>ALERT CLASS [00]: Potentially Bad Traffic</div><div>ALERT PRIO [00]: 2</div><div>ALERT FOUND IN [00]: OTHER</div><div>+================</div></div><div><br></div><div><br></div><div><br></div><div>Here's the rule that triggered them : alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET CURRENT_EVENTS HTTP Request to a *.co.cc domain"; flow: to_server,established; content:".co.cc|0D 0A|"; http_header; classtype:bad-unknown; sid:2011374; rev:5;)</div><div><br></div><div>Snorby is not even able to parse the SRC IP and DST IP from the alert.</div><div><br></div><div>I've also valid alerts from this rule, with packet and stream dump.</div></body></html>