Starting with upcoming Core Update 164, the firewall options page will feature a new checkbox: Drop packets from and to hostile networks. For basic protection of our users and their networks, it will be enabled by default on new installations, staying disabled on existing IPFire systems (but we recommend to turn it on there as well).

Improving network protection for the masses

Although we always preach IPFire is not meant to be installed and then forgotten, we believe this is what happens to a decent amount of installations out there: They are set up once, perhaps being configured in a basic manner, and do not receive any attention afterwards. Resources are scarce, so why bother touching a running system?

Of course, we neither endorse such a modus operandi, nor can we shed the load from our users to define and enforce a proper security policy (including firewall rules and IPS settings, just to name a few ingredients) on their networks.

On the other hand, there are some shady areas of the internet, and virtually everyone in the security community knows about them. A subset of them is so dangerous that you don't even want to process any IP connection from or to them, no matter what.

Having a list of such networks at hand, configuring appropriate firewall rules for dropping such traffic is no problem for skilled users. But why should we make this unnecessary complicated? Why not do this by default?

Simple, yet effective

Since version 0.9.9, libloc, the library behind the IPFire Location database, tags networks and Autonomous Systems being listed by Spamhaus DROP. In IPFire, we use the special country code XD for them, similar to A1 to A3 for anonymous proxies, satellite ISPs and anycast networks. Needless to say, a network is only flagged this way if it poses a significant technical threat:

The Spamhaus DROP (Don't Route Or Peer) lists are advisory "drop all traffic" lists, consisting of netblocks that are "hijacked" or leased by professional spam or cyber-crime operations (used for dissemination of malware, trojan downloaders, botnet controllers).

The aforementioned firewall options checkbox just drops and logs all traffic appearing on the RED interface from and to these networks. As simple as that. Of course, if you know what you're doing, this filter can be deactivated, that such traffic will be processed by IPFire again. It's your firewall after all.

No Silver Bullet

By preventing network communication with the baddest of the bad areas on the internet, we achieve to improve the security of IPFire users in general, especially when it comes to outgoing traffic, and on installations receiving little attention due to lack of resources or knowledge.

However, it is important to understand this change is far from a silver bullet:

• Disrupting malicious traffic - such as C&C communication, malware downloads or accessing phishing sites - does not secure the offending device. As long as a client behind IPFire is infected, it still poses a significant threat to the security of both internal networks, and the internet community.
• Thanks to sloppy abuse handling, cyber criminals have an easy time abusing legitimate infrastructures, especially at some western IT giants, for hosting their infrastructure. Since IP allocations in such networks tend to be very volatile, and these networks are not malicious per se, these will slip through.
• In terms of security, it is best to provide network connectivity on a need-to-work basis: If a client cannot establish any connection to the internet because it does not need to do so, it is much harder to infect and control after being compromised. As mentioned, general information security, a strict firewall ruleset and a good IPS configuration remain important.

While existing installations remain unchanged, this filter can be easily enabled on them as well - and we strongly recommend to do so. As always, please help us test upcoming Core Update 164, and donate if you like what we are doing. Stay safe!