As announced last week, this is the first post of a small series containing security recommendations for IPFire users. The series mainly applies to home users - which are estimated to roughly make up a third of all IPFire installations - and aims to achieve a security level that also offers protection against sophisticated attackers.

When it comes to IT security, you will need to rely on the users sooner or later - think about being lured to enable Macros in malicious MS office documents. This is why raising security awareness of both administrators and users is the first step to a less insecure network. Hence this post focuses on non-technical aspects and preemptive information security (sometimes abbreviated as "infosec") considerations.

The trouble with restoring confidentiality

Regarding infosec, integrity and confidentiality are among the security goals to be achieved. The latter is more difficult to deal with, as it is usually impossible to restore: Once information has lost its confidential state, it cannot be made confidential again. When it comes to login credentials, you might at least be able to change them (and hope for the affected systems to be fully secured meanwhile), thus rendering them unusable to the attacker. Obviously, this only applies to a fraction of all confidential information stored and processed within IT systems.

Creating a risk analysis is a common way of deciding which defense techniques and layers are needed in certain scenarios, keeping the entry and particular ongoing costs as low as possible. A part of such assessments usually consists of identifying the attackers (script kiddies, professional/organised cyber criminals, governments, etc.), which of course require different security countermeasures.

The author has never been very fond of such analysis, since they tend to oversimplify threats. For example, unforeseeable events or adversaries are regularly excluded because necessary countermeasures are too expensive or hard to understand by superiors. Ultimately, however, attackers do not care about whether or not they or their techniques were part of such risk assessments.

Therefore, one has to be effectively prepared against any type of attacker, especially when it comes to confidentiality. This is commonly paraphrased as being "proactively paranoid", and is very useful as a baseline for (personal) security considerations.

RTFM - your adversaries will do as well

Let's face it: People do not read manuals, at least they do not like to do so. Anybody is in a hurry, so some search engine queries here, a little copy & paste there and restarting things if they do not work probably will do.

In most cases, it will. However, when it comes to a firewall, this creates a false sense of security (which is worse than having no security at all), since you have no idea what you were doing and why. Elsewhere people call something like that "security by obscurity". In this case, you are hiding your networks' vulnerabilities from yourself.

A considerable amount questions asked at the IPFire community portal can be solved by just pointing people to IPFire's documentation. Your adversaries will have read those. They probably know you and your system inside-out.

If you care about security - and even if you don't -, go read the f***ing manual.

Nobody can do this for you. The more you know about your infrastructure, the better you can decide what steps are necessary to protect it, and what is going to happen if you enable or disable certain things.

Do not trust the vendors

Expect hard- and software vendors to be lying to you - on purpose or by chance. Although none of us has sufficient resources to validate even most basic functionalities of modern operating systems comprehensively, it should raise suspicion if vendors are obviously trying to prevent third parties from understanding technical details of the services or products they offer.

Make sure you have good knowledge of your devices and their operating systems, how they work and what to do in case of security incidents. While this sounds trivial, it can be very hard to achieve - especially if an operating system does not behave deterministic or introduces fundamental changes to its (security) architecture through updates.

Security costs money. And money is short. Most commercially available security products strive to protect the majority of their users from the majority of attacks in the majority of the time. Some vendors apparently do not even aim at that level, designing their products in such a way that they barely protect against the most common attacks. They are not helping if you have to rely on your networks' security.

Supply network access on a need-to-work basis

The fewer devices connected to your network, the less you need to secure. Even if a device cannot be reached from the internet directly, it might be attacked by a compromised one within the same network. Isolating them as best as possible would require galvanically isolated infrastructure, which costs usually quickly exceed an acceptable level. Introducing VLANs merely is a compromise, as those can be bypassed if involved VLAN infrastructure is misconfigured or vulnerable itself.

Limiting network access to devices which do not work without it not only makes things less insecure, it also makes the IT administrators' life less troublesome.

Modern homes, for example, come with more and more devices being capable of (and sometimes even require) being connected to the internet. Make sure you posses as few of them as possible, and restricted their network access to essential services and destinations.

This, of course, is not chic, but it is worth a thought. To the author's concern, the amount of connected devices needed is actually pretty low. Much of it consists of those pretending to make life more easy or comfortable. Unfortunately, they tend to leak sensitive, sometimes even intimate data, come with poor if any security measures in place, making the - arrogant - assumption of having a direct internet connectivity at the same time.

Be careful if a device can be connected to networks beyond your control

Special consideration should be given for so-called dual-homed devices, such as notebooks or smartphones: They often have more than one network interface and can be connected to different networks at the same time.

This a security threat as you cannot make sure the firewall observes all of the traffic that device is emitting. Perhaps it is compromised, but communicates to it's C&C server via cellular network only. Perhaps a more advanced attacker is intercepting WiFi signals coming out of your home from a nearby location (this is how law enforcement agencies correlated IRC activity of a suspected LulzSec member to an individual in Chicago, who was later accused and sentenced to prison), possibly even exploiting automatic dial-in mechanisms into public WiFi networks.

Do not mix network connectivity of such devices, and avoid wireless networks whenever possible.

Ensure you notice security incidents

A security incident you noticed twice is better than one you have not noticed at all. Spend some time on thinking about how to make sure to achieve that.

For example, most monitoring setups alert in case of predefined threshold values being exceeded or systems becoming unavailable. If an attacker managed to compromise a monitored machine (or the monitoring system itself), he might disable certain checks or forge their results so they continue to look fine. To increase chances of detecting such events, consider running integrity checks irregularly while running checks indicating a successful attack very often (e. g. the number of users logged in might be checked every five seconds). Become suspicious if you receive an unusual low amount of notifications or alerts.

To finish with a concrete example applicable to IPFire machines: If you have set up the Intrusion Prevention System (IPS), consider monitoring the number of IPS hits within, for example, the last 24 hours. Events related to internal IP networks are especially interesting, as they might indicate anomalies or attacks.

If you observe an unusual low amount of attacks, this might be because an attacker has disabled the IPS. Monitoring the process list for /usr/bin/suricata instances running as suricata makes detecting such scenarios more easy. Since an adversary could still disable all IPS rules, which is why you consequently need to monitor the your IPS' configuration as well.

Stay alert

Unfortunately, it is very hard to keep security in general and those recommendations in particular in mind all the time. Attackers, however, are in the strategic advance of being able to strike any time, regardless if you are prepared or not. If nothing (visible) happens, most defense mechanisms are loosened after sooner or later, people become more used to rather sketchy security threats and repeating alarms due to false positives cause new ones not be taken that seriously.

Stay alert. Stay suspicious. Do not forget about the most basic security such as applying patches quickly or installing as little software as possible. It is not easy, and it for most of the time, it is boring. But you do not want the thrill after discovering compromised devices or data leakage.

Thank you for making it through this long and not very jolly post. Next time, we get down to technical issues again, starting with DNS configuration advice.