Snort mailing list archives
Re: high packet loss - low throughput
From: Michal Purzynski <michal () rsbac org>
Date: Sun, 21 Jul 2013 20:16:25 +0200
On 7/21/13 6:08 PM, Joel Esler wrote:
If Snort sees traffic more than once, it will analyze it as many times as it sees it.How does the SSL renegotiation rule work than? It seems to inspect some bytes deeper in the stream (and gets triggered here a few times a day, as people scan us on a regular basis).The SSL preprocessing should discard an ignore a session after it determines the legitimate certificate exchange,
Well it's only snort having problems here. I run Bro (on another host) for all the cool features it's got and have so little packet loss (<1%). Netsniff-ng has 0% loss, etc.But like I said, it sounds like there is something else going on here.
I've tuned the http preprocesor as advised here. I've set it up to not inspect everything and disabled all the unnecessary preprocessors.
preprocessor http_inspect: global iis_unicode_map unicode.map 1252 compress_depth 1460 decompress_depth 2920
server_flow_depth 1460 \ client_flow_depth 1460 \ post_depth 65495 \A very important question, to help me understand what's going on here - are the packet drop, pps, Mbit/sec, and all other counters calculated every period, right?
It looks to me like a new line with a current stats gets added every few minutes. So I did
for i in {1..20}; do cat snort-$i.stats | awk 'BEGIN { drop=0 } /^[0-9]/ { FS=","; drop+=$2 } END { print drop }'; done;
And diving that number by a numer of lines beggining by number for i in {1..20}; do cat snort-1.stats | grep '^[0-9]' | wc -l; done;gets me a packet drop rate from 1.37% to almost 0%, depending on the process.
Still some of the processes can have short "peak" with a very high drop rate. Any ideas what might be a reason that some of them get 'saturated' from time to time? 6.7% loss on a process that's got 29.71Mbit/sec in statistics but later ... 0%.
Sent from my iPhoneOn Jul 21, 2013, at 9:33 AM, Michal Purzynski <michal () rsbac org <mailto:michal () rsbac org>> wrote:On 7/21/13 2:03 PM, Joel Esler wrote:Yes, performance that low seems incorrect. I don't think it's Snort with numbers that low.Also, a question for the more experienced. I have a simple setup - load balancers in front of everything, doing L7 and terminating SSL. Snort gets a copy of all the traffic and that means it can see:1. traffic from Internet to load balancers 2. traffic from LB to the backend servers 3. traffic from the backend to LB 4. traffic from the LB to the InternetIt's clear it can see the same traffic twice, sometimes enrypted sometimes decrypted (SSL preprocessor enabled, so the encrypted traffic is being ignored).Question: does it make sense to leave it like this or should I only direct the "internal" traffic to snort? You know, the one between the LB <-> backend?Sent from my iPadOn Jul 21, 2013, at 6:16 AM, Michal Purzynski <michal () rsbac org <mailto:michal () rsbac org>> wrote:On 7/21/13 2:22 AM, Joel Esler wrote:On Jul 20, 2013, at 6:46 PM, Michal Purzynski <michal () rsbac org <mailto:michal () rsbac org>> wrote:Not really, SO is so wonderful you can enable and disable functionality on demand, and so I've done. The box is running snort and netsniff-ng only, has around 20 processes of snort (24 execution threads with HT enabled).The sourcefire company claims to achieve 1Gbit/sec per CPU core. I findit actualy hard to believe as the "empty" snort used to do around 250-300Mbit/sec per core here. Empty as in no rules at all.Even more. But we have a dedicated appliance specifically tuned with special drivers to run Snort very fast. You are doing this, I assume on commodity hardware, on a stock OS, running many things (Security Onion)Still - 45Mbit/sec per instance with packet loss is disappointing. And 100 would be too.Also, I'm running Intel and pf_ring, can try a Myricom (and not pf_ring). I won't try anything more expensive like FPGA accelerated cards, since I find them too limited and having no real advantage over Myricom and a lot of downsides.
------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users Please visit http://blog.snort.org to stay current on all the latest Snort news!
Current thread:
- Re: high packet loss - low throughput, (continued)
- Re: high packet loss - low throughput rmkml (Jul 19)
- Re: high packet loss - low throughput waldo kitty (Jul 19)
- Re: high packet loss - low throughput waldo kitty (Jul 19)
- Re: high packet loss - low throughput Michal Purzynski (Jul 20)
- Re: high packet loss - low throughput Joel Esler (Jul 20)
- Re: high packet loss - low throughput Michal Purzynski (Jul 21)
- Re: high packet loss - low throughput Joel Esler (Jul 21)
- Re: high packet loss - low throughput Michal Purzynski (Jul 21)
- Re: high packet loss - low throughput beenph (Jul 21)
- Re: high packet loss - low throughput Joel Esler (Jul 21)
- Re: high packet loss - low throughput Michal Purzynski (Jul 21)
- Re: high packet loss - low throughput Michal Purzynski (Jul 22)
- Re: high packet loss - low throughput Livio Ricciulli (Jul 22)
- Re: high packet loss - low throughput Michal Purzynski (Jul 23)
- Re: high packet loss - low throughput Livio Ricciulli (Jul 23)
- Re: high packet loss - low throughput beenph (Jul 21)
- Re: high packet loss - low throughput Michal Purzynski (Jul 21)
- Re: high packet loss - low throughput beenph (Jul 21)
- Re: high packet loss - low throughput Michal Purzynski (Jul 21)
- Re: high packet loss - low throughput Doug Burks (Jul 21)
- Re: high packet loss - low throughput waldo kitty (Jul 19)