[Oisf-users] Questions on suricata configuration

unite unite at openmailbox.org
Mon Jan 19 15:06:27 UTC 2015


Hi guys!

Thanks everyone for help with basic ruleset, I really appreciate that.

I've proceeded configuring suricata and plan to deploy it in the 
production environment soon. I carefully studied the suricata.yaml guide 
(and other guides on infosec) and after that got some questions 
(probably I've just misunderstood something or just didn't got the 
point). I am using suricata in NFQ IPS mode, machine on which suricata 
runs has Intel Xeon 3050 2-core CPU and 8 GB RAM and it is expected to 
scan no more than 100Mb/s of traffic (I guess configuration should be 
done based on the exact hardware I use). So, the questions are:

1. First one is regarding suricata runmodes. I didn't manage to find 
detail explanations of the runmodes (I don't count the output of 
"--list-runmodes" option) - I mean some basic recomendations when to use 
each one. So, there are three runmodes for NFQ mode - auto, autofp and 
workers with the default of "autofp". Is it ok to just leave it "autofp" 
or should consider choosing different one? How can I derive which of 
this runmodes is the most suitable for me?

2. Second one is about NFQ modes. If I understood correctly, the default 
nfq mode is "accept". So, after passing through suricata, packet should 
be accepted or dropped, so suricata won't pass it back to iptables. 
However, when I test it in fact does pass it back. My iptables rules 
are:
iptables -A FORWARD -s 172.25.25.0/24 -j NFQUEUE --queue-num 0 
(172.25.25.0/24 is my test net with "malicious" host, it is excluded 
from HOME_NET variable)

(So I believe if I used "repeat" mode I would got infinite loop here.)

I've enabled the rule which alerts of too big ICMP packets and from 
"malicious" host try to ping the host in my another network - 
10.0.0.0/24. Alerts are generated, I can see them in fast.log and also 
on snorby WebUI. Packets still pass. Then I add the following rule:
iptables -A FORWARD -p icmp -j DROP (so it is the second one in the 
iptables chain).

And those ICMP packets are being dropped. New alerts keep being 
generated in suri, so I believe the traffic passes through it, and then 
gets back to iptables which is dropping them. If I delete this second 
rule traffic passes again.

The question: isn't the default NFQ mode "accept"? Or the behaviour I 
see is expected and I just didn't got the point in suricata.yaml guide?

3. Is there a way to update the rules "on-the-fly" so, for example, to 
enable/disable/update some rules and get them used by suricata without 
restarting the engine itself?

4. Multi-pattern matcher. Am I right: it takes all the patterns from 
signatures and searches for them simultaneously and it looks for the 
exact signature (and it's action) only after some pattern is matched? 
It's just for my understanding of how it works.

5. Stream-engine/flow settings. I have my nf_conntrack module settings 
set to 327680 concurrent sessions max. I looked through the examples in 
suricata.yaml guide (stream-engine and flow stanzas) and found that 
besides memory allocated for different tasks there is "max_sessions" 
parameter in stream-engine settings, which defaults to 262144. I guess I 
need the nf_conntrack and this max_sessions parameter to match so both 
nf_conntrack and suricata can handle the same number of sessions? And 
also I guess I should multiply all other allocated memory by 1,25 
(262144*1,25=327680) for settings to fit each other inside suricata 
itself?

6. Also a question regarding startup script. I'm using Debian Wheezy and 
Suricata 2.0.5. I've found a startup script for Ubuntu on openinfosec 
site and also have found various sysvinit scripts for debian written by 
different people on the net. Is there some kind of "official" init 
script for debian or I should just write it myself?

7. Is the hardware I mentioned above suitable for checking 100Mb/s of 
traffic? Or do I need a more powerful machine?

Thanks in advance!

-- 
With kind regards,
Alex


More information about the Oisf-users mailing list