<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>When you say " If the packets all have the same src/dst ports/IPs,<br>> then they are all going to be handled by the same thread", do you mean that all of these four (src IP, dst IP, src Port and dst Port) have to be the same for one thread to be utilized? what if one of these four is different, is it still the same thread? for example, ping sweep or port scan.<div><br></div><div>Good question about jumbo frames. I am not 100% sure but I would think there are some. In suricata configuration have default-packet-size: set to 1522.</div><div><br></div><div>Yes, I am monitoring flows internally as well but my flow buffers are pretty high. Here is a stat info on that:</div><div><div>flow_mgr.closed_pruned | FlowManagerThread | 271691732</div><div>flow_mgr.new_pruned | FlowManagerThread | 59854939</div><div>flow_mgr.est_pruned | FlowManagerThread | 35647800</div><div>flow.memuse | FlowManagerThread | 11828262632</div><div>flow.spare | FlowManagerThread | 40005878</div><div><br></div><div>Besides last two entries, I am not sure how to read it. </div><div><br></div><div>I should not have local to local flows since local to local traffic doesnt try to use this firewall.</div><div><br></div><div>I did packet profiling with Suricata and it is about 99% HTTP(s).</div><div><br></div><div>I guess, I am trying to figure out if there is a way to reduce packet loss and improve performance while being attacked by either DDOS or something else.</div><div><br></div><div>Thanks.</div><br><div>> Date: Mon, 3 Nov 2014 11:18:59 -0800<br>> From: cnelson@ucsd.edu<br>> To: coolyasha@hotmail.com; oisf-users@lists.openinfosecfoundation.org<br>> Subject: Re: [Oisf-users] Occasional burst of packet loss<br>> <br>> -----BEGIN PGP SIGNED MESSAGE-----<br>> Hash: SHA1<br>> <br>> It doesn't even have to be a DOS attack. Any single high-volume flow<br>> can peg a CPU as the individual packets within the flow are tied to a<br>> single core.<br>> <br>> So, for example, our ISP has a /24 dedicated to CDN servers (like Akamai<br>> and Netflix) and I've seen many cases where a single IP conversation to<br>> this block causes a DOS condition. Since we are a gigabit network, its<br>> not uncommon for a big download (like an Apple update) to average<br>> 500Mbit/second. If the packets all have the same src/dst ports/IPs,<br>> then they are all going to be handled by the same thread.<br>> <br>> Re: packet loss on the internal interface. Are you monitoring internal<br>> flows? Do you have jumbo frames enabled? Local <-> Local IP flows are<br>> also an issue as of course they can be extremely high volume.<br>> Especially for well-tuned protocols like NFS.<br>> <br>> - -Coop<br>> <br>> On 11/3/2014 10:09 AM, Yasha Zislin wrote:<br>> > Coop,<br>> > <br>> > That makes sense. So you are saying that if there is a DOS attack to one<br>> > host, only one thread would be utilized for inspection? It wouldnt just<br>> > spread out across all detection threads?<br>> > <br>> > Also, I did look at other threads and some have less<br>> > capture.kernel_packets and some have MORE. These with higher values have<br>> > no packet loss.<br>> > <br>> > Here is another twist to the story.<br>> > So these two SPAN ports that I monitor are before and after border<br>> > firewall. Packet loss occurs only on internal interface. I would think<br>> > that the firewall has high chance of stopping DOS attack.<br>> > <br>> > Thanks for the info.<br>> > <br>> <br>> - -- <br>> Cooper Nelson<br>> Network Security Analyst<br>> UCSD ACT Security Team<br>> cnelson@ucsd.edu x41042<br>> -----BEGIN PGP SIGNATURE-----<br>> Version: GnuPG v2.0.17 (MingW32)<br>> <br>> iQEcBAEBAgAGBQJUV9UjAAoJEKIFRYQsa8FWiL8H/0jSuWDDKDdwR+2mtBNC82kt<br>> fdB1Q4iWRLjMwS2rjNw99e65ekAr3aowUI4IBU06pZbfW+jnfz7Q/0W7tcim/9BQ<br>> RAbQqbGI93fc5J/k2MAeYveQRh3O8v9xY7IWlHIGclH+w3JWo7O/vi0i2FzKYKW5<br>> dp27tKHNM7kSt/n4vfk+C17p8LVK//aYWEVkNekZHJDdbEwEAdEfFp0VPus2CGFH<br>> Q5n04oqPyzhb17B2Ct4YDP6hCsm4K2/tSW+szxZv3AMZZ9n6fYzXZjftvprovIYZ<br>> dOCbVbhc6Tl+nvgOIoWam9vOUinZcm/vR3wlLzI41Xmiul9GL+k/LeMcAU0LuDY=<br>> =QzIF<br>> -----END PGP SIGNATURE-----<br></div></div> </div></body>
</html>