Linux Firewalls - Michael Rash [19]
The iptables nat table is dedicated to all NAT rules, and within this table there are two chains: PREROUTING and POSTROUTING. The PREROUTING chain is used to apply rules in the nat table to packets that have not yet gone through the routing algorithm in the kernel in order to determine the interface on which they should be transmitted. Packets that are processed in this chain have also not yet been compared against the INPUT or FORWARD chains in the filter table.
The POSTROUTING chain is responsible for processing packets once they have gone through the routing algorithm in the kernel and are just about to be transmitted on the calculated physical interface. Packets processed by this chain have passed the requirements of the OUTPUT or FORWARD chains in the filter table (as well as requirements mandated by other tables that may be registered, such as the mangle table).
Note
For a complete explanation of how iptables does NAT, see http://www.netfilter.org/documentation/howto/nat-howto.html.
###### NAT rules ######
echo "[+] Setting up NAT rules..."
❾ $IPTABLES -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT
--to 192.168.10.3:80
$IPTABLES -t nat -A PREROUTING -p tcp --dport 443 -i eth0 -j DNAT
--to 192.168.10.3:443
$IPTABLES -t nat -A PREROUTING -p tcp --dport 53 -i eth0 -j DNAT --to 192.168.10.4:53
❿ $IPTABLES -t nat -A POSTROUTING -s $INT_NET -o eth0 -j MASQUERADE
Referring to the network diagram in Figure 1-2, the IP addresses of the web- and DNS servers are 192.168.10.3 and 192.168.10.4 in the internal network. The iptables commands required to provide NAT functionality are displayed above (note the restriction of the commands to the nat table through the use of the -t option). The three PREROUTING rules at ❾ allow web services and DNS requests from the external network to be sent to the appropriate internal servers. The final POSTROUTING rule at ❿ allows connections that originate from the internal non-routable network and destined for the external Internet to look as though they come from the IP address 71.157.X.X.
The very last step in building the iptables policy is to enable IP forwarding in the Linux kernel:
###### forwarding ######
echo "[+] Enabling IP forwarding..."
echo 1 > /proc/sys/net/ipv4/ip_forward
Activating the Policy
One of the really nice things about iptables is that instantiating a policy within the kernel is trivially easy through the execution of iptables commands—there are no heavyweight user interfaces, binary file formats, or bloated management protocols (like the ones developed by some proprietary vendors of other security products). Now that we have a shell script that captures the iptables commands (once again, you can download the complete script from http://www.cipherdyne.org/linuxfirewalls), let's execute it:
[iptablesfw]# ./iptables.sh
[+] Flushing existing iptables rules...
[+] Setting up INPUT chain...
[+] Setting up OUTPUT chain...
[+] Setting up FORWARD chain...
[+] Setting up NAT rules...
[+] Enabling IP forwarding...
iptables-save and iptables-restore
All of the previous iptables commands in the iptables.sh script are executed one at a time in order to instantiate new rules, set the default policy on a chain, or delete old rules. Each command requires a separate execution of the iptables userland binary to create the iptables policy. Hence, this is not an optimal solution for bringing the policy into existence quickly at system boot, particularly when the number of iptables rules grows into the hundreds (which can happen with a policy built by fwsnort, as we will see in Chapter 10). A much faster mechanism is provided by the commands iptables-save and iptables-restore, which are installed within the same directory (/sbin in our case) as the main iptables program. The iptables-save command builds a file that contains all iptables rules in a running policy in human-readable format. This format can be interpreted by the iptables-restore