In the last couple of months, we, the IPFire development team, have launched a small side project: A new location database for the Internet. In this article, I would like to give you a brief background story on why and how it come to this...

What is this?

I am sure that you all have used a location database - often called GeoIP database after a brand name from a company called Maxmind. Most likely that was in an online shop that showed you shipping cost based on your location, or you were shown a cookie warning when you visited a website where the EU's cookie guidelines applied.

Other applications would be threat prevention like we use it in IPFire. Connection attempts from certain countries can simply be blocked, or port forwardings can be limited to certain countries only.

That is, however, not an exact science. The Internet changes constantly. IP address ranges are re-assigned from one party to another one, and often it can take some time until those location databases are all updated. Up to that point, you will see wrong information like the Google front page being shown in a wrong language. This might only be a bit of an inconvenience, but for a firewall, we need more recent and reliable data.

Maxmind is the biggest player on the market, and the previous source for GeoIP data in IPFire. They are a Massachusetts-based company and recently changed their terms of their database which was available under a Creative Commons license before. Now, users are required to register before they are permitted to use the database. Although the company claims their database is still free, it is at least a very grey area from our point of view, and since, we have decided to no longer use them. Currently, IPFire ships the last version of the database before registration was required and we did not accept the new end-user license agreement.

Accuracy Issues

Development of our own successor has started long before that, because we have already become more and more unhappy with the accuracy of Maxmind's free data. Potentially it is deliberately made inaccurate to promote paid services. Unfortunately we or any of their customers have no insight on where the data is coming from and how the database is composed.

Since for us, this is security-relevant, we needed these problems fixed.

Most importantly, the data needed to be accurate. We do not care about geo coordinates, or a county or city, but only a country. It isn't really possible to divide the Internet into countries, but what is possible is to have an idea from what jurisdiction someone is accessing a website. For most people, that is enough accuracy.

We also wanted to know from which Autonomous System a user is, because that is the only thing the Internet can be divided into. It is an inter-connected network of autonomous systems and that carries valuable information for us. For example to identify cloud providers.

On top of that, it is often interesting to have other attributes. There are plenty of anonymous proxies out there, that are being used for users to hide. Maxmind is using special country codes (in this case A1) to mark those, but unfortunately that loses the actual country this system is located in.

We added an extra set of attributes that can be used to flag certain networks for various reasons allowing to gather more information without trading in accuracy and use them to mark satellite providers, anonymous proxies and anycast networks.

Finally, we needed to be sure that the database is recent and not modified by a third party. That is something that our competitors do not do. We have instead built a cryptographic signature into the database, so that when it is being downloaded to you local IPFire system, you can be sure that it is coming from us and has not been tampered with before loading it into your firewall.

I will blog more on the technical solutions and challenges in a later post.

Problems solved

So, we are now close to release version 1.0 of what we have built: An always up-to-date location database, that brings you more and accurate data.

We see it as an independent project within the IPFire Project, because not only we can greatly benefit from this piece of software: DNS load-balancers that will steer users to their closest data center, online shops that need to comply with different legal requirements, and many more...

We have implemented it as a C library with a very small footprint and OpenSSL as its only dependency. We then added Python and Perl modules. That way, it can be easily integrated into other software and of course we expect other people to contribute bindings for other scripting languages, etc.

There are download scripts that regularly update the database and use some smart ways to avoid transferring any unnecessary data.

All this is now in its final stages of testing, and you can use it in the latest testing release of IPFire. If you are interested in contributing by either reporting bugs, add language bindings or help making the database more accurate, please join our location mailing list.

More information and a live demo can be found on location.ipfire.org.


After having roamed around infosec in general last week, this post gives some advice on how to gain additional privacy by changing your IPFire's DNS configuration. DNS happens to be a very basic thus quite important protocol of today's internet, but is still being considered a low-risk one when it comes to security and privacy.

DNSSEC - love it or loathe it, it is here to stay

If you are familiar with IPFire, you might have noticed DNSSEC validation is mandatory, since it defeats entire classes of attacks. We receive questions like "where is the switch to turn off DNSSEC" on a regular basis, and to say it once and for all: There is none, and there will never be one. If you are running IPFire, you will be validating DNSSEC. Period.

Another question frequently asked is why IPFire does not support filtering DNS replies for certain FQDNs, commonly referred to as a Response Policy Zone (RPZ). This is because an RPZ does what DNSSEC attempts to secure users against: Tamper with DNS responses. From the perspective of a DNSSEC-validating system, a RPZ will just look like an attacker (if the queried FQDN is DNSSEC-signed, which is what we strive for as much of them as possible), thus creating a considerable amount of background noise. Obviously, this makes detecting ongoing attacks very hard, most times even impossible - the haystack to search just becomes too big.

Further, it does not cover direct connections to hardcoded IP addresses, which is what some devices and attackers usually do, as it does not rely on DNS to be operational and does not leave any traces. Using an RPZ will not make your network more secure, it just attempts to cover up the fact that certain devices within it cannot be trusted.

Back to DNSSEC: In case the queried FQDNs are signed, forged DNS replies are detected since they do not match the RRSIG records retrieved for that domain. Instead of being transparently redirected to a fradulent web server, the client will only display a error message to its user, indicating a DNS lookup failure. Large-scale attacks by returning forged DNS replies are frequently observed in the wild (the DNSChanger trojan is a well-known example), which is why you want to benefit from validating DNSSEC and more and more domains being signed with it.

Since DNSSEC also introduces authentic denial of existence, it enables some improvements such as aggressive NSEC (RFC 8198), where a resolver attempts to determine if a queried record can exist at all according to DNSSEC signatures. If not, there is no need to bother the public DNS infrastructure, thus returning NXDOMAIN to the client faster, which is especially useful for crappy devices querying the same non-existent FQDNs over and over. Needless to say, IPFire comes with common DNS hardening techniques not depending or related to DNSSEC as well, such as cache poisoning prevention or malicious resolvers trying to strip out DNSSEC information.

Do not confuse DNSSEC with DNS over TLS or DNS over HTTPS

While DNSSEC introduces trustworthiness to the Domain Name System, it does not make it more confidential. Despite being unable to tamper with your DNS traffic, an attacker is still able to see which resources are queried. In most cases, those match the web sites visited afterwards, effectively leaking your browser's history up to the "slash" in the URLs, as Michael explained earlier this year.

Unfortunately, DNSSEC and DoT or DoH are regularly mixed up, especially in mass media coverage.

In case you have to combat against a more sophisticated attacker, keeping the list of (frequently) visited web sites confidential might be a good idea to make watering hole attacks more harder, where an attacker tries to inject malware into sites you are likely to visit in future (the NotPetya wiper was distributed that way, causing massive damage especially in Ukraine).

Either way, one might want to hide its DNS traffic from anybody barely able to run a tcpdump on the wire. This includes your ISP, which is why the author would like to stress not using your ISPs resolvers once again.

Choose DoT resolvers wisely

Since using DNS over TLS requires selecting some resolvers capable of TLS, one has to think about which their various aspects of when selecting them (a list of known public resolvers is available from the wiki).

For privacy reasons, it is best to stay away from big resolvers run by profit-oriented companies, such as Google, Cloudflare, Quad9 and others. They do not sell cookies, and they do not provide service for free. If you do not pay with money, you almost certainly pay with your data.

At least in Europe1, there are quite some public DoT resolvers run by non-profit organisations, of which some are engaged in protecting peoples' privacy. Those might be less untrustworthy, but make sure to check their terms and conditions, e.g. for logging policies.

However, in the end, somethings got to give. Even if a resolver operator looks fine, there is usually no way of telling whether or not it does maintain any logs, deletes them properly or has good security practices in place.

To minimise potential damage of data breaches or security incidents, it is therefore recommended to choose at least four DoT resolvers operated by different parties and located in different countries. Depending on legal issues and local adversaries, one might want to entirely avoid resolvers located in the same country as the IPFire machine(s) administered.

"The logs, the logs. All the answers are in the logs."

This quote from Postfix author Wietse Venema does not fully apply to IPFire users, as its DNS resolver, Unbound, is configured not to log queries or even DNS replies. However, it does log DNSSEC validation failures (i.e. queries responded with SERVFAIL), which usually indicate network outages, DNS zone configuration errors, or manipulation attempts by active attackers.

To notice the latter, consider monitoring such events. Depending on your environment, there might be false positives, especially with unstable or overloaded internet uplinks, but in case your banking site fails to validate, things become worth a closer look.

This post assumes all of the clients located behind an IPFire systems are solely using its DNS resolver and are unable to bypass it. This is not always true - for example, some IoT devices come with hard-coded DNS resolver settings -, and some firewall rules are required to enforce this.

This and a secure firewall configuration in general are the topics of the upcoming post.


  1. If you aware of public DNS/DoT resolvers run by non-profit organisations in other continents, please feel free to add them to the mentioned wiki page


This is an update I have personally been waiting for a long time: We finally roll out replacing Maxmind's GeoIP database by our own improved implementation.

IPFire Location

As we have already pre-announced some time ago this side-project inside the IPFire Project is finally ready for prime time.

It comes with a new implementation to build, organise and access a highly optimised database packages with loads of helpful data for our firewall engines, as well as our analytics to analyse where attacks against the firewall are originating from.

With it, IPFire can block attackers from certain countries, or do the opposite - only permit access to certain servers from certain places. Combining rules with the rate-limiting feature allows to limit connections from certain locations which is very helpful for DoS attacks.

No new features have been added, but those that we had have been massively improved. The database is now being updated once a week which makes it more accurate and we no longer require complicated scripts to convert it into different formats to be used in different parts of the operating system.

Instead the database can be opened and ready extremely quickly which allows access in realtime making pages on the web user interface load significantly faster.

We hope that many other projects choose to use our implementation as well, since we have chosen a truly open license for the data as well as the library that works behind it.

I will talk more about this in a later blog post and explain to you the advantages of libloc.

Please help us testing!

In the meantime, please help us testing this important release and report any issues that you find to the development team to make it the best release of IPFire that we have ever had.

You can also support our work with your donation!