IPFire 2.25 - Core Update 153 released

by Michael Tremer, December 22, Updated December 22

This is the official release announcement for the last planned Core Update of this year: IPFire 2.25 - Core Update 153.

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: https://www.ipfire.org/donate

Location Database

The location database has received significant updates that improve its accuracy. This was possible by importing more data into it and correlating it with existing data from other sources.

We have also improved performance of loading data from the database into the kernel for firewall rules which removes a class of issues where IP addresses could have matched more than one country.

Many weeks have been invested into this to optimise the database import and export algorithms to provide this functionality even on hardware that is weak on processor power and/or memory.

WPA3 - Making WiFi Safe Again

WPA3 is the new upcoming standard to protect wireless connections and is now supported in IPFire. It can be enabled together with WPA2 so that you can support any devices that do not support WPA3, yet.

WiFi can also be made more secure by optionally enable Management Frame Protection which hardens the network against any attackers that try to de-authenticate stations and therefore denial-of-service your network.

There is more on a detailed post about this new feature: IPFire Wireless Access Point: Introducing WPA3

Another Intel Security Vulnerability

We have of course spent a lot of our valuable development time on this month's security issues created by Intel. As you might have heard from the news, it is possible to profile instructions and extrapolate information through measuring the power consumption of the processor when that instruction is being executed.

We consider this not exploitable on IPFire, because we do not allow running any third-party code, but are of course shipping fixes in form of a patched Linux kernel based on 4.14.212 and updated microcode where available for all affected processors (version 20201118).


  • The most recent OpenSSL security vulnerability CVE-2020-1971 has been patched by updating the package to version 1.1.1i
  • Safe Search now allows excluding YouTube
  • The zone configuration page now highlights network devices that are assigned to a zone. This change improves usability and avoids any mistakes
  • IPsec tunnels are now showing correctly when they are established or not. A programming error could show connected tunnels as "connecting..." before.
  • The log summary no longer shows useless entries for clients that have renewed their DHCP lease and the iptables summary has been removed, since it does not produce any useful output
  • The IP address information page is now showing the Autonomous System for each IP address
  • Some cosmetic improvements for the web user interface have been implemented by Matthias Fischer.
  • On systems with insufficient memory, some pages of the web user interface could not be loaded when they were using the new location library. Thanks to Bernhard Bitsch for reporting this problem.
  • DDNS: Support for DuckDNS has been reinstated after a significant API change
  • Updated packages: bash 5.0.18, curl 7.73.0, file 5.39, go 1.15.4, knot 3.0.2, libhtp 0.5.63, openvpn 2.5.0, pcengines-firmware, strongswan 5.9.1, suricata 5.0.5, tzdata 2020d, usb_modeswitch 2.6.1, usb_modeswitch_data 20191128


  • Updated packages: amazon-ssm-agent 3.0.356.0, aws-cli 1.18.188, ghostscript 9.53.3, libseccomp 2.4.4, lynis 3.0.1, python-botocore 1.19.28, python-urllib3, spectre-meltdown-checker 0.44, transmission 3.00, vdr 2.4.4
  • Tor has been updated to version and is now using the new location database for showing the relay country. It is also now possible to define a list of exit nodes to use and to select certain countries to use for guard nodes.
  • amavis and spamassassin have been dropped because they have been unused and unmaintained for a long time
  • git has been fixed so that all features implemented in Perl can be used again.
  • The apcupsd package now correctly backups and restores its configuration

Following a certain unethical logic, it makes sense for an attacker to hit the weakest the hardest. Why bother with a reasonably secure firewall if the system behind it is missing important patches? Why try targeting the skilled IT staff - which will ignore the attempt at best, if not blocking your infrastructure for the entire network - if their stressful HR colleagues click on every link and open every document they see? As important as an IPFire's configuration is, this post focuses on the systems behind such a firewall, considering important aspects in terms of both security and privacy.

Separate activities and devices

While living a double life reminds us of spy thrillers or action movies, most people not only live a double life, but multiple lives - usually without being aware of it. Behaviour, habits and disclosed information usually differ significantly if one is in a private or professional context. Depending on the norms of the society one lives in, those spheres are more or less strictly separated from another. While they are the most important ones, they do not fit any given situation, such as being active in a club (neither professional nor private), meeting friends, or communicating with total strangers.

People do separate those spheres from another - but not when it comes to electronic devices.

Unless prohibited by the employment contract or companies' guidelines,2 personal mobile phones are carried to the office or private USB sticks are used to transfer work done at home into the corporate network, causing a cross-contamination between those spheres. As mentioned earlier, the former pose a serious privacy threat as they basically leak information of their users activity by design.

However, buying a dedicated computer for any part of your life is neither practical nor - in terms of environmental protection - desirable. So what now?

Do not run closed-source operating systems

Let's take a step back: In 2020, the most popular desktop operating system for both private and professional usage is Microsoft Windows, well ahead of Apples Mac OS. The number of Linux/BSD desktop users is, unfortunately, negligible.

It may sound like an eternal mantra, but running closed-source software is a bad thing. While this does not necessarily make open-source software intrinsically secure or better in any terms whatsoever, examining, auditing or customising is easier by an order of magnitude.

In case the vendor does not ship a security update or does not provide you with an easy solution to turn off unwanted features such as telemetry, then, at least in theory, you have the opportunity to fix that on your own. On the other hand, the vendor's conflict of interest is obvious: People do not pay for security fixes,3 and in order to make revenue, discontinuing support for older products and making users buy the new ones is a common strategy.

The privacy side does not look better: German Federal Office for Information Security has been conducting a study on important aspects of Windows 10 in terms of security and digital sovereignty for years - it's abbreviation SiSyPHuS ("Studie zu Systemintegrität, Protokollierung, Härtung und Sicherheitsfunktionen in Windows 10", en: "Study on System Integrity, Logging, Hardening and Security relevant Functionality in Windows 10") speaks for itself. Recently having issues with their OCSP server, Apple was found to transmit information of executed applications in clear text every time they are executed, effectively leaking the user's activities and identity (i.e. IP address) to themselves, their CDN (Akamai), and everyone in between.

In terms of privacy, running those operating systems is not just bad, it's not an option anymore.

However, running an open-source operating system does not solve the cross-contamination discussed earlier. Running and maintaining a set of VMs just for doing different things is a lot of work both for using and configuring or patching them.

In the authors opinion, Qubes OS aims to provide a useful and holistic solution to this problem. Trying to separate its users digital life according to his or her analogue one, it makes running and switching between multiple electronic lifes suitable for everyday use.4

Needless to say, this does not come for free - Qubes OS more demanding hardware requirements than common operating systems - and requires some time and effort for setup or customisation, and splitting up data into different VMs. Ultimately, the author believes it is worth the effort for both security and privacy.

Avoid VPN providers: Nobody is going to jail for you for a few bucks per month

A feature frequently asked to add to IPFire is supporting traffic redirection through an IPsec or OpenVPN connection to a VPN provider. While doing so is rather easy and usually does not introduce limitations or compatibility issues to any application, it creates a false sense for privacy:

  • Most applications are not prepared for trying to hide their users' identity, which is why such a configuration frequently creates side-channels such as DNS leaks or being susceptible to fingerprinting attempts.
  • Trustworthy of VPN providers is a much, sometimes heatedly debated issue. From a technical perspective, it is trivial for a VPN provider to establish a correlation between a users public IP address and the (pseudonymous) IP address of a VPN server used. Needless to say, this is a terrible constellation.

To put it drastically: Nobody is going to jail for you for a few bucks per month. A VPN provider certainly not, which is why we do not implement such a feature into IPFire.

The author recommends Tor as an alternative. Being a low-latency anonymity network, it has some (design) flaws as well, particularly when it comes to traffic correlation attacks, however, alternatives are believed to be substantially worse.

Caveats when using Tor

Especially for highly threatened Tor users, a look at the country-level distribution of both guard relays (i. e. those relays a Tor client will pick as an entry to the Tor network and tries to sticks to for several months) and exit relays (relays for accessing the "normal" internet from the Tor network) those days reveals an unpleasant correlation: In both cases, the list is led by Germany - some larger exit relay clusters are hosted in greater Berlin and Nuremberg -, France and the United States.

This means that there is a non-trivial chance to have a Tor connection being passed through these countries - or even just one of them. With close cooperation in intelligence matters and increasingly anti-data protection legislation, this concentration is certainly not desirable.

Especially for guard relays, which are the only ones in a Tor connection being aware of the users public IP address, the author suggests to choose them manually, preferring guards operated by well-known organisations and/or located in countries to whom the users country has no or poor diplomatic relations.

It is not wise to do so for exit relays as well, since they are chosen dynamically for every connection through the Tor network, however, depending on the adversaries capabilities, one might want to tell his or her Tor client to avoid exit relays in certain countries.

While the commonly used Tor Browser is pretty resistant if configured properly, it cannot protect against advanced attacks such as keystroke fingerprinting or downloaded files emitting traffic directly, bypassing Tor and compromising the users' anonymity. Because of this, the author recommends using a specialised distribution such as Whonix instead - mentioned Qubes OS comes with it by default.

Finally: brilliant or paranoid ideas

Even if IT security is never really dull, it can be tiring to follow the news or always discuss the same protective measures or - if things go well - implement them. Believing in simple, but effective security mechanisms, the author would like to share some rather unorthodox ideas at the end of this series:

  • Consider spoofing your device's MAC address by your operating system: It might make vendor fingerprinting more harder, and if the original MAC address becomes active, your system has either lost that setting or somebody is using a different (live?) operating system on that device.
  • When singing up somewhere, make your inputs unique by embedding typos or using dedicated mail addresses. In case of data leaks, this makes identifying their origin more easy and correlation attempts to other accounts more hard.
  • Insert dummy entries to address books and contact lists. If somebody contacts their mail addresses or phone numbers, the device you stored those lists might have been compromised.
  • If your devices are connected by wire (as recommended earlier) using a switch, place it within range of vision and keep an eye on the port activity LEDs of inactive devices. If there is too much traffic on such ports, they might just download updates (which one should be quickly able to tell according to the list of active processes) or perform some post-infection activities such as C&C communications, sending spam, or similar. On Windows machines, be aware of some malware abusing the BITS service to download additional files.


This is the final post of a short series regarding countermeasures in an increasingly hostile internet and an IT security landscape being much worse than the author ever imagined it could be.
While current and foreseeable future developments give little cause for joy or optimism, the author hopes that this series was useful in order to configure your IPFire system and secure the networks protected by it better.
Actually, there are plenty of tools for good IT security. You just have to deal with them and then you can easily protect yourself.

The bill mentioned initially, however, which obliges providers to insert state trojans into network traffic on demand, has surprisingly been supported by the Social Democrats parliamentary group since mid-October and will most probably be adopted shortly, despite massive criticism from industry associations, data protectionists and legal experts.

This article series, for reference, consists of:

  1. German bill provides network traffic redirection to install state trojans
  2. Information security recommendations for IPFire users
  3. DNS configuration recommendations for IPFire users
  4. Firewall configuration recommendations for IPFire users
  5. Thoughts on operations security for the masses
  6. IPS configuration recommendations for IPFire users
  7. Beyond The Far Side: Thoughts on secure and private machines behind IPFire (which you are currently reading)

  1. In case the question arises: The first part of the headline is borrowed from an edition of the The Far Side by Gary Larson, which the author enjoys to read. No paid advertising here. ;-) 

  2. Let's assume people adhere to contracts for the moment... 

  3. Which is, by the way, a problem we experience at IPFire as well - in case every IPFire user would donate only one Euro per month, we would not have to worry about our projects resources and development at all. 

  4. Full disclosure: Apart from being a happy user of Qubes OS, the author is not related to that project. 

Today we are releasing an update to the wireless access point feature of IPFire: WPA3

The new standard to secure wireless connections is arriving. Since we are all spending more time in the office or at home working our way through the pandemic, we want it to do as comfortable as possible - and secure, too!

I am sure most of you remember the days of WEP and WPA1. Breaking them was part of the daily tech news cycle and hopefully nobody is running networks like that any more. WEP has been designed in the late nineties, based on RC4 and artificially weakened because of laws that limited exporting cryptography from the United States. It was therefore easy to implement in hardware, but broken very quickly.

WPA1 was only an intermediary step on the way to WPA2 and designed to continue using RC4 which was implemented in hardware. By that I mean that drivers would normally send a packet to the wireless module which would then perform the encryption and finally transmit the packet. Computers in the early 2000s were not fast enough to properly encrypt tens of megabits per second while staying responsive for the end-user.

WEP didn't even use any kind of authentication to the network. A client could simply associate with the access point and start sending data. If the key was incorrect, the access point would have only received garbage and discard of it. A correct key gave you access to the network.

WPA1 was a small stepping stone to finally introduce WPA2 in 2004. It fundamentally follows the same design by introducing an authentication step of the client with the access point before any data can be transmitted. This allows various new things which are not implemented in IPFire.

To be compatible with existing hardware WPA1 allowed using TKIP - an encryption mode that is based on RC4. Obviously this was not a very big leap forward because RC4 was already considered fairly weak at that time - but fast.

WPA2 made CCMP optional which is based on AES, which we all know well. In IPFire we have already disabled TKIP with WPA2 for quite a while and mandate clients to use CCMP because we want to make your WiFi as secure as possible.

But although the cipher was improved, the key exchange protocol showed more and more weaknesses and therefore we needed to come up with something new.

Work Wireless

Simultaneous Authentication of Equals

WPA3 uses Simultaneous Authentication of Equals (SAE) - a key exchange mechanism which has been introduced in 802.11s - the standard for wireless mesh networks, where there is no "center". The client authenticates the wireless access point and vice-versa.

On top of that, CCMP has been made mandatory and GCMP - another AES-based cipher which is faster than CCMP - has been introduced, too. Forward-secrecy ensures that even capturing all data and trying to decrypt it later is no longer possible - even when the pre-shared-key is known to the attacker.

There will be no performance gain from this, but it is a massive leap forward in moving WiFi to 2020. We have been based on too many old standards because we have to be backwards-compatible to so much old equipment that we have out there. Not only a problem for key exchange protocols, but also for all the modulation that is happening in the air which needs to stay somewhat compatible to each other - from 802.11ac to 802.11g. Maybe 802.11ax might break with a few things again.

One of the most disruptive changes is Management Frame Protection (802.11w or MFP for short). It protects all communication between the clients and the access point from eavesdropping. Normally only the payload is being protected. Many clients do not implement MFP at all; some have loads of bugs (I am looking at you, Intel). So it was made mandatory in WPA3.

Changes in IPFire

WPA3 was added and can be enabled alone or in combination with WPA2. You might also enforce using Management Frame Protection in your network, or you can make it optional. With the latter, clients which don't support MFP will be able to authenticate using WPA2.

IPFire's wireless access point only implements WPA-Personal. Because the average office is too large to simply have one wireless access point, and that the firewall is usually stored away in your comms room down the corridor, there is no point in upgrading IPFire to a full-fledged enterprise-ready access point. But it is great for a small office, or at home. It saves some cheap plastic hardware that never gets patched.

Since there are no downsides of enabling WPA3 on top of WPA2, the recommended setup for everyone who is using the IPFire Wireless Access Point add-on is enabling both and making Management Frame Protection optionally.

This feature will land with IPFire 2.25 - Core Update 153. If you enjoy our work and want to support us, please donate.