We have been busy baking another large update for you which is full of oozy goodness. It includes an updated toolchain based on GCC 10 and glibc 2.32 and we have added a lot of tuning which makes IPFire 33% faster on some systems.

Toolchain Update

IPFire is based on glibc 2.32, the standard library for all C programs, and GCC 10.2, the GNU Compiler Collection. Both bring various bug fixes and improvements.

The most notable change is that we have decided to remove a mitigation Spectre 2 which caused that user space programs in IPFire were running about 50% slower due to using a microcode feature which is called "retpoline". Those "return trampolines" disable the branch prediction engine in out-of-order processors which was considered to help with mitigating leaking any information from any unaccessible kernel space.

This is however not as effective as thought and massively decreases performance in the user land which mainly affects features like our Intrusion Prevention System, Web Proxy and URL filter. We still use this mechanism to avoid leaking any kernel memory into the user space.

On top of that, we have updated various tools used for building IPFire as well as core libraries.

We have also enabled a new GCC feature called "stack clash protection" on x86_64 and aarch64 which adds additional checks to mitigate exploits and we have enabled "CF protection" which hardens all software against attackers gaining control over a program flow and circumventing security checks like password or signature validation.

BootHole, aka GRUB 2.04

As reported on the media, there were various security vulnerabilities in the GRUB boot loader which is used in IPFire on x86_64, i586 and aarch64. These have now been patched in IPFire and the new boot loader is installed automatically.

Intel Security Vulnerabilities & Virtual Machines

In May 2019, we have announced to disable SMT on all machines. This is now disabled for any virtual machines since the mitigation is required to be activated on the host system.

Emulated processors might run on multiple physical processors which IPFire in a virtual machine has no control over. However, we still recommend against running IPFire in a virtual environment.

Deprecating i586

This release also officially degrades the i586 architecture to a secondary architecture. On the download page, you will already find downloads for that architecture at the bottom of the page.

This is because various security mitigations are not available for i586 and development work on the Linux kernel and other software that IPFire relies on is mainly done for x86_64 or other modern 64 bit architectures. This is a development that we saw coming for a while now, and despite that we will try to keep IPFire available in this architecture.

We urge everyone who's hardware supports it to update their systems to x86_64. You will see a notification on the web user interface if you are affected.

Misc.

  • OpenSSL: We have removed all ciphers that do not support Perfect Forward Secrecy from the default cipher list. That means that all programs in IPFire that initiate TLS connections will no longer accept any "weak" ciphers without PFS.
  • OpenVPN
    • In order to make IPFire compliant with PCI DSS, OpenVPN requires all clients to use TLS 1.2 or newer. This change is automatically enabled on all systems and very old clients might need to be updated. Please check if you are using any outdated clients before updating.
    • The maximum number of simultaneous OpenVPN connections can now be set to up to 1024 and was limited to 255 before.
  • New packages: zstd, a modern and fast compression algorithm is now part of IPFire
  • Updated packages: apache 2.4.46, bind 9.11.21, bison 3.7.1, curl 7.71.1, GRUB 2.04, intel-microcode 20200616, hyperscan 5.3.0, iproute2 5.8.0, kbd 2.2.0, logrotate 3.17.0, lsof 4.91, mpfr 4.1.0, popt 1.18, unbound 1.11.0, xfsprogs 5.7.0

Add-ons

  • Updated: clamav 0.102.4, dnsdist 1.5.0, haproxy 2.2.2, fping 5.0, libvirt 6.5.0, minicom 2.7.1, nfs 2.5.1, postfix 3.5.6, qemu 5.0.0, rsync 3.2.3, spandsp 0.0.6, tor 0.4.3.6, tshark 3.2.6, usbredir 0.8.0, watchdog 5.16, WIO
  • Marcel Follert has contributed a new package: socat, a CLI tool which can be used to communicate with UNIX sockets.

The last post discussed a secure configuration of the IPFire firewall engine, and, like all other previous posts of this series, referred to a certain aspect of or information security in general. Although if this is undoubtedly an important aspect of IT security - perhaps the most important one -, it is worth looking beyond the box.

Therefore, this post focuses on operations security (commonly abbreviated as "opsec") and its importance for the masses. We will learn how infosec and opsec affect each other, why opsec should play a role in everybody's life, and how it can look like in particular. Depending on your adversaries and threat level, this post might be too paranoid or not paranoid enough - the author would like to apologise for both cases. Also, it is not directly related to IPFire, however, the author assumes that IPFire users are more security-conscious than the average internet user.

Disambiguation

"Operations security" originally comes from the military. Although it was only coined by US military during the Vietnam War in 1966, signs warning of potentially tapped phone lines already existed in World War I. Virtually all parties involved in World War II used similar campaigns to raise awareness of spies among the population, with striking statements such as "loose lips might sink ships" or "the enemy is listening".

Nowadays, opsec is commonly paraphrased as the process to identify and protect information which might, if aggregated with others, leak critical details of an ongoing or planned operation, involved persons, their organisational structure and their real identities. Countermeasures to protect those or reduce their criticality might be both technical and non-technical.

While the conventional definition includes considerations against specific threats, vulnerability and risk analysis as well, this post is based on the more general definition given above.

Why operations security matters

Even tough the term still strongly reminds of war and military actions, operations security became more and more important to management bodies or senior staff as industrial espionage increased. Obviously threatened individuals or communities such as human rights activists, investigative journalists, victims of domestic violence or regime critics (and, consequently, organisations behind Advanced Persistent Threats (APTs)) usually rely on opsec as well, sometimes without being aware of it.

However, very few of us are likely to belong to these groups, so why care about opsec as an average person in the daily life?

The answer is twofold: First, future threats and adversaries are rarely predictable. Most information disclosed does not look worth protecting in the first place, but might later be used against their source. Catchy examples are party photos on social media that later raise uncomfortable questions in job interviews, or soldiers who inadvertently reveal details of covert missions by using smart fitness trackers. Imagine your employer becoming subject to industrial espionage, future governments being repressive, or similar changing circumstances: As mentioned in an earlier post, it is impossible to restore confidentiality of disclosed information - however, until they are directly affected, most people do not seem to notice about that.

Second, we all have adversaries. Those might be obvious, such as competing companies, but ultimately, the author considers mass surveillance to be every single body’s threat, especially when it comes to surveillance abuse. Since about two decades, we see global surveillance states emerging (among the biggest are USA, China and Russia), "exporting" privacy threats, (self-)censorship and oppression worldwide. An attack on our privacy also impacts the privacy of people we communicate with.

While it might seem a bit far-fetched to consider them as an adversary in terms of opsec, it can be pretty useful to combine opsec and privacy protection, since their ultimate goal is about the same.

Disclose information on a need-to-know basis

Since you won't know about future attackers, their motivations and security incidents at companies having access to your data, the only thing left for you to do is to disclose as little information as possible to anybody at any time.

Do not participate in social media (the author continues to be surprised how easy it is to get confidential information out of them), not even with private accounts. Their content is still visible to the social media operator itself, and could be disclosed to the public due to software bugs or misconfigurations.

If you take pictures of places, relatives, friends or yourselves, do not publish them - they might leak sensitive information by their metadata or be used for targeted phishing campaigns. In fact, companies such as Clearview AI or PimEyes were recently convicted of scraping image files on the web in order to build face databases.

In the author's opinion, this is especially interesting in terms of blanket data retention, which was declared invalid by the ECJ in 2014. However, if people continue to voluntarily share their information, especially - but not limited to - in social media, we have gained nothing. As long as it is legal or without consequences to simply transfer data to regions with more lax data protection regulations in order to be able to process it there in a way that would be illegal in the region of origin, this also counteracts the intention of a GDPR.

If there is no technical reason why something or somebody needs, for example, your correct date of birth, do not put it in.

Never reveal where you are, who you work for or what you are going to do - this goes for technical details as well. Keep in mind this involves your employer, too: Nowadays, many companies strive for a modern appearance, often publishing details (names, departments, sometimes even pictures) about their employees. While this makes them appear in a positive, more personal and customer-caring light, it expands their attack surface even more towards their employees (spear phishing comes to mind) - which are the weakest link in terms of IT security already. The author therefore believes that keeping professional activities secret makes sense for both employees and employers.

It has become hard to leave as little traces as possible within the daily life. Discount offers or bonus programs often require customer accounts, thus making it easier to correlate personal information and consumer behaviour. Credit card companies observe a significant amount of ones' monetary flow. Data exposed to advertising corporations reveal our habits, our health, our worries. Imagine those information falling into wrong hands (such as intelligence agencies buying them to bypass legal restrictions), or just become public - for example, due to security incidents.

Mobiles: Information leak with phone functionality

When it comes to both security and privacy, cellular networks redefine the meaning of "low end". Leaking your location by design, being (intentionally) vulnerable to downgrade and Man-in-the-Middle attacks while requiring closed-source baseband processors and SIM cards running their own (vulnerable) operating system, they are probably the most insecure way to communicate with each other by electronic means still in operation today.

The fact that designing and manufacturing cell phone spy tools is a separate industry says a lot about the drive to make cell phone networks secure. Best known are so-called IMSI catchers, which are supposed to be used by law enforcement agencies and intelligence services. They are often capable of exploiting countless security vulnerabilities, some of them design flaws, and little is known about how exactly they work.

Looking at various operations security failures (such as CIAs "Italian Job", a network of Lebanese informants uncovered by Hezbollah in 2011 or the same terrorist organisation killing Rafic Hariri in 2005), it becomes clear that it is practically impossible to use a mobile phone in everyday life without giving telecommunications companies, affiliated third parties (such as advertising corporations) and law enforcement agencies detailed insights into your own life. Discontinuing to use smartphones is of no use, as simple mobiles are still vulnerable to SIM- or baseband processor-related attacks and continue to leak metadata. Especially in wealthy areas with a high smartphone penetration rate, they also stick out like a sore thumb.

Metadata is no small matter. The NSA kills people on this basis.

Thereof, the author strongly recommends to avoid using mobile phones and cellular networks at all costs.

Do not use biometric authentication

Using biometric characteristics such as a fingerprint, iris or even the entire face in order to pass authentications is quite popular today, since they are easier to use, require less input on tiny displays of mobile devices, and are assumed to be very secure.

While the latter depends on the sensors' quality, its biodetection, and usually several other circumstances, it is often neglected that biometric authentication lacks protection against several abuse scenarios, such as people involuntarily unlocking their devices held in front of their face, or being forced to press their finger onto a fingerprint reader.

Worse, biometric characteristics are effectively public data: You leave your fingerprint pretty much anywhere, so it is trivial to copy. Even worse, biometric characteristics are impossible to change.

To summarise: Biometric authentication means to authenticate people by publicly available, unchangeable information. Even in an ideal world you can tell that this is a very bad idea.

As mentioned at the beginning, operations security also involves non-technical countermeasures. When it comes to biometrics, this includes dress style and appareance: For example, tattoo-based recognition, identification and automated understanding of their meanings is under active research in both USA (NIST, FBI) and Germany (Fraunhofer IOSB) - and probably other countries as well. While it looks chic to wear clothes with prints from conferences you attended, products you bought, or similar, they are effectively information leaks, making identification much easier.

You do not decide what information you disclose - attackers do

As they say, a thousand straws in the wind may or may not make a rope together. This decision is not even up to you, as you do not decide what information you disclose, but what information you intended to disclose. Ultimately, attackers make the former decision, but people are rarely aware of this.

Keeping operations security in mind and acting accordingly is laborious, time-consuming, and often goes along with a loss of comfort. If you are already used to it for professional or private reasons, this is not news for you. Otherwise, consider operations security becoming a part of your daily life - it might pay off later.

A secure configuration of IPFire's Intrusion Prevention System is the subject of the upcoming post.


We have been busy baking another large update for you which is full of oozy goodness. It includes an updated toolchain based on GCC 10 and glibc 2.32 and we have added a lot of tuning which makes IPFire 33% faster on some systems.

Toolchain Update

IPFire is based on glibc 2.32, the standard library for all C programs, and GCC 10.2, the GNU Compiler Collection. Both bring various bug fixes and improvements.

The most notable change is that we have decided to remove a mitigation Spectre 2 which caused that user space programs in IPFire were running about 50% slower due to using a microcode feature which is called "retpoline". Those "return trampolines" disable the branch prediction engine in out-of-order processors which was considered to help with mitigating leaking any information from any unaccessible kernel space.

This is however not as effective as thought and massively decreases performance in the user land which mainly affects features like our Intrusion Prevention System, Web Proxy and URL filter. We still use this mechanism to avoid leaking any kernel memory into the user space.

On top of that, we have updated various tools used for building IPFire as well as core libraries.

We have also enabled a new GCC feature called "stack clash protection" on x86_64 and aarch64 which adds additional checks to mitigate exploits and we have enabled "CF protection" which hardens all software against attackers gaining control over a program flow and circumventing security checks like password or signature validation.

BootHole, aka GRUB 2.04

As reported on the media, there were various security vulnerabilities in the GRUB boot loader which is used in IPFire on x86_64, i586 and aarch64. These have now been patched in IPFire and the new boot loader is installed automatically.

Intel Security Vulnerabilities & Virtual Machines

In May 2019, we have announced to disable SMT on all machines. This is now disabled for any virtual machines since the mitigation is required to be activated on the host system.

Emulated processors might run on multiple physical processors which IPFire in a virtual machine has no control over. However, we still recommend against running IPFire in a virtual environment.

Deprecating i586

This release also officially degrades the i586 architecture to a secondary architecture. On the download page, you will already find downloads for that architecture at the bottom of the page.

This is because various security mitigations are not available for i586 and development work on the Linux kernel and other software that IPFire relies on is mainly done for x86_64 or other modern 64 bit architectures. This is a development that we saw coming for a while now, and despite that we will try to keep IPFire available in this architecture.

We urge everyone who's hardware supports it to update their systems to x86_64. You will see a notification on the web user interface if you are affected.

Misc.

  • OpenSSL: We have removed all ciphers that do not support Perfect Forward Secrecy from the default cipher list. That means that all programs in IPFire that initiate TLS connections will no longer accept any "weak" ciphers without PFS.
  • OpenVPN
    • In order to make IPFire compliant with PCI DSS, OpenVPN requires all clients to use TLS 1.2 or newer. This change is automatically enabled on all systems and very old clients might need to be updated. Please check if you are using any outdated clients before updating.
    • The maximum number of simultaneous OpenVPN connections can now be set to up to 1024 and was limited to 255 before.
  • New packages: zstd, a modern and fast compression algorithm is now part of IPFire
  • Updated packages: apache 2.4.46, bind 9.11.21, bison 3.7.1, curl 7.71.1, GRUB 2.04, intel-microcode 20200616, hyperscan 5.3.0, iproute2 5.8.0, kbd 2.2.0, logrotate 3.17.0, lsof 4.91, mpfr 4.1.0, popt 1.18, unbound 1.11.0, xfsprogs 5.7.0

Add-ons

  • Updated: clamav 0.102.4, dnsdist 1.5.0, haproxy 2.2.2, fping 5.0, libvirt 6.5.0, minicom 2.7.1, nfs 2.5.1, postfix 3.5.6, qemu 5.0.0, rsync 3.2.3, spandsp 0.0.6, tor 0.4.3.6, tshark 3.2.6, usbredir 0.8.0, watchdog 5.16, WIO
  • Marcel Follert has contributed a new package: socat, a CLI tool which can be used to communicate with UNIX sockets.

We ask everyone who can to install this update and report and feedback back to us. That way, you can help to make IPFire better and contribute to the community. If you cannot test, you can donate!