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