[Oisf-users] Tuning Suricata (2.0beta1) -- no rules and lots of packet loss

Cooper F. Nelson cnelson at ucsd.edu
Thu Aug 15 14:51:54 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well, to be clear your #1 problem right now is not having enough memory.
 So, you should address this by either...

1.  Getting more memory.
2.  Running fewer threads.
3.  Using smaller RX Ring buffers.

Reading your suricata.yaml file, you should also use a smaller stream
depth and lower timeouts.

This just occurred to me, but in your environment you might want to try
using 'autofp' and configuring receive/decode/stream to use cores 0-15
in "balanced" mode and detect to use cores 16-47 in "exclusive" mode
(with 32 threads and a 300k RX Ring).

While I appreciate the offer, if you want to make a contribution please
consider donating to the OISF however you can:

http://suricata-ids.org/participate/

Re:DDOS issues, this is why suricata has 'flow emergency mode'.  So what
you can do is set very short timeouts to allow flows to be pruned
quickly, like this:

>     emergency-new: 1
>     emergency-established: 1
>     emergency-closed: 0
>     emergency-new: 1
>     emergency-established: 1
>     emergency-closed: 0
>     emergency-new: 1
>     emergency-established: 1
>     emergency-new: 1
>     emergency-established: 1

However, this does lead to a potential evasion issue as an attacker
could launch a DDOS attack and then run exploits in the background using
a packet shaper.  It's all comes down to what sort of risk you are
trying to manage.

- -Coop

On 8/15/2013 12:39 AM, Tritium Cat wrote:
> Thanks, I will give that a try after I work on filtering out all the
> regular high volume flows I can find.  That has to be the problem.. it
> makes sense now and I feel exceedingly stupid for not addressing it first.
> (trying to analyze all traffic...)  Whenever we meet you are owed food and
> drink, or shoot me your paypal.  At least I have a good sense of failure
> conditions now. :>  I wonder about current DoS attack methodology on
> multi-core IDS systems and the associated flow hashing algorithms... what
> is the minimum volume required and how many flows launched to affect x out
> of y cores on an IDS to cause partial blindness ?  (It is relative to the
> core speed)  Does anyone see such behavior ?  I've not heard or read about
> IDS evasion topics for a long time.  I can sleep now...
> 
> --TC
> 

>>
> 

- -- 
Cooper Nelson
Network Security Analyst
UCSD ACT Security Team
cnelson at ucsd.edu x41042
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSDOsKAAoJEKIFRYQsa8FWlB4H/3yBCDp5+a71gmxzahm04ohp
hO1ExQb7yGwqHHhYaspvds5iAYnyLgZkJb6IzoWZgXD/I+DOBg9JHvJPHxXtOOyJ
Tx7J1CoY+zmsTxmM1hfoyEMknVAhbpQn5MlfRrtLmJxT+OixQVzqYhRfGsjYOefm
rVZRprWBlFuDgl14TUYjf912r/SKtTmJsICaRVSplVTxehIxtIejgFyeKrUPW2u5
Vst2W756guUX6W7Kbq+u4O0wJLgMtr958OtTy7YkjC7KCSk2m4VDXZ07sQfTOO62
MPiyWlEWdyi0QRLjYq1OHXrdd/EdLVbxQbj6q8d/YMuTawyw4QfF9HfZ7ZgqXzE=
=pSjt
-----END PGP SIGNATURE-----



More information about the Oisf-users mailing list