netfilter Operation: Part Two

netfilter operationNow that we have covered the various tables and chains, we can discuss the overall packet flow. The key to remember is that not all packets traverse all chains. To further complicate matters, packets will traverse different chains depending on whether they are sourced from the netfilter host, destined for the netfilter host, or just passing through the netfilter host. Knowing this will save you time when troubleshooting your firewall rules in the future.

Targets are the actions that should be taken when a packet matches a given rule. A target is specified using the -j syntax (for jump). The primary targets used for a firewall are ACCEPT and DENY.

  • ACCEPT: The packet is accepted and processed by the rest of the TCP/IP stack.
  • DENY: The packet is dropped and no notice is given to the sender. While this does not honor the TCP/IP protocol specifications, it is considered the most secure option, because it denies a hacker useful information about the firewall. This behavior also has a negative side effect, which is if a system is trying to initiate a connection to a port that is blocked by a firewall, the connection attempt must time out before the initiating host gives up. If you use REJECT, the Internet Control Message Protocol (ICMP) port will allow the initiating system to abort the connection attempt immediately.
  • LOG: This allows you to perform kernel logging, which appears in the syslog log. Further options allow you to specify the log level and a descriptive prefix for the log entry.
  • RETURN: Processing continues in the previous chain at the rule just after the last rule processed in that chain.
  • QUEUE: This is a special target that will hold (or queue) a packet for processing by a userspace process.


Unlike some firewalls, netfilter allows you to apply multiple rulesets (chains) to the same interface. Although it may seem minor, this option creates a lot of powerful possibilities. For example, suppose you have an ACL and you want to permit all packets originating on the 192.168.1.0 network except those from 192.168.1.25, which is a host that a third party uses and is not a completely trusted system. You want packets sourced from 192.168.1.25 with a destination port of 22, 25, 53, 80 and 443 to be permitted, while all other packets are to be blocked.

Using netfilter and iptables, you can create a rule to implement this policy:

1 somerule
2 iptables -A FORWARD -p tcp -s 192.168.1.25 -j CUSTOM
2.1 iptables -A CUSTOM -p tcp -s 192.168.1.25 –dport 22 -j ACCEPT
2.2 iptables -A CUSTOM -p tcp -s 192.168.1.25 –dport 25 -j ACCEPT
2.3 iptables -A CUSTOM -p tcp -s 192.168.1.25 –dport 53 -j ACCEPT
2.4 iptables -A CUSTOM -p tcp -s 192.168.1.25 –dport 80 -j ACCEPT
2.5 iptables -A CUSTOM -p tcp -s 192.168.1.25 –dport 443 -j ACCEPT
2.6 iptables -A CUSTOM -p ip -s 192.168.1.25 -j DROP
2.7 iptables -A CUSTOM -j RETURN
3 iptables -A FORWARD -p ip -s 192.168.1.0/24 -j ACCEPT
4 somerule

Using netfilter and iptables, we created rule #2, which says that the source address is 192.168.1.25 for processing the CUSTOM chain. You can create the CUSTOM chain with the iptables -N CUSTOM command. Within the CUSTOM chain, you check for the five permitted destination ports (rules 2.1-2.5) and then reject everything else (rule 2.6). Rule #2.7 has no matching criteria and will therefore match on nay packet and instruct the packet to return to the FORWARD chain where processing can continue. FORWARD chain rule #3 permits all other packets from the 192.168.1.10/24 network. This means that packets not sourced from 192.168.1.25 only have to be checked against rule #2 and can then move through the chain(s) instead of being checked against all the rules.


External Links:

Using Custom Chains in iptables at my.safaribooksonline.com

Be Sociable, Share!

Speak Your Mind

*

© 2013 David Zientara. All rights reserved. Privacy Policy