[Oisf-users] Questions on suricata configuration

Andreas Herz andi at geekosphere.org
Tue Jan 20 13:01:02 UTC 2015


On 19/01/15 at 17:06, unite wrote:
> 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)

How do you check that it comes back?
I have the same setup with -j NFQUEUE and the suricata inline mode is
the last step the packets take (unless you did configure something else
in suricata).

> 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).

Does it just alert or did you convert the rules to use "drop" instead of
"alert"?

> 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.

Can you paste your suricata config? Are you sure that these are the same
packets that go through suricata?

> 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?

If you didn't change anything in the config it should be fine, yes.

> 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?

Yes, you need to enable "live rule reload" and then use USR2 signal to
trigger it. Keep in mind that there is an actual memory issue:

https://redmine.openinfosecfoundation.org/issues/1358

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

That depends on the ruleset, the traffic and on the system itself
(running other processes that need a lot of cpu?).
But 100Mbit/s (is what you meant i guess) should be no issue in most
cases, i have slower systems which are capable of checking >100Mbit/s.

-- 
Andreas Herz



More information about the Oisf-users mailing list