The IPFire Project is entirely independent and funded by donations which is quite a tough thing to do these days. It is hard to get donations when you don't have a budget for advertising and encourage people to do more. Unfortunately, donations are at a record low.

That is why we are starting a new challenge: 150 new long-standing donations by the end of the year. That will set up the project for a great year 2019 - and the future is all we are about!

Every donation matters

We appreciate everyone who contributed to the project in the past and we made very good use of every single penny ever donated to the project. That does not only go for financial contributions, but also all other contributions in form of code and time. But a long-term donation is better because it is not only a single event. It is an investment into the project and a commitment to support it and continuous improvement!

It does not matter if you give little or a lot, but it would be appreciated if everyone gives something. Help us to reach out to others and ask them to donate, too. The more people, the better and the more this becomes a community effort!

Instead of asking for a certain sum, we are just asking for a number of new people supporting us regularly. To help us out more, of course donating more helps more, so please try to give as much as you can.

We have a long way ahead of us and need your help

Through our new website and collaboration with Lightning Wire Labs, we are accepting monthly donations and we recommend to everyone to set up one instead of a one-time donation.

We have also improved on payment methods: We support credit card, SEPA Direct Debit and SEPA Bank Transfer to make it fast and easy for use as well as protect your privacy. Also, they do not collect any high fees which ensures that a maximum of the money is going to the project instead of the payment provider. We no longer support PayPal.

Become a donor today

Head over to our new donation page and help us creating change now! Select "Monthly", choose how much you would like to give and complete the form. Thank you!


Dear IPFire Community,

this is the official release announcement for IPFire 2.21 – Core Update 124. It brings new features and immensely improves security and performance of the whole system.

Thanks for the people who contributed to this Core Update. Please help us to support everyone’s work with your donation!

IPFire on Amazon Cloud

IPFire is now available on AWS EC2. This is sponsored by Lightning Wire Labs and provides a virtual cloud appliance that is set up within minutes and provides the full set of features of IPFire.

IPFire is ideal to securely connect your infrastructure to the cloud by using IPsec VPNs and provides throughput of multiple tens of gigabits per second! But IPFire can also be used as a small instance that protects your web, mail and other servers in the cloud with the IPFire Intrusion Detection and Prevention Systen, load balance web traffic and many things more.

Try it now!

Kernel Hardening

We have updated the Linux kernel to version 4.14.72 which comes with a large number of bug fixes, especially for network adapters. It has also been hardened against various attack vectors by enabling and testing built-in kernel security features that prohibit access to privileged memory by unprivileged users and similar mechanisms.

Due to this, the update requires a reboot after it has been installed.

OpenSSH Hardening

Peter has contributed a number of patches that improve security of the SSH daemon running inside IPFire. For those, who have SSH access enabled, it will now require latest ciphers and key exchange algorithms that make the key handshake and connection not only more secure, but also faster when transferring data.

For those admins who use the console: The SSH client has also been enabled to show a graphic representation of the SSH key presented by the server so that comparing those is easier and man-in-the-middle attacks can be spotted quickly and easily.

Unbound Hardening

The settings of the IPFire DNS proxy unbound have been hardened to avoid and DNS cache poisoning and use aggressive NSEC by default. The latter will reduce the load on DNS servers on the internet through more aggressive caching and will make DNS resolution of DNSSEC-enabled domains faster.

EFI

IPFire now supports booting in EFI mode on BIOSes that support it. Some newer hardware only supports EFI mode and booting IPFire on it was impossible before this update. EFI is only supported on x86_64.

Existing installations won’t be upgraded to use EFI. However, the flash image and systems installed with one of the installation images of this update are compatible to be booted in both, BIOS and EFI mode.

Although this change does not improve performance and potentially increases the attack vector on the whole firewall system because of software running underneath the IPFire operating system, we are bringing this change to you to support more hardware. It might be considered to disable EFI in the BIOS if your hardware allows for it.

Misc.

  • CVE-2018-16232: Remote shell command injection in backup.cgi: It has been brought to our attention that it was possible for an authenticated attacker to inject shell commands through the backup.cgi script of the web user interface. Those commands would have been executed as a non-priviledged user. Thanks to Reginald Dodd to spot this vulnerability and informing us through responsible disclosure.
  • The hostname of the system was set incorrectly in the kernel before and is now being set correctly
  • Firewall: Creating rules with the same network as source and destination is now possible and renaming a network/host group is now correctly updating all firewall rules
  • Cryptography: ChaCha20-Poly1305 is now working on ARM, too
  • IPsec: The status of connections in waiting state is now shown correctly at all times; before, they always showed up as enabled although they were disabled.
  • pakfire: Some old and unused code has been cleaned out and the mirror health check has been removed, because a download will fail-over to another available mirror anyways
  • Intrusion Detection: Emerging Threats rules are now being downloaded over HTTPS rather than HTTP
  • Updated packages: bind 9.11.4-P1, iproute2 4.18.0, ntp 4.2.8p12, openssh 7.8p1, parted 3.2, pciutils 3.5.6, rng-tools 6.4, syslinux 6.04-pre1, unbound 1.8.0

Add-Ons

  • Updated packages: nano 3.1, postfix 3.3.1

Launching IPFire on AWS

by Michael Tremer, October 6, Updated November 1

Today, we are launching IPFire on the Amazon Cloud, our first IPFire Appliance in the Cloud.

For everyone, who is already using IPFire in their own data centers, their offices or branches, figuring out AWS is now over. You can now run IPFire as you know it in the Cloud. Using all features as you are used to them and configure them easily through the IPFire web user interface.

Hosting infrastructure in the cloud is becoming more and more important for almost all businesses. It gives you flexibility to grow without a large financial commitment in the beginning and loads of technical features that are expensive to implement in your own data center.

AWS

Amazon is the market leader in the cloud business for years, offering a system that has by far the most advanced features. Anything is possible - given a generous budget. But with that large feature set, it is hard to configure this complex system and very often a simpler solution would have done the job.

IPFire is a lot easier to configure and offers powerful features for the cloud without requiring to be an expert on AWS:

In the Cloud, IPFire grows with you

IPFire runs on smallest hardware as well as on large rack-mounted appliances. It works the same in the cloud!

Starting with a small instance that costs only a few dollars a month to run, you can grow to a large instance that handles gigabits of traffic if you need to. On AWS, 10G and 25G interfaces are supported.

Use IPFire’s powerful set of features

IPFire comes with IPsec and OpenVPN on board making it perfect to securely connect your office, employees or IoT equipment to the cloud giving it access to all internal services you are hosting.

Firewall rules are quickly and easily configured and with the IPFire Intrusion Prevention System, you will find and block any malicious attackers.

See some more examples on the detailed product page.

IPFire is versatile

While setting up IPFire in the cloud, you can grow your business and infrastructre. When ever you decide to leave AWS, you can just backup your configuration and take it with you to the new place.

Whether that would be an on-premise appliance or another AWS region is entirely up to you. Migration is easy and done within minutes.

Try it out today

We have compiled comprehensive documenation on how to set up IPFire on AWS that doesn’t require you to be an expert at all. We also give you a free trial.

What are you waiting for? Try out IPFire on AWS today!


This is the release announcement for IPFire 2.21 – Core Update 123 – a house-keeping release with a large number of fixes and some fixes for security vulnerabilities.

Thanks for the people who contributed to this Core Update by submitting their patches and please help us to support everyone’s work with your donation!


This release ships a large number of microcode updates for various processors (linux-firmware 30.7.2018, intel-microcode 20180807). Most notable, vulnerabilities in Intel processors might have been fixed or mitigations applied. Microcodes are now also being loaded into the processor earlier to avoid any attacks on the system at boot time.

This update also comes with a large number of smaller changes that improve security and fix bugs:

  • OpenSSL has been updated to versions 1.1.0i and for legacy applications version 1.0.2p (CVE-2018-0732 and CVE-2018-0737)
  • IPsec
    • IPsec now supports ChaCha20/Poly1305 for encryption
    • It also allows to configure a connection to passively wait until a peer initiates it. This is helpful in some environments where one peer is behind NAT.
  • OpenVPN
    • Creating Diffie-Hellman keys with length of 1024 bits is no longer possible because they are considered insecure and not being supported by OpenVPN any more
    • There is better warnings about this and other cryptographic issues on the web user interface
  • Intrusion Detection
    • Links in the log files have been fixed to open the correct page with details about a certain attack
    • Downloads of rulesets properly validate any TLS certificates
  • The /proc filesystem has been hardened so that no kernel pointers are being exposed any more
  • nss-myhostname is now being used to dynamically determine the hostname of the IPFire system. Before /etc/hosts was changed which is no longer required.
  • collectd: The cpufreq plugin has been fixed
  • Generating a backup ISO file has been fixed
  • Updated packages: apache 2.4.34, conntrack-tools 1.4.5, coreutils 8.29, fireinfo, gnupg 1.4.23, iana-etc 2.30, iptables 1.6.2, libgcrypt 1.8.3, libnetfilter_conntrack 1.0.7, libstatgrab 0.91, multipath-tools 0.7.7, openvpn 2.4.6, postfix 3.2.6, rng-tools 6.3.1, smartmontools 6.6, squid 3.5.28, strongswan 5.6.3, tzdata 2018e, unbound 1.7.3

Add-ons

  • Support for owncloud has been removed from guardian (version 2.0.2)
  • Updates: clamav 0.100.1, fping 4.0, hplip 3.18.6, ipset 6.38, lynis 2.6.4, mtr 0.92, nginx 1.15.1, tmux 2.7, tor 0.3.3.9
  • avahi has been brought back in version 0.7 as it is required as a dependency by cups which has been fixed to automatically find any printers on the local network automatically
  • asterisk is now compiled with any optimisation for the build system which was accidentally enabled by the asterisk build system

IPFire Nano Box - The First Prototypes

by Michael Tremer, September 10, Updated November 1

Having announced our upcoming product, the IPFire Nano Box, we are now opening the next chapter on the journey of it. The first prototypes have been tested and verified and here is an exclusive sneak peek!

ipfire-nano-board

This is the base board of the IPFire Nano Box with an LTE module plugged in. You can see the green connection board at the far end with various inputs and outputs for power, console, GPIO, and many more. Right at the front are the two Fast Ethernet adapters which have already been verified to achieve maximum throughput.

It has a Quad-Core Cortex-A7 processor with 1.2 GHz clock speed, 512MB of memory and 8GB storage for the IPFire operating system.

We are proud that we have built a custom solution for our customers who need an IoT sized appliance and designing and producing the whole design on our own was an amazing experience so far.

But it isn’t over, yet! There are some final touches to come before we are sending this into production. Stay tuned!


Announcing IPFire Nano Box - Our First ARM-based Appliance

by Michael Tremer, May 30, Updated November 1

We are proud to announce our first ARM-based appliance: The IPFire Nano Box

This small and versatile system will be our latest addition to our professional IPFire Appliance line and will make IPFire ready to deployed on the Internet of Things as well as in smallest locations like a remote working office or in industrial plants.

Together with our hardware parter TX-Team, and with input from many customers, we have designed this new appliance. For the first time, we layouted and are manufacturing the whole baseboard from scratch for an optimal firewall product and also to be able to act as cost-efficient as possible.

The proud result is up to our highest standards in performance, easy handling, versatile deployment where ever our customers need it, maximum extensibility for many different tasks and of course security.

In the weeks to come, I would like to tell you the stories behind our new product and how it came to be. It has been a long journey and we have invested so much effort and thought into creating this for you and - to us - many of those are worth sharing.

Although this is the smallest of all products, in some ways, it is the greatest.

The IPFire Nano Box

The IPFire Nano Box provides connectivity wherever needed and wherever possible. It has two Fast Ethernet ports and an optional WiFi and LTE/3G module.

A quad-core ARM Cortex-A7 processor has enough power to run multiple secure IPsec or OpenVPN connections to your company’s headquarter or data center where connected IoT applications can send their data to. It can also be used in places where our IPFire Duo Box is too large and where only limited performance is needed. For example to provide connectivity via DSL or 4G and WiFi for a remote worker at home.

Wherever the IPFire Nano Box is deployed, it provides the full range of functionality that the IPFire Distribution has which is much more than what most 4G or DSL routers provide. And of course using one software everywhere makes many things a lot easier, too!

In the basic configuration, the power consumption is only 2 watts which will allow the IPFire Nano Box to be battery-powered over a long time as well.

It is wrapped in an industrial aluminium case in a small form-factor, passively cooled of course and IP50 proof. Surrounding temperatures between zero and 60°C are not a problem and its wide-band voltage input of 12-24V allow deploying the system even under difficult circumstances.

As soon as we have released the product, we will also release our designs, plans and mockups as Open Hardware for everyone to audit and review. With this, we will provide you with a 100% transparent system on which you can build other applications if you want to.

Register Your Interest

We have just completed the prototyping stage of this new hardware and mass-production is starting soon. Since we have already received huge interest about our product in the conversations with our customers over the phone, we are excited to keep you updated about the status.

If you would like to know more about the IPFire Nano Box, or register your interest, please get in touch with our sales team at sales@lightningwirelabs.com.


Meltdown/Spectre - The chaotic story

by Michael Tremer, January 12, Updated November 6

I am sure that it has been unmissable: Every modern processor has unfixable security flaws. The story has now been boiling for weeks and has finally made the main news one week ago.

To make this article shorter, I won’t go into details of the technical issue. That has been discussed in many places so far and everyone of you can search around a bit to find an explanation to your desired detail. The most important piece of information that you should know is that the CPUs are allowing applications to access parts of the memory that they should not and that allows an attacker to get important information from the victim’s computer.

Although it took decades to find out about this fundamental design issue, it is very easy to exploit and even a little piece of Javascript executed in a web browser has been reported to be sufficient to execute the attack.

The most important question for us is: Is IPFire affected? And the unfortunate answer is yes, most likely. This is a hardware bug and if IPFire is running on hardware that is vulnerable, it is affected. The even worse news is that there is probably not many systems that are not affected. The IPFire kernel has been patched and hardened against multiple attack vectors and there is a possibility that we are able to mitigate at least some exploitation of this attack through grsecurity. However, this is not 100% confirmed, yet.

Another argument that probably weighs a bit more is that IPFire is never supposed to run untrusted code. The example with the javascript code in a browser might work on a desktop system, but the firewall does not do this. All code is reviewed and compiled by us, signed and verified before it is installed on every single IPFire system. As long as you haven’t installed any third-party software from any other source you should be safe. But any unknown and therefore unpatched remote code execution vulnerability in any of the many packages that IPFire is using would allow an attacker to execute an Meltdown/Spectre exploit. That means we cannot just lean back.

Talking about what we can do from a distribution point of view brings me to point that I have to raise first: I have never read so many speculations, false assumptions and comments that were just wrong about any vulnerability before. For me, new about this vulnerability are just breaking and so are the patches that are out there to mitigate the problem. Many things are just in the unknown until today. The biggest problem there seems to be the embargo that hasn’t been followed properly and one specific vendor who is following their own rules.

It is still officially unconfirmed if 32 bit architectures are affected as well. Logic tells us they are, but the Linux kernel maintainers who pride themselves in having delivered a good set of patches have only working on the 64 bit x86 version of it and not 32 bit. So all 32 bit systems remain unpatched.

The latest versions of the kernel (4.14 and 4.15-rc*) have received a patchset called KAISER which is supposed to mitigate the hardware bug. However, only an old version and parts of that patchset have been backported to older kernels. IPFire is always based on an older kernel that is on long-term support and well maintained just like many other distributions. Some have patched parts of the vulnerability but I think I can be certain that nobody fixes all of it. By that I certainly do not want to say that the kernel maintainers are doing a bad job. They are doing a great job, but of course their time is also limited and this is not a simple fix that requires a few lines like Heartbleed did. It requires major rework of some essential parts of the kernel and I am very grateful for them doing that work. My point is just that they are not done, yet and deploying half a fix is probably not a good idea. People have reported bugs in the other kernels that will probably never be fixed.

So what will IPFire do? Having said that we think that we might already mitigate some portion of that problem and that the distribution is not too easy to exploit, we are continuing to work on rebasing the distribution on 4.14 which is the latest long-term supported kernel. That will take some more time though since supporting ARM is a huge maintenance problem for us right now. It is holding up a release that is basically ready for beta. If a good patchset that is also compatible with grsecurity becomes available we will ship that with the current kernel, but I am not expecting that to happen in the near future.

That leaves me with saying that everyone who can should probably upgrade from 32 bit to 64 bit.

I cannot finish this article with having a rant about Intel and how they dealt with this issue. There are also some other groups who deserve some criticism and but clearly Intel did not handle this well and is still trying to play down the huge size of this problem. First of all it is the most severe hardware issue that has been around in probably all time. It is not only in a product that some people use, but probably every person who reads this article owns at least one Intel processor that has been produced in the last decade. Their power in the market is that huge that they have a monopoly.

Bugs happen. I do not want to point a finger at a certain person or group who did something wrong. Clearly they should have known better, but this has happened now, so we have to deal with it. But you should own your bugs. Take responsibility. Instead their PR department seems to have chosen a route to blame other vendors as well for a bug that only they had. Yes, ARM and yes, AMD is also affected by some problems that are also very severe, but there is one that only affects Intel processors. That is also the most severe one. They continue to put out benchmarks that only show a little performance impact but deliberately neglect older processors where the performance impact is a lot higher.

That is not a very good way to gain my trust. And not that I had the biggest trust in that company before, this did not help. So I am stuck in a world where I do not have many alternatives to what I can buy from the shelfs. Your products are inside every modern computer. Make yourself aware of that responsibility. That includes your CEO who apparently did not want to own that financial risk.

And the only reason why I care about this so much is, that secure software requires secure hardware. It does not matter how secure IPFire is, because when the hardware is compromised, the software is compromised, too.


Finally, we have made the move to host all of our services over TLS only. That means that any website or file that is being downloaded, any email that is being sent or received is being encrypted. Everything is secure now! Well… not really. This is a brief article about TLS considerations and some real-world issues with it.

Up until about two weeks ago, none of the IPFire web services had a certificate – with a few exceptions. If you went onto our main website, you would have just connected over HTTP and that is it. There was no TLS involved whatsoever. It didn’t need it really. At no time any personal data was being transferred. It was just our website which is publicly available for everyone.

For some web services like Bugzilla and some more we used our own CA. That allowed us to issue our own certificates with what ever settings we wanted and we could deploy them very easily. One main incentive was to avoid paying for a number of certificates at a public CA which wasn’t possible for such a number of certificates and being as underfunded as we are it was a wrong place to invest the money. I toyed around with DANE for a little bit, but since no web browser implements this, this is nothing better than a trial.

Let’s Encrypt everything!

But those days are gone now. Over the last weeks I abandoned the IPFire CA and replaced any existing certificates by certificates from Let’s Encrypt. It has been suggested many times by many users but I refused to do it because I do not really see the point of just encrypting everything for the sake of encryption. Encryption is from my point of view very useless in the case of our main website and mirror servers.

What convinced me now to do it is a completely different argument: Integrity. I do not want somebody else injecting some malicious Javascript code into our website. That is the only reason Let’s Encrypt makes sense. Encryption would technically work without a publicly signed certificate and of course in the case of the IPFire forums it is a necessity.

In addition to the sites that already had a certificate, I set up Let’s Encrypt for literally everything else, too. And since this only makes sense if everyone is using TLS, we now redirect every HTTP request to HTTPS first before having our web server replying to it. That means any website, any download is now going over HTTPS.

To enforce that, we use HTTP Strict Transport Security (or HSTS) which lets every browser remember, that “www.ipfire.org” is only available over HTTPS. The next time, you enter that domain into your address bar, the browser will remember to connect over HTTPS only.

Improving TLS performance

Additionally, we use OCSP Stapling, which will help to improve the speed of setting up the first TLS connection. The browser would contact the CA which is Let’s Encrypt in our case and check if the certificate that has been received from the web server is still valid or has been revoked. That takes some time since it is an extra TCP connection and the CA has to respond to a large number of these OCSP requests.

Instead, our web server does this for you and staples the OCSP response to the TLS handshake. It is signed and therefore the browser can trust it without having to contact the CA to verify.

On top of that, we cache TLS sessions to resume them faster.

Securing Encryption

We only allow the browsers to use TLS 1.2. Anything else is not possible since they are considered broken or cryptographically weak.

And finally, we reviewed the list of allowed ciphers and removed anything else but AES256 and AES128 in GCM mode or in CBC mode with SHA384 or SHA256. We introduced using ChaCha20 with Poly1305.

The key handshare is only possible using either the Elliptic Curve Diffie Hellman algorithm or ECDSA. None of which rely on a discrete logarithm.

Downsides of all of this

This is now all new and shiny with icing on top. Latest cryptography. Strongest ciphers. What could go wrong?

We will inevitably kick out a number of users here to enforce these new things. That is at least: Firefox 26 and older, Chrome 29 and older, IE 10 and older, Opera 16 and older, Safari 8 and older and Android 4 and older. Those devices and browser won’t be able to contact our web servers securely and more and since we insist using TLS only, they won’t be able to connect with us at all.

The idea is to try this out now. If you have issues connecting and it should work, please let us know. This will need to be a trade-off of what is good security and what people actually use. But I do have the intention to force you XP users out there to finally upgrade. It’s 2017.

Late spring cleaning in progress

All these things happened during our yearly security review and updating where we check if every part of our infrastructure is using the best possible security that is available to us.

Of course we also added Let’s Encrypt certificates to our other services like Mail and XMPP. But we are not fully done and will need to improve more when ever there is time to do so.