IPtables and Netfilter - PDF Free Download

in tables rely on IPtables and Netfilter Comp Sci 3600 Security

Outline in tables rely on 1 2 in tables rely on 3

Linux firewall: IPtables in tables rely on Iptables is the userspace module, the bit that you, the user, interact with at the command line to enter firewall rules into predefined tables. Netfilter is a kernel module, built into the kernel, that actually does the filtering. There are many GUI front ends for iptables that allow users to add or define rules based on a point and click user interface, but these often lack the flexibility of using the command line interface and limit the users understanding of what s really happening.

Outline in tables rely on 1 2 in tables rely on 3

IPtables and netfilter in tables rely on

IPtables and netfilter in tables rely on User-space: Iptables resides in what we call the user-space, this is your interface to the firewall for setting up your firewall rules. The same applies to ip6tables, nft, etc. Kernel: netfilter, the framework which iptables configures. Netfilter implements a series of hooks that inspect packets in the protocol stack, such as IPv4. These hooks allow for kernel modules to interact with them. Iptables has a huge list of kernel modules used for its firewalling capabilities. We have everything from and to pkttype (Packet Type). In fact if you want to see a list of iptables kernel modules, type: cat /proc/net/ip tables matches. Hardware / interfaces: Network adapters; eth0, eth1, etc. Netfilter uses prerouting and postrouting to and from the network stack to inspect packets sent and received on each interface. Packet inspection is done at the kernel layer with the netfilter, and all the firewall rules and tools to manage the firewall reside in the user-space.

Outline in tables rely on 1 2 in tables rely on 3

IPtables and netfilter in tables rely on

Outline in tables rely on 1 2 in tables rely on 3

in tables in tables rely on As a packet triggers a netfilter hook, the associated chains will be processed as they are listed in the table above from top-to-bottom, with rules processed from top to bottom.

Outline in tables rely on 1 2 in tables rely on 3

in tables rely on 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. 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. mangle table is used to alter the IP headers of the packet in various ways. 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.

in tables rely on The iptables firewall is stateful, meaning that packets are evaluated in regards to their relation to previous packets. The features built on top of the netfilter framework allow iptables to view packets as part of an ongoing or session instead of as a stream of discrete, unrelated packets. The 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. 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- basis.

in tables in tables rely on

Outline in tables rely on 1 2 in tables rely on 3

Netfilter Kernel Hooks in tables rely on 5 netfilter hooks that programs can register with. As packets progress through the stack, they will trigger the kernel modules that have registered with these hooks. Hooks that a packet will trigger depends on whether the packet is incoming or outgoing, the packet s destination, and whether the packet was dropped or rejected at a previous point. NF IP PRE ROUTING: will be triggered by any incoming traffic very soon after entering the network stack. Is processed before any routing decisions have been made regarding where to send the packet. NF IP LOCAL IN: is triggered after an incoming packet has been routed if the packet is destined for the local system. NF IP FORWARD: is triggered after an incoming packet has been routed if the packet is to be forwarded to another host. NF IP LOCAL OUT: is triggered by any locally created outbound traffic as soon it hits the network stack. NF IP POST ROUTING: is triggered by any outgoing or forwarded traffic after routing has taken place and just before being put out on the wire.

Outline in tables rely on 1 2 in tables rely on 3

in tables rely on As you can see, the names of the built-in chains mirror the names of the netfilter hooks they are associated with: PREROUTING: Triggered by the NF IP PRE ROUTING hook. INPUT: Triggered by the NF IP LOCAL IN hook. FORWARD: Triggered by the NF IP FORWARD hook. OUTPUT: Triggered by the NF IP LOCAL OUT hook. POSTROUTING: Triggered by the NF IP POST ROUTING hook.

Outline in tables rely on 1 2 in tables rely on 3

in chains in tables rely on are also processed in order, often with a catch-all at the end

Outline in tables rely on 1 2 in tables rely on 3

Chain Traversal Order in tables rely on Assuming that the server knows how to route a packet and that the firewall rules permit its transmission, the following flows represent the paths that will be traversed in different situations: Incoming packets destined for the local system: PREROUTING > INPUT Incoming packets destined to another host: PREROUTING > FORWARD > POSTROUTING Locally generated packets: OUTPUT > POSTROUTING

IPtables and netfilter flow in tables rely on

Targets (another chain to send to) in tables rely on A target is the action that are triggered when a packet meets the matching criteria of a rule. Targets are generally divided into two categories: Terminating targets: Terminating targets perform an action which terminates evaluation within the chain and returns control to the netfilter hook. Depending on the return value provided, the hook might drop the packet or allow the packet to continue to the next stage of processing. Non-terminating targets: Non-terminating targets perform an action and continue evaluation within the chain. Although each chain must eventually pass back a final terminating decision, any number of non-terminating targets can be executed beforehand. Common are ACCEPT, DROP, REJECT, LOG, etc

Outline in tables rely on 1 2 in tables rely on 3

state : in tables rely on For a stateful firewall:

state : closing in tables rely on

state : client sub- in tables rely on

state : server sub- in tables rely on

Outline in tables rely on 1 2 in tables rely on 3

state : in tables rely on Watches inverted port numbers

State Explanation: NEW in tables rely on The NEW state tells us that the packet is the first packet that we see. This means that the first packet that the conntrack module sees, within a specific, will be matched. For example, if we see a SYN packet and it is the first packet in a that we see, it will match. However, the packet may as well not be a SYN packet and still be considered NEW. This may lead to certain problems in some instances, but it may also be extremely helpful when we need to pick up lost from other firewalls, or when a has already timed out, but in reality is not closed.

State Explanation: ESTABLISHED in tables rely on The ESTABLISHED state has seen traffic in both directions and will then continuously match those packets. ESTABLISHED are fairly easy to understand. The only requirement to get into an ESTABLISHED state is that one host sends a packet, and that it later on gets a reply from the other host. The NEW state will upon receipt of the reply packet to or through the firewall change to the ESTABLISHED state. ICMP reply messages can also be considered as ESTABLISHED, if we created a packet that in turn generated the reply ICMP message.

State Explanation: RELATED in tables rely on The RELATED state is one of the more tricky states. A is considered RELATED when it is related to another already ESTABLISHED. What this means, is that for a to be considered as RELATED, we must first have a that is considered ESTABLISHED. The ESTABLISHED will then spawn a outside of the main. The newly spawned will then be considered RELATED, if the conntrack module is able to understand that it is RELATED. Some good examples of that can be considered as RELATED are the FTP-data that are considered RELATED to the FTP control port, and the DCC issued through IRC. This could be used to allow ICMP error messages, FTP transfers and DCC s to work properly through the firewall. Do note that most protocols and some protocols that rely on this mechanism are quite complex and send information within the payload of the or data segments, and hence require special helper modules to be correctly understood.

State Explanation: INVALID in tables rely on The INVALID state means that the packet can t be identified or that it does not have any state. This may be due to several reasons, such as the system running out of memory or ICMP error messages that do not respond to any known. Generally, it is a good idea to DROP everything in this state.

State Explanation: UNTRACKED in tables rely on This is the UNTRACKED state. In brief, if a packet is marked within the raw table with the NOTRACK target, then that packet will show up as UNTRACKED in the state machine. This also means that all RELATED will not be seen, so some caution must be taken when dealing with the UNTRACKED since the state machine will not be able to see related ICMP messages et cetera.