Following a certain unethical logic, it makes sense for an attacker to hit the weakest the hardest. Why bother with a reasonably secure firewall if the system behind it is missing important patches? Why try targeting the skilled IT staff - which will ignore the attempt at best, if not blocking your infrastructure for the entire network - if their stressful HR colleagues click on every link and open every document they see? As important as an IPFire's configuration is, this post focuses on the systems behind such a firewall, considering important aspects in terms of both security and privacy.

Separate activities and devices

While living a double life reminds us of spy thrillers or action movies, most people not only live a double life, but multiple lives - usually without being aware of it. Behaviour, habits and disclosed information usually differ significantly if one is in a private or professional context. Depending on the norms of the society one lives in, those spheres are more or less strictly separated from another. While they are the most important ones, they do not fit any given situation, such as being active in a club (neither professional nor private), meeting friends, or communicating with total strangers.

People do separate those spheres from another - but not when it comes to electronic devices.

Unless prohibited by the employment contract or companies' guidelines,² personal mobile phones are carried to the office or private USB sticks are used to transfer work done at home into the corporate network, causing a cross-contamination between those spheres. As mentioned earlier, the former pose a serious privacy threat as they basically leak information of their users activity by design.

However, buying a dedicated computer for any part of your life is neither practical nor - in terms of environmental protection - desirable. So what now?

Do not run closed-source operating systems

Let's take a step back: In 2020, the most popular desktop operating system for both private and professional usage is Microsoft Windows, well ahead of Apples Mac OS. The number of Linux/BSD desktop users is, unfortunately, negligible.

It may sound like an eternal mantra, but running closed-source software is a bad thing. While this does not necessarily make open-source software intrinsically secure or better in any terms whatsoever, examining, auditing or customising is easier by an order of magnitude.

In case the vendor does not ship a security update or does not provide you with an easy solution to turn off unwanted features such as telemetry, then, at least in theory, you have the opportunity to fix that on your own. On the other hand, the vendor's conflict of interest is obvious: People do not pay for security fixes,³ and in order to make revenue, discontinuing support for older products and making users buy the new ones is a common strategy.

The privacy side does not look better: German Federal Office for Information Security has been conducting a study on important aspects of Windows 10 in terms of security and digital sovereignty for years - it's abbreviation SiSyPHuS ("Studie zu Systemintegrität, Protokollierung, Härtung und Sicherheitsfunktionen in Windows 10", en: "Study on System Integrity, Logging, Hardening and Security relevant Functionality in Windows 10") speaks for itself. Recently having issues with their OCSP server, Apple was found to transmit information of executed applications in clear text every time they are executed, effectively leaking the user's activities and identity (i.e. IP address) to themselves, their CDN (Akamai), and everyone in between.

In terms of privacy, running those operating systems is not just bad, it's not an option anymore.

However, running an open-source operating system does not solve the cross-contamination discussed earlier. Running and maintaining a set of VMs just for doing different things is a lot of work both for using and configuring or patching them.

In the authors opinion, Qubes OS aims to provide a useful and holistic solution to this problem. Trying to separate its users digital life according to his or her analogue one, it makes running and switching between multiple electronic lifes suitable for everyday use.⁴

Needless to say, this does not come for free - Qubes OS more demanding hardware requirements than common operating systems - and requires some time and effort for setup or customisation, and splitting up data into different VMs. Ultimately, the author believes it is worth the effort for both security and privacy.

Avoid VPN providers: Nobody is going to jail for you for a few bucks per month

A feature frequently asked to add to IPFire is supporting traffic redirection through an IPsec or OpenVPN connection to a VPN provider. While doing so is rather easy and usually does not introduce limitations or compatibility issues to any application, it creates a false sense for privacy:

• Most applications are not prepared for trying to hide their users' identity, which is why such a configuration frequently creates side-channels such as DNS leaks or being susceptible to fingerprinting attempts.
• Trustworthy of VPN providers is a much, sometimes heatedly debated issue. From a technical perspective, it is trivial for a VPN provider to establish a correlation between a users public IP address and the (pseudonymous) IP address of a VPN server used. Needless to say, this is a terrible constellation.

To put it drastically: Nobody is going to jail for you for a few bucks per month. A VPN provider certainly not, which is why we do not implement such a feature into IPFire.

The author recommends Tor as an alternative. Being a low-latency anonymity network, it has some (design) flaws as well, particularly when it comes to traffic correlation attacks, however, alternatives are believed to be substantially worse.

Caveats when using Tor

Especially for highly threatened Tor users, a look at the country-level distribution of both guard relays (i. e. those relays a Tor client will pick as an entry to the Tor network and tries to sticks to for several months) and exit relays (relays for accessing the "normal" internet from the Tor network) those days reveals an unpleasant correlation: In both cases, the list is led by Germany - some larger exit relay clusters are hosted in greater Berlin and Nuremberg -, France and the United States.

This means that there is a non-trivial chance to have a Tor connection being passed through these countries - or even just one of them. With close cooperation in intelligence matters and increasingly anti-data protection legislation, this concentration is certainly not desirable.

Especially for guard relays, which are the only ones in a Tor connection being aware of the users public IP address, the author suggests to choose them manually, preferring guards operated by well-known organisations and/or located in countries to whom the users country has no or poor diplomatic relations.

It is not wise to do so for exit relays as well, since they are chosen dynamically for every connection through the Tor network, however, depending on the adversaries capabilities, one might want to tell his or her Tor client to avoid exit relays in certain countries.

While the commonly used Tor Browser is pretty resistant if configured properly, it cannot protect against advanced attacks such as keystroke fingerprinting or downloaded files emitting traffic directly, bypassing Tor and compromising the users' anonymity. Because of this, the author recommends using a specialised distribution such as Whonix instead - mentioned Qubes OS comes with it by default.

Finally: brilliant or paranoid ideas

Even if IT security is never really dull, it can be tiring to follow the news or always discuss the same protective measures or - if things go well - implement them. Believing in simple, but effective security mechanisms, the author would like to share some rather unorthodox ideas at the end of this series:

• Consider spoofing your device's MAC address by your operating system: It might make vendor fingerprinting more harder, and if the original MAC address becomes active, your system has either lost that setting or somebody is using a different (live?) operating system on that device.
• When singing up somewhere, make your inputs unique by embedding typos or using dedicated mail addresses. In case of data leaks, this makes identifying their origin more easy and correlation attempts to other accounts more hard.
• Insert dummy entries to address books and contact lists. If somebody contacts their mail addresses or phone numbers, the device you stored those lists might have been compromised.
• If your devices are connected by wire (as recommended earlier) using a switch, place it within range of vision and keep an eye on the port activity LEDs of inactive devices. If there is too much traffic on such ports, they might just download updates (which one should be quickly able to tell according to the list of active processes) or perform some post-infection activities such as C&C communications, sending spam, or similar. On Windows machines, be aware of some malware abusing the BITS service to download additional files.

EOF

This is the final post of a short series regarding countermeasures in an increasingly hostile internet and an IT security landscape being much worse than the author ever imagined it could be.
While current and foreseeable future developments give little cause for joy or optimism, the author hopes that this series was useful in order to configure your IPFire system and secure the networks protected by it better.
Actually, there are plenty of tools for good IT security. You just have to deal with them and then you can easily protect yourself.

The bill mentioned initially, however, which obliges providers to insert state trojans into network traffic on demand, has surprisingly been supported by the Social Democrats parliamentary group since mid-October and will most probably be adopted shortly, despite massive criticism from industry associations, data protectionists and legal experts.

This article series, for reference, consists of:

1. German bill provides network traffic redirection to install state trojans
2. Information security recommendations for IPFire users
3. DNS configuration recommendations for IPFire users
4. Firewall configuration recommendations for IPFire users
5. Thoughts on operations security for the masses
6. IPS configuration recommendations for IPFire users
7. Beyond The Far Side: Thoughts on secure and private machines behind IPFire (which you are currently reading)