Hooks only provide an interface where the packets are accessible, but they do not provide a solution to handle the packets. To manage the packets, the Linux kernel provides basically three options which are represented by tables.
Filter table,
responsible for Packet Filtering.
NAT table,
responsible for Network Address Translation.
Mangle table,
responsible for Packet Mangling.
Each table is responsible for one specific action. To fulfil their roles, the tables need to access the packets. Therefore, the tables are registered in the hooks so that they can influence the packet flow in the kernel.
The tables can be configured to carry out other tables' tasks though this solution is not recommended since the tables perform different things and they have different requirements from the hooks, accordingly. Some of the tables cannot be tied to all hooks, but it is also possible that more than one table is involved in one hook. Consequently, more tables can share packets on one hook. Each table can be registered to any hook with a specific priority. The order in which the tables receive the passing packet is based on this priority list.
To successfully pass a hook, the packets have to be accepted on each and every table registered to that given hook. If a packet is dropped by any of the tables it cannot get to the subsequent tables, nor to the subsequent hook.
The following tables are involved in packet filtering:
- filter table
This table is responsible for the packet filtering, so it represents the classic packet filtering items. Packets are usually dropped, rejected and accepted here.
This table is registered to the INPUT, FORWARD and to the OUTPUT hooks with the highest priority, meaning that it is the last table which gets the packets at these hooks.
- NAT table
This table is responsible for network address translations. Since IPTables is a stateful packet filter, translations occur on the connections not on the packets.
It is important that only the first packet of each connections reaches this table, because one connection can only be NATed once and the selected NAT mapping is used for the rest of the packets in the connection.
The NAT table is registered to the PREROUTING, POSTROUTING and to the OUTPUT hooks with a lower priority than the filter table, meaning that it receives the packets right before the filter table.
Note Although it is possible to drop a packet at the NAT table, it is not recommended, because the filter table is responsible for dropping packets. If a packet is dropped at the NAT table it cannot reach the filter table. If a packet is accepted or NATed at the NAT table it has to be accepted at the filter table as well to pass.
Basically, two types of NATs exist: source address, and destination address. They have various special subtypes such as redirect and masquarade. Both NATs can be configured in this table only. Because of the difference between the two NAT types and their influence on the connections, NATs of source type can be configured at the PREROUTING and at the OUTPUT hooks, while NATs of destination type can be configured at the POSTROUTING hook. With careful design, it is possible to translate source and destination NAT on a single specific connection.
- mangle table
This table is responsible for various packet mangling like modifying the TTL of the packet, changing the TOS bits, or setting the FWMARK on the packet. This is the table where the biggest alterations take place in the packet and also where serious administration problems can be experienced.
This table is registered to the PREROUTING, INPUT, FORWARD, OUTPUT, and to the POSTROUTING hooks with the lowest priority meaning that it gets the packets first, right before the other tables.
The default deny or default drop approach is only partially true in this table. As packet filtering occurs at the filter table, the default drop configuration must be utilized only at this table. It is not needed and not possible either, to implement a default drop configuration on all the tables. If a packet targets a local application or leaves the firewall, it has to pass successfully the filter table, so it is enough to drop packets there.
Tip To build a fully functioning configuration, it is a good approach to accept all the packets on the mangle and on the NAT tables and drop all unnecessary packets on the filter table.
Take special care with NATted packets/connections as they appear with their new addresses after the translation so the NATed address must be accepted on the filter table, for example.
Published on May 30, 2024
© BalaSys IT Ltd.
Send your comments to support@balasys.hu
