Using iptables and ipchains

In this section, I will provide you with the iptables (and ipchains) commands you can use to control the fate of packets as they arrive on each cluster node. These commands can also be used to build a firewall outside the cluster. This is done by adding a corresponding FORWARD rule for each of the INPUT rules provided here and installing them on the cluster load balancer. Whether you install these rules on each cluster node, the cluster load balancer, or both is up to you.

These commands can be entered from a shell prompt; however, they will be lost the next time the system boots. To make the rules permanent, you must place them in a script (or a configuration file used by your distribution) that runs each time the system boots. Later in this chapter, you will see a sample script.

Note 

If you are working with a new kernel (series 2.4 or later), use the iptables rules provided (the ipchains rules are for historical purposes only).

Clear Existing Rules

Before adding any rules to the kernel, we want to start with a clean, rule-free configuration. ipchains and iptables are useful commands to use when troubleshooting and building a new configuration if you need to start over and don't want to reboot the system.

Use one of these commands (ipchains on 2.2 series kernels and iptables on 2.4 and later series kernels) to erase all rules in all three chains (INPUT, FORWARD, and OUTPUT):

 #ipchains -F #iptables -F 

Set the Default INPUT Chain Policy

Use one of these commands to set the default INPUT policy to not allow incoming packets:

 #ipchains -P input DENY #iptables -P INPUT DROP 

Remember, if you create routing rules to route packets back out of the system (described later in this chapter), you may also want to set the default FORWARD policy to DROP and explicitly specify the criteria for packets that are allowed to pass through. This is how you build a secure load balancer (in conjunction with the Linux Virtual Server software described in Part III of this book).

Recall that the 2.2 series kernel ipchains input policy affects both locally destined packets and packets that need to be sent back out on the network, whereas the 2.4 and later series kernel iptables INPUT policy affects only locally destined packets.

Note 

If you need to add iptables (or ipchains) rules to a system through a remote telnet or SSH connection, you should first enter the ACCEPT rules (shown later in this section) to allow your telnet or SSH to continue to work even after you have set the default policy to DROP (or DENY).

FTP

Use these rules to allow inbound FTP connections from anywhere:

 #ipchains -A input -i eth0 -p tcp -s any/0 1024:65535 -d MY.NET.IP.ADDR 21 -j ACCEPT #ipchains -A input -i eth0 -p tcp -s any/0 1024:65535 -d MY.NET.IP.ADDR 20 -j ACCEPT #iptables -A INPUT -i eth0 -p tcp -s any/0 --sport 1024:65535 -d MY.NET.IP.ADDR   --dport 21 -j ACCEPT #iptables -A INPUT -i eth0 -p tcp -s any/0 --sport 1024:65535 -d MY.NET.IP.ADDR   --dport 20 -j ACCEPT 

Depending on your version of the kernel, you will use either ipchains or iptables. Use only the two rules that match your utility.

Let's examine the syntax of the two iptables commands more closely:

-A INPUT

• Says that we want to add a new rule to the input filter.

-i eth0

• Applies only to the eth0 interface. You can leave this off if you want an input rule to apply to all interfaces connected to the system. (Using ipchains, you can specify the input interface when you create a rule for the output chain, but this is no longer possible under iptables because the output chain is for locally created packets only.)

-p tcp

• This rule applies to the TCP protocol (required if you plan to block or accept packets based on a port number).

-s any/0 and --sport 1024:65535

• These arguments say the source address can be anything, and the source port (the TCP/IP port we will send our reply to) can be anything between 1024 and 65535. The /0 after any means we are not applying a subnet mask to the IP address. Usually, when you specify a particular IP address, you will need to enter something like:

   ALLOWED.NET.IP.ADDR/255.255.255.0 

  or

   ALLOWED.NET.IP.ADDR/24 

  where ALLOWED.NET.IP.ADDR is an IP address such as 209.100.100.3.

  In both of these examples, the iptables command masks off the first 24 bits of the IP address as the network portion of the address.

Note 

For the moment, we will skip over the details of a TCP/IP conversation. What is important here is that a normal inbound TCP/IP request will come in on a privileged port (a port number defined in /etc/services and in the range of 1-1023) and ask you to send a reply back on an unprivileged port (a port in the range of 1024 to 65535).

-d MY.NET.IP.ADDR and --dport 21

• These two arguments specify the destination IP address and destination port required in the packet header. Replace MY.NET.IP.ADDR with the IP address of your eth0 interface, or enter 0.0.0.0 if you are leaving off the -i option and do not care which interface the packet comes in on. (FTP requires both ports 20 and 21; hence the two iptables commands above.)

-j ACCEPT

• When a packet matches a rule, it drops out of the chain (the INPUT chain in this case). At that point, whatever you have entered here for the -j option specifies what happens next to the packet. If a packet does not match any of the rules, the default filter policy, DENY or DROP in this case, is applied.

Passive FTP

The rules just provided for FTP do not allow for passive FTP connections to the FTP service running on the server. FTP is an old protocol that dates from a time when university computers connected to each other without intervening firewalls to get in the way. In those days, the FTP server would connect back to the FTP client to transmit the requested data. Today, most clients sit behind a firewall, and this is no longer possible. Therefore, the FTP protocol has evolved a new feature called passive FTP that allows the client to request a data connection on port 21, which causes the server to listen for an incoming data connection from the client (rather than connect back to the client as in the old days). To use passive FTP, your FTP server must have an iptables rule that allows it to listen on the unprivileged ports for one of these passive FTP data connections. The rule to do this using iptables looks like this:

 #iptables -A INPUT -i eth0 -p tcp -s any/0 --sport 1024:65535 -d MY.NET.IP.ADDR   --dport 1024:65535 -j ACCEPT 

DNS

Use this rule to allow inbound DNS requests to a DNS server (the "named" or BIND service):

 #ipchains -A input -i eth0 -p udp -s any/0 1024:65535 -d MY.NET.IP.ADDR 53 -j ACCEPT #ipchains -A input -i eth0 -p tcp -s any/0 1024:65535 -d MY.NET.IP.ADDR 53 -j ACCEPT #iptables -A INPUT -i eth0 -p udp -s any/0 --sport 1024:65535 -d MY.NET.IP.ADDR   --dport 53 -j ACCEPT #iptables -A INPUT -i eth0 -p tcp -s any/0 --sport 1024:65535 -d MY.NET.IP.ADDR   --dport 53 -j ACCEPT 

Telnet

Use this rule to allow inbound telnet connections from a specific IP address:

 #ipchains -A input -i eth0 -p tcp -s 209.100.100.10 1024:65535   -d MY.NETWORK.IP.ADDR 23 -j ACCEPT #iptables -A INPUT -i eth0 -p tcp -s 209.100.100.10 --sport 1024:65535   -d MY.NETWORK.IP.ADDR --dport 23 -j ACCEPT 

In this example, we have only allowed the client computer using IP address 209.100.100.10 telnet access into the system. You can change the IP address of the client computer and enter this command repeatedly to grant telnet access to additional client computers.

SSH

Use this rule to allow SSH connections:

 ipchains -A input -i eth0 -p tcp -s 209.200.200.10 1024:65535   -d MY.NETWORK.IP.ADDR 22 -j ACCEPT iptables -A INPUT -i eth0 -p tcp -s 209.200.200.10 --sport 1024:65535   -d MY.NETWORK.IP.ADDR --dport 22 -j ACCEPT 

Again, replace the example 209.200.200.10 address with the IP address you want to allow in, and repeat the command for each IP address that needs SSH access. The SSH daemon (sshd) listens for incoming requests on port 22.

Email

Use this rule to allow email messages to be sent out:

 ipchains -A input -i eth0 -p tcp ! -y -s EMAIL.NET.IP.ADDR 25   -d MY.NETWORK.IP.ADDR 1024:65535 -j ACCEPT iptables -A INPUT -i eth0 -p tcp ! --syn -s EMAIL.NET.IP.ADDR --sport 25   -d MY.NETWORK.IP.ADDR --dport 1024:65535 -j ACCEPT 

This rule says to allow Simple Mail Transport Protocol (SMTP) replies to our request to connect to a remote SMTP server for outbound mail delivery. This command introduces the ! --syn syntax, an added level of security that confirms that the packet coming in is really a reply packet to one we've sent out.

The ! -y syntax says that the acknowledgement flag must be set in the packet header—indicating the packet is in acknowledgement to a packet we've sent out. (We are sending the email out, so we started the SMTP conversation.)

This rule will not allow inbound email messages to come in to the sendmail service on the server. If you are building an email server or a server capable of processing inbound email messages (cluster nodes that do email order entry processing, for example), you must allow inbound packets to port 25 (without using the acknowledgement flag).

HTTP

Use this rule to allow inbound HTTP connections from anywhere:

 #ipchains -A input -i eth0 -p tcp -d MY.NETWORK.IP.ADDR 80 -j ACCEPT #iptables -A INPUT -i eth0 -p tcp -d MY.NETWORK.IP.ADDR --dport 80 -j ACCEPT 

To allow HTTPS (secure) connections, you will also need the following rule:

 #ipchains -A input -i eth0 -p tcp -d MY.NETWORK.IP.ADDR 443 -j ACCEPT #iptables -A INPUT -i eth0 -p tcp -d MY.NETWORK.IP.ADDR --dport 443 -j ACCEPT 

ICMP

Use this rule to allow Internet Control Message Protocol (ICMP) responses:

 ipchains -A input -i eth0 -p icmp -d MY.NETWORK.IP.ADDR -j ACCEPT iptables -A INPUT -i eth0 -p icmp -d MY.NETWORK.IP.ADDR -j ACCEPT 

This command will allow all ICMP messages, which is not something you should do unless you have a firewall between the Linux machine and the Internet with properly defined ICMP filtering rules. Look at the output from the command iptables -p icmp -h (or ipchains icmp -help) to determine which ICMP messages to enable. Start with only the ones you know you need. (You probably should allow MTU discovery, for example.)

Review and Save Your Rules

To view the rules you have created, enter:

 ipchains -L -n iptables -L -n 

To save your iptables rules to the /etc/sysconfig/iptables file on Red Hat so they will take effect each time the system boots, enter:

 #/etc/init.d/iptables save 

Note 

The command service iptables save would work just as well here.

However, if you save your rules using this method as provided by Red Hat, you will not be able to use them as a high-availability resource.^[6] If the cluster load balancer uses sophisticated iptables rules to filter network packets, or, what is more likely, to mark certain packet headers for special handling,^[7] then these rules may need to be on only one machine (the load balancer) at a time.^[8] If this is the case, the iptables rules should be placed in a script such as the one shown at the end of this chapter and configured as a high-availability resource, as described in Part II of this book.

^[6]This is because the standard Red Hat iptables init script does not return something the Heartbeat program will understand when it is run with the status argument. For further discussion of this topic, see the example script at the end of this chapter.

^[7]Marking packets with Netfilter is covered in Chapter 14.

^[8]This would be true in an LVS-DR cluster that is capable of failing over the load-balancing service to one of the real servers inside the cluster. See Chapter 15.