3.15 Using iptables for security

The netfilter/iptables project is the Linux 2.4.x / 2.5.x firewalling subsystem.It delivers you the functionality of packet filtering (stateless or stateful), many different kinds of Network Address Translation (NAT) and packet managing. The homepage of Linux iptables is:

http://www.netfilter.org

Iptables is a part of the Linux kernel or more precisely: "netfilter is a set of hooks inside the linux 2.4.x kernel's network stack which allows kernel modules to register callback functions called every time a network packet traverses one of those hooks". ^[19]

^[19] see http://www.netfilter.org/documentation/

Here we illustrate the use of iptables in a simple example: we have a management server in our environment and several nodes. We want to allow one node to reach the management server and to allow the management server reach the node, but to deny any kind of IP communication from one node to other nodes. This star- formed structure applies to CSM design: the CSM management server communicates with nodes, but nodes do not need to communicate with each other.

In Example 3-30, we limit the communication from a node to one IP address, the management server, allowing any kind of IP traffic between them:

 /sbin/iptables -I INPUT -s ADDRESS -j ACCEPT 

In detail, insert rule (-I) in the chain INPUT anything with source address (-s) management server will be accepted. The same command for the OUTPUT chain with the -d option determines outgoing traffic to the destination. We use default policy DROP - this means the packets not matching the allowed packet rules will be dropped and no reply will be sent. The alternate policy REJECT would mean the packets are rejected and a reply is sent to the initiator saying that the packet was rejected.

Attention

Before experimenting with iptables, ensure you will be able to log in locally or through HMC, or you may lock yourself out. Do not play with servers without having a direct, non-networked login possibility, or at a minimum, set a job to remove the firewall in 30 minutes.

Example 3-30. ip-isolate script

 # This is the location of the iptables command IPTABLES="/sbin/iptables" # Address of our Management Server MGMT=192.168.100.110 ## Flush everything, start from scratch # # Incoming packets from the outside network $IPTABLES -F INPUT # Outgoing packets from the internal network $IPTABLES -F OUTPUT # Forwarding/masquerading $IPTABLES -F FORWARD #Allow everything from and to Management Server $IPTABLES -I INPUT -s $MGMT -j ACCEPT $IPTABLES -I OUTPUT -d $MGMT -j ACCEPT # Set default policy to drop $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP 

Note

The location of the iptables command is /usr/sbin/iptables on SuSE, and /sbin/iptables on the Red Hat system.

After we finished editing our ip-isolate script, we need to make it executable and run it. We can see the state of iptables with the iptables -L command:

Example 3-31. iptables -L output

 # iptables -L Chain INPUT (policy DROP) target     prot opt source            destination ACCEPT     all  --  p630sles          anywhere Chain FORWARD (policy DROP) target     prot opt source            destination Chain OUTPUT (policy DROP) target     prot opt source            destination ACCEPT     all  --  anywhere          p630sles 

As we see in Example 3-31, our default policy for all chains is drop, but we accept anything from machine p630sles and allow all traffic to it. If we try to ping lpar1 (which is another node in the same subnet), we will see following output:

 ping lpar1 PING lpar1.residency.local (192.168.100.77) 56(84) bytes of data. ping: sendmsg: Operation not permitted 

We also cannot ping lpar6 from any other node in the network, or log in to it with ssh. Only traffic to and from the management server is allowed.

We can improve our node isolation by regulating which kind of network traffic is allowed from and to the management server.

Example 3-32. port-isolate script

 #!/bin/sh ### This is the location of the iptables command IPTABLES="/sbin/iptables" ### Adress of our CSM Management Server CSM=192.168.100.110 DNS=192.168.100.110 ### ## Flush everything, start from scratch ## Incoming packets from the outside network $IPTABLES -F INPUT ## Outgoing packets from the internal network $IPTABLES -F OUTPUT ## Forwarding/masquerading $IPTABLES -F FORWARD ########################## Allow ssh from and to CSM Management Server $IPTABLES -I INPUT -s $CSM -p tcp --dport 22 -j ACCEPT $IPTABLES -I OUTPUT -d $CSM -p tcp --dport 22 -j ACCEPT ########################## Allow usage of DNS $IPTABLES -I OUTPUT -d $DNS -p udp --dport 53 -j ACCEPT ########################## CSM $IPTABLES -I OUTPUT -d $CSM -p tcp --dport 657 -j ACCEPT $IPTABLES -I OUTPUT -s $CSM -p udp --dport 657 -j ACCEPT ########################## Be stateful $IPTABLES -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPTABLES -I OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ######################### Default policy is DROP $IPTABLES -P INPUT DROP $IPTABLES -P OUTPUT DROP $IPTABLES -P FORWARD DROP ######################### We log for debugging only #$IPTABLES -A OUTPUT -j LOG #$IPTABLES -A INPUT -j LOG 

Now we have forbidden everything except connections to the management server for ssh (port 22 tcp), name server (port 53 udp) and csm (port 657 tcp/udp). We also accept connections established and related to the connections allowed. We will be able to make an ssh connection to the management server, but not to ping it. We have forbidden any connections to other nodes or from them.

Important

ssh login may fail if the client machine is an LDAP Client and cannot reach the LDAP server, even if root is not an LDAP user .

In the last example, we show a small script to remove our firewall rules.

Example 3-33. fwremove script

 # Remove any existing rules from all chains iptables -F iptables -F -t nat iptables -F -t mangle iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT