Another update for IPFire is out: IPFire 2.25 - Core Update 152

Before we talk about what is new, I would like to as you for your support for our project. IPFire is a small team of people from a range of backgrounds sharing one goal: make the Internet a safer place for everyone. Like many of our open source friends, we’ve taken a hit this year and would like to ask for your continued support. Please follow the link below where your donation can help fund our continued development:

This update comes with various smaller bug fixes and improvements and updates the Windows File Sharing Add-on.


  • Intrusion Prevention System: The IPS has been updated to suricata 5.0.4 which fixes various bugs and security vulnerabilities
  • Leo-Andres Hofman contributed for the first time and cleaned up code that shows the DHCP leases on the web user interface. They are now sorted and expired leases are shown at the bottom of the list for better usability.
  • Steffen Klammer fixed a bug which rendered an invalid proxy.pac configuration file when subnets where added in the CIDR notation
  • Values for average, minimum and maximum were swapped in the firewall hits graph which has been corrected in this release
  • Updated packages: knot 3.0.1, libhtp 0.94, python 2.7.18, python3 3.8.2, unbound 1.12.0, yaml 0.2.5


  • Updated packages: mtr 0.94, nano 5.3, tor
  • Updated Python 3 packages: botocore 1.16.1, colorama 0.4.3, dateutil 2.8.1, docutils 0.16, jmespath 0.9.5, pyasn1 0.4.8, rsa 4.0, s3transfer 0.3.3, six 1.14.0,

Windows File Sharing Services

Samba, has been updated to 4.13.0. Because of various reasons and lack of development time, we were stuck on Samba 3 which is unmaintained for a while. With this new version of Samba, new protocol features like SMB3 and encryption are supported. We have also rewritten large parts of the web user interface, made them tidier and fixed some usability issues.

We also dropped some features which we believe are not being used any more. This mainly concerns compatibility to MS-DOS clients, WINS, and using IPFire as Primary Domain Controller for Windows NT domains.

The new streamlines web user interface provides fewer controls and we have changed some defaults to work in modern networks - or that were ineffective in the newer release of Samba.

New features are as follows:

  • Printing with CUPS now works out of the box
  • SMB file transfers are faster, because of some performance tuning
  • IPFire will now always try to become the master browser for its workgroup
  • The file sharing and printing services will be announced to the local network using mDNS with Avahi
  • Extensions for Mac OS X are enabled by default

Because of the vast amount of changes, we need some extra help to find any regressions introduced here. Please also consider if running this package is following best-practise rules in your organization.

Launching IPFire on Exoscale

by Michael Tremer, November 9

Today, we are launching IPFire on Exoscale, the GDPR-compatible European Cloud Provider based in Switzerland.


For the two years that IPFire is available on Amazon EC2, we have often received feedback from various customers about their data privacy concerns. GDPR and the generally higher data protection regulation in Europe is making it difficult for many people to find the right cloud provider that complies with those laws.

We are proud to offer an option for those customers.

With data centers in Germany, Switzerland, Austria, and Bulgaria, Exoscale is promising that your data won’t “travel halfway around the world”. Privacy has been built into the cloud from the first moment.

With competitive pricing and a user interface that is very easy to use, they are a brilliant alternative to the big, well-known cloud providers.

IPFire in the Cloud, just like you are used to it

IPFire in the cloud enables your business to grow above and beyond. It is the same firewall appliance that you know from your on-premise data center, just in the cloud - and therefore more versatile and flexible.

You can host your infrastructure of web servers, mail servers, and have it protected by a powerful firewall while accessing them easily through a secure VPN connection.

Your cloud infrastructure will grow with you to whatever size you need it to. Whether your website is becoming more popular, or your company is opening more branch offices that need to be securely connected to your central servers. Just upgrade your cloud instance and you have added more CPU power and memory to handle whatever challenges you face.

From a small prototype environment to a 10 Gigabit router. IPFire grows with you.

See some more examples on the detailed product page.

Try out IPFire on Exoscale for free today.

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

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

  1. Source of the poster above: "Don’t Be an Easy Target" by Abraham Pena (CC-BY 4.0) 

  2. Further reading is "Today, Nobody is Going to Attack You"

  3. For critical monitoring or IPS alerts, the author frequently uses a small flip-flop circuit in which an impulse from the monitoring system triggers a beeper, which can only be acknowledged and switched off on the device by pressing a button. Apart from being resistant to network-based attempts trying to cover up an alert, this also increases the psychological strain of keeping the number of relevant alarms as low as possible.