Proper iptables Syntax
|
| In our experience, some of the problems with iptables that are more difficult to diagnose stem from a lack of proper understanding of iptables usage and syntax. As part of the troubleshooting process, make sure you double-check the proper syntax for iptables commands and that you understand how the commands are supposed to be used. It is beyond the scope of this book to document all the switches for iptables; however, a few brief pointers should help with uncovering the proper manner in which a command should be executed. The first useful tool is iptables itself. iptables has a certain amount of built-in documentation that can be accessed by passing iptables the -h switch. When combined with module commands or targets, specific information about that module or target may be available. In this example, we are using a patched 1.2.9 iptables binary with the fake-source patch added. When the -h switch is passed, along with the specific commands and targets we are interested in seeing documentation about, we would use the following command to access the internal documentation: iptables -j REJECT -h Along with the normal iptables command help passed back, at the bottom of the list you may see some text like this: Valid reject types: icmp-net-unreachable ICMP network unreachable net-unreach alias icmp-host-unreachable ICMP host unreachable host-unreach alias icmp-proto-unreachable ICMP protocol unreachable proto-unreach alias icmp-port-unreachable ICMP port unreachable (default) port-unreach alias icmp-net-prohibited ICMP network prohibited net-prohib alias icmp-host-prohibited ICMP host prohibited host-prohib alias tcp-reset TCP RST packet tcp-reset alias icmp-admin-prohibited ICMP administratively prohibited (*) admin-prohib alias --fake-source fake the source address with the destination address of the matched packet (useful for port unreachable ICMP message). (*) See man page or read the INCOMPATIBILITES file for compatibility issues. The proper syntax for this type of documentation request is iptables <command switch> <target> -h This can help with some of the more obscure options and with any custom patches to iptables that may not otherwise be documented by the netfilter project. With regard to the netfilter project, there is no better source of information than from the developers that created netfilter and iptables. The netfilter website (http://www.netfilter.org) contains the most complete set of documentation on iptables and netfilter available anywhere. The key lesson to take away from this section is that before you start digging deeper into a firewall problem, first make certain the syntax for iptables is correct. Moving on, one of the more important set of switches to understand the differences between are the -I and -A switches. -I is used to insert a rule into the top of the current chain. The -A switch, unlike the -I switch, appends a rule to current chain. In other words, -A puts the new rule at the end of the chain, and -I puts it at the beginning. The key thing to stress here is that -I puts rules in before all previous rules, and -A puts them in after. This is because the default behavior of -I is to insert the rule before all other rules in the chain, in what is referred to as "position 1." You can specify the exact position in the chain you want the rule inserted into with -I by passing it an integer with that location. But we really must advise against using the -I switch in this manner. There may be some unique circumstance when you need to do that, but it's a bad habit to get into, and with hard coded numbers, you run the risk of getting out of sync with your other rules. The better habit to get into is to use the -A switch and define your rules in the exact order in which you want the kernel to parse through them. From top to bottom you should have your default deny rules at the end of your list of rules and all your exceptions before these default deny rules. Using -I prodigiously is a very common mistake made by those new to iptables. For instance, adding in a new global DROP rule with the -I switch to the INPUT chain would cause all packets to be dropped; whereas, using the -A switch would just drop any packets not otherwise addressed by your other rules in the INPUT chain before that DROP declaration. -I should only be used if you want to stick something in ahead of rules you have already placed on a system and only if you really know what you are doing. If you are creating a brand new set of rules, again we recommend you always use the -A switch. This will cause the rules to be added to the chain in the exact order in which they are executed whereas with -I, the exact opposite would be true! With regard to defining a rules position by its number, you can also reference a rule by either its nameor by its number. As iptables is linear, each rule added into the kernel is assigned a number either in the order in which it was added, as with -A, or by the position dictated either by default with -I, which is in reverse order, or in explicit order as defined by the user. For instance, suppose you wanted to add a new rule at the top of the INPUT chain as the first rule in that chain and you wanted to reject all SYN packets sent to port 113 on the host. You would use the following syntax: $IPTABLES -I INPUT 1 -p tcp -m tcp --dport 113 \ --syn -j REJECT Because the default behavior of -I is used to insert the new rule into the chain at position 1, then the following command is the same as the previous example: $IPTABLES -I INPUT -p tcp -m tcp --dport 113 \ --syn -j REJECT If you only wanted to add this rule to the end of your current set of rules in your INPUT chain, you would use this syntax: $IPTABLES -A INPUT -p tcp -m tcp --dport 113 \ --syn -j REJECT In addition to adding rules, it might be necessary to delete or replace a rule in its present location. Replacing a rule is done in a manner similar to the example here, where you can either select the rule's name or number when replacing it. $IPTABLES -R INPUT 1 -p tcp -m tcp --dport 113 \ --syn -j ACCEPT And to delete the rule, the process is even simpler: $IPTABLES -D INPUT 1 Aside from creating rules, you also can create your own chains with iptables by using the -N command: $IPTABLES -N my_chain And much like rules, you also can delete, replace, or rename a chain. Deleting a chain is accomplished by using the -X switch: $IPTABLES -X my_chain Renaming a chain is possible through the use of the -E switch, as in this example: $IPTABLES -E my_chain new_name_for_my_chain Finally, a default policy can be set for a chain with the -P switch. This allows for the creation of default behaviors for a chain, perhaps to aid in debugging or to prevent mistakes that might lead to a security breach. For example, imagine that you do not want your firewall to allow any inbound connections to the firewall itself. This is not to be confused with forwarding connections, which are not to the firewall, per se, but rather to some system on the other side of the firewall. To create a default policy to block packets to the firewall, the INPUT chain would have its policy changed to DROP or REJECT: $IPTABLES -P INPUT DROP3 A few administrative commands with iptables that are extremely useful are the list (-L) and zero (-Z) switches. List provides for a means to list the currently loading iptables rules on a system; the -Z switch will zero out the counters for each of the iptables rules. We will review counters in a moment, but first, to view all of the current rules on your system without counters, your iptables command would look like this: iptables -L And your output might look like this: Chain INPUT (policy ACCEPT) target prot opt source destination RH-Lokkit-0-50-INPUT all -- anywhere anywhere SILENT udp -- anywhere anywhere udp SILENT tcp -- anywhere anywhere tcp SILENT udp -- anywhere anywhere udp SILENT tcp -- anywhere anywhere tcp SILENT udp -- anywhere anywhere udp SILENT tcp -- anywhere anywhere tcp SILENT udp -- anywhere anywhere udp SILENT tcp -- anywhere anywhere tcp LOG all -- anywhere anywhere limit: avg 1/sec burst 5 LOG level info tcp-sequence tcp-options ip-options prefix 'STEALTH -- DROP ' Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Lokkit-0-50-INPUT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU Chain RH-Lokkit-0-50-INPUT (2 references) target prot opt source destination ACCEPT udp -- localhost.localdomain anywhere udp spt:domain dpts:1025:65535 ACCEPT ipv6-crypt-- anywhere anywhere ACCEPT ipv6-auth-- anywhere anywhere ACCEPT 61 -- anywhere anywhere ACCEPT udp -- anywhere anywhere udp dpt:isakmp ACCEPT udp -- anywhere anywhere udp dpt:4500 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh flags:SYN,RST,ACK/SYN ACCEPT tcp -- anywhere anywhere tcp dpt:6881 flags:SYN,RST,ACK/SYN ACCEPT udp -- anywhere anywhere udp dpt:6881 ACCEPT udp -- anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc ACCEPT udp -- anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc ACCEPT udp -- anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc ACCEPT udp -- anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc ACCEPT udp -- anywhere anywhere udp spts:bootps:bootpc dpts:bootps:bootpc ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT udp -- anywhere anywhere udp spt:domain REJECT tcp -- anywhere anywhere tcp dpt:auth flags:SYN,RST,ACK/SYN reject-with icmp-port-unreachable DROP tcp -- anywhere anywhere tcp flags:SYN,RST,ACK/SYN DROP udp -- anywhere anywhere udp Chain SILENT (8 references) target prot opt source destination DROP all -- anywhere anywhere Should your iptables -L command "hang," it is because iptables is attempting to perform a hostname lookup of the IP addresses in your rules. In the example here, there are no IP addresses associated with any of the rules. If you have an IP address associated with your rules and your hostname lookups are hanging or taking too long for your purposes, add the -n switch to the iptables command. This switch will tell iptables not to do DNS lookups on IP addresses in the rulesets. $iptables -L -n Again, your output should look something like this, but with your rules: Chain INPUT (policy ACCEPT) target prot opt source destination RH-Lokkit-0-50-INPUT all -- 0.0.0.0/0 0.0.0.0/0 SILENT udp -- 0.0.0.0/0 0.0.0.0/0 udp SILENT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 1/sec burst 5 LOG flags 7 level 6 prefix 'STEALTH -- DROP ' Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Lokkit-0-50-INPUT all -- 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT) target prot opt source destination TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Chain RH-Lokkit-0-50-INPUT (2 references) target prot opt source destination ACCEPT udp -- 127.0.0.1 0.0.0.0/0 udp spt:53 dpts:1025:65535 ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0 ACCEPT 61 -- 0.0.0.0/0 0.0.0.0/0 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:500 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:4500 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 flags:0x16/0x02 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6881 flags:0x16/0x02 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:6881 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spts:67:68 dpts:67:68 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:53 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 flags:0x16/0x02 reject-with icmp-port-unreachable DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02 DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp Chain SILENT (8 references) target prot opt source destination DROP all -- 0.0.0.0/0 0.0.0.0/0 The -L command also has the capability of reporting additional information about the rule, such as how much traffic is being processed by the rule, the aforementioned counters, the number of the rule, and in the most verbose mode very detailed information about the rule. The most common command to pass to your iptables is the -v switch along with -L, which will cause iptables to report the same information as in the preceding example, along with additional information about the amount of traffic processed by that rule or the rule's counters. iptables -L -n -v Chain INPUT (policy ACCEPT 78 packets, 4208 bytes) pkts bytes target prot opt in out source destination 458K 277M RH-Lokkit-0-50-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 SILENT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp 0 0 SILENT tcp -- eth0 * 70 3536 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 1/sec burst 5 LOG flags 7 level 6 prefix 'STEALTH -- DROP ' Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 RH-Lokkit-0-50-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 449K packets, 143M bytes) pkts bytes target prot opt in out source destination 10413 625K TCPMSS tcp -- * ppp0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Chain RH-Lokkit-0-50-INPUT (2 references) pkts bytes target prot opt in out source destination 12981 2380K ACCEPT udp -- * * 127.0.0.1 0.0.0.0/0 udp spt:53 dpts:1025:65535 0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT ah -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT 61 -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:500 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4500 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 flags:0x16/0x02 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6881 flags:0x16/0x02 0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp spts:67:68 dpts:67:68 dpts:67:68 433K 274M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 10931 676K ACCEPT all -- lo * 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 flags:0x16/0x02 reject-with icmp-port-unreachable 494 23808 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02 14 979 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp Chain SILENT (8 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 When -vv is passed to iptables, the level of detail is simply increased. And a subset of what might be returned would look something like this: iptables -L -n -vv Chain INPUT (policy ACCEPT 79 packets, 4236 bytes) pkts bytes target prot opt in out source destination 459K 277M RH-Lokkit-0-50-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 SILENT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp 71 3564 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 1/sec burst 5 LOG flags 7 level 6 prefix 'STEALTH -- DROP ' Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 RH-Lokkit-0-50-INPUT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 450K packets, 143M bytes) pkts bytes target prot opt in out source destination 10414 625K TCPMSS tcp -- * ppp0 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Chain RH-Lokkit-0-50-INPUT (2 references) pkts bytes target prot opt in out source destination 12985 2381K ACCEPT udp -- * * 127.0.0.1 0.0.0.0/0 udp spt:53 dpts:1025:65535 0 0 ACCEPT esp -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT ah -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT 61 -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:500 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4500 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 flags:0x16/0x02 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:6881 flags:0x16/0x02 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:6881 0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp spts:67:68 dpts:67:68 434K 274M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 10933 676K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 flags:0x16/0x02 reject-with icmp-port-unreachable 495 23856 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02 14 979 DROP udp -- * * 0.0.0.0/0 0.0.0.0/0 udp Chain SILENT (8 references) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 libiptc v1.2.8. 44 entries, 7776 bytes. Table 'filter' Hooks: pre/in/fwd/out/post = 0/0/2068/2364/0 Underflows: pre/in/fwd/out/post = 1920/1920/2216/2556/1920 Entry 0 (0): SRC IP: 0.0.0.0/0.0.0.0 DST IP: 0.0.0.0/0.0.0.0 Interface: ''/................to ''/................ Protocol: 0 Flags: 00 Invflags: 00 Counters: 458725 packets, 277161237 bytes Cache: 00000000 Target name: '' [36] verdict=2880 Entry 1 (148): SRC IP: 0.0.0.0/0.0.0.0 DST IP: 0.0.0.0/0.0.0.0 Interface: 'eth0'/XXXXX...........to ''/................ Protocol: 17 Flags: 00 Invflags: 00 Counters: 0 packets, 0 bytes Cache: 00000624 IP_IF_IN IP_PROTO IP_SRC_PT IP_DST_PT Match name: 'udp' Target name: '' [36] verdict=7304 [...] Entry 43 (7600): SRC IP: 0.0.0.0/0.0.0.0 DST IP: 0.0.0.0/0.0.0.0 Interface: ''/................to ''/................ Protocol: 0 Flags: 00 Invflags: 00 Counters: 0 packets, 0 bytes Cache: 00000000 Target name: 'ERROR' [64] error='ERROR' A tangentially useful command to the -L command is the flush (-F) switch. Flush will simply delete a specified rule. If you do not select a rule, the -F switch will delete all the rules on the system. Keep in mind that deleting rules will not delete chains. Chains must be deleted with the -X switch as explained earlier. As with the -F switch, if you do not specify a chain to delete, -X will delete all the chains. The last useful switch to understand with iptables is -j. This tells iptables to "jump" to another chain. This is extremely useful when constructing your own chains, as you can create some logic in your rulesets with different rules triggering different unique chains. For instance, if you created a chain called MY_LOG via this command: iptables -N MY_LOG and your intent was for that chain to log any packets associated with it, you would do this: iptables -A MY_LOG -m limit --limit 1/second -j LOG --log-level info --log-prefix "MY_LOG " Notice that we are using the append command as opposed to the insert command. We could use the insert command here, but we prefer not to as it can create a dangerous habit when you get used to inserting as opposed to appending rules. Insertion can create strange behavior in your rule set, as the logic is inverted (each subsequent rule with -I places itself before all the previous rules). Stick with -A and, as they say, you'll be cream cheese. Now that you have the MY_LOG chain, you can jump to it from other rules. For example, if you had a rule to detect every time someone SSH-ed into your system, you could jump to the MY_LOG chain to log the connection: iptables -A INPUT -i eth1 -p tcp -d <your firewalls IP> --destination-port 22 -m conntrack -j MY_LOG There are many other switches available for iptables, some of which we will describe in greater detail later in the book. It is beyond the scope of this book to cover all of iptables, but additional information on this topic is available at our website, www.gotroot.com, at the www.netfilter.org website, and also if installed on your system, in the iptables man pages. You can access your iptables online documentation by simply running the command man iptables on the system where you have iptables installed. Examples of How the Connection Tracking Engine WorksUDPWith the understanding in hand now as to how the netfilter engine specifically works and the proper manner in which to use iptables, let's take a look at how the engine works with specific protocols. The first protocol to look at is UDP, which is technically a connectionless protocol. Because UDP is connectionless, it would seem that the firewall would not be able to maintain state on these sorts of connections, but in a limited way it can. Let's take a look at an example. Recall from Chapter 6 how netfilter tracks a UDP connection. In this example, a client has sent a DNS lookup request to a remote DNS server. udp 17 20 src=10.10.10.2 dst=10.10.11.1 sport=5353 dport=53 [UNREPLIED] src=10.10.11.1 dst=10.10.10.2 sport=53 dport=5353 use=1 udp 17 20 src=10.10.10.2 dst=10.10.11.1 sport=5353 dport=53 src=10.10.11.1 dst=10.10.10.2 sport=53 dport=5353 use=1 udp 17 20 src=10.10.10.2 dst=10.10.11.1 sport=5353 dport=53 src=10.10.11.1 dst=10.10.10.2 sport=53 dport=5353 [ASSURED] use=1 TCPTCP connections, unlike UDP, are stateful. They consist of a predefined manner of establishing a connection and tearing it down. This mechanism is commonly referred to as the handshaking, which was covered in Chapter 5. Because of its connection-oriented status, a TCP connection has many more intermediate states before it reaches the ESTABLISHED state. Applying What Has Been Covered So Far by Implementing Good RulesNow that we have covered risk management, securing the firewall, problem-solving methodologies, and how netfilter works, it's time to delve into some ideas about how to construct good files rules. One of the first tools you can use are iptables policies. iptables policies allow a user to set absolute and default rules for chains. For instance, if you set the policy for the INPUT chain to DROP, every packet going to the firewall's interfaces but not being FORWARD-ed by the firewall will be dropped unless you explicitly set up a rule to do otherwise. Policies are an excellent way of sanity checking your rules by defining a default behavior for all your rulesif no other conditions are met. For purposes of security, the default DROP rule for the INPUT, OUTPUT, and FORWARD rules is always recommended. iptables is linearthat is, rules are checked in a top to bottom, first inserted into the kernel order. If a rule exists to allow in all traffic to port 23, but a later rule says to block traffic from a specific host, that specific host will still be able to connect to port 23. It's critical then to structure your firewall rules in a carefully chosen order, putting all of your ACCEPT rules at the end of your rulesets so that any explicit and specific DROP or REJECT rules will be triggered before them. One note of cautiondon't put your default DROP and LOG rules above your ACCEPT rules; otherwise, nothing will get through your firewall. To keep it simple, we like to use this layout for our rules:
|
|
