We are celebrating 10 years of Lightning Wire Labs!

A whole decade where we have been working to make the Internet a safer place. Time that has been moving fast, has been full of challenges, as well as a time that has been a great success for ourselves, and our customers and partners we work with.

To say Thank You to our loyal customers, we are offering a 10% discount on all our appliances on store.lightningwirelabs.com for all of August1.

Happy 10 Years

In those 10 Years, we are proud:

  • That we have been working together with our great community, creating IPFire which is trusted by millions of users every day.
  • That we support customers ranging from Businesses of all shapes and sizes, Schools & Universities, Governments & Non-Governmental Organisations all over the world and help them to overcome their challenges.
  • We build tools to help people restoring their privacy from overreaching surveillance and data-collecting corporations.
  • We develop market-leading software so that anyone can make their business, organisation or home a secure place.

Thank you to everyone who has been on this journey together with us.

Cheers to the next 10 Years!

  1. While stocks last. Offer ends on August 31st, 2022. Our terms & conditions apply. 


With the latest update of IPFire, a new feature is available which helps to make OpenVPN connections more secure: OpenVPN Two-Factor Authentication (2FA). This post explains what Two-Factor Authentication is, what it is good for, and how to use it with IPFire and OpenVPN.

Hardening OpenVPN User-Authentication - Why?

In IPFire, OpenVPN is using certificates to authenticate any clients against the server. That is the most secure way, because it is virtually impossible to brute-force a certificate. For an attacker, it is much easier to guess usernames because they can be found in email addresses and on company websites and try out various passwords.

However, certificates do not come free of any disadvantages. For example, they can be stolen and so somebody else who is not authorised can use the certificate. It works just like the key to your front door.

In the real world, we have also learned this lesson from credit cards which now have a PIN. Previously, the person who had the card could use it to pay - but nowadays a PIN is required. Since the card can be stolen, the PIN is something that the card holder knows and never writes down. Therefore, the card is useless for the thief and the PIN can be seen as the second factor.

But aren't certificates password protected? Yes, they are - and it provides strong security, unless a weak password is being used - which is sadly too common as any network administrator who has hundreds of VPN connections will tell you. So, in many cases, someone can simply brute-force the password on a stolen certificate on their own computer without anyone noticing.

If someone tries this on a web login, any failed attempts per user or IP address can be logged and the user account can be disabled. Brute-forcing the certificate's password however goes unnoticed which is why we do not consider this as very strong protection.

2FA FTW

This is where Two-Factor Authentication comes in. Authentication is being performed in two steps:

  • The regular authentication using the certificate. That way, we have strong cryptographic means to identify the user that is trying to establish a VPN connection.
  • After that, the user will be asked for a PIN which is being dynamically generated and constantly changing.

The PIN is usually being generated on a second device to make any theft more difficult. That device needs to be synchronised at the very beginning so that it will produce the correct PINs. Garnished with a static password on the certificate, this method provides strong authentication when being reasonably user-friendly at the same time.

How to set this up?

To get started with securing your OpenVPN client connections, you will need to follow these short steps:

  • Go to the OpenVPN configuration page and either create a new Roadwarrior connection with OTP enabled, or enable OTP on an existing configuration. It is just one checkbox.
  • You will then need to import the connection (or reimport if you changed an existing connection) into your OpenVPN client or your laptop or other device
  • Next to the OpenVPN connection, you will now see a little icon with a QR code. Click on that and scan the code with a compatible app. You can find a list of those on the IPFire Wiki.
  • When you now try to establish the VPN connection, you will be asked for your the number that the app is showing you.

That is all. It is very simple and quick to set up, but will massively improve the security of your VPN connections and reduce any potential damage to your network if a laptop with a certificate is being stolen.


The next Core Update - one of the biggest in size we have ever put together - is released: IPFire 2.27 - Core Update 169. It introduces the support of two-factor authentication (2FA) for OpenVPN clients, updates several core parts of the system, provides mitigations for another two types of CPU side-channel attacks, as well as package updates, bug fixes and other security improvements.

Before we talk in detail about what is new, I would like to ask you for your support. IPFire is a small team of people and like many of our open source friends, we’ve taken a hit this year and would like to ask you to help us out. Please follow the link below where your donation can help fund our continued development: https://www.ipfire.org/donate.

OpenVPN Two-Factor Authentication

For OpenVPN clients, the setup of two-factor authentication based on time-based one-time password (TOTP) is now supported. It can be enforced on a per-client basis, preserving the flexibility of mixing end-user devices with machine clients, where no manual interaction is feasible during OpenVPN connection establishment.

Further documentation on this feature can be retrieved here and here.

Updated Kernel, Updated linux-firmware, Updated Toolchain - All in one go

This Core Update updates the Linux kernel to 5.15.49, thus providing our users with the usual bunch of bug fixes, plugged security vulnerabilities, and hardware support improvements. Particularly noteworthy are mitigations against another CPU side-channel attack, MMIO Stale Data, which can led to the exposure of sensitive memory data. Further upstream documentation can be obtained here; IPFire systems not serving as a hypervisor for VMs (which we recommend against for production due to security reasons anyway) are most likely unaffected. The precise status of all known CPU vulnerabilities is displayed in the web interface.

The following kernel hardening improvements have been made in addition:

  • On x86_64 systems, kernel mitigations for straight-line speculation, another CPU side-channel vulnerability, have been enabled.
  • Support for RPC dprintk debugging has been removed to cut potential attack surface.
  • The YAMA Linux security module is now enabled to provide further control on ptrace operations, for which there is no legitimate use-case on an IPFire machine.

Due to an upstream change, the kernel will now always report to have 256 bits of entropy available. Therefore, the entropy graph has been removed, as it does not provide any useful information anymore.

linux-firmware, the conglomerate of proprietary third party firmware, has been updated. That improves the hardware support, particularly for newer devices and components, and fixes bugs as well as security vulnerabilities in these binary blobs.

GCC, the GNU Compiler Collection, has been updated to 11.3.0, bringing fixes to bugs and regressions (some of them serious ones) from upstream to our users.

Miscellaneous

  • For applications running on IPFire itself, the availability of Extension Mechanisms for DNS (EDNS0), as specified in RFC 2671, is now properly announced. This has already been the case for DNS clients querying the resolver of an IPFire installation.
  • Mount options of /boot have been hardened on flash images. Existing installations remain unchanged for the time being, but we plan to apply this change to them as well soon.
  • IPFire's NTP daemon will now use itself as a preferred time source, rather than any hardware RTC. As the latter can be quite unreliably, particularly if CMOS battery power is low, this will result in more accurate time synchronization.
  • A bug in misc-progs, the safety net between the web interface and the operating system, has been fixed, which sometimes led to the swallowing of a commands' first argument.
  • The Hardware Detection Tool (HDT) has been dropped from the CDROM menu, as it does not run on EFI and better tools are nowadays available for hardware detection.
  • Plain OpenVPN PKCS12 files are now properly downloadable again (#12883).
  • A missing dependency for BorgBackup has been added, making this add-on usable again (#12884).
  • Spaces are now allowed again in OpenVPN static IP pool names (#12865).
  • On IPFire instances running in various clouds, user-data scripts are now executed at the end of initialization, ensuring that such systems are fully initialized before conducting user-defined actions.
  • The download URL for Talos IPS rulesets has been updated.
  • Updated packages: Apache 2.4.54, bind 9.16.30, curl 7.81.1, fuse 3.11.0, gdb 12.1, iptables 1.8.8, libnetfilter_cthelper 1.0.1, libnetfilter_cttimeout 1.0.1, libxml2 2.9.14, libxslt 1.1.35, libyang 2.0.194, lmdb 0.9.29, logrotate 3.20.1, lzip 1.23, OpenSSL 1.1.1p, sqlite 3380500, Squid 5.6, tzdata 2022a, unbound 1.16.0, xfsprogs 5.16.0
  • Updated add-ons: aws-cli 1.23.12, clamav 0.105.0, dnsdist 1.7.2, git 2.36.1, libvorbis 1.3.7, lynis 3.0.8, Postfix 3.7.2, python3-botocore 1.25.12, tmux 3.3, Tor 0.4.7.8

As always, we thank all people contributing to this release in whatever shape and form. Please note IPFire is backed by volunteers, maintaining and improving this distribution in their spare time - should you like what we are doing, please donate to keep the lights on, an consider becoming engaged in development to distribute the load over more shoulders.