IPFire comes with an Intrusion Prevention System named Suricata, which can be easily configured through IPFire's web interface. While an IPS extends, but cannot replace a packet filter - which recommended settings have been discussed earlier -, it needs more customisation in order to work effectively, and some tripping hazards arise in early stages of operation.

You have got plenty of resources - why should you even care?

Especially users in luxury of running IPFire on powerful hardware might sit back now, as their machines can easily handle any IPS configuration, no matter which amount of rules has been turned on and how demanding they are in terms of CPU load.

The more common scenario, however, is IT staff already working to full capacity being told to run or activate an IPS on dated hardware. Sometimes, this is a desperate bid to compensate security issues in the networks behind the firewall or gateway machine, or due to a superior reading about IPS making things more secure in his or her glossy tech magazine.

Both scenarios have something in common which virtually enforces spending more time and thoughts on your IPS' configuration: False Positives.

The more IPS rules you enable, the more False Positives will arise. As mentioned in another post before, they might cause more damage to a networks' security than the attackers itself: After a series of False Positives, alerts because of True Positives are not given the attention they deserve anymore.

While it might be certainly interesting to detect and analyse attacks against protocols for industrial control systems (such as SCADA) in terms of academic interest, those are simply irrelevant for people not administering the network of a power plant or production hall. Unless you are a telephone company, STCP scans in order to detect entry points to the SS7 network might be an interesting read, but do not really matter.

Most users will observe the usual background noise: Port scanning en masse, brute force login attempts against popular services such as SSH, spam waves or open SMTP relay hijacking, or bots trying to infect other machines on the internet by using common exploits against known vulnerabilities.

Actually, most True Positives do not matter either

If a network is given some attention, most of the background noise is annoying, but harmless. Patched systems are not vulnerable, reasonable configured mail infrastructures do not permit unauthenticated relaying, services not exposed to the internet cannot be trivially attacked from it.²

So, if those attacks are not worth mentioning, why paying attention to an IPS at all?

The answer is twofold: First, some attacks matter indeed. If your webserver is trying to resolve a couple of suspicious FQDNs, it might have been compromised and an attacker tries to exfiltrate data using DNS tunneling.

Second, IPS alerts related to IP addresses used in internal networks are intrinsically relevant. Needless to say, there might be some IPS rules frequently triggered by chatty or broken devices (telemetry of Windows 10 machines is a notable example), but for the vast majority of IPS rules, there is little legitimate reason to match on internal network traffic.

It is therefore necessary to look at IPS alerts more closely: If they are coming from the internet and match the "background noise" mentioned above, they can virtually always be safely ignored, since the packet(s) in question have been dropped by the IPS anyway. Something sticking out from that common threat level or related to internal networks should set off alarm bells.

Make sure you notice such events as soon as possible, preferably by monitoring the IPS logs automatically.³ If you are in a corporate network and/or are short on resources, prioritise events the right way: A server in the DMZ emitting traffic indicating a successful attack is more critical than somebody trying to run a DoS attack against your internal, fully patched NTP server. On the other hand, an internal portscan coming out of nowhere might be more important than a heuristic pattern indicating an ongoing exploit of the Heartbleed (CVE-2014-0160) vulnerability against a patched TLS server - the latter is probably a False Positive.

Introduce a stricter policy instead of weakening security

Sooner or later, you will be in need of solving a problem at its root. Perhaps a shared WiFi is generating too much critical IPS alerts to be ignored, or an internal network segment for testing purposes is clogging up the logs.

While most users (and superiors) are not delighted to see IT staff breaking things that worked before, this is better than becoming used to it and let things go. You might have experienced similar trouble when restricting your firewall configuration as well, however, a packet filter and an IPS take completely different approaches to anomaly detection.

A packet filter has its rules, which precisely describe what to do with any given packet. Anomalies do not matter, there is always a (almost) binary answer: Drop or permit.

As discussed earlier, even if the IPS itself is based on rule signatures rather than anomaly detection, it is useless without having a baseline or knowing the much quoted background noise. How are you going to do anomaly detection in a network where nothing is normal?

Introduce additional network segments if needed. Move problematic parts of your infrastructure to a dedicated "dirty network" so you can at least be sure about the relevance of IPS alerts in the rest. Then, investigate those systems closely and decide whether they have to be redesigned or you have to make adjustments to the IPS configuration.

Nothing in life is ever easy: Monitor wisely

While it is tempting to set up an IPS, configure it reasonably and never touch it again, it is certainly not a good idea to do so in terms of security. Although it drops offending packets, this post tried to point out that being aware of such incidents is the more sustainable value of an IPS.

However, even if you are monitoring things closely and - figuratively speaking - fight aggressively for your networks' security, attackers might still fly under the radar. For example, searching today's IPS logs for relevant activities, and trigger an alert in case of matches would be an intuitive approach.

This has a significant downside: The later an attack occurs in the evening, the more likely it is to go unnoticed, as today's logs are clear again after midnight.

That vulnerability could be easily fixed by searching the logs written within the last 24 hours. Surprisingly, many monitoring systems are designed to work the other way round.

Special considerations should be taken into account in case of sudden bursts of IPS alerts: More sophisticated attackers with knowledge of a victims' internal structure might try to divert the focus of the IT security staff from the actually targeted systems by creating a lot of noise somewhere else.

Thanks for making it through this rather disillusioning post. For the sake of completeness, IPFires' IPS documentation can be accessed here. The next post will end this series, and focus on security considerations for computers behind IPFire machines.