[Oisf-users] rule understanding questions

[Victor Julien]

>> On 03/25/2013 02:45 PM, David wrote:
>>> Hi all!
>>>
>>> I finally have Suricata setup on my home network the way I want, with traffic being monitored via a passive tap.  I'm in the process of filtering the ET rules (I've currently enabled /all/ the rules, just because) so I'm not getting flooded with info.  Some of the alerts I'm getting I understand (SSH scan attacks, etc), however, there are a few I'm not sure of.  
>>>
>>> In the context of /what/ they are I understand (I understand the tcp 3-way handshake, for example). It's the context of /why/ I'm being alerted that's alluding me.
>>>
>>> 2210000 - SURICATA STREAM 3way handshake with ack in wrong dir 
>>> - I got over 3 million dings for this one while my wife was watching something on netflix.
>>>
>>> 2210010 - SURICATA STREAM 3way handshake wrong seq wrong ack
>>> - These all originate from my local external IP address, during the same "watching netflix" window of time. Over a million dings.
>>>
>>> 2210020 - SURICATA STREAM ESTABLISHED packet out of window
>>> - Same netflix window, about 500,000 dings
>>>
>>> 2210045 - SURICATA STREAM Packet with invalid ack
>>> - Again, netflix
>>>
>>> 2210029 - SURICATA STREAM ESTABLISHED invalid ack
>>> - Netflix, you jerk.  
>>>
>>> I've googled most of these, however, the results are generally links to the ET rulesets, not to anything that helps me understand what causes these alerts.  I've set some threshold rules for them, so I'm not flooding splunk with extreneous info.
>>>
>>> Can anyone point me in a direction where I can find out why these are being generated?
>>
>> What version of Suricata are you running? We improved this quite a bit
>> in 1.4.
>>
>> Are you seeing a lot of pkt loss? Maybe you can share a record of the
>> stats.log, this should give us an idea on that.
>>

On 03/25/2013 09:38 PM, David wrote:
> Perfect, here it is:
>
> Date: 3/24/2013 -- 00:34:55 (uptime: 2d, 03h 49m 59s)
> -------------------------------------------------------------------
> Counter                   | TM Name                   | Value
> -------------------------------------------------------------------
> capture.kernel_packets    | RxAFPeth11                | 5611583
> capture.kernel_drops      | RxAFPeth11                | 209
> capture.kernel_packets    | RxAFPeth21                | 9107856
> capture.kernel_drops      | RxAFPeth21                | 3575

You have some light loss reported by af_packet.

> tcp.memuse                | Detect                    | 18087936
> tcp.segment_memcap_drop   | Detect                    | 2391

Some more packets are not processed due to memory (memcap) constrains.
Try increasing stream.reassembly.memcap in your yaml.

> tcp.reassembly_memuse     | Detect                    | 33881088

If this is at or close to your memcap, increase the memcap further.

> tcp.reassembly_gap        | Detect                    | 840

This is an indicator for packet loss, caused both by real loss, and
rejected packets because of memcap, checksums, etc. Ideally this is 0
during normal operations.

Cheers,
Victor

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------