Inbound: Creating a Rule for a New TCP Service | Troubleshooting Linux Firewalls

Undoubtedly you're going to run into a situation where you need to create a rule for a new service. In this example, we have a system running a service called "turtled," which is responsible for controlling a 300-foot tall, fire-breathing rocket turtle named "Gamera." According to legend, he was made by Atlanteans, and because they're all gone, we don't have the documentation for turtled anymore. Even worse, because there's only one Gamera, you're not going to find any help on Google or a mailing list. Not to worry! First we need to determine what port turtled runs on. We can do that with the netstat -pan command:

  [root@winona root]# netstat -pan |grep turtled tcp        0      0 0.0.0.0:2212              0.0.0.0:* LISTEN      3806/turtled

The first column tells us that this is a TCP protocol, and 0 0.0.0.0:2212 tells us that the service is listening on the port 2212. On a host-only firewall, the rule for this service would look like this:

 $IPTABLES -A INPUT -p tcp -dport 2212 -j ACCEPT

If we wanted to limit connections to the turtled service, we could use the RETURN rule to create an exception to exclude hosts from a DROP rule. In this example, two users, Asagi coming from the host 22.33.44.55, and Ayana coming from the host 11.22.33.44, need access to turtled:

 $IPTABLES -N USERS $IPTABLES -N GAMERA $IPTABLES -A USERS -s 11.22.33.44 -j RETURN $IPTABLES -A USERS -s 22.33.44.55 -j RETURN $IPTABLES -A USERS -j DROP $IPTABLES -A GAMERA -j USERS $IPTABLES -A GAMERA -p tcp -dport 2122 -j ACCEPT $IPTABLES -A GAMERA -j DROP

The first chain, USERS, contains a list of IP addresses we'll allow. The second chain, GAMERA, starts with a test against the first chain. This test matches the incoming rule against the IPs listed in USERS, if that rule is matched against the IP address 22.33.44.55for example, we get an exception and RETURN to the GAMERA chain to process the next rule, which is to allow the connection to port 2122. If the IP address does not match anything in the USERS chain, the final rule is a DROP, which is matched, and terminates the rest of the GAMERA chain. As you can see, the use of RETURN in a firewall chain is very powerful. It allows you to quickly create groups of users and separate your rules more cleanly.

To continue with this example, let's assume that you are attempting to forward requests to turtled to an internal server. The firewall, Host-A, has three interfaces: external, internal (10.10.10.0/24), and DMZ (192.168.1.0/24). turtled runs on the system Host-B, located on the DMZ network with the IP address of 192.168.1.10. We will forward connections from Host-A's external IP address to Host-B:

 # where eth0 is the external interface (Internet) # where eth1 is the internal interface (10.10.10.0/24) with the IP 10.10.10.1 # where eth2 is the DMZ interface (192.168.1.0/24) with the IP 192.168.1.1 EXTERNAL=eth0 INTERNAL=eth1 DMZ=eth2 SERVER=192.168.1.10 $IPTABLES -A FORWARD -i $EXTERNAL -o $DMZ -p tcp \       --dport 2122 -m state \       --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPTABLES -t nat -A PREROUTING -i $EXTERNAL -p tcp \       --dport 2122 -j DNAT --to-destination  $SERVER

Figure 13.2. Using DNAT to connect to a DMZ server.

This would allow all connections to 2122 to be forwarded to 192.168.1.10. If we wanted to limit this to the same hosts, because let's face it, a 300-foot tall, fire-breathing rocket turtle is a dangerous thing, we would use a chain with exception rules (the -j RETURN flag). Asagi is coming from the host 22.33.44.55 and Ayana from the host 11.22.33.44we will use the following to ensure only those addresses are allowed:

 # where eth0 is the external interface (Internet) # where eth1 is the internal interface (10.10.10.0/24) # with the IP 10.10.10.1 # where eth2 is the DMZ interface (192.168.1.0/24) with # the IP 192.168.1.1 EXTERNAL=eth0 INTERNAL=eth1 DMZ=eth2 SERVER=192.168.1.10 # Create our user defined chain for exceptions $IPTABLES -N USERS $IPTABLES -A USERS -s 11.22.33.44 -j RETURN $IPTABLES -A USERS -s 22.33.44.55 -j RETURN $IPTABLES -A USERS -j DROP $IPTABLES -A FORWARD -i $EXTERNAL -o $DMZ -p tcp \       --dport 2122 -m state \       --state NEW,ESTABLISHED,RELATED -j USERS $IPTABLES -A FORWARD -i $EXTERNAL -o $DMZ -p tcp \       --dport 2122 -m state \       --state NEW,ESTABLISHED,RELATED -j ACCEPT $IPTABLES -t nat -A PREROUTING -i $EXTERNAL -p tcp \       --dport 2122 -j DNAT --to-destination  $SERVER

This is the first time we demonstrate the use of -j RETURN. Basically this means when the rule is matched, stop parsing this chain and either return to the chain this rule was called from (which we are not doing in this example) or go to the next chain, in this case the line:

 $IPTABLES -A FORWARD -i $EXTERNAL -o $DMZ -p tcp \       --dport 2122 -m state \       --state NEW,ESTABLISHED,RELATED -j ACCEPT

This allows our users to merrily resume wielding their 300-foot tall, fire-breathing rocket turtle. If you are familiar with the concept of groups in Unix, then this idea should not be too much of a stretch to grasp. We are basically creating a "group" of trusted IP addresses with the name "USERS." This way, we can reuse these IP addresses in other rules, thereby simplifying our overall ruleset.