[Oisf-users] tcp.reassembly_gap
Luke Whitworth
l.a.whitworth at gmail.com
Tue Jan 26 10:32:37 UTC 2016
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:
Snort
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
GB 138.250.128.17 GB 138.250.13.32 ET TROJAN Downloader User-Agent
HTTPGET 9:35 AM
GB 138.250.5.215 DE 46.33.68.72 ET CURRENT_EVENTS Fake Virus
Phone Scam Landing Nov 16 9:41 AM
GB 138.250.72.201 -- 104.66.229.96 ET CURRENT_EVENTS Terse
alphanumeric executable downloader hig... 9:49 AM
Suricata
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} 138.250.4.235:63342 ->
115.159.15.29:80
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} 138.250.5.215:58869 -> 46.33.68.72:80
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}
138.250.72.201:65131 -> 104.66.229.96:80
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?
Cheers,
Luke
On 22 January 2016 at 12:12, Peter Manev <petermanev at gmail.com> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20160126/884cd449/attachment-0002.html>
More information about the Oisf-users
mailing list