1

This question is a follow-up to my previous question.

Logic for me to says that an in-kernel firewall sits between the network access layer and the Internet layer, because it needs to have access to the IP-packet header to read the source and destination IP address in order to do filtering before determining if the packet is destined for the host, or it the packet should forwarded to the next hop if it is destined elsewhere.

Somehow, it also seems logical to say that firewall is part of Internet layer, because that is where routing table is and a firewall is in some respects similar to routing table rules.

3
  • According to your logic, why would the firewall need to be below the Internet layer, if the lowermost protocol it concerns itself with is the IP protocol? Apr 3, 2014 at 8:13
  • The reason for saying that is it checks the rule (allowed/disallowed source IP and destination IP) before the allowed packet data is processed further by appropriate internet layer protocol. Right now, I also think that part of the firewall also sits between internet layer and transport layer to filter port number of segment data before processed further by appropriate transport layer protocol. In other words, part of firewall sits between network access layer and internet layer. Another part sits between internet layer and transport layer. Maybe I am wrong..
    – Ron Vince
    Apr 3, 2014 at 9:17
  • I updated my answer to include information on how, in the case of Linux iptables, the packet filter abstractions fit together with the OSI model. Apr 3, 2014 at 9:36

1 Answer 1

8

A firewall does not exist in a single place in the kernel network stack. In Linux, for instance, the underlying infrastructure to support firewall functionality is provided by the netfilter packet filter framework. The netfilter framework in itself is nothing more than a set of hooks at various points in the kernel protocol stack.

Netfilter provides five hooks:

  • NF_IP_PRE_ROUTING

    Packets which pass initial sanity checks are passed to the NF_IP_PRE_ROUTING hook. This occurs before any routing decisions have been made.

  • NF_IP_LOCAL_IN

    Packets which destined to the host itself are passed to the NF_IP_LOCAL_IN hook.

  • NF_IP_FORWARD

    Packets destined to another interface are passed to the NF_IP_FORWARD hook.

  • NF_IP_LOCAL_OUT

    Locally created packets are passed to NF_IP_LOCAL_OUT after routing decisions have been made, although the routing can be altered as a result of the hook.

  • NF_IP_POST_ROUTING

    The NF_IP_POST_ROUTING hook is the final hook packets can be passed to before being transmitted on the wire.

A firewall consists of a kernel module, which registers a callback function for each of the hooks provided by the the netfilter framework; and userspace tools for configuring the firewall. Each time a packet is passed to a hook, the corresponding callback function is invoked. The callback function is free to manipulate the packet that triggered the callback. The callback function also determines if the packet is processed further; dropped; handled by the callback itself; queued, typically for userspace handling; or if the same hook should be invoked again for the packet.

Netfilter is usually associated with the iptables packet filter. As Gnouc already pointed out in your previous question, iptables has a kernel module, ip_tables, which interfaces with netfilter, and a userspace program, iptables, for configuring the in-kernel packet filter. In fact, the iptables packet filter provides several tools, each associated with a different kind of packet processing:

  • The iptables userspace tool and ip_tables kernel module concern themselves with IPv4 packet filtering.

  • The ip6tables userspace tool and ip6_tables kernel module concern themselves with IPv6 packet filtering.

  • The arptables userspace tool and arp_tables kernel module concern themselves with ARP packet filtering.

In addition to the iptables packet filters, the ebtables userspace tool and eb_tables kernel module concern themselves with link layer Ethernet frame filtering. Collectively, these tools are sometimes referred to as xtables, because of the similar table-based architecture.

This architecture provides a packet selection abstraction based on tables packets traverse along. Each table contains packet filtering rules organized in chains. The five predefined chains, PREROUTING, INPUT, FORWARD, OUTPUT and POSTROUTING correspond to the five in-kernel hooks provided by netfilter. The table a rule belongs to determines the relative ordering of rules when they are applied at a particular netfilter hook:

  • The raw table filters packets before any of the other table.
  • The mangle table is used for altering packets.
  • The nat table is used for Network Address Translation (e.g. port forwarding).
  • The filter table is used for packet filtering, it should never alter packets.
  • The security table is used for Mandatory Access Control (MAC) networking rules implemented by Linux Security Modules (LSMs), such as SELinux.

The following diagram by Jan Engelhardt shows how the tables and chains correspond to the different layers of the OSI-model:

Schematic for the packet flow paths through Linux networking and xtables

Earlier this year, a new packet filter framework called nftables was merged in the mainline Linux kernel version 3.13. The nftables framework is intended to replace the existing xtables tools. It is also based on the netfilter infrastructure.

Other kernel-based firewalls in Unix-like operating systems include IPFilter (multi-platform), PF (OpenBSD, ported to various other BSD variants and Mac OS X), NPF (NetBSD), ipfirewall (FreeBSD, ported to various operating systems).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .