It is time to test the upcoming release: IPFire 2.25 - Core Update 157. This is the largest release in size we have ever had and updates various parts of the operating system and brings an updated kernel.

Since IPFire is built from source and not based on any distribution, we get to select the best versions of open source software to be a part of it. This release is the second part of our "spring clean" release which updates various software packages and we have also dropped software that we no longer need. The vast amount of this work has been done by Adolf Belka who has been spending many nights in front of a compiler trying to make it all work. If you want to support him and the entire development team, please help us with your donation.

Deprecating Python 2

We have made huge efforts to migrate away from Python 2 which has reached its end of life on January 1st of this year. That includes repackaging third-party modules for Python 3 and migrating our own software to Python 3.

The work will continue over the next couple of weeks and we are hopeful to remove all Python 2 code with the next release. We will keep Python 2 around for a little bit longer to give everyone with custom scripts a little bit of time to migrate them away, too.


  • The IPFire kernel has been rebased on Linux 4.14.232 which brings various security and stability fixes
  • Updated packages: bash 5.1.4, boost 1.76.0, cmake 3.20.2, curl 7.76.1, dejavu-fonts-ttf 2.37, expat 2.3.0, file 5.40, fuse 3.10.3, gdb 10.2, glib 2.68.1, iproute2 5.12.0, less 581.2, libaio 0.3.112, libarchive 3.5.1, libcap-ng 0.8.2, libedit 20210419-3.1, libevent2 2.1.12, libexif 0.6.22, libgcrypt 1.9.3, libgpg-error 1.42, libtiff 4.3.0, libupnp 1.14.6, libxcrypt 4.4.20, libxml2 2.9.10, lm_sensors 3.6.0, lua 5.4.3, meson 0.58.0, OpenSSH 8.6p1, perl-Canary-Stability, perl-Convert-TNET 0.18, perl-Convert-UUlib 1.8, perl-Crypt-PasswdMD5 1.41, perl-Digest 1.19, pixman 0.40.0, poppler 21.05.0 (and poppler-data 0.4.10), pppd 2.4.9, readline 8.1, sqlite 3.35.5, squid 4.15, sudo 1.9.7, wireless-regdb 2020.11.20, xfsprogs 5.11.0
  • Some packages that are no longer needed for the build process have been dropped
  • Peter Müller has cleaned up the web server configuration for the web user interface and removed various quirks and hacks for old software like Microsoft Internet Explorer 8
  • Leo-Andres Hofmann has contributed some cosmetic changes for the live graphs
  • A security vulnerability has been reported by Mücahit Saratar (#12619) where it was possible to change a script as an unprivileged user due to a file permission error which could later be executed as root. Thank you for reporting this to us.


  • Updated packages: cifs-utils 6.13, cups 2.3.3op2, cups-filters 1.28.8, dnsdist 1.6.0, elfutils 0.184, fetchmail 6.4.19, ffmpeg 4.4, libmicrohttpd 0.9.73, mpd 0.22.6, ncat 7.91, nmap 7.91, samba 4.14.4, Tor

Another update is available: IPFire 2.25 - Core Update 156. As usual for this time of the year, it is a spring clear release that updates lots of software and brings a new exciting feature: Live Graphs.

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:

Live Graphs

Our beautiful graphs are now updating themselves. You can now leave your browser tab open and see bandwidth or CPU usage and everything else always being up to date:

Latency Graph


  • Networking: Interfaces in bridges are now numbered and renamed to mark to which bridge they belong
  • Support for macvtap has been dropped - Please use bridges instead
  • Alexander Marx has fixed a bug where copied firewall rules showed an incorrect source port (#12479)
  • The kernel's BPF JIT hardening has been enabled
  • Instructions helping users to restore their backup correctly have been added
  • Thomas Cekal has contributed a fix for IPFire getting stuck at boot on Hyper-V
  • All alternative themes for the web user interface have been dropped
  • Adolf Belka and Matthias Fischer have updated loads of packages of the core system: acl 2.3.1, attr 2.5.1, bind 9.11.28, bison 3.7.6, bzip2 1.0.8, cmake 3.20, crda 4.14, diffutils 3.7, ed 1.17, gawk 5.1.0, gettext 0.21, gmp 6.2.1, gperf 3.1, grep 3.6, jQuery 3.6.0, libcap 2.49, libloc 0.9.6, libmpc 1.2.1, libnfsidmap 0.27, libpcap 1.10.0, libstatgrab 0.92, libtirpc 1.3.1, mcelog 175, nettle 3.7.2, openssl 1.1.1k, parted 3.4, Perl 5.32.1, perl-Carp-Clan 6.08, perl-Date-Calc 6.4, perl-Date-Manip 6.85, perl-File-Tail 1.3, perl-MIME-Base64 3.16, perl-Net-DNS 1.30, perl-Net-SMTP-SSL 1.04, pigz 2.6, poppler 0.89.0, rust 1.51, strace 5.11, strongswan 5.9.2, sudo 1.9.6p1, swig 4.0.2, sysbench 1.0.20 (no longer available on armv5tel), sysvinit 2.99, zstd 1.4.9


  • Updated packages: clamav 0.103.2, git 2.31.0, monit 5.28.0, mpc 0.33, nfs 2.5.3, libmpdclient 2.19, rpcbind 1.2.5, samba 4.13.7, speedtest-cli 2.1.3, swatch 3.2.4, tcpdump 4.99.0, Tor

Imagine you are in need of an ISP to host your 100,000 malware distribution sites. Which one would be your first choice? You operate a website for exchanging stolen credit card data, and need a reliable place for web and DNS services. Where do you go? A botnet operation of yours relies on reachable C&C servers, but even the dirtiest ISPs shut them down quickly. What to do?

Among the western cloud providers that fit the bill are Google, Microsoft and Cloudflare. Choose three.

Bulletproof ISPs: Dangerous, but easy to block

For years, some Russian and Chinese networks were commonly referred to as being the most dangerous parts of the internet. To a certain extent, this was (and is) right; both countries have an impressive history of hosting so-called bulletproof ISPs, which respond sloppily to complaints regarding malicious activities on their networks, if all. The Russian Business Network (RBN), operating out of Saint Petersburg, was probably the most infamous one.1 Among today's best-known bulletproof ISPs located in or linked to Russia are Media Land LLC and DDoS-Guard. Some places, though, never really made it into public knowledge, such as a complex of shady webhosting companies operating out of The Netherlands, providing services to miscreants for nearly 20 years.

While such ISPs certainly pose a threat to internet users, they usually scatter across a handful of IP networks and Autonomous Systems with little or no legitimate customers located there. As a result, it is rather easy to drop all network traffic from and - more importantly - to them, preventing users to reach malicious or questionable resources hosted there.

IPFire currently supports firewall rules based on IP addresses or networks, and locations. Building firewall rules based on Autonomous System is currently planned thanks to our location database, allowing more fine-grained network access control, especially if the networks of interest propagate many IP prefixes and/or are located in countries such as the United States, being too big to be blocked or allowed as such.

Hosting malicious content on hacked machines around the world - usually referred to as Fast Flux - is a more sophisticated approach to overcome IP-based blocking. Given it's technical nature, it requires access to compromised systems galore (sadly not a problem), often relies on bulletproof domain registrars not taking down the FQDNs used, and does not really offer bandwidth and latency guarantees, depending on the location of the hacked systems used this minute.

While attackers use Fast Flux techniques for high-risk content or infrastructure, (ab)using common western cloud services turns out to be both cheaper and more reliable. Why bother with all the complex technical stuff if you can achieve the same goals at legitimate ISPs for a fraction of the price?

The rise of "bulletproof" IT giants

Firewall rules tend to fail when it comes to malicious activity originating from big cloud providers or other heavily centralised IT players, such as major ESPs (email service providers). While processing Autonomous Systems makes it easier to permit access to one distinct cloud provider, but drop traffic to others located in the same area, they cannot protect against abuse within the AS or IP networks allowed.

This is precisely why the author is so disappointed about Google, Microsoft and Cloudflare: Blocking them is impossible in almost any circumstances - even dropping traffic to single IP addresses of them already causes huge collateral damage. Worse, they know they can get away with this attitude. Among the motivations behind this post is to raise pressure on such ISPs, striving for a internet being less dirty than the one we have to make do with today.

Using IPFire's web proxy in combination with some good and reliable domain-based blocklists2 is not a silver bullet either: While it helps to deny access to knowingly malicious domains hosted on legitimate infrastructure, it is of no use if the offending domain is something like firebasestorage.googleapis[.]com, being abused for hosting phishing sites for years.

Within the past few years, the picture of abuse on the internet has changed: While at least some ISPs in Russia and Eastern Europe improved significantly on detecting and terminating criminal customers, the situation at western cloud providers - especially the biggest ones - got even worse than it has been before.

Today, we are used to see 100,000 malware distribution sites hosted at Google, Microsoft Azure being abused for hosting C&C servers, open (!) redirection services of Google being used in phishing campaigns, Microsoft failing to drain the swamp of hijacked subdomains under * and *, Cloudflare hosting numerous "carding" sites - this list literally goes on for pages, ad nausem.

Among the The World's Worst Spam Support ISPs, Google currently ranks second, Microsoft is on #4 and Cloudflare on #6. Combined, they outrank the leader of this list, the Guangdong province division of Chinanet, by about 60 percent. While the internet community will certainly and rightly blame the latter for being a safe harbour to miscreants, similar accusations against western IT companies are rarely made at the same intensity.

A handful of IT companies can shape policies - for better or for worse

Regrettably, the future looks grim. As the internet becomes more and more centralised, today's IT giants will probably get even bigger, becoming even more "too big to fail" - or "too big to care" in terms of abuse handling.

We saw these actors enforcing good policies, such as HTTPS becoming the de-facto standard for today's web-based internet. Efforts against spoofed e-mails would not be possible at this extend if it wasn't for companies like Yahoo or PayPal having a huge problem with phishing mails targeting their customers. If big providers adopt security mechanisms, we have a large amount of users being protected very quickly - perhaps without even noticing.

On the other hand, the internet community keeps forgetting that those are in for profit after all. When it comes to privacy, we slowly realise how dangerous some ambitions of today's global IT players are - we do not seem to have fully noticed the danger caused by poor abuse handling of these actors as well. With it's cloud division making huge operational losses, Google certainly won't hire more personnel for their anti-abuse desk unless forced to do so. Sendgrid, to mention an ESP for once, fails to mitigate spam and phishing relayed through them due to hacked customers, but is too big to be blocked entirely. In his dayjob and while operating IPFire's mail systems, the author continues to observe a decent amount of junk mail traffic emitted by Google's mail infrastructure.

The mourner of this is the everyday internet user, and protecting them against malicious threats out of legitimate infrastructures is hard, costly, time-consuming and ultimately impossible.

We should force western IT giants to handle abuse seriously. Or we should at least stop applying double standards to smaller ISPs or providers in countries we do not like.

  1. Disappeared from the internet as such in 2008, it is unclear whether the actors behind RBN have ever ceased to operate malicious infrastructure. 

  2. Supporting DNS-based blackhole lists (DNSBLs) for IPFire's web proxy is planned as well, to enable using more precise and faster updated blocklist sources. However, unless the DNSBL infrastructure is located within the same organisation or network, this impacts both performance and privacy, as every FQDN accessed results in a DNS query emitted to the internet.