Hello. I have upgraded to 171 and things run well so far. I was particularly curious about the new IP address blocklists.
So next to the very powerful (and complex) IDS system, ipfire has 3 levels of more simple defences: Location filter, IP address blocklists and the “drop everything from hostile network” option. When I look at the firewall protocoll, I see thousands of entries per day, which is very impressive for a non-pro like me.
I wonder which is the order in which the packets are filtered. Let’s say a packet is coming from a country that is blocked by the location filter and it’s IP is also blacklisted in the IP address blocklist and last but not least is from a know hostile network. So all 3 filters will ring the alarm bell. Now which filter will kick in first and drop the packet and write an entry in the log? Before core 171 I used to have the location filter on (only allowing traffic from my own country) and also activated the Hostile Network protection. I used to have not so many log entries so I thought that the location filter will be the first line of defence and ignore most of the incoming packets. Now with the new IP blacklist feature I get many more log entries. So I guess that this filter is checking the packets before the location filter kicks in, right?
Is there a way to manipulate the order of the filters? Wouldn’t it make sense to have the location filter first, then hostile network filter and the IP blacklist as the 3rd filter?
I do not think so. If I know the IP and can check and block it directly, why should I check the location filter first, especially since this is not a trustworthy filter?
Thanks for your answer! Didn’t know location filter ist not trustworthy. I guess the best order would be the one with the lowest CPU usage and fastest performance.
Concerning the question of the filtering order, two premises:
The rules of iptables are grouped in sets (chains) which in turn are grouped in tables.
The packets follow a predetermined path following a set of criteria that determines first in which table they end up, next in which chain and finally they start following the rules, one after the other, or branching to other chains with the -j directive.
You can simply list the tables in you machines with this command:
cat /proc/net/ip_tables_names
raw
mangle
nat
filter
The table relevant for your question is filter.
Once the packets end up in the table filter they start following the chains defined there, starting with INPUT. They either follow one rule after the other or they jump to another chain.
if you call iptables-save it will list on the screen everything (tables, chains, rules). If you focus on the filter table, you will see first the list of the chain’s names mainly in alphabetic order, followed by the rules listed in the execution order. From there by following the -j directive you can see what is the order of the rules. For example, this is a abridged output of the filter table in my machine:
[...]
*filter <--- table
:INPUT DROP [0:0] <--- chain names, the user defined chains in alphabetic order
:FORWARD DROP [0:0]
[...]
-A INPUT -m mark --mark 0xc0000000/0xc0000000 -j IPSBYPASS <--- first rule of the chain
-A INPUT -p tcp -j BADTCP <--- second rule, and so on
-A INPUT -j CUSTOMINPUT
-A INPUT -j HOSTILE
[...]
[...] means redacted, the arrows are my comments.
You see listed above:
the name of the table,
the first two chains, the list is structured showing first the default chains, followed by the custom in alphabetical order (here redacted),
the rules in execution order, starting with directive -A adding the rule to the INPUT chain,
the -j jump directive to the next chain.
By looking at the -A and -j directive you can follow in which chain the packet ends up, from there you follow the rules, and so on. Take pen and paper and follow the breadcrumbs and you can discover the order of the rules.
I do not know if there is a better method. This is the best way I could find searching the documentation. Looking forward to learning from someone that knows this stuff a better way to do this, if it exists.
There is a wiki page covering iptables and it finishes with a diagram showing the order in which IPFire has everything organised.
It does not have the IP Blocklist in it. The diagram needs to be updated.
I deleted the post because I wrote a stupid thing. Let me try again. The diagram shows only the forward chains, which are used by several tables (tab 6.3), including the filter table which I believe is where the Blocklist chains are.
How can this nest of spaghetti rules be built without a billion bugs makes me appreciate immensely the work of the developers.
Thank you Adolf Belka a lot for that link to the diagram. Very impressive. Now I wonder even more how millions of packets per second can make it through this system of filters, routes, tables blocklists etc. What a great piece of intelligence lies in such code but also in the hardware that can process that code in fragments of a second.
In this post I use table to mean a data-structure of netfilter, and “table” to mean an element of the documentation file linked below.
I wanted to write a follow up to the post above which is a distilled version of my (poor) understanding of netfilter. That post was contaminated by a faulty understanding of the tables vs chain data-structure. I thought that tables were a super-set of chains, which they are, and that this would mean that the packets would be assigned to one table based on certain rules and stick to that table, which was clearly a misunderstanding of their role from my part.
Now I understand that the flow of packets is pretty much chain centered and that tables role is not really structural but more a functional classification of chains that play a similar role, mainly - I assume - for helping with the use of custom chains.
I would like to point to this figure from the official documentation of netfilter (and also from the same document, table 6.1, 6.2 and 6.3):
The figure shows in small letter the table and in bigger font the chain. This figure summarizes in graphical form what is stated by the excellent wiki page that @bonnietwin linked in the above post. The entry point for all the packets is always the PREROUTING chain in the raw table. Then the packet moves to the mangletable followed by the nattable, while remaining in the PREROUTINGchain.
Notice also how in the first important sorting point, the packets can take two paths:
local delivery or
directed to another machine.
Even in this sorting station, they stay in the mangletable, and the cross-roads are the chains (INPUT vs FORWARD). Again, mangle is a group of chains functionally grouped and not structurally as I thought.
Could not agree more. As a logical consequence of your statement (especially the hardware part), I propose the following thought: the search of cheap hardware for a firewall lies on a fundamental misunderstanding of what a statefull firewall is not. A Statefull Firewall is not even in the same league of a router. We are talking about differences comparable to the ones between a car and a bulldozer or a tractor. They both have four wheels and an engine, but they are made for very different purpose.
I also submit the following thought: IPFire is the lock, and your network is your life. Would you use a 20 euros lock to secure your life savings?
In general the rationale for putting the IP Blocklist early in the chain is that it can search through a large list of blocked addresses without using very much processing power. It doesn’t have to analyse the packet; it just extracts the IP address and looks it up a a series of hash tables.
By putting this early IPFire can avoid processing these packets in later stages, for example in the IPS which can do the same job, but has to analyse the packet in more detail.
I fully understand. That is why I was wondering what the order of the features is. I think it does make sense that the feature with the smallest need of power comes first. I have no clue what is more power consuming or time consuming. IP Blocklists, Spamhouse Drop or Location filter.
Thanks for your investigation!! I really didn’t realise this can be seen in the WUI. As I don’t really understand the magic behind iptables I have always ignored this confusing information so far.
Now I wonder even more how millions of packets per second can make it through this system of filters, routes, tables blocklists etc. What a great piece of intelligence lies in such code but also in the hardware that can process that code in fragments of a second.
so far.