Just a couple of days after the release of IPFire 2.21 - Core Update 130, the next release is available. This is an emergency update with various bug fixes and a large number of security fixes.

Security

IPFire 2.21 - Core Update 130 contains security updates for the following packages:

  • Apache 2.4.39: The Apache Web Server, which runs the IPFire Web User Interface, was vulnerable for various privilege escalations (CVE-2019-0211), access control bypasses (CVE-2019-0215, CVE-2019-0217), DoS attacks (CVE-2019-0197), buffer overflow (CVE-2019-0196) and a URL normalisation inconsistency (CVE-2019-0220). They are all regarded to be of "low" severity.
  • wget 1.20.3: wget has had multiple vulnerabilities that allowed an attacker to execute arbitrary code (CVE-2019-5953).
  • clamav 0.101.2: ClamAV, the virus scanner, has had multiple vulnerabilities that allowed DoS and a buffer overflow in a bundled third-party library.

Although some of these vulnerabilities are only of low severity, we recommend to install this update as soon as possible!

IPsec Regression

The last update introduced a regression in the IPsec stack that caused that the firewall could no longer access any hosts on the remote side when the tunnel was run in tunnel mode without any VTI/GRE interfaces. This update fixes that.


This is the official release announcement for IPFire 2.21 - Core Update 129 - an update that introduces routed IPsec VPNs and comes with various other changes that update the core system and fix several bugs.

IPsec Reloaded

IPsec has been massively extended. Although IPsec in IPFire is already quite versatile and delivered high performance, some features for experts were required and are now available through the web UI:

  • Routed VPNs with GRE & VTI
  • Transport Mode for net-to-net tunnels
  • IPsec connections can now originate from any public IP address of the IPFire installation. This can be selected on a per-connection basis.

The code has also been cleaned up the UI has been made a little bit tidier to accommodate for the new settings.

Smaller changes include:

  • The "On-Demand" mode is finally the default setting. Tunnels will shut down when they are not used and they will be established again when they are required.

Misc.

  • DHCP: A crash has been fixed when filenames containing a slash have been entered for PXE boot.
  • DHCP: Editing static leases has been fixed
  • Domains in the "DNS Forwarding" section can now be disabled for DNSSEC validation. This is a dangerous change, but has been requested by many users.
  • Updated packages: bind 9.11.6, groff 1.22.4, ipset 7.1, iptables 1.8.2, less 530, libgcrypt 1.8.4, openssl 1.1.1b, openvpn 2.4.7, squid 4.6, tar 1.32, unbound 1.9.0, wpa_supplicant 2.7
  • New commands: kdig 2.8.0
  • The build system has been optimised to reduce build time of the whole distribution to around 4-5 hours on a fast machine.

Add-Ons

  • Alexander Koch has contributed zabbix_agentd which is the agent that is installed on the monitored machine. With this, IPFire can now be integrated into an environment that is monitored by Zabbix.
  • On that note, the SNMP daemon has also been updated to version 5.8 for people who use the SNMP protocol for monitoring.
  • tor has been updated to 0.3.5.8 and some minor bugs have been fixed in the web user interface
  • The spectre-meltdown-checker script is available as an add-on which allows IPFire users to test their hardware for vulnerabilities
  • Other updates: amavisd 2.11.1, hostapd 2.7, postfix 3.4.3

Thank you very much to everyone who contributed to this Core Update. Please support our project and donate today so that we can keep up our work!


This is the official release announcement for IPFire 2.21 - Core Update 128; another maintenance update with a brand new kernel, introducing TLS 1.3 throughout the whole system and of course a whole package of bug fixes and other improvements.

Thanks to everyone who has contributed to this Core Update with either sending in patches, testing, reporting bugs and many many other things. I am quite happy to see the team grow! Thank you very much as well to all of you who have supported our Donations Challenge so far. We have received a lot of nice words and support from you, but we are not there, yet! Please support our project and donate!

Kernel Update

The Linux kernel, the core of the IPFire operating system, has been updated to the latest release of the 4.14 branch. We have added some extra patches to improve hardware support and fix some security vulnerabilities. LEDs of PCengines' APU boards are now supported on newer versions of the mainboard and on those boards, the serial console is always enabled. On x86-based systems, we now support up to 64 processors.

OpenSSL 1.1.1 & TLS 1.3

We have also updated the main TLS/SSL library to OpenSSL in version 1.1.1. This adds support for TLS 1.3 and of course brings various other improvements with it. On browsers that support it, the IPFire web user interface is now available over TLS 1.3 and any outgoing SSL connection from the firewall supports it, too. We ensure that those connections only use secure and performant ciphers to make connections as fast as they can be.

We have also updated the list of trusted Certificate Authorities (CAs).

We have removed any previous versions of OpenSSL from the system which will soon be end-of-life. If you have anything custom that you have compiled yourself on your system, please be aware of that and note that you might potentially rebuild your custom software.

Add-ons provided by the IPFire Project now support TLS 1.3 as well. If you are running a custom configuration for postfix or haproxy make sure that TLS 1.3 is not excluded from the supported TLS protocols.

Performance Tuning

The system is now configured to be able to route more packets. During some benchmarks and testing we have discovered that IPFire does not always use the full performance of the hardware underneath it. While most system probably won't benefit much from these improvements, some systems with very fast processor cores will see a 5-10% increase in bandwidth from and to the firewall as well as routed through it. That comes at the cost of very slight increase of power consumption, but we figured that that is a price worth paying not only provide you a secure firewall, but also a fast one.

Misc.

  • A change of the firewall policy might potentially be backwards-incompatible, but we saw no other way to improve the security of the system: Previously, systems on the ORANGE network were always allowed to connect to the Internet on RED. This was carried over from the very beginning of IPFire when the firewall user interface was way more basic and rules to change this behaviour could not be configured at all. Now, it makes a lot more sense to not have this default which was also not well-known and allow users to create rules to either allow or deny traffic like this.
  • The kdig utility is now available on command line which supports DNS lookups via TLS
  • Updated packages: apache 2.4.38, apr 1.6.5, curl 7.64.0, dhcpcd 7.1.1, ghostscript 9.26, logrotate 3.15, openssl 7.9p1, postfix 3.3.2, strongswan 5.7.2, tzdata 2018i

Add-ons

  • powertop has been updated to version 2.10
  • tor has been updated to version 0.3.5.7
  • sendEmail has been fixed by Rob. The script had a wrong file ownership.

The first update of the year and it is packed with loads of new features, many many performance improvements as well as some security fixes. This is quite a long change log, but please read through it. It is worth it!

To support our project and keep us bringing these updates for you, please donate!

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.

Misc.

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

Add-ons

  • 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

IPFire 2.21 - Core Update 126 released

by Michael Tremer, December 28, Updated December 28

Finally, the next release of IPFire is available: IPFire 2.21 - Core Update 126 This update comes with a new kernel and security enhancements. This change log is rather short, but the changes are very important.

Thank you very much to all of you who have supported our Donations Challenge so far. We have received a lot of nice words and support from you, but we are not there, yet! Please support our project and donate!

Linux 4.14.86

The kernel has been updated to the latest version of the Linux 4.14.x branch which brings various improvements around stability, enhances performance and fixes some security vulnerabilities. This kernel also has major updates for the Spectre and Meltdown vulnerabilities that remove previously existent performance penalties in some use-cases.

The kernel's modules are now compressed with the XZ algorithm which will save some space on disk as the kernel is one of the largest components of IPFire.

Misc.

  • openssl has been updated to 1.1.0j and 1.0.2q which fixes some minor security issues and has various bug fixes
  • The bind package has now changed to ship shared libraries which it did not before. Those allow that commands like dig and host use those shared libraries and are no longer statically linked. This makes the files a lot smaller.
  • Stéphane Pautrel has substantially improved the French translation of IPFire. Thank you very much for that!

Add-ons

  • Updated packages: bird 2.0.2, nano 3.2
  • New packages: shairport-sync

Thanks for the people who contributed to this Core Update. Please support us and donate!


The end of another year

by Michael Tremer, December 24, Updated December 25

It is the end of another year and I would like to take this opportunity to simply say thank you. It has been an eventful year and we have come a long way.

The Stats

We have brought you eight Core Updates with probably the largest changes that we have had in a while. A new kernel 4.14 that is running better than ever before; we have had a spring clean and remove loads of old add-ons and other packages to make space for new ones as well as getting rid of some older cryptography; we fought Meltdown and Spectre; we have launched IPFire on AWS and added support for EFI and 802.11ac WiFi; we have added loads of new features that make IPFire simply better.

We are all proud of our achievements and I would like to thank everyone who has contributed. Whether that is by submitting patches, reporting bugs, writing documentation and all the other things. You guys know who I am talking about.

Take a couple of days off and enjoy the holidays. Merry Christmas if you are celebrating. Hope to see you all again next year!

Twenty-Nineteen

Of course we already have loads of plans for the next year. We have a bug tracker full of feature requests, error reports and ideas how to improve things. We also hope that we can finally move IPFire 3 over the line so that the project gains more traction - and a new Core Update is ready to be released, too!

We hope that our community keeps growing, more and more people keep installing IPFire and finally throw away their old gear. We have achieved a lot, but there is definitely loads to do, still.

Please Donate Today

Help us to achieve our goals! We are still running our donation challenge which unfortunately has not hit its goal, yet. Please consider to support our project and donate today. If you have already done so and set up a monthly donation, we thank you very very much for that.


Finally, the next release of IPFire is available: IPFire 2.21 - Core Update 125 This update comes with various security and bug fixes as well as cleanups and some new features.

Thank you very much to all of you who have supported our Donations Challenge so far. We have received a lot of nice words and support from you, but we are not there, yet! Please support our project and donate!

802.11ac WiFi

The IPFire Access Point add-on now supports 802.11ac WiFi if the chipset supports it. This allows better coverage and higher network throughputs. Although IPFire might not be the first choice as a wireless access point in larger environments, it is perfect to run a single office or apartment.

Additionally, a new switch allows to disable the so called neighbourhood scan where the access point will search for other wireless networks in the area. If those are found, 40 MHz channel bandwidth is disabled leading to slower throughput.

Misc.

  • strongswan 5.7.1: This updated fixes various security vulnerabilities filed under CVE-2018-16151, CVE-2018-16152 and CVE-2018-17540. Several flaws in the implementation that parsed and verified RSA signatures in the gmp plugin may allow for Bleichenbacher-style low-exponent signature forgery in certificates and during IKE authentication.
  • The IO graphs now support NVMe disks
  • The SFTP subsystem is enabled again in the OpenSSH Server
  • Swap behaviour has been changed so that the kernel will make space for a large process when not enough physical memory is available. Before, sudden jumps in memory consumption where not possible and the process requesting that memory was terminated.
  • The backup scripts have been rewritten in Shell and now package all add-ons backups with the main backup. Now, it is no longer required to save any add-on configuration separately.
  • Updated packages: apache 2.4.35, bind 9.11.4-P2, coreutils 8.30, dhcpcd 7.0.8, e2fsprogs 1.44.4, eudev 3.2.6, glibc 2.28, gnutls 3.5.19, json-c 0.13.1, keyutils 1.5.11, kmod 25, LVM2 2.02.181, ntfs-3g 2017.3.23, reiserfsprogs 3.6.27, sqlite 3.25.2.0, squid 3.5.28, tzdata 2018g, xfsprogs 4.18.0

New Add-Ons

  • dehydrated - A lightweight client to retrieve certificates from Let's Encrypt written in bash
  • frr, an IP routing protocol suite and BGP and OSPF are supported on IPFire. Find out more on their website.
  • observium-agent - An xinet.d-based agent for Observium, a network monitoring platform

Updated Add-Ons

  • clamav has been updated to 0.100.2 and the virus database files have been moved to the /var partition. This makes more space available on the root partition.
  • nfs 2.3.3, haproxy 1.8.14, hostapd 2.6, libvirt 4.6.0, tor 0.3.4.9

Thanks for the people who contributed to this Core Update.

Please help us to support everyone’s work with your donation!


Donations Challenge

by Michael Tremer, November 18, Updated March 13

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!

Update from Wednesday, Mar 13 2019: So far, we have 19 monthly recurring donations :( We had hoped for more to be able to do more. Please donate today!

Update from Wednesday, Dec 12 2018: So far we have 17 monthly donations! Thank you for everyone who donated. We got an amazing number of smaller one-time donations which is amazing, too, but please consider setting up a monthly donation if you can!

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

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, 2018, 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.