[Oisf-users] tcp.reassembly_gap

[Peter Manev]

On Fri, Jan 22, 2016 at 12:20 PM, Luke Whitworth
<l.a.whitworth at gmail.com> wrote:
> Cheers Peter,
>
> I wasn't actually using 3.0RC3, however having read a bit about it
> (specifically the pf_ring improvements) I've just switched both monitors
> over to it anyway.  I've also made the config change you suggested and the
> stats are certainly a lot more readable now!
>
> As the reassembly gaps are a fact of life I'll just keep looking into why
> the snort sensors are alerting on items that Suricata isn't.  Suricata does
> see stuff that the Snort sensors don't as well, so it's a bit of a good news
> bad news situation at present!

Ok.
Please let us know if you need any help or have some new findings.

>
> Thanks,
>
> Luke
>
> On 22 January 2016 at 10:50, Peter Manev <petermanev at gmail.com> wrote:
>>
>> On Fri, Jan 22, 2016 at 10:13 AM, Luke Whitworth
>> <l.a.whitworth at gmail.com> wrote:
>> > Hi all,
>> >
>> > I'm pretty new to Suricata so please forgive me if I'm about to ask
>> > stupid
>> > questions!
>> >
>> > I'm hoping to replace some Snort monitors with Suricata.  I've got
>> > Suricata
>> > setup in workers mode using pf_ring:
>> >
>> > pfring:
>> >   - interface: eth0;eth1
>> >     threads: 24
>> >     cluster-id: 39
>> >     cluster-type: cluster_flow
>> >
>> > I'm seeing what I'd hope to see, no kernel drops:
>> >
>> > -------------------------------------------------------------------
>> > Date: 1/20/2016 -- 16:08:16 (uptime: 0d, 00h 19m 58s)
>> > -------------------------------------------------------------------
>> > Counter                   | TM Name                   | Value
>> > -------------------------------------------------------------------
>> > capture.kernel_packets    | RxPFReth0;eth11           | 27716639
>> > capture.kernel_drops      | RxPFReth0;eth11           | 0
>> >
>> > However occasionally the Snort monitor (running on the same box) will
>> > still
>> > see events that Suricata doesn't, which at the minute I'm putting down
>> > to:
>> >
>> > tcp.reassembly_gap        | RxPFReth0;eth11           | 408
>> > tcp.reassembly_gap        | RxPFReth0;eth12           | 160
>> > tcp.reassembly_gap        | RxPFReth0;eth13           | 26
>> > tcp.reassembly_gap        | RxPFReth0;eth14           | 32
>> > tcp.reassembly_gap        | RxPFReth0;eth15           | 35
>> > tcp.reassembly_gap        | RxPFReth0;eth16           | 27
>> > tcp.reassembly_gap        | RxPFReth0;eth17           | 18
>> > tcp.reassembly_gap        | RxPFReth0;eth18           | 31
>> > tcp.reassembly_gap        | RxPFReth0;eth19           | 23
>> >
>> > Granted I might be getting the wrong end of the stick here (I'm also
>> > unsure
>> > why I only see 9 in my stats.log when there's 24 threads running:
>> > 20/1/2016
>> > -- 15:48:36 - <Notice> - all 24 packet processing threads, 3 management
>> > threads initialized, engine started.).
>>
>> If not mistaken you are running the latest git master or 3.0RC3 - by
>> default when it comes to stats if there are "0" counters they will not
>> be shown.
>> To change that you can un-comment -
>>
>> #null-values: yes
>> in the stats log section, please see reference link below:
>>
>> https://redmine.openinfosecfoundation.org/projects/suricata/repository/revisions/master/entry/suricata.yaml.in#L31
>>
>> >
>> > Other (hopefully) relevant parts of Suricata.yml:
>> >
>> > flow:
>> >   # memcap: 128mb
>> >   memcap: 8gb
>> >   # hash-size: 65536
>> >   hash-size: 131072
>> >   # prealloc: 10000
>> >   prealloc: 50000
>> >   emergency-recovery: 30
>> >
>> > stream:
>> >   memcap: 12gb
>> >   prealloc-sessions: 2500000  # Added by LW
>> >   # checksum-validation: yes      # reject wrong csums
>> >   checksum-validation: no      # reject wrong csums
>> >   inline: auto                  # auto will use inline mode in IPS mode,
>> > yes
>> > or no set it statically
>> >   reassembly:
>> >     #memcap: 128mb
>> >     memcap: 24gb
>> >     depth: 6mb                  # reassemble 1mb into a stream
>> >     toserver-chunk-size: 2560
>> >     toclient-chunk-size: 2560
>> >     randomize-chunk-size: yes
>> >
>> > The box has 32GB of RAM and a couple of Intel® Xeon® Processor X5690
>> > CPUs
>> > (Hex core, dual thread, hence the 24 threads for pf_ring).
>> >
>> > Am I looking along the right lines?  Am I expecting the impossible for
>> > tcp.reassembly_gap to be 0?
>>
>>
>> Unfortunately reassembly gaps do exist and most of the time they have
>> nothing to do with Suricata but rather other actors are responsible
>> like  unseen retransmission's , drops at the mirror port etc..
>>
>> >
>> > Cheers,
>> >
>> > Luke
>> >
>> > _______________________________________________
>> > Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>> > Site: http://suricata-ids.org | Support:
>> > http://suricata-ids.org/support/
>> > List:
>> > https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>> > Suricata User Conference November 9-11 in Washington, DC:
>> > http://oisfevents.net
>>
>>
>>
>> --
>> Regards,
>> Peter Manev
>
>



-- 
Regards,
Peter Manev