Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
linux_router:netfilter [2024-06-23 Sun wk25 09:03] – [Relationships Between Chains and Tables] baumkplinux_router:netfilter [2024-06-23 Sun wk25 09:11] (current) – baumkp
Line 47: Line 47:
 </code> </code>
  
-====IPTables Tables and Chains==== 
  
-The iptables firewall uses tables to organize its rules. These tables classify rules according to the type of decisions they are used to make. For instance, if a rule deals with network address translation, it will be put into the nat table. If the rule is used to decide whether to allow the packet to continue to its destination, it would probably be added to the filter table.+=====IPTables and Netfilter===== 
 +The following is taken from Digitalocean [[https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture|A Deep Dive into Iptables and Netfilter Architecture]].  While it it is focus on iptables the concepts are basically valid for nftables.  
 + 
 +++++ tldr| 
 + 
 +====IPTables Tables and Chains====
  
-Within each iptables table, rules are further organized within separate “chains”. While tables are defined by the general aim of the rules they hold, the built-in chains represent the netfilter hooks which trigger them. Chains determine when rules will be evaluated.+The ''iptables'' firewall uses tables to organize its rules. These tables classify rules according to the type of decisions they are used to make. For instance, if a rule deals with network address translation, it will be put into the nat table. If the rule is used to decide whether to allow the packet to continue to its destination, it would probably be added to the ''filter'' table.
  
-The names of the built-in chains mirror the names of the netfilter hooks they are associated with:+Within each ''iptables'' table, rules are further organized within separate “chains”. While tables are defined by the general aim of the rules they hold, the built-in chains represent the ''netfilter'' hooks which trigger them. Chains determine when rules will be evaluated.
  
-    PREROUTING: Triggered by the NF_IP_PRE_ROUTING hook. +The names of the built-in chains mirror the names of the ''netfilter'' hooks they are associated with: 
-    INPUT: Triggered by the NF_IP_LOCAL_IN hook. +  *''PREROUTING'': Triggered by the NF_IP_PRE_ROUTING hook. 
-    FORWARD: Triggered by the NF_IP_FORWARD hook. +  *''INPUT'': Triggered by the NF_IP_LOCAL_IN hook. 
-    OUTPUT: Triggered by the NF_IP_LOCAL_OUT hook. +  *''FORWARD'': Triggered by the NF_IP_FORWARD hook. 
-    POSTROUTING: Triggered by the NF_IP_POST_ROUTING hook.+  *''OUTPUT'': Triggered by the NF_IP_LOCAL_OUT hook. 
 +  *''POSTROUTING'': Triggered by the NF_IP_POST_ROUTING hook.
  
 Chains allow the administrator to control where in a packet’s delivery path a rule will be evaluated. Since each table has multiple chains, a table’s influence can be exerted at multiple points in processing. Because certain types of decisions only make sense at certain points in the network stack, every table will not have a chain registered with each kernel hook. Chains allow the administrator to control where in a packet’s delivery path a rule will be evaluated. Since each table has multiple chains, a table’s influence can be exerted at multiple points in processing. Because certain types of decisions only make sense at certain points in the network stack, every table will not have a chain registered with each kernel hook.
  
-There are only five netfilter kernel hooks, so chains from multiple tables are registered at each of the hooks. For instance, three tables have PREROUTING chains. When these chains register at the associated NF_IP_PRE_ROUTING hook, they specify a priority that dictates what order each table’s PREROUTING chain is called. Each of the rules inside the highest priority PREROUTING chain is evaluated sequentially before moving onto the next PREROUTING chain. We will take a look at the specific order of each chain in a moment.+There are only five ''netfilter'' kernel hooks, so chains from multiple tables are registered at each of the hooks. For instance, three tables have ''PREROUTING'' chains. When these chains register at the associated ''NF_IP_PRE_ROUTING'' hook, they specify a priority that dictates what order each table’s ''PREROUTING'' chain is called. Each of the rules inside the highest priority ''PREROUTING'' chain is evaluated sequentially before moving onto the next ''PREROUTING'' chain. We will take a look at the specific order of each chain in a moment.
  
 ====Which Tables are Available?==== ====Which Tables are Available?====
  
-Let’s step back for a moment and take a look at the different tables that iptables provides. These represent distinct sets of rules, organized by area of concern, for evaluating packets.+Let’s step back for a moment and take a look at the different tables that ''iptables'' provides. These represent distinct sets of rules, organized by area of concern, for evaluating packets. 
 ===The Filter Table=== ===The Filter Table===
 +The filter table is one of the most widely used tables in ''iptables''. The ''filter'' table is used to make decisions about whether to let a packet continue to its intended destination or to deny its request. In firewall parlance, this is known as “filtering” packets. This table provides the bulk of functionality that people think of when discussing firewalls.
  
-The filter table is one of the most widely used tables in iptables. The filter table is used to make decisions about whether to let a packet continue to its intended destination or to deny its request. In firewall parlance, this is known as “filtering” packets. This table provides the bulk of functionality that people think of when discussing firewalls. 
 ===The NAT Table=== ===The NAT Table===
 +The ''nat'' table is used to implement network address translation rules. As packets enter the network stack, rules in this table will determine whether and how to modify the packet’s source or destination addresses in order to impact the way that the packet and any response traffic are routed. This is often used to route packets to networks when direct access is not possible.
  
-The nat table is used to implement network address translation rules. As packets enter the network stack, rules in this table will determine whether and how to modify the packet’s source or destination addresses in order to impact the way that the packet and any response traffic are routed. This is often used to route packets to networks when direct access is not possible. 
 ===The Mangle Table=== ===The Mangle Table===
-The mangle table is used to alter the IP headers of the packet in various ways. For instance, you can adjust the TTL (Time to Live) value of a packet, either lengthening or shortening the number of valid network hops the packet can sustain. Other IP headers can be altered in similar ways.+The ''mangle'' table is used to alter the IP headers of the packet in various ways. For instance, you can adjust the TTL (Time to Live) value of a packet, either lengthening or shortening the number of valid network hops the packet can sustain. Other IP headers can be altered in similar ways.
  
 This table can also place an internal kernel “mark” on the packet for further processing in other tables and by other networking tools. This mark does not touch the actual packet, but adds the mark to the kernel’s representation of the packet. This table can also place an internal kernel “mark” on the packet for further processing in other tables and by other networking tools. This mark does not touch the actual packet, but adds the mark to the kernel’s representation of the packet.
 +
 ===The Raw Table=== ===The Raw Table===
 +The ''iptables'' firewall is stateful, meaning that packets are evaluated in regards to their relation to previous packets. The connection tracking features built on top of the ''netfilter'' framework allow ''iptables'' to view packets as part of an ongoing connection or session instead of as a stream of discrete, unrelated packets. The connection tracking logic is usually applied very soon after the packet hits the network interface.
  
-The iptables firewall is stateful, meaning that packets are evaluated in regards to their relation to previous packets. The connection tracking features built on top of the netfilter framework allow iptables to view packets as part of an ongoing connection or session instead of as a stream of discrete, unrelated packets. The connection tracking logic is usually applied very soon after the packet hits the network interface.+The ''raw'' table has a very narrowly defined function. Its only purpose is to provide a mechanism for marking packets in order to opt-out of connection tracking.
  
-The raw table has a very narrowly defined function. Its only purpose is to provide a mechanism for marking packets in order to opt-out of connection tracking. 
 ===The Security Table=== ===The Security Table===
- +The ''security'' table is used to set internal SELinux security context marks on packets, which will affect how SELinux or other systems that can interpret SELinux security contexts handle the packets. These marks can be applied on a per-packet or per-connection basis.
-The security table is used to set internal SELinux security context marks on packets, which will affect how SELinux or other systems that can interpret SELinux security contexts handle the packets. These marks can be applied on a per-packet or per-connection basis.+
  
 ====Relationships Between Chains and Tables==== ====Relationships Between Chains and Tables====
Line 139: Line 145:
  
 The states tracked in the connection tracking system allow administrators to craft rules that target specific points in a connection’s lifetime. This provides the functionality needed for more thorough and secure rules. The states tracked in the connection tracking system allow administrators to craft rules that target specific points in a connection’s lifetime. This provides the functionality needed for more thorough and secure rules.
 +++++
  
 ====Some references==== ====Some references====