<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1444311546408_83104"><span>Hi Victor,</span></div><div id="yui_3_16_0_1_1444311546408_83104"><span><br></span></div><div id="yui_3_16_0_1_1444311546408_83104"><span id="yui_3_16_0_1_1444311546408_83743">I'm trying to understand what you meant by making "sure all packets from a flow are delivered to the same Suricata thread".</span></div><div id="yui_3_16_0_1_1444311546408_83104"><span><br></span></div><div id="yui_3_16_0_1_1444311546408_83104" dir="ltr"><span id="yui_3_16_0_1_1444311546408_83173">Right now I'm looking at the /proc/interrupts and it shows that CPU 1 is handling the interrupts for the Napatech card (based on lscpu NUMA node 1 is handling CPUs 1,3,5,7,9,11,13,15,17,19). I've set the Napatech card to assign its HostBuffersRx to NUMA node 1. Would it be wise to set the CPU affinity for receive, decode and stream-cpu-set to all the CPUs on NUMA node 1? And if so, then should I assign the detect-cpu-set to the other CPUs on NUMA node 0?<br><br>Steve</span></div> <br><div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"> <font size="2" face="Arial"> On Friday, October 9, 2015 12:01 PM, Victor Julien <lists@inliniac.net> wrote:<br> </font> </div> <br><br> <div class="y_msg_container">On 09-10-15 17:15, Stephen Castellarin wrote:<br clear="none">> Yes there still is progress to make. Looking at CPU utilization through<br clear="none">> SAR, for today I'm seeing an average of 88.86 %idle, so they're not<br clear="none">> being overworked. As far as memory consumption, stats are showing I'm<br clear="none">> using roughly 50gb of 128gb available. So I know I have plenty of<br clear="none">> breathing room from the hardware's perspective.<br clear="none"><br clear="none">One thing to check is how the card does the traffic distributions. You<br clear="none">need to make sure all packets from a flow are delivered to the same<br clear="none">Suricata thread. IIRC napatech cards give you a lot of control there.<br clear="none"><br clear="none">Cheers,<br clear="none">Victor<br clear="none"><br clear="none"><br clear="none">> To your point about the rules, I know I've stripped down a whole bunch<br clear="none">> of the ETPRO rules - only sticking with the exploit, malware, scan,<br clear="none">> trojan, current_events, web_server and web_specific_apps rules. The<br clear="none">> largest number of rules from that list are in the trojan.rules (~9763),<br clear="none">> web_specific_apps.rules (~5603) and current_events.rules(~2505). When I<br clear="none">> cut down to that list of rule files from the full ETPRO rule list that<br clear="none">> definitely cut out unnecessary stuff for us. It's going to be real<br clear="none">> tough to dig through the remainder to see what is pertinent to us and<br clear="none">> what isn't.<br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> On Friday, October 9, 2015 10:32 AM, Rob MacGregor<br clear="none">> <<a shape="rect" ymailto="mailto:rob.macgregor@gmail.com" href="mailto:rob.macgregor@gmail.com">rob.macgregor@gmail.com</a>> wrote:<br clear="none">> <br clear="none">> <br clear="none">> On Fri, Oct 9, 2015 at 3:05 PM Stephen Castellarin <<a shape="rect" ymailto="mailto:castle1126@yahoo.com" href="mailto:castle1126@yahoo.com">castle1126@yahoo.com</a><br clear="none">> <mailto:<a shape="rect" ymailto="mailto:castle1126@yahoo.com" href="mailto:castle1126@yahoo.com">castle1126@yahoo.com</a>>> wrote:<div class="yqt2922283843" id="yqtfd51804"><br clear="none">> <br clear="none">> Sorry for the quick reply yeaterday, I forgot to hit Reply All.<br clear="none">> <br clear="none">> As for the tuning, I know my current, underpowered Suricata system<br clear="none">> is missing events, as is my new hardware/configuration. I base this<br clear="none">> on some attack traffic I saw from one IP yesterday. <br clear="none">> <br clear="none">> So our configuration is a front end router feeding an inline IPS<br clear="none">> which then is tapped - one tap to my old Suricata system and the<br clear="none">> second to my new Suricata system. From a full take packet capture I<br clear="none">> see 45 attempts to issue malicious POST attempts to a webserver we<br clear="none">> have. My original Suricata system triggered on 10 of those while my<br clear="none">> new Suricata triggered on 15. I then took the pcap I extracted and<br clear="none">> ran it through Suricata on the new system and that system showed it<br clear="none">> trigger on all 45. So that's giving me a feeling that I'm not<br clear="none">> tuning something correct - causing the running Suricata to miss things.<br clear="none">> <br clear="none">> <br clear="none">> So, things are improving but there's still progress to make?<br clear="none">> <br clear="none">> I'd look at things like CPU and RAM usage - are you maxing out your<br clear="none">> CPUs/RAM?<br clear="none">> <br clear="none">> Also, really look at those rules, are they really all relevant to your<br clear="none">> network? Also, if you strip it down to just the rules that'd catch those<br clear="none">> POST attempts, does it fire for every event?<br clear="none">> <br clear="none">> -- <br clear="none">> Rob </div><br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> <br clear="none">> _______________________________________________<br clear="none">> Suricata IDS Users mailing list: <a shape="rect" ymailto="mailto:oisf-users@openinfosecfoundation.org" href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a><br clear="none">> Site: <a shape="rect" href="http://suricata-ids.org/" target="_blank">http://suricata-ids.org </a>| Support: <a shape="rect" href="http://suricata-ids.org/support/" target="_blank">http://suricata-ids.org/support/</a><br clear="none">> List: <a shape="rect" href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br clear="none">> Suricata User Conference November 4 & 5 in Barcelona: <a shape="rect" href="http://oisfevents.net/" target="_blank">http://oisfevents.net</a><br clear="none">> <br clear="none"><br clear="none"><br clear="none">-- <br clear="none">---------------------------------------------<br clear="none">Victor Julien<br clear="none"><a shape="rect" href="http://www.inliniac.net/" target="_blank">http://www.inliniac.net/</a><br clear="none">PGP: <a shape="rect" href="http://www.inliniac.net/victorjulien.asc" target="_blank">http://www.inliniac.net/victorjulien.asc</a><br clear="none">---------------------------------------------<br clear="none"><br clear="none">_______________________________________________<br clear="none">Suricata IDS Users mailing list: <a shape="rect" ymailto="mailto:oisf-users@openinfosecfoundation.org" href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a><br clear="none">Site: <a shape="rect" href="http://suricata-ids.org/" target="_blank">http://suricata-ids.org </a>| Support: <a shape="rect" href="http://suricata-ids.org/support/" target="_blank">http://suricata-ids.org/support/</a><br clear="none">List: <a shape="rect" href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br clear="none">Suricata User Conference November 4 & 5 in Barcelona: <a shape="rect" href="http://oisfevents.net/" target="_blank">http://oisfevents.net</a><div class="yqt2922283843" id="yqtfd46506"><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>