<div dir="ltr"><span style="font-size:12.8px">Victor (or any one else for that matter), do you have any guides or examples of how to set "best-practice" </span><span style="font-size:12.8px">traffic distributions with regards to Suricata processing? I have seen the same as described in this thread: Less output on live network analysis VS output playback of the same traffic.</span><br><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Scenario:</span></div><div><span style="font-size:12.8px">- A collection of VLANs aggreagted to a SPAN session, sent on two interfaces (each interface is monitored by different machines)</span></div><div><span style="font-size:12.8px">- Interface 1 is Suricata (only running IDS) and tcpdump to capture the data</span></div><div><span style="font-size:12.8px">- Interface 2 is tcpdump.</span></div><div><span style="font-size:12.8px">- pcaps from VM/Interface 1 and VM/Interface 2 are compared and found identical.</span></div><div><span style="font-size:12.8px">- Lots of RAM and CPU to go on, Tested on 10GBit/s and 1Gbit/s cards, with different drivers. Tested traffic was only at between 100 and 600Mbit/s.</span></div><div><span style="font-size:12.8px">- Found alerts of VM/Interface 1 (live listening mode) is compared to Suricata replay-pcap-mode of pcaps from VM/Interface 1 and VM/Interface 2</span></div><div><span style="font-size:12.8px">- Results indicate lower detection rate on the live running mode.</span></div><div><br></div><div>So, this traffic distribution / making sure that the same flow is sent to the correct thread, any pointers on that? cluster_cpu, cluster_flow, ethtool settings, os settings (linux/RHEL), etc?<br>I know its not a dirrectly associated sceniario, since the OP of the thread was with regards to Napatech cards, which my exaplained scenario was not utilizing.</div><div><br></div><div>TL;DR What i found nice to do, was to check the expected output (based on suricata -r mode) vs live capture mode, and comparing outputs, and not just blindly looking at the stats counters saying that there is no drop (either kernel, memcap, or other).</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-09 18:01 GMT+02:00 Victor Julien <span dir="ltr"><<a href="mailto:lists@inliniac.net" target="_blank">lists@inliniac.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09-10-15 17:15, Stephen Castellarin wrote:<br>
> Yes there still is progress to make.  Looking at CPU utilization through<br>
> SAR, for today I'm seeing an average of 88.86 %idle, so they're not<br>
> being overworked.  As far as memory consumption, stats are showing I'm<br>
> using roughly 50gb of 128gb available.  So I know I have plenty of<br>
> breathing room from the hardware's perspective.<br>
<br>
One thing to check is how the card does the traffic distributions. You<br>
need to make sure all packets from a flow are delivered to the same<br>
Suricata thread. IIRC napatech cards give you a lot of control there.<br>
<br>
Cheers,<br>
Victor<br>
<br>
<br>
> To your point about the rules, I know I've stripped down a whole bunch<br>
> of the ETPRO rules - only sticking with the exploit, malware, scan,<br>
> trojan, current_events, web_server and web_specific_apps rules.  The<br>
> largest number of rules from that list are in the trojan.rules (~9763),<br>
> web_specific_apps.rules (~5603) and current_events.rules(~2505).  When I<br>
> cut down to that list of rule files from the full ETPRO rule list that<br>
> definitely cut out unnecessary stuff for us.  It's going to be real<br>
> tough to dig through the remainder to see what is pertinent to us and<br>
> what isn't.<br>
><br>
><br>
><br>
> On Friday, October 9, 2015 10:32 AM, Rob MacGregor<br>
<span class="">> <<a href="mailto:rob.macgregor@gmail.com">rob.macgregor@gmail.com</a>> wrote:<br>
><br>
><br>
> On Fri, Oct 9, 2015 at 3:05 PM Stephen Castellarin <<a href="mailto:castle1126@yahoo.com">castle1126@yahoo.com</a><br>
</span><span class="">> <mailto:<a href="mailto:castle1126@yahoo.com">castle1126@yahoo.com</a>>> wrote:<br>
><br>
>     Sorry for the quick reply yeaterday, I forgot to hit Reply All.<br>
><br>
>     As for the tuning, I know my current, underpowered Suricata system<br>
>     is missing events, as is my new hardware/configuration.  I base this<br>
>     on some attack traffic I saw from one IP yesterday.<br>
><br>
>     So our configuration is a front end router feeding an inline IPS<br>
>     which then is tapped - one tap to my old Suricata system and the<br>
>     second to my new Suricata system.  From a full take packet capture I<br>
>     see 45 attempts to issue malicious POST attempts to a webserver we<br>
>     have.  My original Suricata system triggered on 10 of those while my<br>
>     new Suricata triggered on 15.  I then took the pcap I extracted and<br>
>     ran it through Suricata on the new system and that system showed it<br>
>     trigger on all 45.  So that's giving me a feeling that I'm not<br>
>     tuning something correct - causing the running Suricata to miss things.<br>
><br>
><br>
> So, things are improving but there's still progress to make?<br>
><br>
> I'd look at things like CPU and RAM usage - are you maxing out your<br>
> CPUs/RAM?<br>
><br>
> Also, really look at those rules, are they really all relevant to your<br>
> network? Also, if you strip it down to just the rules that'd catch those<br>
> POST attempts, does it fire for every event?<br>
><br>
> --<br>
>  Rob<br>
><br>
><br>
><br>
><br>
</span>> _______________________________________________<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 4 & 5 in Barcelona: <a href="http://oisfevents.net" rel="noreferrer" target="_blank">http://oisfevents.net</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
---------------------------------------------<br>
Victor Julien<br>
<a href="http://www.inliniac.net/" rel="noreferrer" target="_blank">http://www.inliniac.net/</a><br>
PGP: <a href="http://www.inliniac.net/victorjulien.asc" rel="noreferrer" target="_blank">http://www.inliniac.net/victorjulien.asc</a><br>
---------------------------------------------<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 4 & 5 in Barcelona: <a href="http://oisfevents.net" rel="noreferrer" target="_blank">http://oisfevents.net</a><br>
</font></span></blockquote></div><br></div>