<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Steve.
<div class=""><br class="">
</div>
<div class="">The profiling tool is also good. Do you so equal packet drops on all hostbuffers, or is it just a few hostbuffers that show drops?</div>
<div class=""><br class="">
</div>
<div class="">The reason why I’m asking this is:</div>
<div class=""><br class="">
</div>
<div class=""> - if all hostbuffers drops approx. equal amount of packets I think it’s a mis-configuration of Suricata. Suricata is not taking of packets fast enough, and probably not threaded correctly to the hostbuffers.</div>
<div class=""> - if one or two hostbuffers are dropping packets, and some are not, it is probably the Suricata packet analyzer that is too busy. Meaning that too much traffic is coming in on the thread.</div>
<div class=""><br class="">
</div>
<div class="">As previously mentioned it can easily be the case that you have to many filters for the Suricata thread to process.</div>
<div class=""><br class="">
</div>
<div class="">You also have the option to prefilter the hostbuffers in order to ease the traffic on a hostbuffer.</div>
<div class=""><br class="">
</div>
<div class="">Best Regards</div>
<div class="">Jesper</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">On 14 Oct 2015, at 12:50, Steve <<a href="mailto:castle1126@yahoo.com" class="">castle1126@yahoo.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="auto" class="">
<div class="">Hi Jesper,</div>
<div class=""><br class="">
</div>
<div class="">Thank you for this. I worked with a local Napatech engineer to use NTPL to set up more streams (10), set up the 5-Tuple index and make sure those streams are tied to Numa 1 because of the interrupts seen in /proc/interrupts. He told me of the
'profiling' command which would show if there are any drops per stream - which there are. I've also been running the monitoring tool, which may be showing drops (I previously posted I had no drops looking at that tool, but I think I was viewing the stats
from that tool incorrectly).</div>
<div class=""><br class="">
</div>
<div class="">So based on your comments, seeing drops in each stream shows Suricata isn't configured appropriately to keep up with the host buffers. I've tried different worker configurations in suricata.yaml but no luck. Same goes for running with "autofp".
Each time I restart Suricata with a reconfigured yaml I see drops via the profiling tool in a short amount of time, and those drops grow in number.</div>
<div class=""><br class="">
</div>
<div class="">Do you have any suggestions on a way to configure?</div>
<div class=""><br class="">
</div>
<div class="">Thanks!!</div>
<div class=""><br class="">
On Oct 14, 2015, at 6:14 AM, Jesper Lyager Nielsen <<a href="mailto:jln@napatech.com" class="">jln@napatech.com</a>> wrote:<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div class="">Hi Steve.
<div class=""><br class="">
</div>
<div class="">I think what Victor means is that with a Napatech card you are able to distribute your traffic to different hostbuffers, fx based on a 5 tuple index. You can then have a Suricata thread for each hostbuffer, and hereby distribute your load.</div>
<div class=""><br class="">
</div>
<div class="">First thing I would check in your setup is if your ‘monitoring’ tool (default location: '/opt/napatech3/bin/monitoring’) are showing drops or errors. If that is the case Suricata is not taking packets of the Napatech hostbuffers fast enough.</div>
<div class=""><br class="">
</div>
<div class="">Best Regards</div>
<div class="">Jesper</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 13 Oct 2015, at 19:59, Stephen Castellarin <<a href="mailto:castle1126@yahoo.com" class="">castle1126@yahoo.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<div style="background-color: rgb(255, 255, 255); font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; font-size: 16px;" class="">
<div id="yui_3_16_0_1_1444311546408_83104" class=""><span class="">Hi Victor,</span></div>
<div id="yui_3_16_0_1_1444311546408_83104" class=""><span class=""><br class="">
</span></div>
<div id="yui_3_16_0_1_1444311546408_83104" class=""><span id="yui_3_16_0_1_1444311546408_83743" class="">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" class=""><span class=""><br class="">
</span></div>
<div id="yui_3_16_0_1_1444311546408_83104" dir="ltr" class=""><span id="yui_3_16_0_1_1444311546408_83173" class="">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 class="">
<br class="">
Steve</span></div>
<br class="">
<div class="qtdSeparateBR"><br class="">
<br class="">
</div>
<div class="yahoo_quoted" style="display: block;">
<div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" class="">
<div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" class="">
<div dir="ltr" class=""><font size="2" face="Arial" class="">On Friday, October 9, 2015 12:01 PM, Victor Julien <<a href="mailto:lists@inliniac.net" class="">lists@inliniac.net</a>> wrote:<br class="">
</font></div>
<br class="">
<br class="">
<div class="y_msg_container">On 09-10-15 17:15, Stephen Castellarin wrote:<br clear="none" class="">
> Yes there still is progress to make. Looking at CPU utilization through<br clear="none" class="">
> SAR, for today I'm seeing an average of 88.86 %idle, so they're not<br clear="none" class="">
> being overworked. As far as memory consumption, stats are showing I'm<br clear="none" class="">
> using roughly 50gb of 128gb available. So I know I have plenty of<br clear="none" class="">
> breathing room from the hardware's perspective.<br clear="none" class="">
<br clear="none" class="">
One thing to check is how the card does the traffic distributions. You<br clear="none" class="">
need to make sure all packets from a flow are delivered to the same<br clear="none" class="">
Suricata thread. IIRC napatech cards give you a lot of control there.<br clear="none" class="">
<br clear="none" class="">
Cheers,<br clear="none" class="">
Victor<br clear="none" class="">
<br clear="none" class="">
<br clear="none" class="">
> To your point about the rules, I know I've stripped down a whole bunch<br clear="none" class="">
> of the ETPRO rules - only sticking with the exploit, malware, scan,<br clear="none" class="">
> trojan, current_events, web_server and web_specific_apps rules. The<br clear="none" class="">
> largest number of rules from that list are in the trojan.rules (~9763),<br clear="none" class="">
> web_specific_apps.rules (~5603) and current_events.rules(~2505). When I<br clear="none" class="">
> cut down to that list of rule files from the full ETPRO rule list that<br clear="none" class="">
> definitely cut out unnecessary stuff for us. It's going to be real<br clear="none" class="">
> tough to dig through the remainder to see what is pertinent to us and<br clear="none" class="">
> what isn't.<br clear="none" class="">
> <br clear="none" class="">
> <br clear="none" class="">
> <br clear="none" class="">
> On Friday, October 9, 2015 10:32 AM, Rob MacGregor<br clear="none" class="">
> <<a shape="rect" ymailto="mailto:rob.macgregor@gmail.com" href="mailto:rob.macgregor@gmail.com" class="">rob.macgregor@gmail.com</a>> wrote:<br clear="none" class="">
> <br clear="none" class="">
> <br clear="none" class="">
> On Fri, Oct 9, 2015 at 3:05 PM Stephen Castellarin <<a shape="rect" ymailto="mailto:castle1126@yahoo.com" href="mailto:castle1126@yahoo.com" class="">castle1126@yahoo.com</a><br clear="none" class="">
> <mailto:<a shape="rect" ymailto="mailto:castle1126@yahoo.com" href="mailto:castle1126@yahoo.com" class="">castle1126@yahoo.com</a>>> wrote:
<div class="yqt2922283843" id="yqtfd51804"><br clear="none" class="">
> <br clear="none" class="">
> Sorry for the quick reply yeaterday, I forgot to hit Reply All.<br clear="none" class="">
> <br clear="none" class="">
> As for the tuning, I know my current, underpowered Suricata system<br clear="none" class="">
> is missing events, as is my new hardware/configuration. I base this<br clear="none" class="">
> on some attack traffic I saw from one IP yesterday. <br clear="none" class="">
> <br clear="none" class="">
> So our configuration is a front end router feeding an inline IPS<br clear="none" class="">
> which then is tapped - one tap to my old Suricata system and the<br clear="none" class="">
> second to my new Suricata system. From a full take packet capture I<br clear="none" class="">
> see 45 attempts to issue malicious POST attempts to a webserver we<br clear="none" class="">
> have. My original Suricata system triggered on 10 of those while my<br clear="none" class="">
> new Suricata triggered on 15. I then took the pcap I extracted and<br clear="none" class="">
> ran it through Suricata on the new system and that system showed it<br clear="none" class="">
> trigger on all 45. So that's giving me a feeling that I'm not<br clear="none" class="">
> tuning something correct - causing the running Suricata to miss things.<br clear="none" class="">
> <br clear="none" class="">
> <br clear="none" class="">
> So, things are improving but there's still progress to make?<br clear="none" class="">
> <br clear="none" class="">
> I'd look at things like CPU and RAM usage - are you maxing out your<br clear="none" class="">
> CPUs/RAM?<br clear="none" class="">
> <br clear="none" class="">
> Also, really look at those rules, are they really all relevant to your<br clear="none" class="">
> network? Also, if you strip it down to just the rules that'd catch those<br clear="none" class="">
> POST attempts, does it fire for every event?<br clear="none" class="">
> <br clear="none" class="">
> -- <br clear="none" class="">
> Rob </div>
<br clear="none" class="">
> <br clear="none" class="">
> <br clear="none" class="">
> <br clear="none" class="">
> <br clear="none" class="">
> _______________________________________________<br clear="none" class="">
> Suricata IDS Users mailing list: <a shape="rect" ymailto="mailto:oisf-users@openinfosecfoundation.org" href="mailto:oisf-users@openinfosecfoundation.org" class="">
oisf-users@openinfosecfoundation.org</a><br clear="none" class="">
> Site: <a shape="rect" href="http://suricata-ids.org/" target="_blank" class="">
http://suricata-ids.org </a>| Support: <a shape="rect" href="http://suricata-ids.org/support/" target="_blank" class="">
http://suricata-ids.org/support/</a><br clear="none" class="">
> List: <a shape="rect" href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank" class="">
https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br clear="none" class="">
> Suricata User Conference November 4 & 5 in Barcelona: <a shape="rect" href="http://oisfevents.net/" target="_blank" class="">
http://oisfevents.net</a><br clear="none" class="">
> <br clear="none" class="">
<br clear="none" class="">
<br clear="none" class="">
-- <br clear="none" class="">
---------------------------------------------<br clear="none" class="">
Victor Julien<br clear="none" class="">
<a shape="rect" href="http://www.inliniac.net/" target="_blank" class="">http://www.inliniac.net/</a><br clear="none" class="">
PGP: <a shape="rect" href="http://www.inliniac.net/victorjulien.asc" target="_blank" class="">
http://www.inliniac.net/victorjulien.asc</a><br clear="none" class="">
---------------------------------------------<br clear="none" class="">
<br clear="none" class="">
_______________________________________________<br clear="none" class="">
Suricata IDS Users mailing list: <a shape="rect" ymailto="mailto:oisf-users@openinfosecfoundation.org" href="mailto:oisf-users@openinfosecfoundation.org" class="">
oisf-users@openinfosecfoundation.org</a><br clear="none" class="">
Site: <a shape="rect" href="http://suricata-ids.org/" target="_blank" class="">http://suricata-ids.org
</a>| Support: <a shape="rect" href="http://suricata-ids.org/support/" target="_blank" class="">
http://suricata-ids.org/support/</a><br clear="none" class="">
List: <a shape="rect" href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" target="_blank" class="">
https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br clear="none" class="">
Suricata User Conference November 4 & 5 in Barcelona: <a shape="rect" href="http://oisfevents.net/" target="_blank" class="">
http://oisfevents.net</a>
<div class="yqt2922283843" id="yqtfd46506"><br clear="none" class="">
</div>
<br class="">
<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br class="">
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" class="">
oisf-users@openinfosecfoundation.org</a><br class="">
Site: <a href="http://suricata-ids.org/" class="">http://suricata-ids.org</a> | Support:
<a href="http://suricata-ids.org/support/" class="">http://suricata-ids.org/support/</a><br class="">
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" class="">
https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br class="">
Suricata User Conference November 4 & 5 in Barcelona: <a href="http://oisfevents.net/" class="">
http://oisfevents.net</a></div>
</blockquote>
</div>
<br class="">
</div>
Disclaimer: This email and any files transmitted with it may contain confidential information intended for the addressee(s) only. The information is not to be surrendered or copied to unauthorized persons. If you have received this communication in error, please
notify the sender immediately and delete this e-mail from your system. </div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
Disclaimer: This email and any files transmitted with it may contain confidential information intended for the addressee(s) only. The information is not to be surrendered or copied to unauthorized persons. If you have received this communication in error, please
notify the sender immediately and delete this e-mail from your system.
</body>
</html>