<div dir="ltr"><div><div><div>Still sadly seeing some gaps in detection on Suricata that I'm not seeing in Snort on this host. Both Snort and Suricata are pulling from pfring, running side by side on the same server. If I check detections side by side:<br><br>Snort<br>GB 138.250.4.235 CN 140.207.217.32 ET TROJAN Possible Win32/Hupigon ip.txt with a Non-Mozilla UA 9:15 AM<br>GB 138.250.128.17 GB 138.250.13.32 ET TROJAN Downloader User-Agent HTTPGET 9:35 AM<br>GB 138.250.5.215 DE 46.33.68.72 ET CURRENT_EVENTS Fake Virus Phone Scam Landing Nov 16 9:41 AM<br>GB 138.250.72.201 -- 104.66.229.96 ET CURRENT_EVENTS Terse alphanumeric executable downloader hig... 9:49 AM<br><br>Suricata<br>01/26/2016-09:15:14.166186 [**] [1:2016950:2] ET TROJAN Possible Win32/Hupigon ip.txt with a Non-Mozilla UA [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} <a href="http://138.250.4.235:63342">138.250.4.235:63342</a> -> <a href="http://115.159.15.29:80">115.159.15.29:80</a><br>01/26/2016-09:41:37.799048 [**] [1:2022103:2] ET CURRENT_EVENTS Fake Virus Phone Scam Landing Nov 16 [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} <a href="http://138.250.5.215:58869">138.250.5.215:58869</a> -> <a href="http://46.33.68.72:80">46.33.68.72:80</a><br>01/26/2016-09:49:24.287326 [**] [1:2019714:3] ET CURRENT_EVENTS Terse alphanumeric executable downloader high likelihood of being hostile [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} <a href="http://138.250.72.201:65131">138.250.72.201:65131</a> -> <a href="http://104.66.229.96:80">104.66.229.96:80</a><br><br></div>So for some reason Snort managed to detect the event at 9:35 AM that Suricata didn't. I'm having a bit of trouble getting to the bottom of why this might be the case. Does anyone have any suggestions for me where to start?<br><br></div>Cheers,<br><br></div>Luke<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 22 January 2016 at 12:12, 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"><span class="">On Fri, Jan 22, 2016 at 12:20 PM, Luke Whitworth<br>
<<a href="mailto:l.a.whitworth@gmail.com">l.a.whitworth@gmail.com</a>> wrote:<br>
> Cheers Peter,<br>
><br>
> I wasn't actually using 3.0RC3, however having read a bit about it<br>
> (specifically the pf_ring improvements) I've just switched both monitors<br>
> over to it anyway. I've also made the config change you suggested and the<br>
> stats are certainly a lot more readable now!<br>
><br>
> As the reassembly gaps are a fact of life I'll just keep looking into why<br>
> the snort sensors are alerting on items that Suricata isn't. Suricata does<br>
> see stuff that the Snort sensors don't as well, so it's a bit of a good news<br>
> bad news situation at present!<br>
<br>
</span>Ok.<br>
Please let us know if you need any help or have some new findings.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Thanks,<br>
><br>
> Luke<br>
><br>
> On 22 January 2016 at 10:50, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> wrote:<br>
>><br>
>> 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<br>
>> > stupid<br>
>> > questions!<br>
>> ><br>
>> > I'm hoping to replace some Snort monitors with Suricata. I've got<br>
>> > 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<br>
>> > still<br>
>> > see events that Suricata doesn't, which at the minute I'm putting down<br>
>> > 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<br>
>> > unsure<br>
>> > why I only see 9 in my stats.log when there's 24 threads running:<br>
>> > 20/1/2016<br>
>> > -- 15:48:36 - <Notice> - all 24 packet processing threads, 3 management<br>
>> > threads initialized, engine started.).<br>
>><br>
>> 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>
>><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>
>><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,<br>
>> > 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<br>
>> > 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>
>> 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:<br>
>> > <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/support/</a><br>
>> > List:<br>
>> > <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>
>><br>
>><br>
>><br>
>> --<br>
>> Regards,<br>
>> Peter Manev<br>
><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Regards,<br>
Peter Manev<br>
</font></span></blockquote></div><br></div>