[Oisf-users] Discrepancies in Snort and Suricata alerts

[fatema bannatwala]

Had a quick question regarding using pf_ring, I think I am doing something
wrong:
So in the suricata.yaml it says:

"#Number of receive threads (>1 will enable experimental flow pinned
runmode)"
  #threads: 1

And I am using 18 as the threads value here in pf_ring section. So should I
change it to 1?

Also, I am running kernel Linux 3.10 and for h/w NIC based RSS hashing it
requires at least  Linux 3.14, so I can't use it unless I upgrade the
kernel.
But I think if I can set the pf_ring the correct way it should work.
Do I have to undo the ethtool settings mentioned in Septune to use pf_ring
over af_packet? I believe those settings were mentioned for using af_packet
and shouldn't be needed/set for pf_ring?

Thanks,
Fatema

On Tue, Oct 16, 2018 at 1:30 PM fatema bannatwala <
fatema.bannatwala at gmail.com> wrote:

> I tried with pf_ring, but couldn't get the "SearchProtect" (sid:2022813)
> to trigger still.
> Next I am going to try the hardware hashing and af_packet in qm mode and
> see if there's any difference, will keep posted..
>
> On Fri, Oct 12, 2018 at 2:45 PM Michał Purzyński <
> michalpurzynski1 at gmail.com> wrote:
>
>> After talking a bit more with Fatema, we learned there might be a problem
>> with the kernel version on that server.
>>
>> Victor's patch shows 30% of packets sent to a wrong thread. Bro and Snort
>> use pf_ring.
>>
>> Suggestions would be to use hardware hashing and af_packet in QM mode.
>> Note - the XDP part is not needed for this setup to work.
>>
>> *https://github.com/pevma/SEPTun-Mark-II/blob/master/SEPTun-Mark-II.rst#setup-symmetric-hashing-on-the-nic
>> <https://github.com/pevma/SEPTun-Mark-II/blob/master/SEPTun-Mark-II.rst#setup-symmetric-hashing-on-the-nic>*
>>
>> just do the symmetric hashing part and then change Suricata's
>> configuration to use cluster_qm
>>
>>   cluster-type: cluster_qm # symmetric hashing  is a must!
>>
>>
>>
>>
>>
>> On Fri, Oct 5, 2018 at 2:20 PM Michał Purzyński <
>> michalpurzynski1 at gmail.com> wrote:
>>
>>> How about we make Suricata write us a pcap in afpacket workers mode? I’m
>>> pretty sure a rule can do that.
>>>
>>> > On Oct 5, 2018, at 8:17 PM, fatema bannatwala <
>>> fatema.bannatwala at gmail.com> wrote:
>>> >
>>> > Changing $HOME_NET to any in sid 2022813 didn't help though, still not
>>> getting that alert fired.
>>> > One difference I had in suricata.yaml when running in offline pcap
>>> reading mode was, I set runmode to "single", while when suricata runs in
>>> packet sniffing mode it's set to "workers".
>>> >
>>> > I tried to set it to "runmode:single" while on interface sniffing mode
>>> but was hit by ~60% capture loss, which makes sense as single threaded
>>> suricata can't handle the traffic flowing through the interface.
>>> >
>>> > The fact that alerts are fired when in offline single threaded mode
>>> and same alerts are not fired when online packet sniffing multi-threaded
>>> mode, makes me think it has to do with multi-threading vs single threaded
>>> mode and how "workers" are capturing packets.
>>> >
>>> > I will keep looking.
>>> >
>>> > (The good thing is that Interrupt/IRQ pinning has helped to reduce
>>> capture loss to 0%)
>>> >
>>> > Thanks,
>>> > Fatema
>>> >
>>> >
>>> > _______________________________________________
>>> > 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
>>> >
>>> > Conference: https://suricon.net
>>> > Trainings: https://suricata-ids.org/training/
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20181016/f438c1d3/attachment-0001.html>