New year, new update ready for testing! We have been busy over the holidays and are bringing you an update that is packed with new features and many many performance improvements.

This is quite a long change log, but please read through it. It is worth it!

Squid 4.5 - Making the web proxy faster and more secure

We have finally updated to squid 4.5, the latest version of the web proxy working inside IPFire. It has various improvements in speed due to major parts being rewritten in C++.

We have as well changed some things on the user interface to make its configuration easier and to avoid any configuration mistakes.

One of the major changes is that we have removed a control that allowed to configure the number of child processes for each redirector (e.g. URL filter, Update Accelerator, etc.). This is now statically configured to the number of processors. Due to that, we only use as many processes as the system has memory for but allow to use maximum CPU power by being able to saturate all cores at the same time. That makes the URL filter and other redirectors faster and more efficient in their resource consumption. They will now also be launched at the start of the web proxy so that there is no wait any more for the first request being handled or when the proxy is under higher load.

We expect these improvements to make proxies that serve hundreds or even thousands of users at the same time to become faster by being more efficient.

We have dropped some features that no longer make sense in 2019: Those are the web browser check and download throttling by file extension. Since the web is migrating more and more towards HTTPS, those neither work for all the traffic, nor are they very reliable or commonly used.

We have also removed authentication against Microsoft Windows NT 4.0 domains. Those authentication protocols used back then are unsafe for years and nobody should be using those any more. Please consider this when updating to this release.

We have also mitigated a security issue in the proxy authentication against Microsoft Windows Active Directory domains. Due to squid's default configuration, an authenticated user was remembered by their IP address for up to one second. That means that with an authenticated browser, any other software coming from the same system was allowed for one second to send requests to the web proxy being properly authenticated. This could have been exploited by malware or other software running inside a virtual machine or similar services to get access to the internet without having valid credentials. This is now resolved and (re-)authorisation is always required.

New installations will now be recommended to set up a proxy with slightly more cache in memory and no cache on disk. Ultimately, this is something that should be considered for each installation individually, but is a better default than the previous values.

Furthermore, some minor usability improvements of the web proxy configuration page have been implemented.

DNS Forwarding

The DNS forwarding feature has been extended to make using it more flexible. It now accepts hostnames as well as IP addresses to forward requests to multiple servers that are found by resolving the hostname. It is also possible to add multiple servers as a comma-separated list so that multiple servers can be queries for one single domain. Before only one IP address was supported which rendered the domain unresolvable in case of that specific server becoming unreachable.

These changes allow to redirect requests to DNS blacklists for example directly to the right name servers and not worry about any changes of IP addresses at the provider. There is also load-balancing between multiple servers and the fastest server is being preferred so that DNS resolution for all domains is faster and more resilient, too.


  • Kernel modules that initialised framebuffer are no longer being loaded again. This cause some crashes on various hardware with processors from VIA and was a regression introduced by compression kernel modules with the last Core Update.
  • Creating certificates for IPsec and OpenVPN threw an error before which has now been fixed by ensuring that the internal certificate database is initialised correctly
  • We have enabled a Just-In-Time compiler for the Perl Regular Expressions engine. This will increase speed of various modules that use it like the Intrusion Detection system which might have significantly more throughput as well as speed of the URL filter and various other components on the system.
  • `fireinfo now supports authentication against any upstream web proxies
  • Installing IPFire from ISO on i586-based systems failed because of a bug in the EFI code of the installer. This has now been fixed.
  • Installing IPFire on XFS filesystems is now also working again. Before, the installed system was not able to boot because GRUB did not support some modern file system features.
  • The description on which SSH port IPFire is listening has been fixed.
  • Connection Tracking support is now enabled by default for Linux Virtual Servers, i.e. layer-4 load-balancers.
  • The system is now using TCP fast-open where possible. This will make TCP connections to some servers open faster because some payload can already be sent with the first packet.
  • GeoIP: Scripts have been updated to use a new format of the GeoIP database
  • Updated packages: bind 9.11.5-P1, ipvsadm 1.29, Python 2.7.15, snort 2.9.12, sqlite 3.26.0 which fixes a couple of security vulnerabilities, squid 4.5, tar 1.31 which fixes a couple of security vulnerabilities, unbound 1.8.3, wget 1.20.1


  • Updated packages: clamav 0.101.1, libvirt 4.10 which fixes some problems with stopping and resuming virtual machines, mc 4.8.22, transmission 2.94
  • The haproxy package now correctly handles its backup

Thanks as always to everyone who has contributed to make this Core Update happen. I am very excited to be able to ship these features as soon as possible and for that we need the help of our community to find any bugs as soon as possible. So, please help us testing!

Today, we have updated IPFire on AWS to IPFire 2.21 - Core Update 126 - the latest official release of IPFire.

This update brings you of course all the features that come with this new version and helps you to avoid updating a newly installed system.

Go to IPFire on AWS

Every image that we provide has to be tested and approved by Amazon which is a long and manual process. Since IPFire has a great update mechanism, it is not necessary to do this for every single release since all installations can be updated as usual.

But from time to time, we are going to release a new image so that fewer updates have to be installed. The original release was based on IPFire 2.21 - Core Update 124 and in version 126 a new kernel has been shipped which makes this update a little bit larger than usual.

This way, any new instance of IPFire in the cloud is available to use a little bit quicker allowing you more time to spend on how to secure up the rest of your infrastructure.

For all customers that are already running on the latest image, there is nothing to do here but to make sure that you have all updates installed on your instance so that everything is up to date and secure.

The number of security vulnerabilities is rising. 2018 is another record year. There is a couple of theories why that is: Some say it is only more vulnerabilities being reported. Others are saying more money is being spent on finding vulnerabilities. What ever it is, it is a positive thing. Every vulnerability that is found can be fixed and not be used as a zero-day vulnerability.

Regardless of that, 2018 has been an especially bad year for Cisco. It feels like there has not been a day without a major security vulnerability in one of their products. There is a total of 16 CVE reports on Cisco's flagship firewall appliance in 2018.

My Personal Hitlist

There is plenty of Denial-of-Service attacks like CVE-2018-15454 that can be used to remotely shut down your company's network. There are vulnerabilities where an attacker can change system configuration without authentication (CVE-2018-15386, CVE-2018-0448) and hijack traffic. Most severe is the hard-coded backdoor - also known as a pre-configured user with a password only known to Cisco - until somebody else found out.

There is a full list about of all vulnerabilities available on Cisco's Website. Not how many there are in the last couple of days and how many of them are of "high" severity or "critical".

Cisco's Security Report

Unfortunately Cisco is not very transparent about these issues - a common thing with larger vendors. They list them, but usually without further detail. There is a Security Report that is published once a year but can only downloaded after giving your full name, email address, country and company you are working for. Signing up to marketing emails or even phone calls is the goal of this form.

I guess we can all imagine what the intent of the "sales representative" is after you have downloaded the report: Downplaying those security issues. The vast majority of sales people I have ever met never understood basic things about their technology.

They are selling phrases and those phrases are supposed to create a feeling about that there will be someone in the large company who knows what is right and buyers should just trust them.

This is not transparency what Cisco is trying to achieve here. They are collecting addresses of potential customers. This is creating deception about systemic issues with their products. It works very well on many decision makers.

The Quality of Their Security Vulnerabilities

This all is only exceptionally bad because the number of reported vulnerabilities, but also the quality of them. Loads of them were very easily exploitable and the consequences especially severe.

Most surprising is, that loads of them are so simple that they must have been found. I cannot imagine that any code that has been audited still has those remote code execution issues in them because they should be obvious - at least to a trained eye.

One could come to the conclusion that they are not performing any internal audits at all.

Of course an external party cannot audit their code because they do not Open Source it.

Entirely unacceptable is that there are hardcoded credentials in some products. A reason to fail any audit.

There is absolutely no excuse for this.

They are called backdoors and why would somebody put those in there without ever intending to use them? Development never needs any experimental access without authentication; penetration testing never needs them. There is no legitimate reason for a backdoor except unauthorised access to systems deployed in production.

Imagine that those logins are in the wrong hands - which they probably will be. Are you comfortable with anybody else "administering" your routers? Seeing all traffic? Keeping a copy of it? Redirecting parts or all of it? I certainly wouldn't.

A firewall is very sensitive system in a network because there are not that many packets that are not going through it. A jackpot for an intruder.

Luckily, those products are certified

How these products ever pass those certifications that they have is a miracle to me. IPFire does not have any certifications because they are usually more non-sense as these cases here clearly show. Some also require you to not change the code again or you will lose the certification. IPFire is changed every day. We develop, the improve and we fix problems. All that won't be possible then.

IPFire is of course not free from any security vulnerabilities. Those that we have had were of a totally different quality though. They allowed executing of shell commands as an unprivileged user after authentication to the web user interface. This is quite a hurdle for an attacker and makes it very hard to exploit. At no time, there was any chance to take over the whole system or to gain root access to the whole system over the network.

Although IPFire might not have all the enterprise features, you might not even need them. It at least does those things that it can do very well and what it can't do you will be added because we have an active development team whose focus is on security. It is not on marketing. It is not about adding feature after feature at any price. We double-check every change that goes into the code. We share it with you because we do everything in the open. There is nothing to hide.

In my humble opinion...

According to general security guidelines of this project, Cisco has entirely disqualified itself as a vendor of critical infrastructure. There seem to be too many problems in the release process of their software and decisions have been made for which I can see no excuse. They are not advantaging their users.

They charge a lot of money for their products that are clearly lacking basic quality assurance and miss most basic expectations from the customers.

Ask yourself the question if it is worth it paying thousands of dollars to a company that is risking the security of your company?