[Oisf-users] Packet capture dump in unified2 logs.

[Nikolay Denev]

On Feb 16, 2012, at 4:10 PM, Nikolay Denev wrote:

> 
> On Feb 16, 2012, at 3:51 PM, Peter Manev wrote:
> 
>> 
>> 
>> On Thu, Feb 16, 2012 at 2:40 PM, Nikolay Denev <ndenev at gmail.com> wrote:
>> 
>> On Feb 15, 2012, at 5:03 PM, Peter Manev wrote:
>> 
>> >
>> > Ok,
>> > Just a couple of suggestions:
>> > 1. Make the MTU on the suricata box equal the MTU on the switch port where it is connected to.
>> 
>> 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.
>> 
>>  
>> Ok, I thought you have frames bigger than that...
>> > 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.
>> >
>> 
>> I was wrong, there are some untagged packets, but they are mirrored LACP and LLDP frames.
>> 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)
>> Suricata seems to handle this OK, probably ignores the vlan tag?
>> 
>> 
>>  
>> 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?
>>  
> 
> 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.
> 
> 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.
> 
>> > and if you could check that these two have any different effect ? ...
>> >
>> > thanks
>> >
>> > --
>> > Regards,
>> > Peter Manev
>> >
>> 
>> 
>> 
>> 
>> -- 
>> Regards,
>> Peter Manev
>> 
> 

Here are a few more alerts without payload :

+================
TIME:              02/20/2012-16:04:34.004598
SRC IP:            X.X.X.X
DST IP:            Y.Y.Y.Y
PROTO:             6
SRC PORT:          56946
DST PORT:          80
TCP SEQ:           3549381042
TCP ACK:           3077078161
FLOW:              to_server: TRUE, to_client: FALSE
FLOW Start TS:     02/20/2012-15:03:00.216065
FLOW IPONLY SET:   TOSERVER: TRUE, TOCLIENT: TRUE
FLOW ACTION:       DROP: FALSE, PASS FALSE
FLOW NOINSPECTION: PACKET: FALSE, PAYLOAD: FALSE, APP_LAYER: FALSE
FLOW APP_LAYER:    DETECTED: TRUE, PROTO 1
PACKET LEN:        0
PACKET:

ALERT CNT:           1
ALERT MSG [00]:      ET CURRENT_EVENTS HTTP Request to a *.co.cc domain
ALERT GID [00]:      1
ALERT SID [00]:      2011374
ALERT REV [00]:      5
ALERT CLASS [00]:    Potentially Bad Traffic
ALERT PRIO [00]:     2
ALERT FOUND IN [00]: OTHER
+================



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;)

Snorby is not even able to parse the SRC IP and DST IP from the alert.

I've also valid alerts from this rule, with packet and stream dump.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20120220/f4b66b29/attachment-0002.html>