Hello all,
I have suricata enabled on both the RED and GREEN interface but I‘m actually questioning the point. I only have the openvpn port open - no other services are available on RED. Between the default DROP rule for incoming and the bad asn blocker (location filter is disabled btw) I don‘t see the point of having the ips on incoming traffic. I however do think it makes sense to scan outgoing traffic - for example ET COMPROMISED. So I would at least get a notification that something in my network tries to contact such an ip. Yet I get quite a few hits on incomming traffic that got blocked anyway. Therefor I only have malware/phishing/botcc rules enabled atm.
Long story short:
How can I tune suricata to ignore inbound on RED for closed ports? Is there a filter on the IPS Log page for filtering on rank?
I’m not sure how you would achieve what you’re asking for, but I’d question why you want to achieve it. IF you’re not hosting services, the volume of traffic on RED should be minimal, thus the “cost” of that security later is low. Is this a case of better to have and not need?
Well I do have a lot of suricata Stream messages - over 120000 (!) one day. If there was a real alert in there I do have missed it. And I can‘t disable or filter these messages so I ended up with disabling suricata altogether.
I agree my point is still muddled. I probably am not really where I want to be with it but have a hard time nailing it down properly. As it stands it isn‘t really useful for me (which is fine!) but I think it could become useful with a couple of options. Or I‘m missing something obvious here and need to lern a bit more. Thanks for replying though. Discussion such things helps sorting these issues too.
Hi,
first of all, sorry for my late reply.
While I get the idea, OpenVPN is just another TLS service at the end of the day. Should we ever see some vulnerabilities such as Heartbleed, OpenVPN would most likely be affected as well. In such cases, having the IPS enabled on RED makes sense.
Also, some IPS rules only trigger on packets reaching your IPFire installation. This can lead to poor outbound traffic being only spotted due to an incoming IPS rule hit; I observed such incidents several times. While this is not optimal, IPFire has no influence on the quality of IPS rules provided by 3rd parties, and I think it is better to have some coverage on such incidents than letting them go unnoticed.
To the best of my knowledge, Suricata does not support this. Neither does any other IDS/IPS I am aware of.
Unfortunately not, and the rank of an IPS rule can be a bit misleading sometimes as well.
The rule causing this can be safely disabled; it does not being you any benefit at all.
Generally speaking, I found the “OSIF Traffic ID Rules” rather useless, and do not run it on any machine.
For monitoring purposes (as elaborated on here), I cobbled together a simple shell script, which ignores IPS hits caused by rules or rule categories I do not care about, only alerting (via NRPE + Icinga) if there are any hits left. While that script is not sophisticated at all, I can share it, should you be interested.
That way, you would have Icinga checks on IPS hits, which makes things more actionable. 
Thanks, and best regards,
Peter Müller