2

1

THEORY

Purpose

The purpose of this lab is to give the student a basic understanding of the iptables firewalling software.

2

Theory

Linux is popular as a platform for developing inexpensive, reliable firewalls. An old PC that is too underpowered for any other use will make an admirable packet filtering firewall machine. Such a packet filter examines incoming packets and decides what to do with them based on a set of rules defined by the system administrator. Generally you will have one of two types of firewalls - those which protect what is known as a DMZ (de-militarized zone) and those which don’t. A DMZ is an area of your network which provides one or more services to the entire Internet, such as public mail, DNS, or web access. These machines are kept on a separate network from computers which do not provide public services. There are two common topologies if you have a DMZ, diagrammed below.

1

2

2

THEORY

2

THEORY

The primary difference between the two is that in the first illustration, one firewall machine protects both the DMZ and the private LAN. In the second example, traffic for the public machines is routed through a dedicated DMZ firewall. This firewall never sees any traffic intended for the LAN. The opposite is true of the LAN firewall - it never sees any traffic intended for the DMZ. The first solution eliminates some hardware by simply adding a third NIC, and so is less expensive. However, a failure in the firewall can potentially compromise every machine, public and private. The second scheme, though it requires more hardware, distributes our areas of potential vulnerability. Linux has had a number of different firewalling programs. The 2.0 kernel series used ipfwadm; the 2.2 kernel series used ipchains; and 2.4 can use either ipchains or iptables. Both ipchains and iptables have their own sets of kernel modules; the kernel can only accept one or the other at any given time. You may need to check which modules your distribution loads by default.

3

3

EXERCISE

Iptables is packet filtering software which can be divided into three main "tables", or purposes. The first of these tables is the filter table, which examines a packet and makes an access control decision based on an existing ruleset. The second, nat (network address translation) is a form of redirection. It can take outgoing packets from multiple machines and make them seem to come from only one publicly visible computer, as in masquerading. It also functions in the reverse direction, splitting packets intended for one hostname among various computers with different IP addresses, which is done in load-balancing servers. A specialized type of redirection is possible which enables transparent proxying. See the squid proxy server lab for more information on this subject. The third table, "mangle", alters packet content. This is a more advanced function which will not be discussed in this lab. Iptables works at the network and transport layers; it does not differentiate among applications. For application-level control, an application gateway (proxy) such as squid must be configured. Iptables can redirect packets to squid, a process called transparent redirection. Generally, iptables rulesets will be saved in an executable shell script run at boot time. A default policy will be set as a catch-all for packets which do not match any rules. Good firewalls deny all traffic by default and then allow specific connections. This is much safer than trying to guess every malicious which might potentially come in. Initial kernel configuration by manipulation of various files in and under /proc/sys/net may also be done at the beginning of the script. The more thorough knowledge you have of the TCP/IP protocols, the easier this material will be. If you feel you have a weakness, or simply want to understand more., take a look at the various Internet and published references. The various network-related HOWTOs will also be helpful. The iptables command has a multitude of confusing options, many of which may be combined. For that reason, we do not quote the man page first. Rather, we will work through many examples.

3 3.1

Exercise Packet filtering

Packet filtering is the process of selecting what incoming packets to accept, reject, or forward. it is used to block out unwanted or malicious traffic, and to restrict outbound traffic. First, set up rules on one machine, and test with the other. It is also possible to do some of these exercises on one machine (just block out all interfaces, including "lo" - loopback to the specified ports). Before starting, make sure that you

4

3.1

Packet filtering

3 EXERCISE

have telnet and ftp services available on the machine which will have the iptables established. Remember that this is typically configured with inetd or xinetd. All of the examples in this lab will be executed from the command line. To start with, we need to make sure what our policies are. The policy is the default action which will be applied to all packets which do not match a rule. We will set our policies to “ACCEPT” in order to make examples easier, but in real life, they should be “DROP”. We need to set a policy for each chain of the filter table. #iptables -P INPUT ACCEPT #iptables -P OUTPUT ACCEPT #iptables -P FORWARD ACCEPT Note that the chain names (INPUT, OUTPUT, and FORWARD), and the policies attached to them are all in caps. What each chain does should be explanatory from their names. In addition, because we are using the filter table, we do not need to specify a table. The following is equivalent to what we have done above: #iptables -t filter INPUT ACCEPT #iptables -t filter OUTPUT ACCEPT #iptables -t filter FORWARD ACCEPT Next, flush any rules that may already be set up. Just because our policy is ACCEPT doesn’t mean that we have eliminated all packet filtering - we need to eliminate the rules as well. #iptables -F INPUT #iptables -F INPUT #iptables -F INPUT This simply removes (flushes) any rules that are currently set up. We now have a clean slate. No network traffic, either incoming or outgoing will be blocked. Verify that your firewall is wide-open with the following commands: trane:/home/jeff # iptables -L -v -n Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination

5

3.1

Packet filtering

3 EXERCISE

We are given a listing of each rule (in this case, there are none) in each chain. Our default behavior (ACCEPT) is shown as well. The other listings will be explained shortly. Now we can do some actual filtering: #iptables -A INPUT -i eth0 -j DROP This command appends a rule (-A) to the INPUT chain. It also specifies an interface (-i), eth0, and jumps (-j) to a target, which is DROP. Had we specified the OUTPUT chain, we would have needed to change the “-i” to “-o”, which we will demonstrate shortly. List your rules now: trane:/home/jeff # iptables -L -v -n Chain INPUT (policy ACCEPT 6 packets, 862 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- eth0 * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 5 packets, 623 bytes) pkts bytes target prot opt in out source destination The “L” stands for list, the “v” for verbose, and the “n” prevents name lookups. The system maintains a counter of the packets and bytes your rule has been applied to. It shows the target (DROP), the protocols (all), options, the input and output addresses the rule applies to (0.0.0.0 stands for all ip addresses) . Now try pinging the machine with incoming traffic over eth0 blocked: jeff@diz:~$ ping trane PING trane.example.com (192.168.1.3): 56 octets data --- trane.example.com ping statistics --2 packets transmitted, 0 packets received, 100% packet loss

6

3.1

Packet filtering

3 EXERCISE

List your ruleset again: trane:/home/jeff # iptables -L -v -n Chain INPUT (policy ACCEPT 6 packets, 862 bytes) pkts bytes target prot opt in out source destination 20 1622 DROP all -- eth0 * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 19 packets, 1630 bytes) pkts bytes target prot opt in out source destination You can see that we have blocked 20 packets with our lone rule. Now we will block all outgoing traffic on eth0: trane:/home/jeff # iptables -A OUTPUT -o eth0 -j DROP Try to ping out: trane:/home/jeff # ping bird PING bird.example.com (192.168.1.10) from 192.168.1.3 : 56(84) bytes of data. ping: sendmsg: Operation not permitted ping: sendmsg: Operation not permitted --- bird.example.com ping statistics --2 packets transmitted, 0 received, 100% loss, time 999ms List your rules again: trane:/home/jeff # iptables -L -v -n Chain INPUT (policy ACCEPT 6 packets, 862 bytes) pkts bytes target prot opt in out source destination 22 1702 DROP all -- eth0 * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 21 packets, 1718 bytes) pkts bytes target prot opt in out source destination 3 212 DROP all -- * eth0 0.0.0.0/0 0.0.0.0/0 Now you can see the packets we have blocked outbound as well.

7

3.1

Packet filtering

3 EXERCISE

We can reset the packet counters with the -Z flag: trane:/home/jeff # iptables -Z trane:/home/jeff # iptables -L -v -n Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- eth0 * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * eth0 0.0.0.0/0 0.0.0.0/0 If you have a problem with figuring out where your firewall is going wrong, you can use the counters to track what is being allowed and isn’t being allowed. Flush your ruleset and we’ll start a more finely-grained example: #iptables -F trane:/home/jeff # iptables -A INPUT -p tcp --dport 23 -j DROP trane:/home/jeff # iptables -L -v -n Chain INPUT (policy ACCEPT 27 packets, 4742 bytes) pkts bytes target prot opt in out source destination 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 29 packets, 3573 bytes) pkts bytes target prot opt in out source destination What we have done is specified that any incoming connection using TCP intended for port 23 (telnet) will be dropped. Try telnetting to your machine to verify this. At this point, we have blocked all interfaces with our telnet rule, but we can combine flags to achieve even more granularity. Here we block all outgoing telnet traffic on eth0: trane:/home/jeff # iptables -A OUTPUT -o eth0 --dport p tcp --dport 23 -j DROP trane:/home/jeff # iptables -L -v -n Chain INPUT (policy ACCEPT 29 packets, 4842 bytes) pkts bytes target prot opt in out source destination

8

3.1

Packet filtering

3 EXERCISE

0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 31 packets, 3673 bytes) pkts bytes target prot opt in out source destination 0 0 DROP tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 We block based on the server port because that is constant - we cannot know what the client port will be. An even more specific role would be: trane:/home/jeff # iptables -A OUTPUT -d 216.90.523. 221.54 -p tcp --dport 21 -j DROP trane:/home/jeff # iptables -L -v -n Chain INPUT (policy ACCEPT 34 packets, 5664 bytes) pkts bytes target prot opt in out source destination 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 37 packets, 4370 bytes) pkts bytes target prot opt in out source destination 0 0 DROP tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 0 0 DROP tcp -- * * 0.0.0.0/0 216.90.221.54 tcp dpt:21 At this point, we are blocking outgoing access to the ftp port on 216.90.221.54 on all interfaces. If we wished, we could specify only one interface using “-o”. We can also specify incoming hosts which we will block: trane:/home/jeff # iptables -A INPUT -p tcp -s 216.90.221.54 --sport 21 -j DROP trane:/home/jeff # iptables -L -v -n Chain INPUT (policy ACCEPT 38 packets, 5882 bytes) pkts bytes target prot opt in out source destination 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 0 0 DROP tcp -- * * 216.90.221.54 0.0.0.0/0 tcp spt:21 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 41 packets, 4644 bytes) pkts bytes target prot opt in out source destination 9

3.2

Logging

3 EXERCISE

0 0 DROP tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp dpt:23 0 0 DROP tcp -- * * 0.0.0.0/0 216.90.221.54 tcp dpt:21 The “-s” specifies a source, and “–sport” specifies a source port. Whenever we specify sources or destinations, we can do so with names or IP addresses; IP addresses are preferable in order to prevent slowdowns due to DNS lookups. In addition, whenever we specify a port, we must specify a protocol as well with “p”. The meaning of a flag can often be reversed by preceding it with an exclamation point. For example, to allow everything but telnet traffic, and assuming our policy is DROP, we could do: #iptables -A INPUT -p tcp !

--dport 23 -j ACCEPT

Other flags which can be reversed include –sport, -p , -s. -d, -i, and -o. You may also find examples where numbers are substituted for protocol names. The numbers are found in /etc/protocols: 1

ICMP

6

TCP

17

UDP

There are other protocols listed in /etc/protocols, but the three listed here are the important ones for our needs.

3.2

Logging

Flush your rules and start over with new rules. We can use iptables to log via syslog, as in the following example. # iptables -A INPUT -p tcp -i eth0 -s 0.0.0.0/0 -d 0.0.0.0/0 -dport 23 -j LOG --log-prefix "Telnet attempt" # iptables -A INPUT -p tcp -i eth0 -s 0.0.0.0/0 -d 0.0.0.0/0 -dport 23 -j DROP This tells iptables to append (-A) this rule to the input chain, look only at TCP traffic, deal only with the traffic on eth0, from all sources, to all destinations, on port 23 only (telnet’s port), DROP any of this traffic, and log (-l) all traffic that the rule denies. Note that we set the LOG target up first - otherwise, the packet would be dropped before it could be logged.

10

3.3

State Matching

3 EXERCISE

Try telnetting into the machine. You should have received a message saying that the connection could not be established. Since we told iptables to log all violations of our rule, now would be a good time to take a look at the logs, to familiarize ourselves with the location and format of the log file. # tail /var/log/messages This will display on the screen, the last 10 lines of the /var/log/messages file. You should notice at least one line at the end warning of blocked network traffic. This file tends to be a little cryptic, but once you are a little familiar with the format, it is not quite as bad. Now, we will do basically what we did in step 2, only with ftp traffic. # iptables -A INPUT -p tcp -i eth0 -s 0.0.0.0/0 -d 0.0.0.0/0 -dport 21 -j LOG --log-prefix "FTP attempt" # iptables -A INPUT -p tcp -i eth0 -s 0.0.0.0/0 -d 0.0.0.0/0 -dport 21 -j DENY Notice that the only thing we did differently this time was change the port number. We still want to append to the input chain, look at tcp traffic on eth0, coming from or going to anywhere, we still want to deny it, and we still want to log it. Now try to ftp. It should come as no surprise that you are unable to!

3.3

State Matching

Iptables supports state matching. A stateful firewall is one which can track connections, and can associate the current packet with an earlier one. Set up some stateful rules. Assuming you have set your INPUT policy to deny, the next rule allows incoming traffic only if it is related to an outgoing request. Such a rule is typical of networks which run no publicly available servers, such as those behind a dial-up connection. Flush your ruleset with: #iptables -F and then do: # iptables -A INPUT -i eth0 -m state -state ESTABLISHED -j ACCEPT Set your INPUT policy to DROP with: #iptables -P INPUT DROP

11

3.4

NAT (Network Address Translation)

3 EXERCISE

Make sure that your other machine has telnet available. You should be able to telnet to that machine, but not the other way around. Statefulness allows us to do some rate limiting: Flush the ruleset again, set your input policy to drop, and then do the following: #iptables -A INPUT -p icmp --icmp-type echo-request -m limit -limit 1/s -j ACCEPT Now have ping-flood your machine with "ping -f". Watch the loss rate of the packets on the pinging machine. In addition, to echo-request, iptables also supports echo-replies, but blocking requests is better from the standpoint of preventing a denial of service.

3.4

NAT (Network Address Translation)

Do some masquerading and network address translation (NAT). Address translation changes an incoming packet’s destination (destination nat) or and outgoing packet’s original address(source nat). Masquerading is a specific type of source nat used by hosts with dynamically assigned IP’s, such as dialup connections. Traditional source nat (not masquerading) is used when there is one publicly routable IP address on the gateway and everything behind the gateway has nonroutable, private IP addresses. Assuming that your public IP is 216.90.72.8 on eth0, you would have an iptables rule such as the following: # iptables -t nat -A POSTROUTING -o eth0 -j SNAT -to-source 216.90.72.8 Optionally, if a range of public IP’s could be specified if available, as could a range of ports. Note that we must specify the nat table with -t, and that we are using the POSTROUTING chain. POSTROUTING refers to the fact that we already know the route the packet must take out to get to its destination. Masquerading uses a similar rule: #iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE In other words, anything going through ppp0 is masqueraded. DNAT (destination nat) is used to send incoming packets to a different IP address. Here, eth0 is our public interface. We use PREROUTING because this is the first time we see the packet. # iptables -t nat -A PREROUTING -i eth0 -p tcp -sport 1024:65535 -d 216.90.72.8 -dport 80 -j DNAT -to-destination 206.90.72.9-216.90.72.12 12

3.5

Kernel Configuration

3

EXERCISE

Here , any packet intended for port 80 on 216.90.72.8 gets sent to one of the hosts specified. This is a configuration that might be used in load balancing web requests. We could also redirect to a proxy server running on our gateway, assuming that the proxy has been configured correctly: # iptables -t nat -A PREROUTING -i eth0 -p tcp -dport 80 -j REDIRECT -to-port 3128 Forwarding is routing traffic between networks (also known as routing). Earlier linux firewall implementations such as ipchains confused forwarding and masquerading/nat, since the "masquerade" target could only be used on the FORWARD chain. Iptables separates the two. When forwarding, you generally have a pair of rules; one rule in the pair reverses the interfaces of the other. It is possible to simplify this pairing with the use of state checking. The first rule accepts all new incoming web requests on public interface eth0 and sends them out private interface eth1 to 216.90.72.12. # iptables -A FORWARD -i eth0 -o eth1 -p tcp --sport 1024:65535 -d 192.168.1.5 -dport 80 -m state -state NEW -j ACCEPT We then check for statefulness in replies from our web server: # iptables -A FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT And reverse the interfaces to check for client replies: # iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT

3.5

Kernel Configuration

Many of the capabilities of iptables must be compiled into the kernel for them to work . For the most part, a stock kernel from any major distribution will have everything you need. Most likely, these features will be compiled as modules and loaded on the fly. Other kernel capabilities can be tuned be setting values in various files in /proc. This is doable by inserting the appropriate commands in shell scripts. Some of them are: 1. echo broadcast protection: Protection against ICMP broadcasts is accomplished with:

13

3.5

Kernel Configuration

3

EXERCISE

#echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore broadcasts 2. source routing protection: If a packet has been instructed to follow a specific route by the sender, the intent is often to do ill. Source-routing can be defeated with:

#for f in /proc/sys/net/ipv4/conf/*/accept_source_route >do echo 0 > $f >done 3. syn cookies: Syn cookies are a defense against SYN floods, which send lots of spurious SYN requests in a denial-of-service attempt. Enable syn cookies with:

#echo 1 > /proc/sys/net/ipv4/tcp_syncookies 4. ICMP redirects: ICMP redirects, which use ICMP to redirect network traffic, are another sign of malicious intent. Defeat their acceptance with:

#for f in /proc/sys/net/ipv4/conf/*/send_redirects >do echo 0 > $f >done You can avoid sending them with:

#for f in /proc/sys/net/ipv4/conf/*/send_redirects >do echo 0 > $f >done 5. spoofed packets: A response should always be sent on the same interface the initial request was received on. We can guarantee that spoofed packets won’t defeat this by doing:

#for f in /proc/sys/net/ipv4/conf/*/rp_filter 14

3.6

Assembling a complete ruleset

4

COMMAND REFERENCE

>do >echo 1 > $f >done Another form of spoofing is done by creating illegal addresses. These addresses can be logged with:

#for f in /proc/sys/net/ipv4/conf/*/log_martians >do >echo 1 > $f >done 6. routing and forwarding: Routing is enabled by the following command:

#echo 1 > /proc/sys/net/ipv4/ip_forward

3.6 Assembling a complete ruleset Firewall rules are usually executed in a shell script at boot time. Check out http: //www.linuxguruz.org/iptables/ and examine their complete firewall scripts to give yourself an idea of what a complete ruleset looks like. Once this lab is completed, the student should have a basic understanding of iptables. Iptables is capable of much more than what was demonstrated in this lab, however. The student is strongly encouraged to spend as much time as possible practicing with iptables.

4

Command Reference

We have only touched on the most basic functions of iptables - for more information, consult a good reference or tutorial online. You may find one at http:// www.linuxsecurity.com/resource_files/firewalls/IPTables-Tutorial/ iptables-tutorial.html; written by Oskar Andreasson, it is the best online reference to iptables there is, possibly even including the original iptables documentation. However, the material presented here should give you a firm basis in Linux firewalling that will allow you to proceed further on your own.

15

4.1

4.1

Tables

4

COMMAND REFERENCE

Tables

-t, –table table

This option specifies the packet matching table which the command should operate on. If the kernel is configured with automatic module loading, an attempt will be made to load the appropriate module for that table if it is not already there. The tables are as follows:

4.2

filter

This is the default table (if no -t option is passed). It contains the built-in chains INPUT (for packets coming into the box itself), FORWARD (for packets being routed through the box), and OUTPUT (for locally-generated packets).

nat

This table is consulted when a packet that creates a new connection is encountered. It consists of three built-ins: PREROUTING (for altering packets as soon as they come in), OUTPUT (for altering locally-generated packets before routing), and POSTROUTING (for altering packets as they are about to go out).

mangle

This table is used for specialized packet alteration. Until kernel 2.4.17 it had two built-in chains: PREROUTING (for altering incoming packets before routing) and OUTPUT (for altering locally- generated packets before routing). Since kernel 2.4.18, three other built-in chains are also supported: INPUT (for packets coming into the box itself), FORWARD (for altering packets being routed through the box), and POSTROUTING (for altering packets as they are about to go out).

Commands

These options specify the specific action to perform. Only one of them can be specified on the command line unless otherwise specified below. For all the long ver sions of the command and option names, you need to use only enough letters to ensure that iptables can differentiate it from all other options. -A, –append chain rule-specification

Append one or more rules to the end of the selected chain. When the source and/or destination names resolve to more than one address, a rule will be added for each possible address combination.

-L, –list [chain]

List all rules in the selected chain. If no chain is selected, all chains are listed. 16

4.3

Parameters

4

COMMAND REFERENCE

As every other iptables command, it applies to the specified table (filter is the default), so NAT rules get listed by iptables -t nat -n -L Please note that it is often used with the -n option, in order to avoid long reverse DNS lookups. It is legal to specify the -Z (zero) option as well, in which case the chain(s) will be atomically listed and zeroed. The exact output is affected by the other arguments given. The exact rules are suppressed until you use iptables -L -v -F, –flush [chain]

Flush the selected chain (all the chains in the table if none is given). This is equivalent to deleting all the rules one by one.

-Z, –zero [chain]

Zero the packet and byte counters in all chains. It is legal to specify the L, –list (list) option as well, to see the counters immediately before they are cleared. (See above.)

-P, –policy chain target

Set the policy for the chain to the given target. See the section TARGETS for the legal targets. Only built-in (nonuser-defined) chains can have policies, and neither built-in nor user-defined chains can be policy targets.

4.3

Parameters

The following parameters make up a rule specification (as used in the add, delete, insert, replace and append commands). -p, –protocol [!] protocol

The protocol of the rule or of the packet to check. The specified protocol can be one of tcp, udp, icmp, or all, or it can be a numeric value, representing one of these protocols or a different one. A protocol name from /etc/protocols is also allowed. A "!" argument before the protocol inverts the test.

17

4.3

Parameters

4

COMMAND REFERENCE

The number zero is equivalent to all. Protocol all will match with all protocols and is taken as default when this option is omit ted. -s, –source [!] address[/mask]

Source specification. Address can be either a network name, a hostname (please note that specifying any name to be resolved with a remote query such as DNS is a really bad idea), a network IP address (with /mask), or a plain IP address. The mask can be either a network mask or a plain number, speci fying the number of 1’s at the left side of the network mask. Thus, a mask of 24 is equivalent to 255.255.255.0. A "!" argument before the address specification inverts the sense of the address. The flag –src is an alias for this option.

-d, –destination [!] address[/mask]

Destination specification. See the description of the -s (source) flag for a detailed description of the syntax. The flag –dst is an alias for this option.

-j, –jump target

This specifies the target of the rule; i.e., what to do if the packet matches it. The target can be a user-defined chain (other than the one this rule is in), one of the special builtin targets which decide the fate of the packet immediately, or an extension (see EXTENSIONS below). If this option is omitted in a rule, then matching the rule will have no effect on the packet’s fate, but the coun ters on the rule will be incremented.

-i, –in-interface [!] name

Name of an interface via which a packet is going to be received (only for packets entering the INPUT, FORWARD and PREROUTING chains). When the "!" argument is used before the interface name, the sense is inverted. If the interface name ends in a "+", then any interface which begins with this name will match. If this option is omitted, any interface name will match.

-o, –out-interface [!] name

Name of an interface via which a packet is going to be sent (for packets entering the FORWARD, OUTPUT and POSTROUTING 18

4.4

Other options

4

COMMAND REFERENCE

chains). When the "!" argument is used before the interface name, the sense is inverted. If the interface name ends in a "+", then any interface which begins with this name will match. If this option is omitted, any interface name will match.

4.4

Other options

-v, –verbose

Verbose output. This option makes the list command show the interface name, the rule options (if any), and the TOS masks. The packet and byte counters are also listed, with the suffix ’K’, ’M’ or ’G’ for 1000, 1,000,000 and 1,000,000,000 multipliers respectively (but see the -x flag to change this). For appending, insertion, deletion and replacement, this causes detailed information on the rule or rules to be printed.

-n, –numeric

Numeric output. IP addresses and port numbers will be printed in numeric format. By default, the program will try to display them as host names, net work names, or services (whenever applicable).

4.5

Match extensions

iptables can use extended packet matching modules. These are loaded in two ways: implicitly, when -p or –protocol is specified, or with the -m or –match options, followed by the matching module name; after these, various extra command line options become available, depending on the specific module. You can specify multiple extended match modules in one line, and you can use the -h or –help options after the module has been specified to receive help specific to that module. The following are included in the base package, and most of these can be preceded by a ! to invert the sense of the match. 4.5.1

TCP

–source-port [!] port[:port]

Source port or port range specification. This can either be a service name or a port number. An inclusive range can also be specified, using the format port:port. If the first port is omitted, "0" is assumed; if the last is omitted, "65535" is assumed. If the second port greater then the first they will be swapped. The flag –sport is a convenient alias for this option.

19

4.5

Match extensions

4

COMMAND REFERENCE

–destination-port [!] port[:port]

Destination port or port range specification. The flag –dport is a convenient alias for this option.

–tcp-flags [!] mask comp

Match when the TCP flags are as specified. The first argument is the flags which we should exam ine, written as a comma-separated list, and the second argument is a comma-separated list of flags which must be set. Flags are: SYN ACK FIN RST URG PSH ALL NONE. Hence the command iptables -A FORWARD -p tcp –tcp-flags SYN,ACK,FIN,RST SYN will only match packets with the SYN flag set, and the ACK, FIN and RST flags unset.

[!] –syn

4.5.2

Only match TCP packets with the SYN bit set and the ACK and FIN bits cleared. Such packets are used to request TCP connection initiation; for example, blocking such packets coming in an interface will prevent incoming TCP connections, but outgoing TCP connections will be unaffected. It is equivalent to – tcp-flags SYN,RST,ACK SYN. If the "!" flag precedes the "–syn", the sense of the option is inverted.

UDP

–source-port [!] port[:port]

Source port or port range specification. See the description of the –source-port option of the TCP extension for details.

–destination-port [!] port[:port]

Destination port or port range specification. See the description of the –destination-port option of the TCP extension for details.

4.5.3

ICMP

–icmp-type [!] typename

This allows specification of the ICMP type, which can be a numeric ICMP type, or one of the ICMP type names shown by the command iptables -p icmp -h

20

4.6

4.6

Limit

4

COMMAND REFERENCE

Limit

–limit rate

Maximum average matching rate: specified as a number, with an optional ‘/second’, ‘/minute’, ‘/hour’, or ‘/day’ suffix; the default is 3/hour.

–limit-burst number

Maximum initial number of packets to match: this number gets recharged by one every time the limit specified above is not reached, up to this number; the default is 5.

4.7

States

–state state

4.8 LOG

Where state is a comma separated list of the connection states to match. Possible states are INVALID meaning that the packet is associated with no known connection, ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions, NEW meaning that the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions, and RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.

Log Extensions Turn on kernel logging of matching packets. When this option is set for a rule, the Linux kernel will print some information on all matching packets (like most IP header fields) via the kernel log (where it can be read with dmesg or syslogd(8)). This is a "non-terminating target", i.e. rule traversal continues at the next rule. So if you want to LOG the packets you refuse, use two separate rules with the same matching criteria, first using target LOG then DROP (or REJECT).

–log-level level Level of logging (numeric or see syslog.conf(5)). –log-prefix prefix Prefix log messages with the specified prefix; up to 29 letters long, and useful for distinguishing messages in the logs. –log-tcp-sequence Log TCP sequence numbers. This is a security risk if the log is readable by users. –log-tcp-options Log options from the TCP packet header. –log-ip-options Log options from the IP packet header.

21

4.9

4.9 4.9.1

NAT

4

NAT SNAT

–to-source ipaddr[-ipaddr][:port-port]

4.9.2

which can specify a single new source IP address, an inclusive range of IP addresses, and optionally, a port range (which is only valid if the rule also specifies -p tcp or -p udp). If no port range is specified, then source ports below 512 will be mapped to other ports below 512: those between 512 and 1023 inclusive will be mapped to ports below 1024, and other ports will be mapped to 1024 or above. Where possible, no port alteration will occur.

DNAT

–to-destination ipaddr[-ipaddr][:port-port]

4.10

COMMAND REFERENCE

which can specify a single new destination IP address, an inclusive range of IP addresses, and optionally, a port range (which is only valid if the rule also specifies -p tcp or -p udp). If no port range is specified, then the destination port will never be modified.

Redirect

–to-ports port[-port]

This specifies a destination port or range of ports to use: without this, the destination port is never altered. This is only valid if the rule also specifies -p tcp or -p udp.

22