| .TH IPTABLES 8 "Mar 09, 2002" "" "" |
| .\" |
| .\" Man page written by Herve Eychenne <rv@wallfire.org> (May 1999) |
| .\" It is based on ipchains page. |
| .\" TODO: add a word for protocol helpers (FTP, IRC, SNMP-ALG) |
| .\" |
| .\" ipchains page by Paul ``Rusty'' Russell March 1997 |
| .\" Based on the original ipfwadm man page by Jos Vos <jos@xos.nl> |
| .\" |
| .\" This program is free software; you can redistribute it and/or modify |
| .\" it under the terms of the GNU General Public License as published by |
| .\" the Free Software Foundation; either version 2 of the License, or |
| .\" (at your option) any later version. |
| .\" |
| .\" This program is distributed in the hope that it will be useful, |
| .\" but WITHOUT ANY WARRANTY; without even the implied warranty of |
| .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| .\" GNU General Public License for more details. |
| .\" |
| .\" You should have received a copy of the GNU General Public License |
| .\" along with this program; if not, write to the Free Software |
| .\" Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. |
| .\" |
| .\" |
| .SH NAME |
| iptables \- administration tool for IPv4 packet filtering and NAT |
| .SH SYNOPSIS |
| .BR "iptables [-t table] -[ADC] " "chain rule-specification [options]" |
| .br |
| .BR "iptables [-t table] -I " "chain [rulenum] rule-specification [options]" |
| .br |
| .BR "iptables [-t table] -R " "chain rulenum rule-specification [options]" |
| .br |
| .BR "iptables [-t table] -D " "chain rulenum [options]" |
| .br |
| .BR "iptables [-t table] -[LFZ] " "[chain] [options]" |
| .br |
| .BR "iptables [-t table] -N " "chain" |
| .br |
| .BR "iptables [-t table] -X " "[chain]" |
| .br |
| .BR "iptables [-t table] -P " "chain target [options]" |
| .br |
| .BR "iptables [-t table] -E " "old-chain-name new-chain-name" |
| .SH DESCRIPTION |
| .B Iptables |
| is used to set up, maintain, and inspect the tables of IP packet |
| filter rules in the Linux kernel. Several different tables |
| may be defined. Each table contains a number of built-in |
| chains and may also contain user-defined chains. |
| |
| Each chain is a list of rules which can match a set of packets. Each |
| rule specifies what to do with a packet that matches. This is called |
| a `target', which may be a jump to a user-defined chain in the same |
| table. |
| |
| .SH TARGETS |
| A firewall rule specifies criteria for a packet, and a target. If the |
| packet does not match, the next rule in the chain is the examined; if |
| it does match, then the next rule is specified by the value of the |
| target, which can be the name of a user-defined chain or one of the |
| special values |
| .IR ACCEPT , |
| .IR DROP , |
| .IR QUEUE , |
| or |
| .IR RETURN . |
| .PP |
| .I ACCEPT |
| means to let the packet through. |
| .I DROP |
| means to drop the packet on the floor. |
| .I QUEUE |
| means to pass the packet to userspace (if supported by the kernel). |
| .I RETURN |
| means stop traversing this chain and resume at the next rule in the |
| previous (calling) chain. If the end of a built-in chain is reached |
| or a rule in a built-in chain with target |
| .I RETURN |
| is matched, the target specified by the chain policy determines the |
| fate of the packet. |
| .SH TABLES |
| There are currently three independent tables (which tables are present |
| at any time depends on the kernel configuration options and which |
| modules are present). |
| .TP |
| .BI "-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: |
| .TP |
| .B "filter" |
| This is the default table (if no -t option is passed). It contains |
| the built-in chains |
| .B INPUT |
| (for packets coming into the box itself), |
| .B FORWARD |
| (for packets being routed through the box), and |
| .B OUTPUT |
| (for locally-generated packets). |
| .TP |
| .B "nat" |
| This table is consulted when a packet that creates a new |
| connection is encountered. It consists of three built-ins: |
| .B PREROUTING |
| (for altering packets as soon as they come in), |
| .B OUTPUT |
| (for altering locally-generated packets before routing), and |
| .B POSTROUTING |
| (for altering packets as they are about to go out). |
| .TP |
| .B "mangle" |
| This table is used for specialized packet alteration. Until kernel |
| 2.4.17 it had two built-in chains: |
| .B PREROUTING |
| (for altering incoming packets before routing) and |
| .B OUTPUT |
| (for altering locally-generated packets before routing). |
| Since kernel 2.4.18, three other built-in chains are also supported: |
| .B INPUT |
| (for packets coming into the box itself), |
| .B FORWARD |
| (for altering packets being routed through the box), and |
| .B POSTROUTING |
| (for altering packets as they are about to go out). |
| .SH OPTIONS |
| The options that are recognized by |
| .B iptables |
| can be divided into several different groups. |
| .SS 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 versions of the command and option names, you |
| need to use only enough letters to ensure that |
| .B iptables |
| can differentiate it from all other options. |
| .TP |
| .BI "-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. |
| .TP |
| .BI "-D, --delete " "chain rule-specification" |
| .ns |
| .TP |
| .BI "-D, --delete " "chain rulenum" |
| Delete one or more rules from the selected chain. There are two |
| versions of this command: the rule can be specified as a number in the |
| chain (starting at 1 for the first rule) or a rule to match. |
| .TP |
| .BR "-I, --insert " "\fIchain\fP [\fIrulenum\fP] \fIrule-specification\fP" |
| Insert one or more rules in the selected chain as the given rule |
| number. So, if the rule number is 1, the rule or rules are inserted |
| at the head of the chain. This is also the default if no rule number |
| is specified. |
| .TP |
| .BI "-R, --replace " "chain rulenum rule-specification" |
| Replace a rule in the selected chain. If the source and/or |
| destination names resolve to multiple addresses, the command will |
| fail. Rules are numbered starting at 1. |
| .TP |
| .BR "-L, --list " "[\fIchain\fP]" |
| List all rules in the selected chain. If no chain is selected, all |
| chains are listed. As every other iptables command, it applies to the |
| specified table (filter is the default), so NAT rules get listed by |
| .br |
| iptables -t nat -n -L |
| .br |
| Please note that it is often used with the |
| .B -n |
| option, in order to avoid long reverse DNS lookups. |
| It is legal to specify the |
| .B -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 |
| .br |
| iptables -L -v |
| .br |
| .TP |
| .BR "-F, --flush " "[\fIchain\fP]" |
| 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. |
| .TP |
| .BR "-Z, --zero " "[\fIchain\fP]" |
| Zero the packet and byte counters in all chains. It is legal to |
| specify the |
| .B "-L, --list" |
| (list) option as well, to see the counters immediately before they are |
| cleared. (See above.) |
| .TP |
| .BI "-N, --new-chain " "chain" |
| Create a new user-defined chain by the given name. There must be no |
| target of that name already. |
| .TP |
| .BR "-X, --delete-chain " "[\fIchain\fP]" |
| Delete the optional user-defined chain specified. There must be no references |
| to the chain. If there are, you must delete or replace the referring |
| rules before the chain can be deleted. If no argument is given, it |
| will attempt to delete every non-builtin chain in the table. |
| .TP |
| .BI "-P, --policy " "chain target" |
| Set the policy for the chain to the given target. See the section |
| .B TARGETS |
| for the legal targets. Only built-in (non-user-defined) chains can have |
| policies, and neither built-in nor user-defined chains can be policy |
| targets. |
| .TP |
| .BI "-E, --rename-chain " "old-chain new-chain" |
| Rename the user specified chain to the user supplied name. This is |
| cosmetic, and has no effect on the structure of the table. |
| .TP |
| .B -h |
| Help. |
| Give a (currently very brief) description of the command syntax. |
| .SS PARAMETERS |
| The following parameters make up a rule specification (as used in the |
| add, delete, insert, replace and append commands). |
| .TP |
| .BR "-p, --protocol " "[!] \fIprotocol\fP" |
| The protocol of the rule or of the packet to check. |
| The specified protocol can be one of |
| .IR tcp , |
| .IR udp , |
| .IR icmp , |
| or |
| .IR 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. The number zero is equivalent to |
| .IR all . |
| Protocol |
| .I all |
| will match with all protocols and is taken as default when this |
| option is omitted. |
| .TP |
| .BR "-s, --source " "[!] \fIaddress\fP[/\fImask\fP]" |
| Source specification. |
| .I 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 |
| .I mask |
| can be either a network mask or a plain number, |
| specifying the number of 1's at the left side of the network mask. |
| Thus, a mask of |
| .I 24 |
| is equivalent to |
| .IR 255.255.255.0 . |
| A "!" argument before the address specification inverts the sense of |
| the address. The flag |
| .B --src |
| is an alias for this option. |
| .TP |
| .BR "-d, --destination " "[!] \fIaddress\fP[/\fImask\fP]" |
| Destination specification. |
| See the description of the |
| .B -s |
| (source) flag for a detailed description of the syntax. The flag |
| .B --dst |
| is an alias for this option. |
| .TP |
| .BI "-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 |
| .B 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 counters on the rule will be |
| incremented. |
| .TP |
| .BR "-i, --in-interface " "[!] \fIname\fP" |
| Name of an interface via which a packet is going to be received (only for |
| packets entering the |
| .BR INPUT , |
| .B FORWARD |
| and |
| .B 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. |
| .TP |
| .BR "-o, --out-interface " "[!] \fIname\fP" |
| Name of an interface via which a packet is going to be sent (for packets |
| entering the |
| .BR FORWARD , |
| .B OUTPUT |
| and |
| .B POSTROUTING |
| 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. |
| .TP |
| .B "[!] " "-f, --fragment" |
| This means that the rule only refers to second and further fragments |
| of fragmented packets. Since there is no way to tell the source or |
| destination ports of such a packet (or ICMP type), such a packet will |
| not match any rules which specify them. When the "!" argument |
| precedes the "-f" flag, the rule will only match head fragments, or |
| unfragmented packets. |
| .TP |
| .BI "-c, --set-counters " "PKTS BYTES" |
| This enables the administrator to initialize the packet and byte |
| counters of a rule (during |
| .B INSERT, |
| .B APPEND, |
| .B REPLACE |
| operations). |
| .SS "OTHER OPTIONS" |
| The following additional options can be specified: |
| .TP |
| .B "-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 |
| .B -x |
| flag to change this). |
| For appending, insertion, deletion and replacement, this causes |
| detailed information on the rule or rules to be printed. |
| .TP |
| .B "-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, |
| network names, or services (whenever applicable). |
| .TP |
| .B "-x, --exact" |
| Expand numbers. |
| Display the exact value of the packet and byte counters, |
| instead of only the rounded number in K's (multiples of 1000) |
| M's (multiples of 1000K) or G's (multiples of 1000M). This option is |
| only relevant for the |
| .B -L |
| command. |
| .TP |
| .B "--line-numbers" |
| When listing rules, add line numbers to the beginning of each rule, |
| corresponding to that rule's position in the chain. |
| .TP |
| .B "--modprobe=command" |
| When adding or inserting rules into a chain, use |
| .B command |
| to load any necessary modules (targets, match extensions, etc). |
| .SH MATCH EXTENSIONS |
| iptables can use extended packet matching modules. These are loaded |
| in two ways: implicitly, when |
| .B -p |
| or |
| .B --protocol |
| is specified, or with the |
| .B -m |
| or |
| .B --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 |
| .B -h |
| or |
| .B --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 |
| .B ! |
| to invert the sense of the match. |
| .SS tcp |
| These extensions are loaded if `--protocol tcp' is specified. It |
| provides the following options: |
| .TP |
| .BR "--source-port " "[!] \fIport\fP[:\fIport\fP]" |
| 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 |
| .IR 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 |
| .B --sport |
| is a convenient alias for this option. |
| .TP |
| .BR "--destination-port " "[!] \fIport\fP[:\fIport\fP]" |
| Destination port or port range specification. The flag |
| .B --dport |
| is a convenient alias for this option. |
| .TP |
| .BR "--tcp-flags " "[!] \fImask\fP \fIcomp\fP" |
| Match when the TCP flags are as specified. The first argument is the |
| flags which we should examine, written as a comma-separated list, and |
| the second argument is a comma-separated list of flags which must be |
| set. Flags are: |
| .BR "SYN ACK FIN RST URG PSH ALL NONE" . |
| Hence the command |
| .br |
| iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST SYN |
| .br |
| will only match packets with the SYN flag set, and the ACK, FIN and |
| RST flags unset. |
| .TP |
| .B "[!] --syn" |
| 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 \fB--tcp-flags SYN,RST,ACK SYN\fP. |
| If the "!" flag precedes the "--syn", the sense of the |
| option is inverted. |
| .TP |
| .BR "--tcp-option " "[!] \fInumber\fP" |
| Match if TCP option set. |
| .TP |
| .BR "--mss " "\fIvalue\fP[:\fIvalue\fP]" |
| Match TCP SYN or SYN/ACK packets with the specified MSS value (or range), |
| which control the maximum packet size for that connection. |
| .SS udp |
| These extensions are loaded if `--protocol udp' is specified. It |
| provides the following options: |
| .TP |
| .BR "--source-port " "[!] \fIport\fP[:\fIport\fP]" |
| Source port or port range specification. |
| See the description of the |
| .B --source-port |
| option of the TCP extension for details. |
| .TP |
| .BR "--destination-port " "[!] \fIport\fP[:\fIport\fP]" |
| Destination port or port range specification. |
| See the description of the |
| .B --destination-port |
| option of the TCP extension for details. |
| .SS icmp |
| This extension is loaded if `--protocol icmp' is specified. It |
| provides the following option: |
| .TP |
| .BR "--icmp-type " "[!] \fItypename\fP" |
| 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 |
| .br |
| iptables -p icmp -h |
| .br |
| .SS mac |
| .TP |
| .BR "--mac-source " "[!] \fIaddress\fP" |
| Match source MAC address. It must be of the form XX:XX:XX:XX:XX:XX. |
| Note that this only makes sense for packets coming from an Ethernet device |
| and entering the |
| .BR PREROUTING , |
| .B FORWARD |
| or |
| .B INPUT |
| chains. |
| .SS limit |
| This module matches at a limited rate using a token bucket filter. |
| A rule using this extension will match until this limit is reached |
| (unless the `!' flag is used). It can be used in combination with the |
| .B LOG |
| target to give limited logging, for example. |
| .TP |
| .BI "--limit " "rate" |
| Maximum average matching rate: specified as a number, with an optional |
| `/second', `/minute', `/hour', or `/day' suffix; the default is |
| 3/hour. |
| .TP |
| .BI "--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. |
| .SS multiport |
| This module matches a set of source or destination ports. Up to 15 |
| ports can be specified. It can only be used in conjunction with |
| .B "-p tcp" |
| or |
| .BR "-p udp" . |
| .TP |
| .BR "--source-ports " "\fIport\fP[,\fIport\fP[,\fIport\fP...]]" |
| Match if the source port is one of the given ports. The flag |
| .B --sports |
| is a convenient alias for this option. |
| .TP |
| .BR "--destination-ports " "\fIport\fP[,\fIport\fP[,\fIport\fP...]]" |
| Match if the destination port is one of the given ports. The flag |
| .B --dports |
| is a convenient alias for this option. |
| .TP |
| .BR "--ports " "\fIport\fP[,\fIport\fP[,\fIport\fP...]]" |
| Match if the both the source and destination ports are equal to each |
| other and to one of the given ports. |
| .SS mark |
| This module matches the netfilter mark field associated with a packet |
| (which can be set using the |
| .B MARK |
| target below). |
| .TP |
| .BR "--mark " "\fIvalue\fP[/\fImask\fP]" |
| Matches packets with the given unsigned mark value (if a mask is |
| specified, this is logically ANDed with the mask before the |
| comparison). |
| .SS owner |
| This module attempts to match various characteristics of the packet |
| creator, for locally-generated packets. It is only valid in the |
| .B OUTPUT |
| chain, and even this some packets (such as ICMP ping responses) may |
| have no owner, and hence never match. |
| .TP |
| .BI "--uid-owner " "userid" |
| Matches if the packet was created by a process with the given |
| effective user id. |
| .TP |
| .BI "--gid-owner " "groupid" |
| Matches if the packet was created by a process with the given |
| effective group id. |
| .TP |
| .BI "--pid-owner " "processid" |
| Matches if the packet was created by a process with the given |
| process id. |
| .TP |
| .BI "--sid-owner " "sessionid" |
| Matches if the packet was created by a process in the given session |
| group. |
| .TP |
| .BI "--cmd-owner " "name" |
| Matches if the packet was created by a process with the given command name. |
| (this option is present only if iptables was compiled under a kernel |
| supporting this feature) |
| .SS state |
| This module, when combined with connection tracking, allows access to |
| the connection tracking state for this packet. |
| .TP |
| .BI "--state " "state" |
| Where state is a comma separated list of the connection states to |
| match. Possible states are |
| .B INVALID |
| meaning that the packet is associated with no known connection, |
| .B ESTABLISHED |
| meaning that the packet is associated with a connection which has seen |
| packets in both directions, |
| .B 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 |
| .B 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. |
| .SS conntrack |
| This module, when combined with connection tracking, allows access to |
| more connection tracking information than the "state" match. |
| (this module is present only if iptables was compiled under a kernel |
| supporting this feature) |
| .TP |
| .BI "--ctstate " "state" |
| Where state is a comma separated list of the connection states to |
| match. Possible states are |
| .B INVALID |
| meaning that the packet is associated with no known connection, |
| .B ESTABLISHED |
| meaning that the packet is associated with a connection which has seen |
| packets in both directions, |
| .B 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 |
| .B 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. |
| .B SNAT |
| A virtual state, matching if the original source address differs from |
| the reply destination. |
| .B DNAT |
| A virtual state, matching if the original destination differs from the |
| reply source. |
| .TP |
| .BI "--ctproto " "proto" |
| Protocol to match (by number or name) |
| .TP |
| .BI "--ctorigsrc " "[!] \fIaddress\fP[/\fImask\fP]" |
| Match against original source address |
| .TP |
| .BI "--ctorigdst " "[!] \fIaddress\fP[/\fImask\fP]" |
| Match against original destination address |
| .TP |
| .BI "--ctreplsrc " "[!] \fIaddress\fP[/\fImask\fP]" |
| Match against reply source address |
| .TP |
| .BI "--ctrepldst " "[!] \fIaddress\fB[/\fImask\fP]" |
| Match against reply destination address |
| .TP |
| .BI "--ctstatus " "[\fINONE|EXPECTED|SEEN_REPLY|ASSURED\fP][,...]" |
| Match against internal conntrack states |
| .TP |
| .BI "--ctexpire " "\fItime\fP[\fI:time\fP]" |
| Match remaining lifetime in seconds against given value |
| or range of values (inclusive) |
| .SS dscp |
| This module matches the 6 bit DSCP field within the TOS field in the |
| IP header. DSCP has superseded TOS within the IETF. |
| .TP |
| .BI "--dscp " "value" |
| Match against a numeric (decimal or hex) value [0-32]. |
| .TP |
| .BI "--dscp-class " "\fIDiffServ Class\fP" |
| Match the DiffServ class. This value may be any of the |
| BE, EF, AFxx or CSx classes. It will then be converted |
| into it's according numeric value. |
| .SS pkttype |
| This module matches the link-layer packet type. |
| .TP |
| .BI "--pkt-type " "[\fIunicast\fP|\fIbroadcast\fP|\fImulticast\fP]" |
| .SS tos |
| This module matches the 8 bits of Type of Service field in the IP |
| header (ie. including the precedence bits). |
| .TP |
| .BI "--tos " "tos" |
| The argument is either a standard name, (use |
| .br |
| iptables -m tos -h |
| .br |
| to see the list), or a numeric value to match. |
| .SS ah |
| This module matches the SPIs in AH header of IPSec packets. |
| .TP |
| .BR "--ahspi " "[!] \fIspi\fP[:\fIspi\fP]" |
| .SS esp |
| This module matches the SPIs in ESP header of IPSec packets. |
| .TP |
| .BR "--espspi " "[!] \fIspi\fP[:\fIspi\fP]" |
| .SS length |
| This module matches the length of a packet against a specific value |
| or range of values. |
| .TP |
| .BR "--length " "\fIlength\fP[:\fIlength\fP]" |
| .SS ttl |
| This module matches the time to live field in the IP header. |
| .TP |
| .BI "--ttl " "ttl" |
| Matches the given TTL value. |
| .SS unclean |
| This module takes no options, but attempts to match packets which seem |
| malformed or unusual. This is regarded as experimental. |
| .SH TARGET EXTENSIONS |
| iptables can use extended target modules: the following are included |
| in the standard distribution. |
| .SS LOG |
| 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 |
| .I dmesg |
| or |
| .IR 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). |
| .TP |
| .BI "--log-level " "level" |
| Level of logging (numeric or see \fIsyslog.conf\fP(5)). |
| .TP |
| .BI "--log-prefix " "prefix" |
| Prefix log messages with the specified prefix; up to 29 letters long, |
| and useful for distinguishing messages in the logs. |
| .TP |
| .B --log-tcp-sequence |
| Log TCP sequence numbers. This is a security risk if the log is |
| readable by users. |
| .TP |
| .B --log-tcp-options |
| Log options from the TCP packet header. |
| .TP |
| .B --log-ip-options |
| Log options from the IP packet header. |
| .SS MARK |
| This is used to set the netfilter mark value associated with the |
| packet. It is only valid in the |
| .B mangle |
| table. It can for example be used in conjunction with iproute2. |
| .TP |
| .BI "--set-mark " "mark" |
| .SS REJECT |
| This is used to send back an error packet in response to the matched |
| packet: otherwise it is equivalent to |
| .B DROP |
| so it is a terminating TARGET, ending rule traversal. |
| This target is only valid in the |
| .BR INPUT , |
| .B FORWARD |
| and |
| .B OUTPUT |
| chains, and user-defined chains which are only called from those |
| chains. The following option controls the nature of the error packet |
| returned: |
| .TP |
| .BI "--reject-with " "type" |
| The type given can be |
| .BR icmp-net-unreachable , |
| .BR icmp-host-unreachable , |
| .BR icmp-port-unreachable , |
| .BR icmp-proto-unreachable , |
| .BR "icmp-net-prohibited or" |
| .BR icmp-host-prohibited , |
| which return the appropriate ICMP error message (\fBport-unreachable\fP is |
| the default). The option |
| .B tcp-reset |
| can be used on rules which only match the TCP protocol: this causes a |
| TCP RST packet to be sent back. This is mainly useful for blocking |
| .I ident |
| (113/tcp) probes which frequently occur when sending mail to broken mail |
| hosts (which won't accept your mail otherwise). |
| .SS TOS |
| This is used to set the 8-bit Type of Service field in the IP header. |
| It is only valid in the |
| .B mangle |
| table. |
| .TP |
| .BI "--set-tos " "tos" |
| You can use a numeric TOS values, or use |
| .br |
| iptables -j TOS -h |
| .br |
| to see the list of valid TOS names. |
| .SS MIRROR |
| This is an experimental demonstration target which inverts the source |
| and destination fields in the IP header and retransmits the packet. |
| It is only valid in the |
| .BR INPUT , |
| .B FORWARD |
| and |
| .B PREROUTING |
| chains, and user-defined chains which are only called from those |
| chains. Note that the outgoing packets are |
| .B NOT |
| seen by any packet filtering chains, connection tracking or NAT, to |
| avoid loops and other problems. |
| .SS SNAT |
| This target is only valid in the |
| .B nat |
| table, in the |
| .B POSTROUTING |
| chain. It specifies that the source address of the packet should be |
| modified (and all future packets in this connection will also be |
| mangled), and rules should cease being examined. It takes one type |
| of option: |
| .TP |
| .BR "--to-source " "\fIipaddr\fP[-\fIipaddr\fP][:\fIport\fP-\fIport\fP]" |
| 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 |
| .B "-p tcp" |
| or |
| .BR "-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. |
| .TP |
| You can add several --to-source options. If you specify more |
| than one source address, either via an address range or multiple |
| --to-source options, a simple round-robin (one after another in |
| cycle) takes place between these adresses. |
| .SS DNAT |
| This target is only valid in the |
| .B nat |
| table, in the |
| .B PREROUTING |
| and |
| .B OUTPUT |
| chains, and user-defined chains which are only called from those |
| chains. It specifies that the destination address of the packet |
| should be modified (and all future packets in this connection will |
| also be mangled), and rules should cease being examined. It takes one |
| type of option: |
| .TP |
| .BR "--to-destination " "\fIipaddr\fP[-\fIipaddr\fP][:\fIport\fP-\fIport\fP]" |
| 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 |
| .B "-p tcp" |
| or |
| .BR "-p udp" ). |
| If no port range is specified, then the destination port will never be |
| modified. |
| .TP |
| You can add several --to-destination options. If you specify more |
| than one destination address, either via an address range or multiple |
| --to-destination options, a simple round-robin (one after another in |
| cycle) load balancing takes place between these adresses. |
| .SS MASQUERADE |
| This target is only valid in the |
| .B nat |
| table, in the |
| .B POSTROUTING |
| chain. It should only be used with dynamically assigned IP (dialup) |
| connections: if you have a static IP address, you should use the SNAT |
| target. Masquerading is equivalent to specifying a mapping to the IP |
| address of the interface the packet is going out, but also has the |
| effect that connections are |
| .I forgotten |
| when the interface goes down. This is the correct behavior when the |
| next dialup is unlikely to have the same interface address (and hence |
| any established connections are lost anyway). It takes one option: |
| .TP |
| .BR "--to-ports " "\fIport\fP[-\fIport\fP]" |
| This specifies a range of source ports to use, overriding the default |
| .B SNAT |
| source port-selection heuristics (see above). This is only valid |
| if the rule also specifies |
| .B "-p tcp" |
| or |
| .BR "-p udp" . |
| .SS REDIRECT |
| This target is only valid in the |
| .B nat |
| table, in the |
| .B PREROUTING |
| and |
| .B OUTPUT |
| chains, and user-defined chains which are only called from those |
| chains. It alters the destination IP address to send the packet to |
| the machine itself (locally-generated packets are mapped to the |
| 127.0.0.1 address). It takes one option: |
| .TP |
| .BR "--to-ports " "\fIport\fP[-\fIport\fP]" |
| 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 |
| .B "-p tcp" |
| or |
| .BR "-p udp" . |
| .SS ULOG |
| This target provides userspace logging of matching packets. When this |
| target is set for a rule, the Linux kernel will multicast this packet |
| through a |
| .IR netlink |
| socket. One or more userspace processes may then subscribe to various |
| multicast groups and receive the packets. |
| Like LOG, this is a "non-terminating target", i.e. rule traversal |
| continues at the next rule. |
| .TP |
| .BI "--ulog-nlgroup " "nlgroup" |
| This specifies the netlink group (1-32) to which the packet is sent. |
| Default value is 1. |
| .TP |
| .BI "--ulog-prefix " "prefix" |
| Prefix log messages with the specified prefix; up to 32 characters |
| long, and useful for distinguishing messages in the logs. |
| .TP |
| .BI "--ulog-cprange " "size" |
| Number of bytes to be copied to userspace. A value of 0 always copies |
| the entire packet, regardless of its size. Default is 0. |
| .TP |
| .BI "--ulog-qthreshold " "size" |
| Number of packet to queue inside kernel. Setting this value to, e.g. 10 |
| accumulates ten packets inside the kernel and transmits them as one |
| netlink multipart message to userspace. Default is 1 (for backwards |
| compatibility). |
| .SS TCPMSS |
| This target allows to alter the MSS value of TCP SYN packets, to control |
| the maximum size for that connection (usually limiting it to your |
| outgoing interface's MTU minus 40). Of course, it can only be used |
| in conjunction with |
| .BR "-p tcp" . |
| .br |
| This target is used to overcome criminally braindead ISPs or servers |
| which block ICMP Fragmentation Needed packets. The symptoms of this |
| problem are that everything works fine from your Linux |
| firewall/router, but machines behind it can never exchange large |
| packets: |
| .br |
| 1) Web browsers connect, then hang with no data received. |
| .br |
| 2) Small mail works fine, but large emails hang. |
| .br |
| 3) ssh works fine, but scp hangs after initial handshaking. |
| .br |
| Workaround: activate this option and add a rule to your firewall |
| configuration like: |
| .br |
| iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN \\ |
| .br |
| -j TCPMSS --clamp-mss-to-pmtu |
| .TP |
| .BI "--set-mss " "value" |
| Explicitly set MSS option to specified value. |
| .TP |
| .B "--clamp-mss-to-pmtu" |
| Automatically clamp MSS value to (path_MTU - 40). |
| .TP |
| These options are mutually exclusive. |
| .SS DSCP |
| This target allows to alter the value of the DSCP bits within the TOS |
| header of the IPv4 packet. As this manipulates a packet, it can only |
| be used in the mangle table. |
| .TP |
| .BI "--set-dscp " "value" |
| Set the DSCP field to a numerical value (can be decimal or hex) |
| .TP |
| .BI "--set-dscp-class " "class" |
| Set the DSCP field to a DiffServ class. |
| .SS ECN |
| This target allows to selectively work around known ECN blackholes. |
| It can only be used in the mangle table. |
| .TP |
| .BI "--ecn-tcp-remove" |
| Remove all ECN bits from the TCP header. Of course, it can only be used |
| in conjunction with |
| .BR "-p tcp" . |
| .br |
| .SH DIAGNOSTICS |
| Various error messages are printed to standard error. The exit code |
| is 0 for correct functioning. Errors which appear to be caused by |
| invalid or abused command line parameters cause an exit code of 2, and |
| other errors cause an exit code of 1. |
| .SH BUGS |
| Bugs? What's this? ;-) |
| Well... the counters are not reliable on sparc64. |
| .SH COMPATIBILITY WITH IPCHAINS |
| This |
| .B iptables |
| is very similar to ipchains by Rusty Russell. The main difference is |
| that the chains |
| .B INPUT |
| and |
| .B OUTPUT |
| are only traversed for packets coming into the local host and |
| originating from the local host respectively. Hence every packet only |
| passes through one of the three chains; previously a forwarded packet |
| would pass through all three. |
| .PP |
| The other main difference is that |
| .B -i |
| refers to the input interface; |
| .B -o |
| refers to the output interface, and both are available for packets |
| entering the |
| .B FORWARD |
| chain. |
| .PP The various forms of NAT have been separated out; |
| .B iptables |
| is a pure packet filter when using the default `filter' table, with |
| optional extension modules. This should simplify much of the previous |
| confusion over the combination of IP masquerading and packet filtering |
| seen previously. So the following options are handled differently: |
| .br |
| -j MASQ |
| .br |
| -M -S |
| .br |
| -M -L |
| .br |
| There are several other changes in iptables. |
| .SH SEE ALSO |
| .BR iptables-save (8), |
| .BR iptables-restore (8), |
| .BR ip6tables (8), |
| .BR ip6tables-save (8), |
| .BR ip6tables-restore(8). |
| .P |
| The packet-filtering-HOWTO details iptables usage for |
| packet filtering, the NAT-HOWTO details NAT, |
| the netfilter-extensions-HOWTO details the extensions that are |
| not in the standard distribution, |
| and the netfilter-hacking-HOWTO details the netfilter internals. |
| .br |
| See |
| .BR "http://www.netfilter.org/" . |
| .SH AUTHORS |
| Rusty Russell wrote iptables, in early consultation with Michael |
| Neuling. |
| .PP |
| Marc Boucher made Rusty abandon ipnatctl by lobbying for a generic packet |
| selection framework in iptables, then wrote the mangle table, the owner match, |
| the mark stuff, and ran around doing cool stuff everywhere. |
| .PP |
| James Morris wrote the TOS target, and tos match. |
| .PP |
| Jozsef Kadlecsik wrote the REJECT target. |
| .PP |
| Harald Welte wrote the ULOG target, TTL, DSCP, ECN matches and targets. |
| .PP |
| The Netfilter Core Team is: Marc Boucher, Jozsef Kadlecsik, James Morris, |
| Harald Welte and Rusty Russell. |
| .PP |
| Man page written by Herve Eychenne <rv@wallfire.org>. |
| |
| .\" .. and did I mention that we are incredibly cool people? |
| .\" .. sexy, too .. |
| .\" .. witty, charming, powerful .. |
| .\" .. and most of all, modest .. |