3498 lines
131 KiB
HTML
3498 lines
131 KiB
HTML
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<HTML><HEAD><TITLE>Man page of iptables-extensions</TITLE>
|
|
</HEAD><BODY>
|
|
<H1>iptables-extensions</H1>
|
|
Section: iptables 1.8.4 (8)<BR>Updated: <BR><A HREF="#index">Index</A>
|
|
<A HREF="/cgi-bin/man/man2html">Return to Main Contents</A><HR>
|
|
|
|
<A NAME="lbAB"> </A>
|
|
<H2>NAME</H2>
|
|
|
|
iptables-extensions --- list of extensions in the standard iptables distribution
|
|
<A NAME="lbAC"> </A>
|
|
<H2>SYNOPSIS</H2>
|
|
|
|
<B>ip6tables</B> [<B>-m</B> <I>name</I> [<I>module-options</I>...]]
|
|
[<B>-j</B> <I>target-name</I> [<I>target-options</I>...]
|
|
<P>
|
|
|
|
<B>iptables</B> [<B>-m</B> <I>name</I> [<I>module-options</I>...]]
|
|
[<B>-j</B> <I>target-name</I> [<I>target-options</I>...]
|
|
<A NAME="lbAD"> </A>
|
|
<H2>MATCH EXTENSIONS</H2>
|
|
|
|
iptables can use extended packet matching modules
|
|
with the <B>-m</B> or <B>--match</B>
|
|
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</B> or <B>--help</B>
|
|
options after the module has been specified to receive help specific
|
|
to that module. The extended match modules are evaluated in the order
|
|
they are specified in the rule.
|
|
<P>
|
|
|
|
If the <B>-p</B> or <B>--protocol</B> was specified and if and only if an
|
|
unknown option is encountered, iptables will try load a match module of the
|
|
same name as the protocol, to try making the option available.
|
|
|
|
<A NAME="lbAE"> </A>
|
|
<H3>addrtype</H3>
|
|
|
|
This module matches packets based on their
|
|
<B>address type.</B>
|
|
|
|
Address types are used within the kernel networking stack and categorize
|
|
addresses into various groups. The exact definition of that group depends on the specific layer three protocol.
|
|
<P>
|
|
|
|
The following address types are possible:
|
|
<DL COMPACT>
|
|
<DT id="1"><B>UNSPEC</B>
|
|
|
|
<DD>
|
|
an unspecified address (i.e. 0.0.0.0)
|
|
<DT id="2"><B>UNICAST</B>
|
|
|
|
<DD>
|
|
an unicast address
|
|
<DT id="3"><B>LOCAL</B>
|
|
|
|
<DD>
|
|
a local address
|
|
<DT id="4"><B>BROADCAST</B>
|
|
|
|
<DD>
|
|
a broadcast address
|
|
<DT id="5"><B>ANYCAST</B>
|
|
|
|
<DD>
|
|
an anycast packet
|
|
<DT id="6"><B>MULTICAST</B>
|
|
|
|
<DD>
|
|
a multicast address
|
|
<DT id="7"><B>BLACKHOLE</B>
|
|
|
|
<DD>
|
|
a blackhole address
|
|
<DT id="8"><B>UNREACHABLE</B>
|
|
|
|
<DD>
|
|
an unreachable address
|
|
<DT id="9"><B>PROHIBIT</B>
|
|
|
|
<DD>
|
|
a prohibited address
|
|
<DT id="10"><B>THROW</B>
|
|
|
|
<DD>
|
|
FIXME
|
|
<DT id="11"><B>NAT</B>
|
|
|
|
<DD>
|
|
FIXME
|
|
<DT id="12"><B>XRESOLVE</B>
|
|
|
|
<DD>
|
|
<DT id="13">[<B>!</B>] <B>--src-type</B> <I>type</I><DD>
|
|
Matches if the source address is of given type
|
|
<DT id="14">[<B>!</B>] <B>--dst-type</B> <I>type</I><DD>
|
|
Matches if the destination address is of given type
|
|
<DT id="15"><B>--limit-iface-in</B>
|
|
|
|
<DD>
|
|
The address type checking can be limited to the interface the packet is coming
|
|
in. This option is only valid in the
|
|
<B>PREROUTING</B>,
|
|
|
|
<B>INPUT</B>
|
|
|
|
and
|
|
<B>FORWARD</B>
|
|
|
|
chains. It cannot be specified with the
|
|
<B>--limit-iface-out</B>
|
|
option.
|
|
<DT id="16"><B>--limit-iface-out</B><DD>
|
|
The address type checking can be limited to the interface the packet is going
|
|
out. This option is only valid in the
|
|
<B>POSTROUTING</B>,
|
|
|
|
<B>OUTPUT</B>
|
|
|
|
and
|
|
<B>FORWARD</B>
|
|
|
|
chains. It cannot be specified with the
|
|
<B>--limit-iface-in</B>
|
|
option.
|
|
</DL>
|
|
<A NAME="lbAF"> </A>
|
|
<H3>ah (IPv6-specific)</H3>
|
|
|
|
This module matches the parameters in Authentication header of IPsec packets.
|
|
<DL COMPACT>
|
|
<DT id="17">[<B>!</B>] <B>--ahspi</B> <I>spi</I>[<B>:</B><I>spi</I>]<DD>
|
|
Matches SPI.
|
|
<DT id="18">[<B>!</B>] <B>--ahlen</B> <I>length</I><DD>
|
|
Total length of this header in octets.
|
|
<DT id="19"><B>--ahres</B><DD>
|
|
Matches if the reserved field is filled with zero.
|
|
</DL>
|
|
<A NAME="lbAG"> </A>
|
|
<H3>ah (IPv4-specific)</H3>
|
|
|
|
This module matches the SPIs in Authentication header of IPsec packets.
|
|
<DL COMPACT>
|
|
<DT id="20">[<B>!</B>] <B>--ahspi</B> <I>spi</I>[<B>:</B><I>spi</I>]<DD>
|
|
</DL>
|
|
<A NAME="lbAH"> </A>
|
|
<H3>bpf</H3>
|
|
|
|
Match using Linux Socket Filter. Expects a path to an eBPF object or a cBPF
|
|
program in decimal format.
|
|
<DL COMPACT>
|
|
<DT id="21"><B>--object-pinned</B> <I>path</I><DD>
|
|
Pass a path to a pinned eBPF object.
|
|
</DL>
|
|
<P>
|
|
|
|
Applications load eBPF programs into the kernel with the bpf() system call and
|
|
BPF_PROG_LOAD command and can pin them in a virtual filesystem with BPF_OBJ_PIN.
|
|
To use a pinned object in iptables, mount the bpf filesystem using
|
|
<DL COMPACT>
|
|
<DT id="22"><DD>
|
|
mount -t bpf bpf ${BPF_MOUNT}
|
|
</DL>
|
|
<P>
|
|
|
|
then insert the filter in iptables by path:
|
|
<DL COMPACT>
|
|
<DT id="23"><DD>
|
|
iptables -A OUTPUT -m bpf --object-pinned ${BPF_MOUNT}/{PINNED_PATH} -j ACCEPT
|
|
<DT id="24"><B>--bytecode</B> <I>code</I><DD>
|
|
Pass the BPF byte code format as generated by the <B>nfbpf_compile</B> utility.
|
|
</DL>
|
|
<P>
|
|
|
|
The code format is similar to the output of the tcpdump -ddd command: one line
|
|
that stores the number of instructions, followed by one line for each
|
|
instruction. Instruction lines follow the pattern 'u16 u8 u8 u32' in decimal
|
|
notation. Fields encode the operation, jump offset if true, jump offset if
|
|
false and generic multiuse field 'K'. Comments are not supported.
|
|
<P>
|
|
|
|
For example, to read only packets matching 'ip proto 6', insert the following,
|
|
without the comments or trailing whitespace:
|
|
<DL COMPACT>
|
|
<DT id="25"><DD>
|
|
4 # number of instructions
|
|
<BR>
|
|
|
|
48 0 0 9 # load byte ip->proto
|
|
<BR>
|
|
|
|
21 0 1 6 # jump equal IPPROTO_TCP
|
|
<BR>
|
|
|
|
6 0 0 1 # return pass (non-zero)
|
|
<BR>
|
|
|
|
6 0 0 0 # return fail (zero)
|
|
</DL>
|
|
<P>
|
|
|
|
You can pass this filter to the bpf match with the following command:
|
|
<DL COMPACT>
|
|
<DT id="26"><DD>
|
|
iptables -A OUTPUT -m bpf --bytecode '4,48 0 0 9,21 0 1 6,6 0 0 1,6 0 0 0' -j ACCEPT
|
|
</DL>
|
|
<P>
|
|
|
|
Or instead, you can invoke the nfbpf_compile utility.
|
|
<DL COMPACT>
|
|
<DT id="27"><DD>
|
|
iptables -A OUTPUT -m bpf --bytecode "`nfbpf_compile RAW 'ip proto 6'`" -j ACCEPT
|
|
</DL>
|
|
<P>
|
|
|
|
Or use tcpdump -ddd. In that case, generate BPF targeting a device with the
|
|
same data link type as the xtables match. Iptables passes packets from the
|
|
network layer up, without mac layer. Select a device with data link type RAW,
|
|
such as a tun device:
|
|
<DL COMPACT>
|
|
<DT id="28"><DD>
|
|
ip tuntap add tun0 mode tun
|
|
<BR>
|
|
|
|
ip link set tun0 up
|
|
<BR>
|
|
|
|
tcpdump -ddd -i tun0 ip proto 6
|
|
</DL>
|
|
<P>
|
|
|
|
See tcpdump -L -i $dev for a list of known data link types for a given device.
|
|
<P>
|
|
|
|
You may want to learn more about BPF from FreeBSD's <A HREF="/cgi-bin/man/man2html?4+bpf">bpf</A>(4) manpage.
|
|
<A NAME="lbAI"> </A>
|
|
<H3>cgroup</H3>
|
|
|
|
<DL COMPACT>
|
|
<DT id="29">[<B>!</B>] <B>--path</B> <I>path</I><DD>
|
|
Match cgroup2 membership.
|
|
<P>
|
|
Each socket is associated with the v2 cgroup of the creating process.
|
|
This matches packets coming from or going to all sockets in the
|
|
sub-hierarchy of the specified path. The path should be relative to
|
|
the root of the cgroup2 hierarchy.
|
|
<DT id="30">[<B>!</B>] <B>--cgroup</B> <I>classid</I><DD>
|
|
Match cgroup net_cls classid.
|
|
<P>
|
|
classid is the marker set through the cgroup net_cls controller. This
|
|
option and --path can't be used together.
|
|
</DL>
|
|
<P>
|
|
|
|
Example:
|
|
<DL COMPACT>
|
|
<DT id="31"><DD>
|
|
iptables -A OUTPUT -p tcp --sport 80 -m cgroup ! --path service/http-server -j DROP
|
|
<DT id="32"><DD>
|
|
iptables -A OUTPUT -p tcp --sport 80 -m cgroup ! --cgroup 1
|
|
-j DROP
|
|
</DL>
|
|
<P>
|
|
|
|
<B>IMPORTANT</B>: when being used in the INPUT chain, the cgroup
|
|
matcher is currently only of limited functionality, meaning it
|
|
will only match on packets that are processed for local sockets
|
|
through early socket demuxing. Therefore, general usage on the
|
|
INPUT chain is not advised unless the implications are well
|
|
understood.
|
|
<P>
|
|
|
|
Available since Linux 3.14.
|
|
<A NAME="lbAJ"> </A>
|
|
<H3>cluster</H3>
|
|
|
|
Allows you to deploy gateway and back-end load-sharing clusters without the
|
|
need of load-balancers.
|
|
<P>
|
|
|
|
This match requires that all the nodes see the same packets. Thus, the cluster
|
|
match decides if this node has to handle a packet given the following options:
|
|
<DL COMPACT>
|
|
<DT id="33"><B>--cluster-total-nodes</B> <I>num</I><DD>
|
|
Set number of total nodes in cluster.
|
|
<DT id="34">[<B>!</B>] <B>--cluster-local-node</B> <I>num</I><DD>
|
|
Set the local node number ID.
|
|
<DT id="35">[<B>!</B>] <B>--cluster-local-nodemask</B> <I>mask</I><DD>
|
|
Set the local node number ID mask. You can use this option instead
|
|
of <B>--cluster-local-node</B>.
|
|
<DT id="36"><B>--cluster-hash-seed</B> <I>value</I><DD>
|
|
Set seed value of the Jenkins hash.
|
|
</DL>
|
|
<P>
|
|
|
|
Example:
|
|
<DL COMPACT>
|
|
<DT id="37"><DD>
|
|
iptables -A PREROUTING -t mangle -i eth1 -m cluster
|
|
--cluster-total-nodes 2 --cluster-local-node 1
|
|
--cluster-hash-seed 0xdeadbeef
|
|
-j MARK --set-mark 0xffff
|
|
<DT id="38"><DD>
|
|
iptables -A PREROUTING -t mangle -i eth2 -m cluster
|
|
--cluster-total-nodes 2 --cluster-local-node 1
|
|
--cluster-hash-seed 0xdeadbeef
|
|
-j MARK --set-mark 0xffff
|
|
<DT id="39"><DD>
|
|
iptables -A PREROUTING -t mangle -i eth1
|
|
-m mark ! --mark 0xffff -j DROP
|
|
<DT id="40"><DD>
|
|
iptables -A PREROUTING -t mangle -i eth2
|
|
-m mark ! --mark 0xffff -j DROP
|
|
</DL>
|
|
<P>
|
|
|
|
And the following commands to make all nodes see the same packets:
|
|
<DL COMPACT>
|
|
<DT id="41"><DD>
|
|
ip maddr add 01:00:5e:00:01:01 dev eth1
|
|
<DT id="42"><DD>
|
|
ip maddr add 01:00:5e:00:01:02 dev eth2
|
|
<DT id="43"><DD>
|
|
arptables -A OUTPUT -o eth1 --h-length 6
|
|
-j mangle --mangle-mac-s 01:00:5e:00:01:01
|
|
<DT id="44"><DD>
|
|
arptables -A INPUT -i eth1 --h-length 6
|
|
--destination-mac 01:00:5e:00:01:01
|
|
-j mangle --mangle-mac-d 00:zz:yy:xx:5a:27
|
|
<DT id="45"><DD>
|
|
arptables -A OUTPUT -o eth2 --h-length 6
|
|
-j mangle --mangle-mac-s 01:00:5e:00:01:02
|
|
<DT id="46"><DD>
|
|
arptables -A INPUT -i eth2 --h-length 6
|
|
--destination-mac 01:00:5e:00:01:02
|
|
-j mangle --mangle-mac-d 00:zz:yy:xx:5a:27
|
|
</DL>
|
|
<P>
|
|
|
|
<B>NOTE</B>: the arptables commands above use mainstream syntax. If you
|
|
are using arptables-jf included in some RedHat, CentOS and Fedora
|
|
versions, you will hit syntax errors. Therefore, you'll have to adapt
|
|
these to the arptables-jf syntax to get them working.
|
|
<P>
|
|
|
|
In the case of TCP connections, pickup facility has to be disabled
|
|
to avoid marking TCP ACK packets coming in the reply direction as
|
|
valid.
|
|
<DL COMPACT>
|
|
<DT id="47"><DD>
|
|
echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
|
|
</DL>
|
|
<A NAME="lbAK"> </A>
|
|
<H3>comment</H3>
|
|
|
|
Allows you to add comments (up to 256 characters) to any rule.
|
|
<DL COMPACT>
|
|
<DT id="48"><B>--comment</B> <I>comment</I><DD>
|
|
<DT id="49">Example:<DD>
|
|
iptables -A INPUT -i eth1 -m comment --comment "my local LAN"
|
|
</DL>
|
|
<A NAME="lbAL"> </A>
|
|
<H3>connbytes</H3>
|
|
|
|
Match by how many bytes or packets a connection (or one of the two
|
|
flows constituting the connection) has transferred so far, or by
|
|
average bytes per packet.
|
|
<P>
|
|
|
|
The counters are 64-bit and are thus not expected to overflow ;)
|
|
<P>
|
|
|
|
The primary use is to detect long-lived downloads and mark them to be
|
|
scheduled using a lower priority band in traffic control.
|
|
<P>
|
|
|
|
The transferred bytes per connection can also be viewed through
|
|
`conntrack -L` and accessed via ctnetlink.
|
|
<P>
|
|
|
|
NOTE that for connections which have no accounting information, the match will
|
|
always return false. The "net.netfilter.nf_conntrack_acct" sysctl flag controls
|
|
whether <B>new</B> connections will be byte/packet counted. Existing connection
|
|
flows will not be gaining/losing a/the accounting structure when be sysctl flag
|
|
is flipped.
|
|
<DL COMPACT>
|
|
<DT id="50">[<B>!</B>] <B>--connbytes</B> <I>from</I>[<B>:</B><I>to</I>]<DD>
|
|
match packets from a connection whose packets/bytes/average packet
|
|
size is more than FROM and less than TO bytes/packets. if TO is
|
|
omitted only FROM check is done. "!" is used to match packets not
|
|
falling in the range.
|
|
<DT id="51"><B>--connbytes-dir</B> {<B>original</B>|<B>reply</B>|<B>both</B>}<DD>
|
|
which packets to consider
|
|
<DT id="52"><B>--connbytes-mode</B> {<B>packets</B>|<B>bytes</B>|<B>avgpkt</B>}<DD>
|
|
whether to check the amount of packets, number of bytes transferred or
|
|
the average size (in bytes) of all packets received so far. Note that
|
|
when "both" is used together with "avgpkt", and data is going (mainly)
|
|
only in one direction (for example HTTP), the average packet size will
|
|
be about half of the actual data packets.
|
|
<DT id="53">Example:<DD>
|
|
iptables .. -m connbytes --connbytes 10000:100000 --connbytes-dir both --connbytes-mode bytes ...
|
|
</DL>
|
|
<A NAME="lbAM"> </A>
|
|
<H3>connlabel</H3>
|
|
|
|
Module matches or adds connlabels to a connection.
|
|
connlabels are similar to connmarks, except labels are bit-based; i.e.
|
|
all labels may be attached to a flow at the same time.
|
|
Up to 128 unique labels are currently supported.
|
|
<DL COMPACT>
|
|
<DT id="54">[<B>!</B>] <B>--label</B> <B>name</B><DD>
|
|
matches if label <B>name</B> has been set on a connection.
|
|
Instead of a name (which will be translated to a number, see EXAMPLE below),
|
|
a number may be used instead. Using a number always overrides connlabel.conf.
|
|
<DT id="55"><B>--set</B><DD>
|
|
if the label has not been set on the connection, set it.
|
|
Note that setting a label can fail. This is because the kernel allocates the
|
|
conntrack label storage area when the connection is created, and it only
|
|
reserves the amount of memory required by the ruleset that exists at
|
|
the time the connection is created.
|
|
In this case, the match will fail (or succeed, in case <B>--label</B>
|
|
option was negated).
|
|
</DL>
|
|
<P>
|
|
|
|
This match depends on libnetfilter_conntrack 1.0.4 or later.
|
|
Label translation is done via the <B>/etc/xtables/connlabel.conf</B> configuration file.
|
|
<P>
|
|
|
|
Example:
|
|
<DL COMPACT>
|
|
<DT id="56"><DD>
|
|
<PRE>
|
|
0 eth0-in
|
|
1 eth0-out
|
|
2 ppp-in
|
|
3 ppp-out
|
|
4 bulk-traffic
|
|
5 interactive
|
|
</PRE>
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
<A NAME="lbAN"> </A>
|
|
<H3>connlimit</H3>
|
|
|
|
Allows you to restrict the number of parallel connections to a server per
|
|
client IP address (or client address block).
|
|
<DL COMPACT>
|
|
<DT id="57"><B>--connlimit-upto</B> <I>n</I><DD>
|
|
Match if the number of existing connections is below or equal <I>n</I>.
|
|
<DT id="58"><B>--connlimit-above</B> <I>n</I><DD>
|
|
Match if the number of existing connections is above <I>n</I>.
|
|
<DT id="59"><B>--connlimit-mask</B> <I>prefix_length</I><DD>
|
|
Group hosts using the prefix length. For IPv4, this must be a number between
|
|
(including) 0 and 32. For IPv6, between 0 and 128. If not specified, the
|
|
maximum prefix length for the applicable protocol is used.
|
|
<DT id="60"><B>--connlimit-saddr</B><DD>
|
|
Apply the limit onto the source group. This is the default if
|
|
--connlimit-daddr is not specified.
|
|
<DT id="61"><B>--connlimit-daddr</B><DD>
|
|
Apply the limit onto the destination group.
|
|
</DL>
|
|
<P>
|
|
|
|
Examples:
|
|
<DL COMPACT>
|
|
<DT id="62"># allow 2 telnet connections per client host<DD>
|
|
iptables -A INPUT -p tcp --syn --dport 23 -m connlimit --connlimit-above 2 -j REJECT
|
|
<DT id="63"># you can also match the other way around:<DD>
|
|
iptables -A INPUT -p tcp --syn --dport 23 -m connlimit --connlimit-upto 2 -j ACCEPT
|
|
<DT id="64"># limit the number of parallel HTTP requests to 16 per class C sized source network (24 bit netmask)<DD>
|
|
iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 16
|
|
--connlimit-mask 24 -j REJECT
|
|
<DT id="65"># limit the number of parallel HTTP requests to 16 for the link local network<DD>
|
|
(ipv6)
|
|
ip6tables -p tcp --syn --dport 80 -s fe80::/64 -m connlimit --connlimit-above
|
|
16 --connlimit-mask 64 -j REJECT
|
|
<DT id="66"># Limit the number of connections to a particular host:<DD>
|
|
ip6tables -p tcp --syn --dport 49152:65535 -d 2001:db8::1 -m connlimit
|
|
--connlimit-above 100 -j REJECT
|
|
</DL>
|
|
<A NAME="lbAO"> </A>
|
|
<H3>connmark</H3>
|
|
|
|
This module matches the netfilter mark field associated with a connection
|
|
(which can be set using the <B>CONNMARK</B> target below).
|
|
<DL COMPACT>
|
|
<DT id="67">[<B>!</B>] <B>--mark</B> <I>value</I>[<B>/</B><I>mask</I>]<DD>
|
|
Matches packets in connections with the given mark value (if a mask is
|
|
specified, this is logically ANDed with the mark before the comparison).
|
|
</DL>
|
|
<A NAME="lbAP"> </A>
|
|
<H3>conntrack</H3>
|
|
|
|
This module, when combined with connection tracking, allows access to the
|
|
connection tracking state for this packet/connection.
|
|
<DL COMPACT>
|
|
<DT id="68">[<B>!</B>] <B>--ctstate</B> <I>statelist</I><DD>
|
|
<I>statelist</I> is a comma separated list of the connection states to match.
|
|
Possible states are listed below.
|
|
<DT id="69">[<B>!</B>] <B>--ctproto</B> <I>l4proto</I><DD>
|
|
Layer-4 protocol to match (by number or name)
|
|
<DT id="70">[<B>!</B>] <B>--ctorigsrc</B> <I>address</I>[<B>/</B><I>mask</I>]<DD>
|
|
<DT id="71">[<B>!</B>] <B>--ctorigdst</B> <I>address</I>[<B>/</B><I>mask</I>]<DD>
|
|
<DT id="72">[<B>!</B>] <B>--ctreplsrc</B> <I>address</I>[<B>/</B><I>mask</I>]<DD>
|
|
<DT id="73">[<B>!</B>] <B>--ctrepldst</B> <I>address</I>[<B>/</B><I>mask</I>]<DD>
|
|
Match against original/reply source/destination address
|
|
<DT id="74">[<B>!</B>] <B>--ctorigsrcport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
<DT id="75">[<B>!</B>] <B>--ctorigdstport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
<DT id="76">[<B>!</B>] <B>--ctreplsrcport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
<DT id="77">[<B>!</B>] <B>--ctrepldstport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
Match against original/reply source/destination port (TCP/UDP/etc.) or GRE key.
|
|
Matching against port ranges is only supported in kernel versions above 2.6.38.
|
|
<DT id="78">[<B>!</B>] <B>--ctstatus</B> <I>statelist</I><DD>
|
|
<I>statuslist</I> is a comma separated list of the connection statuses to match.
|
|
Possible statuses are listed below.
|
|
<DT id="79">[<B>!</B>] <B>--ctexpire</B> <I>time</I>[<B>:</B><I>time</I>]<DD>
|
|
Match remaining lifetime in seconds against given value or range of values
|
|
(inclusive)
|
|
<DT id="80"><B>--ctdir</B> {<B>ORIGINAL</B>|<B>REPLY</B>}<DD>
|
|
Match packets that are flowing in the specified direction. If this flag is not
|
|
specified at all, matches packets in both directions.
|
|
</DL>
|
|
<P>
|
|
|
|
States for <B>--ctstate</B>:
|
|
<DL COMPACT>
|
|
<DT id="81"><B>INVALID</B><DD>
|
|
The packet is associated with no known connection.
|
|
<DT id="82"><B>NEW</B><DD>
|
|
The packet has started a new connection or otherwise associated
|
|
with a connection which has not seen packets in both directions.
|
|
<DT id="83"><B>ESTABLISHED</B><DD>
|
|
The packet is associated with a connection which has seen packets
|
|
in both directions.
|
|
<DT id="84"><B>RELATED</B><DD>
|
|
The packet is starting a new connection, but is associated with an
|
|
existing connection, such as an FTP data transfer or an ICMP error.
|
|
<DT id="85"><B>UNTRACKED</B><DD>
|
|
The packet is not tracked at all, which happens if you explicitly untrack it
|
|
by using -j CT --notrack in the raw table.
|
|
<DT id="86"><B>SNAT</B><DD>
|
|
A virtual state, matching if the original source address differs from the reply
|
|
destination.
|
|
<DT id="87"><B>DNAT</B><DD>
|
|
A virtual state, matching if the original destination differs from the reply
|
|
source.
|
|
</DL>
|
|
<P>
|
|
|
|
Statuses for <B>--ctstatus</B>:
|
|
<DL COMPACT>
|
|
<DT id="88"><B>NONE</B><DD>
|
|
None of the below.
|
|
<DT id="89"><B>EXPECTED</B><DD>
|
|
This is an expected connection (i.e. a conntrack helper set it up).
|
|
<DT id="90"><B>SEEN_REPLY</B><DD>
|
|
Conntrack has seen packets in both directions.
|
|
<DT id="91"><B>ASSURED</B><DD>
|
|
Conntrack entry should never be early-expired.
|
|
<DT id="92"><B>CONFIRMED</B><DD>
|
|
Connection is confirmed: originating packet has left box.
|
|
</DL>
|
|
<A NAME="lbAQ"> </A>
|
|
<H3>cpu</H3>
|
|
|
|
<DL COMPACT>
|
|
<DT id="93">[<B>!</B>] <B>--cpu</B> <I>number</I><DD>
|
|
Match cpu handling this packet. cpus are numbered from 0 to NR_CPUS-1
|
|
Can be used in combination with RPS (Remote Packet Steering) or
|
|
multiqueue NICs to spread network traffic on different queues.
|
|
</DL>
|
|
<P>
|
|
|
|
Example:
|
|
<P>
|
|
|
|
iptables -t nat -A PREROUTING -p tcp --dport 80 -m cpu --cpu 0
|
|
-j REDIRECT --to-port 8080
|
|
<P>
|
|
|
|
iptables -t nat -A PREROUTING -p tcp --dport 80 -m cpu --cpu 1
|
|
-j REDIRECT --to-port 8081
|
|
<P>
|
|
|
|
Available since Linux 2.6.36.
|
|
<A NAME="lbAR"> </A>
|
|
<H3>dccp</H3>
|
|
|
|
<DL COMPACT>
|
|
<DT id="94">[<B>!</B>] <B>--source-port</B>,<B>--sport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
<DT id="95">[<B>!</B>] <B>--destination-port</B>,<B>--dport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
<DT id="96">[<B>!</B>] <B>--dccp-types</B> <I>mask</I><DD>
|
|
Match when the DCCP packet type is one of 'mask'. 'mask' is a comma-separated
|
|
list of packet types. Packet types are:
|
|
<B>REQUEST RESPONSE DATA ACK DATAACK CLOSEREQ CLOSE RESET SYNC SYNCACK INVALID</B>.
|
|
|
|
<DT id="97">[<B>!</B>] <B>--dccp-option</B> <I>number</I><DD>
|
|
Match if DCCP option set.
|
|
</DL>
|
|
<A NAME="lbAS"> </A>
|
|
<H3>devgroup</H3>
|
|
|
|
Match device group of a packets incoming/outgoing interface.
|
|
<DL COMPACT>
|
|
<DT id="98">[<B>!</B>] <B>--src-group</B> <I>name</I><DD>
|
|
Match device group of incoming device
|
|
<DT id="99">[<B>!</B>] <B>--dst-group</B> <I>name</I><DD>
|
|
Match device group of outgoing device
|
|
</DL>
|
|
<A NAME="lbAT"> </A>
|
|
<H3>dscp</H3>
|
|
|
|
This module matches the 6 bit DSCP field within the TOS field in the
|
|
IP header. DSCP has superseded TOS within the IETF.
|
|
<DL COMPACT>
|
|
<DT id="100">[<B>!</B>] <B>--dscp</B> <I>value</I><DD>
|
|
Match against a numeric (decimal or hex) value [0-63].
|
|
<DT id="101">[<B>!</B>] <B>--dscp-class</B> <I>class</I><DD>
|
|
Match the DiffServ class. This value may be any of the
|
|
BE, EF, AFxx or CSx classes. It will then be converted
|
|
into its according numeric value.
|
|
</DL>
|
|
<A NAME="lbAU"> </A>
|
|
<H3>dst (IPv6-specific)</H3>
|
|
|
|
This module matches the parameters in Destination Options header
|
|
<DL COMPACT>
|
|
<DT id="102">[<B>!</B>] <B>--dst-len</B> <I>length</I><DD>
|
|
Total length of this header in octets.
|
|
<DT id="103"><B>--dst-opts</B> <I>type</I>[<B>:</B><I>length</I>][<B>,</B><I>type</I>[<B>:</B><I>length</I>]...]<DD>
|
|
numeric type of option and the length of the option data in octets.
|
|
</DL>
|
|
<A NAME="lbAV"> </A>
|
|
<H3>ecn</H3>
|
|
|
|
This allows you to match the ECN bits of the IPv4/IPv6 and TCP header. ECN is the Explicit Congestion Notification mechanism as specified in RFC3168
|
|
<DL COMPACT>
|
|
<DT id="104">[<B>!</B>] <B>--ecn-tcp-cwr</B><DD>
|
|
This matches if the TCP ECN CWR (Congestion Window Received) bit is set.
|
|
<DT id="105">[<B>!</B>] <B>--ecn-tcp-ece</B><DD>
|
|
This matches if the TCP ECN ECE (ECN Echo) bit is set.
|
|
<DT id="106">[<B>!</B>] <B>--ecn-ip-ect</B> <I>num</I><DD>
|
|
This matches a particular IPv4/IPv6 ECT (ECN-Capable Transport). You have to specify
|
|
a number between `0' and `3'.
|
|
</DL>
|
|
<A NAME="lbAW"> </A>
|
|
<H3>esp</H3>
|
|
|
|
This module matches the SPIs in ESP header of IPsec packets.
|
|
<DL COMPACT>
|
|
<DT id="107">[<B>!</B>] <B>--espspi</B> <I>spi</I>[<B>:</B><I>spi</I>]<DD>
|
|
</DL>
|
|
<A NAME="lbAX"> </A>
|
|
<H3>eui64 (IPv6-specific)</H3>
|
|
|
|
This module matches the EUI-64 part of a stateless autoconfigured IPv6 address.
|
|
It compares the EUI-64 derived from the source MAC address in Ethernet frame
|
|
with the lower 64 bits of the IPv6 source address. But "Universal/Local"
|
|
bit is not compared. This module doesn't match other link layer frame, and
|
|
is only valid in the
|
|
<B>PREROUTING</B>,
|
|
|
|
<B>INPUT</B>
|
|
|
|
and
|
|
<B>FORWARD</B>
|
|
|
|
chains.
|
|
<A NAME="lbAY"> </A>
|
|
<H3>frag (IPv6-specific)</H3>
|
|
|
|
This module matches the parameters in Fragment header.
|
|
<DL COMPACT>
|
|
<DT id="108">[<B>!</B>] <B>--fragid</B> <I>id</I>[<B>:</B><I>id</I>]<DD>
|
|
Matches the given Identification or range of it.
|
|
<DT id="109">[<B>!</B>] <B>--fraglen</B> <I>length</I><DD>
|
|
This option cannot be used with kernel version 2.6.10 or later. The length of
|
|
Fragment header is static and this option doesn't make sense.
|
|
<DT id="110"><B>--fragres</B><DD>
|
|
Matches if the reserved fields are filled with zero.
|
|
<DT id="111"><B>--fragfirst</B><DD>
|
|
Matches on the first fragment.
|
|
<DT id="112"><B>--fragmore</B><DD>
|
|
Matches if there are more fragments.
|
|
<DT id="113"><B>--fraglast</B><DD>
|
|
Matches if this is the last fragment.
|
|
</DL>
|
|
<A NAME="lbAZ"> </A>
|
|
<H3>hashlimit</H3>
|
|
|
|
<B>hashlimit</B> uses hash buckets to express a rate limiting match (like the
|
|
<B>limit</B> match) for a group of connections using a <B>single</B> iptables
|
|
rule. Grouping can be done per-hostgroup (source and/or destination address)
|
|
and/or per-port. It gives you the ability to express "<I>N</I> packets per time
|
|
quantum per group" or "<I>N</I> bytes per seconds" (see below for some examples).
|
|
<P>
|
|
|
|
A hash limit option (<B>--hashlimit-upto</B>, <B>--hashlimit-above</B>) and
|
|
<B>--hashlimit-name</B> are required.
|
|
<DL COMPACT>
|
|
<DT id="114"><B>--hashlimit-upto</B> <I>amount</I>[<B>/second</B>|<B>/minute</B>|<B>/hour</B>|<B>/day</B>]<DD>
|
|
Match if the rate is below or equal to <I>amount</I>/quantum. It is specified either as
|
|
a number, with an optional time quantum suffix (the default is 3/hour), or as
|
|
<I>amount</I>b/second (number of bytes per second).
|
|
<DT id="115"><B>--hashlimit-above</B> <I>amount</I>[<B>/second</B>|<B>/minute</B>|<B>/hour</B>|<B>/day</B>]<DD>
|
|
Match if the rate is above <I>amount</I>/quantum.
|
|
<DT id="116"><B>--hashlimit-burst</B> <I>amount</I><DD>
|
|
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. When byte-based rate matching is requested, this option specifies
|
|
the amount of bytes that can exceed the given rate. This option should be used
|
|
with caution -- if the entry expires, the burst value is reset too.
|
|
<DT id="117"><B>--hashlimit-mode</B> {<B>srcip</B>|<B>srcport</B>|<B>dstip</B>|<B>dstport</B>}<B>,</B>...<DD>
|
|
A comma-separated list of objects to take into consideration. If no
|
|
--hashlimit-mode option is given, hashlimit acts like limit, but at the
|
|
expensive of doing the hash housekeeping.
|
|
<DT id="118"><B>--hashlimit-srcmask</B> <I>prefix</I><DD>
|
|
When --hashlimit-mode srcip is used, all source addresses encountered will be
|
|
grouped according to the given prefix length and the so-created subnet will be
|
|
subject to hashlimit. <I>prefix</I> must be between (inclusive) 0 and 32. Note
|
|
that --hashlimit-srcmask 0 is basically doing the same thing as not specifying
|
|
srcip for --hashlimit-mode, but is technically more expensive.
|
|
<DT id="119"><B>--hashlimit-dstmask</B> <I>prefix</I><DD>
|
|
Like --hashlimit-srcmask, but for destination addresses.
|
|
<DT id="120"><B>--hashlimit-name</B> <I>foo</I><DD>
|
|
The name for the /proc/net/ipt_hashlimit/foo entry.
|
|
<DT id="121"><B>--hashlimit-htable-size</B> <I>buckets</I><DD>
|
|
The number of buckets of the hash table
|
|
<DT id="122"><B>--hashlimit-htable-max</B> <I>entries</I><DD>
|
|
Maximum entries in the hash.
|
|
<DT id="123"><B>--hashlimit-htable-expire</B> <I>msec</I><DD>
|
|
After how many milliseconds do hash entries expire.
|
|
<DT id="124"><B>--hashlimit-htable-gcinterval</B> <I>msec</I><DD>
|
|
How many milliseconds between garbage collection intervals.
|
|
<DT id="125"><B>--hashlimit-rate-match</B><DD>
|
|
Classify the flow instead of rate-limiting it. This acts like a
|
|
true/false match on whether the rate is above/below a certain number
|
|
<DT id="126"><B>--hashlimit-rate-interval</B> <I>sec</I><DD>
|
|
Can be used with --hashlimit-rate-match to specify the interval
|
|
at which the rate should be sampled
|
|
</DL>
|
|
<P>
|
|
|
|
Examples:
|
|
<DL COMPACT>
|
|
<DT id="127">matching on source host<DD>
|
|
"1000 packets per second for every host in 192.168.0.0/16" =>
|
|
-s 192.168.0.0/16 --hashlimit-mode srcip --hashlimit-upto 1000/sec
|
|
<DT id="128">matching on source port<DD>
|
|
"100 packets per second for every service of 192.168.1.1" =>
|
|
-s 192.168.1.1 --hashlimit-mode srcport --hashlimit-upto 100/sec
|
|
<DT id="129">matching on subnet<DD>
|
|
"10000 packets per minute for every /28 subnet (groups of 8 addresses)
|
|
in 10.0.0.0/8" =>
|
|
-s 10.0.0.0/8 --hashlimit-mask 28 --hashlimit-upto 10000/min
|
|
<DT id="130">matching bytes per second<DD>
|
|
"flows exceeding 512kbyte/s" =>
|
|
--hashlimit-mode srcip,dstip,srcport,dstport --hashlimit-above 512kb/s
|
|
<DT id="131">matching bytes per second<DD>
|
|
"hosts that exceed 512kbyte/s, but permit up to 1Megabytes without matching"
|
|
--hashlimit-mode dstip --hashlimit-above 512kb/s --hashlimit-burst 1mb
|
|
</DL>
|
|
<A NAME="lbBA"> </A>
|
|
<H3>hbh (IPv6-specific)</H3>
|
|
|
|
This module matches the parameters in Hop-by-Hop Options header
|
|
<DL COMPACT>
|
|
<DT id="132">[<B>!</B>] <B>--hbh-len</B> <I>length</I><DD>
|
|
Total length of this header in octets.
|
|
<DT id="133"><B>--hbh-opts</B> <I>type</I>[<B>:</B><I>length</I>][<B>,</B><I>type</I>[<B>:</B><I>length</I>]...]<DD>
|
|
numeric type of option and the length of the option data in octets.
|
|
</DL>
|
|
<A NAME="lbBB"> </A>
|
|
<H3>helper</H3>
|
|
|
|
This module matches packets related to a specific conntrack-helper.
|
|
<DL COMPACT>
|
|
<DT id="134">[<B>!</B>] <B>--helper</B> <I>string</I><DD>
|
|
Matches packets related to the specified conntrack-helper.
|
|
<DL COMPACT><DT id="135"><DD>
|
|
<P>
|
|
|
|
string can be "ftp" for packets related to a ftp-session on default port.
|
|
For other ports append -portnr to the value, ie. "ftp-2121".
|
|
<P>
|
|
|
|
Same rules apply for other conntrack-helpers.
|
|
</DL>
|
|
|
|
</DL>
|
|
<A NAME="lbBC"> </A>
|
|
<H3>hl (IPv6-specific)</H3>
|
|
|
|
This module matches the Hop Limit field in the IPv6 header.
|
|
<DL COMPACT>
|
|
<DT id="136">[<B>!</B>] <B>--hl-eq</B> <I>value</I><DD>
|
|
Matches if Hop Limit equals <I>value</I>.
|
|
<DT id="137"><B>--hl-lt</B> <I>value</I><DD>
|
|
Matches if Hop Limit is less than <I>value</I>.
|
|
<DT id="138"><B>--hl-gt</B> <I>value</I><DD>
|
|
Matches if Hop Limit is greater than <I>value</I>.
|
|
</DL>
|
|
<A NAME="lbBD"> </A>
|
|
<H3>icmp (IPv4-specific)</H3>
|
|
|
|
This extension can be used if `--protocol icmp' is specified. It
|
|
provides the following option:
|
|
<DL COMPACT>
|
|
<DT id="139">[<B>!</B>] <B>--icmp-type</B> {<I>type</I>[<B>/</B><I>code</I>]|<I>typename</I>}<DD>
|
|
This allows specification of the ICMP type, which can be a numeric
|
|
ICMP type, type/code pair, or one of the ICMP type names shown by the command
|
|
<PRE>
|
|
iptables -p icmp -h
|
|
</PRE>
|
|
|
|
</DL>
|
|
<A NAME="lbBE"> </A>
|
|
<H3>icmp6 (IPv6-specific)</H3>
|
|
|
|
This extension can be used if `--protocol ipv6-icmp' or `--protocol icmpv6' is
|
|
specified. It provides the following option:
|
|
<DL COMPACT>
|
|
<DT id="140">[<B>!</B>] <B>--icmpv6-type</B> <I>type</I>[<B>/</B><I>code</I>]|<I>typename</I><DD>
|
|
This allows specification of the ICMPv6 type, which can be a numeric
|
|
ICMPv6
|
|
<I>type</I>,
|
|
|
|
<I>type</I>
|
|
|
|
and
|
|
<I>code</I>,
|
|
|
|
or one of the ICMPv6 type names shown by the command
|
|
<PRE>
|
|
ip6tables -p ipv6-icmp -h
|
|
</PRE>
|
|
|
|
</DL>
|
|
<A NAME="lbBF"> </A>
|
|
<H3>iprange</H3>
|
|
|
|
This matches on a given arbitrary range of IP addresses.
|
|
<DL COMPACT>
|
|
<DT id="141">[<B>!</B>] <B>--src-range</B> <I>from</I>[<B>-</B><I>to</I>]<DD>
|
|
Match source IP in the specified range.
|
|
<DT id="142">[<B>!</B>] <B>--dst-range</B> <I>from</I>[<B>-</B><I>to</I>]<DD>
|
|
Match destination IP in the specified range.
|
|
</DL>
|
|
<A NAME="lbBG"> </A>
|
|
<H3>ipv6header (IPv6-specific)</H3>
|
|
|
|
This module matches IPv6 extension headers and/or upper layer header.
|
|
<DL COMPACT>
|
|
<DT id="143"><B>--soft</B><DD>
|
|
Matches if the packet includes <B>any</B> of the headers specified with
|
|
<B>--header</B>.
|
|
<DT id="144">[<B>!</B>] <B>--header</B> <I>header</I>[<B>,</B><I>header</I>...]<DD>
|
|
Matches the packet which EXACTLY includes all specified headers. The headers
|
|
encapsulated with ESP header are out of scope.
|
|
Possible <I>header</I> types can be:
|
|
<DT id="145"><B>hop</B>|<B>hop-by-hop</B><DD>
|
|
Hop-by-Hop Options header
|
|
<DT id="146"><B>dst</B><DD>
|
|
Destination Options header
|
|
<DT id="147"><B>route</B><DD>
|
|
Routing header
|
|
<DT id="148"><B>frag</B><DD>
|
|
Fragment header
|
|
<DT id="149"><B>auth</B><DD>
|
|
Authentication header
|
|
<DT id="150"><B>esp</B><DD>
|
|
Encapsulating Security Payload header
|
|
<DT id="151"><B>none</B><DD>
|
|
No Next header which matches 59 in the 'Next Header field' of IPv6 header or
|
|
any IPv6 extension headers
|
|
<DT id="152"><B>prot</B><DD>
|
|
which matches any upper layer protocol header. A protocol name from
|
|
/etc/protocols and numeric value also allowed. The number 255 is equivalent to
|
|
<B>prot</B>.
|
|
</DL>
|
|
<A NAME="lbBH"> </A>
|
|
<H3>ipvs</H3>
|
|
|
|
Match IPVS connection properties.
|
|
<DL COMPACT>
|
|
<DT id="153">[<B>!</B>] <B>--ipvs</B><DD>
|
|
packet belongs to an IPVS connection
|
|
<DT id="154">Any of the following options implies --ipvs (even negated)<DD>
|
|
<DT id="155">[<B>!</B>] <B>--vproto</B> <I>protocol</I><DD>
|
|
VIP protocol to match; by number or name, e.g. "tcp"
|
|
<DT id="156">[<B>!</B>] <B>--vaddr</B> <I>address</I>[<B>/</B><I>mask</I>]<DD>
|
|
VIP address to match
|
|
<DT id="157">[<B>!</B>] <B>--vport</B> <I>port</I><DD>
|
|
VIP port to match; by number or name, e.g. "http"
|
|
<DT id="158"><B>--vdir</B> {<B>ORIGINAL</B>|<B>REPLY</B>}<DD>
|
|
flow direction of packet
|
|
<DT id="159">[<B>!</B>] <B>--vmethod</B> {<B>GATE</B>|<B>IPIP</B>|<B>MASQ</B>}<DD>
|
|
IPVS forwarding method used
|
|
<DT id="160">[<B>!</B>] <B>--vportctl</B> <I>port</I><DD>
|
|
VIP port of the controlling connection to match, e.g. 21 for FTP
|
|
</DL>
|
|
<A NAME="lbBI"> </A>
|
|
<H3>length</H3>
|
|
|
|
This module matches the length of the layer-3 payload (e.g. layer-4 packet)
|
|
of a packet against a specific value
|
|
or range of values.
|
|
<DL COMPACT>
|
|
<DT id="161">[<B>!</B>] <B>--length</B> <I>length</I>[<B>:</B><I>length</I>]<DD>
|
|
</DL>
|
|
<A NAME="lbBJ"> </A>
|
|
<H3>limit</H3>
|
|
|
|
This module matches at a limited rate using a token bucket filter.
|
|
A rule using this extension will match until this limit is reached.
|
|
It can be used in combination with the
|
|
<B>LOG</B>
|
|
|
|
target to give limited logging, for example.
|
|
<P>
|
|
|
|
xt_limit has no negation support - you will have to use -m hashlimit !
|
|
--hashlimit <I>rate</I> in this case whilst omitting --hashlimit-mode.
|
|
<DL COMPACT>
|
|
<DT id="162"><B>--limit</B> <I>rate</I>[<B>/second</B>|<B>/minute</B>|<B>/hour</B>|<B>/day</B>]<DD>
|
|
Maximum average matching rate: specified as a number, with an optional
|
|
`/second', `/minute', `/hour', or `/day' suffix; the default is
|
|
3/hour.
|
|
<DT id="163"><B>--limit-burst</B> <I>number</I><DD>
|
|
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.
|
|
</DL>
|
|
<A NAME="lbBK"> </A>
|
|
<H3>mac</H3>
|
|
|
|
<DL COMPACT>
|
|
<DT id="164">[<B>!</B>] <B>--mac-source</B> <I>address</I><DD>
|
|
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
|
|
<B>PREROUTING</B>,
|
|
|
|
<B>FORWARD</B>
|
|
|
|
or
|
|
<B>INPUT</B>
|
|
|
|
chains.
|
|
</DL>
|
|
<A NAME="lbBL"> </A>
|
|
<H3>mark</H3>
|
|
|
|
This module matches the netfilter mark field associated with a packet
|
|
(which can be set using the
|
|
<B>MARK</B>
|
|
|
|
target below).
|
|
<DL COMPACT>
|
|
<DT id="165">[<B>!</B>] <B>--mark</B> <I>value</I>[<B>/</B><I>mask</I>]<DD>
|
|
Matches packets with the given unsigned mark value (if a <I>mask</I> is
|
|
specified, this is logically ANDed with the <I>mask</I> before the
|
|
comparison).
|
|
</DL>
|
|
<A NAME="lbBM"> </A>
|
|
<H3>mh (IPv6-specific)</H3>
|
|
|
|
This extension is loaded if `--protocol ipv6-mh' or `--protocol mh' is
|
|
specified. It provides the following option:
|
|
<DL COMPACT>
|
|
<DT id="166">[<B>!</B>] <B>--mh-type</B> <I>type</I>[<B>:</B><I>type</I>]<DD>
|
|
This allows specification of the Mobility Header(MH) type, which can be
|
|
a numeric MH
|
|
<I>type</I>,
|
|
|
|
<I>type</I>
|
|
|
|
or one of the MH type names shown by the command
|
|
<PRE>
|
|
ip6tables -p mh -h
|
|
</PRE>
|
|
|
|
</DL>
|
|
<A NAME="lbBN"> </A>
|
|
<H3>multiport</H3>
|
|
|
|
This module matches a set of source or destination ports. Up to 15
|
|
ports can be specified. A port range (port:port) counts as two
|
|
ports. It can only be used in conjunction with one of the
|
|
following protocols:
|
|
<B>tcp</B>, <B>udp</B>, <B>udplite</B>, <B>dccp</B> and <B>sctp</B>.
|
|
<DL COMPACT>
|
|
<DT id="167">[<B>!</B>] <B>--source-ports</B>,<B>--sports</B> <I>port</I>[<B>,</B><I>port</I>|<B>,</B><I>port</I><B>:</B><I>port</I>]...<DD>
|
|
Match if the source port is one of the given ports. The flag
|
|
<B>--sports</B>
|
|
is a convenient alias for this option. Multiple ports or port ranges are
|
|
separated using a comma, and a port range is specified using a colon.
|
|
<B>53,1024:65535</B> would therefore match ports 53 and all from 1024 through
|
|
65535.
|
|
<DT id="168">[<B>!</B>] <B>--destination-ports</B>,<B>--dports</B> <I>port</I>[<B>,</B><I>port</I>|<B>,</B><I>port</I><B>:</B><I>port</I>]...<DD>
|
|
Match if the destination port is one of the given ports. The flag
|
|
<B>--dports</B>
|
|
is a convenient alias for this option.
|
|
<DT id="169">[<B>!</B>] <B>--ports</B> <I>port</I>[<B>,</B><I>port</I>|<B>,</B><I>port</I><B>:</B><I>port</I>]...<DD>
|
|
Match if either the source or destination ports are equal to one of
|
|
the given ports.
|
|
</DL>
|
|
<A NAME="lbBO"> </A>
|
|
<H3>nfacct</H3>
|
|
|
|
The nfacct match provides the extended accounting infrastructure for iptables.
|
|
You have to use this match together with the standalone user-space utility
|
|
<B><A HREF="/cgi-bin/man/man2html?8+nfacct">nfacct</A>(8)</B>
|
|
|
|
<P>
|
|
|
|
The only option available for this match is the following:
|
|
<DL COMPACT>
|
|
<DT id="170"><B>--nfacct-name</B> <I>name</I><DD>
|
|
This allows you to specify the existing object name that will be use for
|
|
accounting the traffic that this rule-set is matching.
|
|
</DL>
|
|
<P>
|
|
|
|
To use this extension, you have to create an accounting object:
|
|
<DL COMPACT>
|
|
<DT id="171"><DD>
|
|
nfacct add http-traffic
|
|
</DL>
|
|
<P>
|
|
|
|
Then, you have to attach it to the accounting object via iptables:
|
|
<DL COMPACT>
|
|
<DT id="172"><DD>
|
|
iptables -I INPUT -p tcp --sport 80 -m nfacct --nfacct-name http-traffic
|
|
<DT id="173"><DD>
|
|
iptables -I OUTPUT -p tcp --dport 80 -m nfacct --nfacct-name http-traffic
|
|
</DL>
|
|
<P>
|
|
|
|
Then, you can check for the amount of traffic that the rules match:
|
|
<DL COMPACT>
|
|
<DT id="174"><DD>
|
|
nfacct get http-traffic
|
|
<DT id="175"><DD>
|
|
{ pkts = 00000000000000000156, bytes = 00000000000000151786 } = http-traffic;
|
|
</DL>
|
|
<P>
|
|
|
|
You can obtain
|
|
<B><A HREF="/cgi-bin/man/man2html?8+nfacct">nfacct</A>(8)</B>
|
|
|
|
from <A HREF="http://www.netfilter.org">http://www.netfilter.org</A> or, alternatively, from the git.netfilter.org
|
|
repository.
|
|
<A NAME="lbBP"> </A>
|
|
<H3>osf</H3>
|
|
|
|
The osf module does passive operating system fingerprinting. This modules
|
|
compares some data (Window Size, MSS, options and their order, TTL, DF,
|
|
and others) from packets with the SYN bit set.
|
|
<DL COMPACT>
|
|
<DT id="176">[<B>!</B>] <B>--genre</B> <I>string</I><DD>
|
|
Match an operating system genre by using a passive fingerprinting.
|
|
<DT id="177"><B>--ttl</B> <I>level</I><DD>
|
|
Do additional TTL checks on the packet to determine the operating system.
|
|
<I>level</I> can be one of the following values:
|
|
<DT id="178">•<DD>
|
|
0 - True IP address and fingerprint TTL comparison. This generally works for
|
|
LANs.
|
|
<DT id="179">•<DD>
|
|
1 - Check if the IP header's TTL is less than the fingerprint one. Works for
|
|
globally-routable addresses.
|
|
<DT id="180">•<DD>
|
|
2 - Do not compare the TTL at all.
|
|
<DT id="181"><B>--log</B> <I>level</I><DD>
|
|
Log determined genres into dmesg even if they do not match the desired one.
|
|
<I>level</I> can be one of the following values:
|
|
<DT id="182">•<DD>
|
|
0 - Log all matched or unknown signatures
|
|
<DT id="183">•<DD>
|
|
1 - Log only the first one
|
|
<DT id="184">•<DD>
|
|
2 - Log all known matched signatures
|
|
</DL>
|
|
<P>
|
|
|
|
You may find something like this in syslog:
|
|
<P>
|
|
|
|
Windows [2000:SP3:Windows XP Pro SP1, 2000 SP3]: 11.22.33.55:4024 ->
|
|
11.22.33.44:139 hops=3 Linux [2.5-2.6:] : 1.2.3.4:42624 -> 1.2.3.5:22 hops=4
|
|
<P>
|
|
|
|
OS fingerprints are loadable using the <B>nfnl_osf</B> program. To load
|
|
fingerprints from a file, use:
|
|
<P>
|
|
|
|
<B>nfnl_osf -f /usr/share/xtables/pf.os</B>
|
|
<P>
|
|
|
|
To remove them again,
|
|
<P>
|
|
|
|
<B>nfnl_osf -f /usr/share/xtables/pf.os -d</B>
|
|
<P>
|
|
|
|
The fingerprint database can be downloaded from
|
|
<A HREF="http://www.openbsd.org/cgi-bin/cvsweb/src/etc/pf.os">http://www.openbsd.org/cgi-bin/cvsweb/src/etc/pf.os</A> .
|
|
<A NAME="lbBQ"> </A>
|
|
<H3>owner</H3>
|
|
|
|
This module attempts to match various characteristics of the packet creator,
|
|
for locally generated packets. This match is only valid in the OUTPUT and
|
|
POSTROUTING chains. Forwarded packets do not have any socket associated with
|
|
them. Packets from kernel threads do have a socket, but usually no owner.
|
|
<DL COMPACT>
|
|
<DT id="185">[<B>!</B>] <B>--uid-owner</B> <I>username</I><DD>
|
|
<DT id="186">[<B>!</B>] <B>--uid-owner</B> <I>userid</I>[<B>-</B><I>userid</I>]<DD>
|
|
Matches if the packet socket's file structure (if it has one) is owned by the
|
|
given user. You may also specify a numerical UID, or an UID range.
|
|
<DT id="187">[<B>!</B>] <B>--gid-owner</B> <I>groupname</I><DD>
|
|
<DT id="188">[<B>!</B>] <B>--gid-owner</B> <I>groupid</I>[<B>-</B><I>groupid</I>]<DD>
|
|
Matches if the packet socket's file structure is owned by the given group.
|
|
You may also specify a numerical GID, or a GID range.
|
|
<DT id="189"><B>--suppl-groups</B><DD>
|
|
Causes group(s) specified with <B>--gid-owner</B> to be also checked in the
|
|
supplementary groups of a process.
|
|
<DT id="190">[<B>!</B>] <B>--socket-exists</B><DD>
|
|
Matches if the packet is associated with a socket.
|
|
</DL>
|
|
<A NAME="lbBR"> </A>
|
|
<H3>physdev</H3>
|
|
|
|
This module matches on the bridge port input and output devices enslaved
|
|
to a bridge device. This module is a part of the infrastructure that enables
|
|
a transparent bridging IP firewall and is only useful for kernel versions
|
|
above version 2.5.44.
|
|
<DL COMPACT>
|
|
<DT id="191">[<B>!</B>] <B>--physdev-in</B> <I>name</I><DD>
|
|
Name of a bridge port via which a packet is received (only for
|
|
packets entering the
|
|
<B>INPUT</B>,
|
|
|
|
<B>FORWARD</B>
|
|
|
|
and
|
|
<B>PREROUTING</B>
|
|
|
|
chains). If the interface name ends in a "+", then any
|
|
interface which begins with this name will match. If the packet didn't arrive
|
|
through a bridge device, this packet won't match this option, unless '!' is used.
|
|
<DT id="192">[<B>!</B>] <B>--physdev-out</B> <I>name</I><DD>
|
|
Name of a bridge port via which a packet is going to be sent (for bridged packets
|
|
entering the
|
|
<B>FORWARD</B>
|
|
|
|
and
|
|
<B>POSTROUTING</B>
|
|
|
|
chains). If the interface name ends in a "+", then any
|
|
interface which begins with this name will match.
|
|
<DT id="193">[<B>!</B>] <B>--physdev-is-in</B><DD>
|
|
Matches if the packet has entered through a bridge interface.
|
|
<DT id="194">[<B>!</B>] <B>--physdev-is-out</B><DD>
|
|
Matches if the packet will leave through a bridge interface.
|
|
<DT id="195">[<B>!</B>] <B>--physdev-is-bridged</B><DD>
|
|
Matches if the packet is being bridged and therefore is not being routed.
|
|
This is only useful in the FORWARD and POSTROUTING chains.
|
|
</DL>
|
|
<A NAME="lbBS"> </A>
|
|
<H3>pkttype</H3>
|
|
|
|
This module matches the link-layer packet type.
|
|
<DL COMPACT>
|
|
<DT id="196">[<B>!</B>] <B>--pkt-type</B> {<B>unicast</B>|<B>broadcast</B>|<B>multicast</B>}<DD>
|
|
</DL>
|
|
<A NAME="lbBT"> </A>
|
|
<H3>policy</H3>
|
|
|
|
This modules matches the policy used by IPsec for handling a packet.
|
|
<DL COMPACT>
|
|
<DT id="197"><B>--dir</B> {<B>in</B>|<B>out</B>}<DD>
|
|
Used to select whether to match the policy used for decapsulation or the
|
|
policy that will be used for encapsulation.
|
|
<B>in</B>
|
|
|
|
is valid in the
|
|
<B>PREROUTING, INPUT and FORWARD</B>
|
|
|
|
chains,
|
|
<B>out</B>
|
|
|
|
is valid in the
|
|
<B>POSTROUTING, OUTPUT and FORWARD</B>
|
|
|
|
chains.
|
|
<DT id="198"><B>--pol</B> {<B>none</B>|<B>ipsec</B>}<DD>
|
|
Matches if the packet is subject to IPsec processing. <B>--pol none</B>
|
|
cannot be combined with <B>--strict</B>.
|
|
<DT id="199"><B>--strict</B><DD>
|
|
Selects whether to match the exact policy or match if any rule of
|
|
the policy matches the given policy.
|
|
</DL>
|
|
<P>
|
|
|
|
For each policy element that is to be described, one can use one or more of
|
|
the following options. When <B>--strict</B> is in effect, at least one must be
|
|
used per element.
|
|
<DL COMPACT>
|
|
<DT id="200">[<B>!</B>] <B>--reqid</B> <I>id</I><DD>
|
|
Matches the reqid of the policy rule. The reqid can be specified with
|
|
<B><A HREF="/cgi-bin/man/man2html?8+setkey">setkey</A>(8)</B>
|
|
|
|
using
|
|
<B>unique:id</B>
|
|
|
|
as level.
|
|
<DT id="201">[<B>!</B>] <B>--spi</B> <I>spi</I><DD>
|
|
Matches the SPI of the SA.
|
|
<DT id="202">[<B>!</B>] <B>--proto</B> {<B>ah</B>|<B>esp</B>|<B>ipcomp</B>}<DD>
|
|
Matches the encapsulation protocol.
|
|
<DT id="203">[<B>!</B>] <B>--mode</B> {<B>tunnel</B>|<B>transport</B>}<DD>
|
|
Matches the encapsulation mode.
|
|
<DT id="204">[<B>!</B>] <B>--tunnel-src</B> <I>addr</I>[<B>/</B><I>mask</I>]<DD>
|
|
Matches the source end-point address of a tunnel mode SA.
|
|
Only valid with <B>--mode tunnel</B>.
|
|
<DT id="205">[<B>!</B>] <B>--tunnel-dst</B> <I>addr</I>[<B>/</B><I>mask</I>]<DD>
|
|
Matches the destination end-point address of a tunnel mode SA.
|
|
Only valid with <B>--mode tunnel</B>.
|
|
<DT id="206"><B>--next</B><DD>
|
|
Start the next element in the policy specification. Can only be used with
|
|
<B>--strict</B>.
|
|
</DL>
|
|
<A NAME="lbBU"> </A>
|
|
<H3>quota</H3>
|
|
|
|
Implements network quotas by decrementing a byte counter with each
|
|
packet. The condition matches until the byte counter reaches zero. Behavior
|
|
is reversed with negation (i.e. the condition does not match until the
|
|
byte counter reaches zero).
|
|
<DL COMPACT>
|
|
<DT id="207">[<B>!</B>] <B>--quota</B> <I>bytes</I><DD>
|
|
The quota in bytes.
|
|
</DL>
|
|
<A NAME="lbBV"> </A>
|
|
<H3>rateest</H3>
|
|
|
|
The rate estimator can match on estimated rates as collected by the RATEEST
|
|
target. It supports matching on absolute bps/pps values, comparing two rate
|
|
estimators and matching on the difference between two rate estimators.
|
|
<P>
|
|
|
|
For a better understanding of the available options, these are all possible
|
|
combinations:
|
|
|
|
<DL COMPACT>
|
|
<DT id="208">•<DD>
|
|
<B>rateest</B> <I>operator</I> <B>rateest-bps</B>
|
|
<DT id="209">•<DD>
|
|
<B>rateest</B> <I>operator</I> <B>rateest-pps</B>
|
|
|
|
<DT id="210">•<DD>
|
|
(<B>rateest</B> minus <B>rateest-bps1</B>) <I>operator</I> <B>rateest-bps2</B>
|
|
<DT id="211">•<DD>
|
|
(<B>rateest</B> minus <B>rateest-pps1</B>) <I>operator</I> <B>rateest-pps2</B>
|
|
|
|
<DT id="212">•<DD>
|
|
<B>rateest1</B> <I>operator</I> <B>rateest2</B> <B>rateest-bps</B>(without rate!)
|
|
<DT id="213">•<DD>
|
|
<B>rateest1</B> <I>operator</I> <B>rateest2</B> <B>rateest-pps</B>(without rate!)
|
|
|
|
<DT id="214">•<DD>
|
|
(<B>rateest1</B> minus <B>rateest-bps1</B>) <I>operator</I>
|
|
(<B>rateest2</B> minus <B>rateest-bps2</B>)
|
|
<DT id="215">•<DD>
|
|
(<B>rateest1</B> minus <B>rateest-pps1</B>) <I>operator</I>
|
|
(<B>rateest2</B> minus <B>rateest-pps2</B>)
|
|
<DT id="216"><B>--rateest-delta</B><DD>
|
|
For each estimator (either absolute or relative mode), calculate the difference
|
|
between the estimator-determined flow rate and the static value chosen with the
|
|
BPS/PPS options. If the flow rate is higher than the specified BPS/PPS, 0 will
|
|
be used instead of a negative value. In other words, "max(0, rateest#_rate -
|
|
rateest#_bps)" is used.
|
|
<DT id="217">[<B>!</B>] <B>--rateest-lt</B><DD>
|
|
Match if rate is less than given rate/estimator.
|
|
<DT id="218">[<B>!</B>] <B>--rateest-gt</B><DD>
|
|
Match if rate is greater than given rate/estimator.
|
|
<DT id="219">[<B>!</B>] <B>--rateest-eq</B><DD>
|
|
Match if rate is equal to given rate/estimator.
|
|
</DL>
|
|
<P>
|
|
|
|
In the so-called "absolute mode", only one rate estimator is used and compared
|
|
against a static value, while in "relative mode", two rate estimators are
|
|
compared against another.
|
|
<DL COMPACT>
|
|
<DT id="220"><B>--rateest</B> <I>name</I><DD>
|
|
Name of the one rate estimator for absolute mode.
|
|
<DT id="221"><B>--rateest1</B> <I>name</I><DD>
|
|
<DT id="222"><B>--rateest2</B> <I>name</I><DD>
|
|
The names of the two rate estimators for relative mode.
|
|
<DT id="223"><B>--rateest-bps</B> [<I>value</I>]<DD>
|
|
<DT id="224"><B>--rateest-pps</B> [<I>value</I>]<DD>
|
|
<DT id="225"><B>--rateest-bps1</B> [<I>value</I>]<DD>
|
|
<DT id="226"><B>--rateest-bps2</B> [<I>value</I>]<DD>
|
|
<DT id="227"><B>--rateest-pps1</B> [<I>value</I>]<DD>
|
|
<DT id="228"><B>--rateest-pps2</B> [<I>value</I>]<DD>
|
|
Compare the estimator(s) by bytes or packets per second, and compare against
|
|
the chosen value. See the above bullet list for which option is to be used in
|
|
which case. A unit suffix may be used - available ones are: bit, [kmgt]bit,
|
|
[KMGT]ibit, Bps, [KMGT]Bps, [KMGT]iBps.
|
|
</DL>
|
|
<P>
|
|
|
|
Example: This is what can be used to route outgoing data connections from an
|
|
FTP server over two lines based on the available bandwidth at the time the data
|
|
connection was started:
|
|
<P>
|
|
|
|
# Estimate outgoing rates
|
|
<P>
|
|
|
|
iptables -t mangle -A POSTROUTING -o eth0 -j RATEEST --rateest-name eth0
|
|
--rateest-interval 250ms --rateest-ewma 0.5s
|
|
<P>
|
|
|
|
iptables -t mangle -A POSTROUTING -o ppp0 -j RATEEST --rateest-name ppp0
|
|
--rateest-interval 250ms --rateest-ewma 0.5s
|
|
<P>
|
|
|
|
# Mark based on available bandwidth
|
|
<P>
|
|
|
|
iptables -t mangle -A balance -m conntrack --ctstate NEW -m helper --helper ftp
|
|
-m rateest --rateest-delta --rateest1 eth0 --rateest-bps1 2.5mbit --rateest-gt
|
|
--rateest2 ppp0 --rateest-bps2 2mbit -j CONNMARK --set-mark 1
|
|
<P>
|
|
|
|
iptables -t mangle -A balance -m conntrack --ctstate NEW -m helper --helper ftp
|
|
-m rateest --rateest-delta --rateest1 ppp0 --rateest-bps1 2mbit --rateest-gt
|
|
--rateest2 eth0 --rateest-bps2 2.5mbit -j CONNMARK --set-mark 2
|
|
<P>
|
|
|
|
iptables -t mangle -A balance -j CONNMARK --restore-mark
|
|
<A NAME="lbBW"> </A>
|
|
<H3>realm (IPv4-specific)</H3>
|
|
|
|
This matches the routing realm. Routing realms are used in complex routing
|
|
setups involving dynamic routing protocols like BGP.
|
|
<DL COMPACT>
|
|
<DT id="229">[<B>!</B>] <B>--realm</B> <I>value</I>[<B>/</B><I>mask</I>]<DD>
|
|
Matches a given realm number (and optionally mask). If not a number, value
|
|
can be a named realm from /etc/iproute2/rt_realms (mask can not be used in
|
|
that case).
|
|
Both value and mask are four byte unsigned integers and may be specified in
|
|
decimal, hex (by prefixing with "0x") or octal (if a leading zero is given).
|
|
</DL>
|
|
<A NAME="lbBX"> </A>
|
|
<H3>recent</H3>
|
|
|
|
Allows you to dynamically create a list of IP addresses and then match against
|
|
that list in a few different ways.
|
|
<P>
|
|
|
|
For example, you can create a "badguy" list out of people attempting to connect
|
|
to port 139 on your firewall and then DROP all future packets from them without
|
|
considering them.
|
|
<P>
|
|
|
|
<B>--set</B>, <B>--rcheck</B>, <B>--update</B> and <B>--remove</B> are
|
|
mutually exclusive.
|
|
<DL COMPACT>
|
|
<DT id="230"><B>--name</B> <I>name</I><DD>
|
|
Specify the list to use for the commands. If no name is given then
|
|
<B>DEFAULT</B> will be used.
|
|
<DT id="231">[<B>!</B>] <B>--set</B><DD>
|
|
This will add the source address of the packet to the list. If the source
|
|
address is already in the list, this will update the existing entry. This will
|
|
always return success (or failure if <B>!</B> is passed in).
|
|
<DT id="232"><B>--rsource</B><DD>
|
|
Match/save the source address of each packet in the recent list table. This
|
|
is the default.
|
|
<DT id="233"><B>--rdest</B><DD>
|
|
Match/save the destination address of each packet in the recent list table.
|
|
<DT id="234"><B>--mask</B> <I>netmask</I><DD>
|
|
Netmask that will be applied to this recent list.
|
|
<DT id="235">[<B>!</B>] <B>--rcheck</B><DD>
|
|
Check if the source address of the packet is currently in the list.
|
|
<DT id="236">[<B>!</B>] <B>--update</B><DD>
|
|
Like <B>--rcheck</B>, except it will update the "last seen" timestamp if it
|
|
matches.
|
|
<DT id="237">[<B>!</B>] <B>--remove</B><DD>
|
|
Check if the source address of the packet is currently in the list and if so
|
|
that address will be removed from the list and the rule will return true. If
|
|
the address is not found, false is returned.
|
|
<DT id="238"><B>--seconds</B> <I>seconds</I><DD>
|
|
This option must be used in conjunction with one of <B>--rcheck</B> or
|
|
<B>--update</B>. When used, this will narrow the match to only happen when the
|
|
address is in the list and was seen within the last given number of seconds.
|
|
<DT id="239"><B>--reap</B><DD>
|
|
This option can only be used in conjunction with <B>--seconds</B>.
|
|
When used, this will cause entries older than the last given number of seconds
|
|
to be purged.
|
|
<DT id="240"><B>--hitcount</B> <I>hits</I><DD>
|
|
This option must be used in conjunction with one of <B>--rcheck</B> or
|
|
<B>--update</B>. When used, this will narrow the match to only happen when the
|
|
address is in the list and packets had been received greater than or equal to
|
|
the given value. This option may be used along with <B>--seconds</B> to create
|
|
an even narrower match requiring a certain number of hits within a specific
|
|
time frame. The maximum value for the hitcount parameter is given by the
|
|
"ip_pkt_list_tot" parameter of the xt_recent kernel module. Exceeding this
|
|
value on the command line will cause the rule to be rejected.
|
|
<DT id="241"><B>--rttl</B><DD>
|
|
This option may only be used in conjunction with one of <B>--rcheck</B> or
|
|
<B>--update</B>. When used, this will narrow the match to only happen when the
|
|
address is in the list and the TTL of the current packet matches that of the
|
|
packet which hit the <B>--set</B> rule. This may be useful if you have problems
|
|
with people faking their source address in order to DoS you via this module by
|
|
disallowing others access to your site by sending bogus packets to you.
|
|
</DL>
|
|
<P>
|
|
|
|
Examples:
|
|
<DL COMPACT>
|
|
<DT id="242"><DD>
|
|
iptables -A FORWARD -m recent --name badguy --rcheck --seconds 60 -j DROP
|
|
<DT id="243"><DD>
|
|
iptables -A FORWARD -p tcp -i eth0 --dport 139 -m recent --name badguy --set -j DROP
|
|
</DL>
|
|
<P>
|
|
|
|
<B>/proc/net/xt_recent/*</B> are the current lists of addresses and information
|
|
about each entry of each list.
|
|
<P>
|
|
|
|
Each file in <B>/proc/net/xt_recent/</B> can be read from to see the current
|
|
list or written two using the following commands to modify the list:
|
|
<DL COMPACT>
|
|
<DT id="244"><B>echo +</B><I>addr</I><B> >/proc/net/xt_recent/DEFAULT</B><DD>
|
|
to add <I>addr</I> to the DEFAULT list
|
|
<DT id="245"><B>echo -</B><I>addr</I><B> >/proc/net/xt_recent/DEFAULT</B><DD>
|
|
to remove <I>addr</I> from the DEFAULT list
|
|
<DT id="246"><B>echo / >/proc/net/xt_recent/DEFAULT</B><DD>
|
|
to flush the DEFAULT list (remove all entries).
|
|
</DL>
|
|
<P>
|
|
|
|
The module itself accepts parameters, defaults shown:
|
|
<DL COMPACT>
|
|
<DT id="247"><B>ip_list_tot</B>=<I>100</I><DD>
|
|
Number of addresses remembered per table.
|
|
<DT id="248"><B>ip_pkt_list_tot</B>=<I>20</I><DD>
|
|
Number of packets per address remembered.
|
|
<DT id="249"><B>ip_list_hash_size</B>=<I>0</I><DD>
|
|
Hash table size. 0 means to calculate it based on ip_list_tot, default: 512.
|
|
<DT id="250"><B>ip_list_perms</B>=<I>0644</I><DD>
|
|
Permissions for /proc/net/xt_recent/* files.
|
|
<DT id="251"><B>ip_list_uid</B>=<I>0</I><DD>
|
|
Numerical UID for ownership of /proc/net/xt_recent/* files.
|
|
<DT id="252"><B>ip_list_gid</B>=<I>0</I><DD>
|
|
Numerical GID for ownership of /proc/net/xt_recent/* files.
|
|
</DL>
|
|
<A NAME="lbBY"> </A>
|
|
<H3>rpfilter</H3>
|
|
|
|
Performs a reverse path filter test on a packet.
|
|
If a reply to the packet would be sent via the same interface
|
|
that the packet arrived on, the packet will match.
|
|
Note that, unlike the in-kernel rp_filter, packets protected
|
|
by IPSec are not treated specially. Combine this match with
|
|
the policy match if you want this.
|
|
Also, packets arriving via the loopback interface are always permitted.
|
|
This match can only be used in the PREROUTING chain of the raw or mangle table.
|
|
<DL COMPACT>
|
|
<DT id="253"><B>--loose</B><DD>
|
|
Used to specify that the reverse path filter test should match
|
|
even if the selected output device is not the expected one.
|
|
<DT id="254"><B>--validmark</B><DD>
|
|
Also use the packets' nfmark value when performing the reverse path route lookup.
|
|
<DT id="255"><B>--accept-local</B><DD>
|
|
This will permit packets arriving from the network with a source address that is also
|
|
assigned to the local machine.
|
|
<DT id="256"><B>--invert</B><DD>
|
|
This will invert the sense of the match. Instead of matching packets that passed the
|
|
reverse path filter test, match those that have failed it.
|
|
</DL>
|
|
<P>
|
|
|
|
Example to log and drop packets failing the reverse path filter test:
|
|
<P>
|
|
iptables -t raw -N RPFILTER
|
|
<P>
|
|
iptables -t raw -A RPFILTER -m rpfilter -j RETURN
|
|
<P>
|
|
iptables -t raw -A RPFILTER -m limit --limit 10/minute -j NFLOG --nflog-prefix "rpfilter drop"
|
|
<P>
|
|
iptables -t raw -A RPFILTER -j DROP
|
|
<P>
|
|
iptables -t raw -A PREROUTING -j RPFILTER
|
|
<P>
|
|
Example to drop failed packets, without logging:
|
|
<P>
|
|
iptables -t raw -A RPFILTER -m rpfilter --invert -j DROP
|
|
<A NAME="lbBZ"> </A>
|
|
<H3>rt (IPv6-specific)</H3>
|
|
|
|
Match on IPv6 routing header
|
|
<DL COMPACT>
|
|
<DT id="257">[<B>!</B>] <B>--rt-type</B> <I>type</I><DD>
|
|
Match the type (numeric).
|
|
<DT id="258">[<B>!</B>] <B>--rt-segsleft</B> <I>num</I>[<B>:</B><I>num</I>]<DD>
|
|
Match the `segments left' field (range).
|
|
<DT id="259">[<B>!</B>] <B>--rt-len</B> <I>length</I><DD>
|
|
Match the length of this header.
|
|
<DT id="260"><B>--rt-0-res</B><DD>
|
|
Match the reserved field, too (type=0)
|
|
<DT id="261"><B>--rt-0-addrs</B> <I>addr</I>[<B>,</B><I>addr</I>...]<DD>
|
|
Match type=0 addresses (list).
|
|
<DT id="262"><B>--rt-0-not-strict</B><DD>
|
|
List of type=0 addresses is not a strict list.
|
|
</DL>
|
|
<A NAME="lbCA"> </A>
|
|
<H3>sctp</H3>
|
|
|
|
This module matches Stream Control Transmission Protocol headers.
|
|
<DL COMPACT>
|
|
<DT id="263">[<B>!</B>] <B>--source-port</B>,<B>--sport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
<DT id="264">[<B>!</B>] <B>--destination-port</B>,<B>--dport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
<DT id="265">[<B>!</B>] <B>--chunk-types</B> {<B>all</B>|<B>any</B>|<B>only</B>} <I>chunktype</I>[<B>:</B><I>flags</I>] [...]<DD>
|
|
The flag letter in upper case indicates that the flag is to match if set,
|
|
in the lower case indicates to match if unset.
|
|
<P>
|
|
Chunk types: DATA INIT INIT_ACK SACK HEARTBEAT HEARTBEAT_ACK ABORT SHUTDOWN SHUTDOWN_ACK ERROR COOKIE_ECHO COOKIE_ACK ECN_ECNE ECN_CWR SHUTDOWN_COMPLETE ASCONF ASCONF_ACK FORWARD_TSN
|
|
<P>
|
|
chunk type available flags
|
|
<BR>
|
|
|
|
DATA I U B E i u b e
|
|
<BR>
|
|
|
|
ABORT T t
|
|
<BR>
|
|
|
|
SHUTDOWN_COMPLETE T t
|
|
<P>
|
|
(lowercase means flag should be "off", uppercase means "on")
|
|
</DL>
|
|
<P>
|
|
|
|
Examples:
|
|
<P>
|
|
iptables -A INPUT -p sctp --dport 80 -j DROP
|
|
<P>
|
|
iptables -A INPUT -p sctp --chunk-types any DATA,INIT -j DROP
|
|
<P>
|
|
iptables -A INPUT -p sctp --chunk-types any DATA:Be -j ACCEPT
|
|
<A NAME="lbCB"> </A>
|
|
<H3>set</H3>
|
|
|
|
This module matches IP sets which can be defined by <A HREF="/cgi-bin/man/man2html?8+ipset">ipset</A>(8).
|
|
<DL COMPACT>
|
|
<DT id="266">[<B>!</B>] <B>--match-set</B> <I>setname</I> <I>flag</I>[<B>,</B><I>flag</I>]...<DD>
|
|
where flags are the comma separated list of
|
|
<B>src</B>
|
|
|
|
and/or
|
|
<B>dst</B>
|
|
|
|
specifications and there can be no more than six of them. Hence the command
|
|
<DT id="267"><DD>
|
|
<BR> iptables -A FORWARD -m set --match-set test src,dst
|
|
<DT id="268"><DD>
|
|
will match packets, for which (if the set type is ipportmap) the source
|
|
address and destination port pair can be found in the specified set. If
|
|
the set type of the specified set is single dimension (for example ipmap),
|
|
then the command will match packets for which the source address can be
|
|
found in the specified set.
|
|
<DT id="269"><B>--return-nomatch</B><DD>
|
|
If the <B>--return-nomatch</B> option is specified and the set type
|
|
supports the <B>nomatch</B> flag, then the matching is reversed: a match
|
|
with an element flagged with <B>nomatch</B> returns <B>true</B>, while a
|
|
match with a plain element returns <B>false</B>.
|
|
<DT id="270"><B>!</B> <B>--update-counters</B><DD>
|
|
If the <B>--update-counters</B> flag is negated, then the packet and
|
|
byte counters of the matching element in the set won't be updated. Default
|
|
the packet and byte counters are updated.
|
|
<DT id="271"><B>!</B> <B>--update-subcounters</B><DD>
|
|
If the <B>--update-subcounters</B> flag is negated, then the packet and
|
|
byte counters of the matching element in the member set of a list type of
|
|
set won't be updated. Default the packet and byte counters are updated.
|
|
<DT id="272">[<B>!</B>] <B>--packets-eq</B> <I>value</I><DD>
|
|
If the packet is matched an element in the set, match only if the
|
|
packet counter of the element matches the given value too.
|
|
<DT id="273"><B>--packets-lt</B> <I>value</I><DD>
|
|
If the packet is matched an element in the set, match only if the
|
|
packet counter of the element is less than the given value as well.
|
|
<DT id="274"><B>--packets-gt</B> <I>value</I><DD>
|
|
If the packet is matched an element in the set, match only if the
|
|
packet counter of the element is greater than the given value as well.
|
|
<DT id="275">[<B>!</B>] <B>--bytes-eq</B> <I>value</I><DD>
|
|
If the packet is matched an element in the set, match only if the
|
|
byte counter of the element matches the given value too.
|
|
<DT id="276"><B>--bytes-lt</B> <I>value</I><DD>
|
|
If the packet is matched an element in the set, match only if the
|
|
byte counter of the element is less than the given value as well.
|
|
<DT id="277"><B>--bytes-gt</B> <I>value</I><DD>
|
|
If the packet is matched an element in the set, match only if the
|
|
byte counter of the element is greater than the given value as well.
|
|
</DL>
|
|
<P>
|
|
|
|
The packet and byte counters related options and flags are ignored
|
|
when the set was defined without counter support.
|
|
<P>
|
|
|
|
The option <B>--match-set</B> can be replaced by <B>--set</B> if that does
|
|
not clash with an option of other extensions.
|
|
<P>
|
|
|
|
Use of -m set requires that ipset kernel support is provided, which, for
|
|
standard kernels, is the case since Linux 2.6.39.
|
|
<A NAME="lbCC"> </A>
|
|
<H3>socket</H3>
|
|
|
|
This matches if an open TCP/UDP socket can be found by doing a socket lookup on the
|
|
packet. It matches if there is an established or non-zero bound listening
|
|
socket (possibly with a non-local address). The lookup is performed using
|
|
the <B>packet</B> tuple of TCP/UDP packets, or the original TCP/UDP header
|
|
<B>embedded</B> in an ICMP/ICPMv6 error packet.
|
|
<DL COMPACT>
|
|
<DT id="278"><B>--transparent</B><DD>
|
|
Ignore non-transparent sockets.
|
|
<DT id="279"><B>--nowildcard</B><DD>
|
|
Do not ignore sockets bound to 'any' address.
|
|
The socket match won't accept zero-bound listeners by default, since
|
|
then local services could intercept traffic that would otherwise be forwarded.
|
|
This option therefore has security implications when used to match traffic being
|
|
forwarded to redirect such packets to local machine with policy routing.
|
|
When using the socket match to implement fully transparent
|
|
proxies bound to non-local addresses it is recommended to use the --transparent
|
|
option instead.
|
|
</DL>
|
|
<P>
|
|
|
|
Example (assuming packets with mark 1 are delivered locally):
|
|
<DL COMPACT>
|
|
<DT id="280"><DD>
|
|
-t mangle -A PREROUTING -m socket --transparent -j MARK --set-mark 1
|
|
<DT id="281"><B>--restore-skmark</B><DD>
|
|
Set the packet mark to the matching socket's mark. Can be combined with the
|
|
<B>--transparent</B> and <B>--nowildcard</B> options to restrict the sockets
|
|
to be matched when restoring the packet mark.
|
|
</DL>
|
|
<P>
|
|
|
|
Example: An application opens 2 transparent (<B>IP_TRANSPARENT</B>) sockets and
|
|
sets a mark on them with <B>SO_MARK</B> socket option. We can filter matching packets:
|
|
<DL COMPACT>
|
|
<DT id="282"><DD>
|
|
-t mangle -I PREROUTING -m socket --transparent --restore-skmark -j action
|
|
<DT id="283"><DD>
|
|
-t mangle -A action -m mark --mark 10 -j action2
|
|
<DT id="284"><DD>
|
|
-t mangle -A action -m mark --mark 11 -j action3
|
|
</DL>
|
|
<A NAME="lbCD"> </A>
|
|
<H3>state</H3>
|
|
|
|
The "state" extension is a subset of the "conntrack" module.
|
|
"state" allows access to the connection tracking state for this packet.
|
|
<DL COMPACT>
|
|
<DT id="285">[<B>!</B>] <B>--state</B> <I>state</I><DD>
|
|
Where state is a comma separated list of the connection states to match. Only a
|
|
subset of the states unterstood by "conntrack" are recognized: <B>INVALID</B>,
|
|
<B>ESTABLISHED</B>, <B>NEW</B>, <B>RELATED</B> or <B>UNTRACKED</B>. For their
|
|
description, see the "conntrack" heading in this manpage.
|
|
</DL>
|
|
<A NAME="lbCE"> </A>
|
|
<H3>statistic</H3>
|
|
|
|
This module matches packets based on some statistic condition.
|
|
It supports two distinct modes settable with the
|
|
<B>--mode</B>
|
|
option.
|
|
<P>
|
|
|
|
Supported options:
|
|
<DL COMPACT>
|
|
<DT id="286"><B>--mode</B> <I>mode</I><DD>
|
|
Set the matching mode of the matching rule, supported modes are
|
|
<B>random</B>
|
|
|
|
and
|
|
<B>nth. </B>
|
|
|
|
<DT id="287">[<B>!</B>] <B>--probability</B> <I>p</I><DD>
|
|
Set the probability for a packet to be randomly matched. It only works with the
|
|
<B>random</B> mode. <I>p</I> must be within 0.0 and 1.0. The supported
|
|
granularity is in 1/2147483648th increments.
|
|
<DT id="288">[<B>!</B>] <B>--every</B> <I>n</I><DD>
|
|
Match one packet every nth packet. It works only with the
|
|
<B>nth</B>
|
|
|
|
mode (see also the
|
|
<B>--packet</B>
|
|
option).
|
|
<DT id="289"><B>--packet</B> <I>p</I><DD>
|
|
Set the initial counter value (0 <= p <= n-1, default 0) for the
|
|
<B>nth </B>
|
|
|
|
mode.
|
|
</DL>
|
|
<A NAME="lbCF"> </A>
|
|
<H3>string</H3>
|
|
|
|
This modules matches a given string by using some pattern matching strategy. It requires a linux kernel >= 2.6.14.
|
|
<DL COMPACT>
|
|
<DT id="290"><B>--algo</B> {<B>bm</B>|<B>kmp</B>}<DD>
|
|
Select the pattern matching strategy. (bm = Boyer-Moore, kmp = Knuth-Pratt-Morris)
|
|
<DT id="291"><B>--from</B> <I>offset</I><DD>
|
|
Set the offset from which it starts looking for any matching. If not passed, default is 0.
|
|
<DT id="292"><B>--to</B> <I>offset</I><DD>
|
|
Set the offset up to which should be scanned. That is, byte <I>offset</I>-1
|
|
(counting from 0) is the last one that is scanned.
|
|
If not passed, default is the packet size.
|
|
<DT id="293">[<B>!</B>] <B>--string</B> <I>pattern</I><DD>
|
|
Matches the given pattern.
|
|
<DT id="294">[<B>!</B>] <B>--hex-string</B> <I>pattern</I><DD>
|
|
Matches the given pattern in hex notation.
|
|
<DT id="295"><B>--icase</B><DD>
|
|
Ignore case when searching.
|
|
<DT id="296">Examples:<DD>
|
|
<DT id="297"><DD>
|
|
# The string pattern can be used for simple text characters.
|
|
<BR>
|
|
|
|
iptables -A INPUT -p tcp --dport 80 -m string --algo bm --string 'GET /index.html' -j LOG
|
|
<DT id="298"><DD>
|
|
# The hex string pattern can be used for non-printable characters, like |0D 0A| or |0D0A|.
|
|
<BR>
|
|
|
|
iptables -p udp --dport 53 -m string --algo bm --from 40 --to 57 --hex-string '|03|www|09|netfilter|03|org|00|'
|
|
</DL>
|
|
<A NAME="lbCG"> </A>
|
|
<H3>tcp</H3>
|
|
|
|
These extensions can be used if `--protocol tcp' is specified. It
|
|
provides the following options:
|
|
<DL COMPACT>
|
|
<DT id="299">[<B>!</B>] <B>--source-port</B>,<B>--sport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
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 <I>first</I><B>:</B><I>last</I>.
|
|
If the first port is omitted, "0" is assumed; if the last is omitted,
|
|
"65535" is assumed.
|
|
The flag
|
|
<B>--sport</B>
|
|
is a convenient alias for this option.
|
|
<DT id="300">[<B>!</B>] <B>--destination-port</B>,<B>--dport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
Destination port or port range specification. The flag
|
|
<B>--dport</B>
|
|
is a convenient alias for this option.
|
|
<DT id="301">[<B>!</B>] <B>--tcp-flags</B> <I>mask</I> <I>comp</I><DD>
|
|
Match when the TCP flags are as specified. The first argument <I>mask</I> is the
|
|
flags which we should examine, written as a comma-separated list, and
|
|
the second argument <I>comp</I> is a comma-separated list of flags which must be
|
|
set. Flags are:
|
|
<B>SYN ACK FIN RST URG PSH ALL NONE</B>.
|
|
|
|
Hence the command
|
|
<PRE>
|
|
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST SYN
|
|
</PRE>
|
|
|
|
will only match packets with the SYN flag set, and the ACK, FIN and
|
|
RST flags unset.
|
|
<DT id="302">[<B>!</B>] <B>--syn</B><DD>
|
|
Only match TCP packets with the SYN bit set and the ACK,RST 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 <B>--tcp-flags SYN,RST,ACK,FIN SYN</B>.
|
|
If the "!" flag precedes the "--syn", the sense of the
|
|
option is inverted.
|
|
<DT id="303">[<B>!</B>] <B>--tcp-option</B> <I>number</I><DD>
|
|
Match if TCP option set.
|
|
</DL>
|
|
<A NAME="lbCH"> </A>
|
|
<H3>tcpmss</H3>
|
|
|
|
This matches the TCP MSS (maximum segment size) field of the TCP header. You can only use this on TCP SYN or SYN/ACK packets, since the MSS is only negotiated during the TCP handshake at connection startup time.
|
|
<DL COMPACT>
|
|
<DT id="304">[<B>!</B>] <B>--mss</B> <I>value</I>[<B>:</B><I>value</I>]<DD>
|
|
Match a given TCP MSS value or range. If a range is given, the second <I>value</I> must be greater than or equal to the first <I>value</I>.
|
|
</DL>
|
|
<A NAME="lbCI"> </A>
|
|
<H3>time</H3>
|
|
|
|
This matches if the packet arrival time/date is within a given range. All
|
|
options are optional, but are ANDed when specified. All times are interpreted
|
|
as UTC by default.
|
|
<DL COMPACT>
|
|
<DT id="305"><B>--datestart</B> <I>YYYY</I>[<B>-</B><I>MM</I>[<B>-</B><I>DD</I>[<B>T</B><I>hh</I>[<B>:</B><I>mm</I>[<B>:</B><I>ss</I>]]]]]<DD>
|
|
<DT id="306"><B>--datestop</B> <I>YYYY</I>[<B>-</B><I>MM</I>[<B>-</B><I>DD</I>[<B>T</B><I>hh</I>[<B>:</B><I>mm</I>[<B>:</B><I>ss</I>]]]]]<DD>
|
|
Only match during the given time, which must be in ISO 8601 "T" notation.
|
|
The possible time range is 1970-01-01T00:00:00 to 2038-01-19T04:17:07.
|
|
<DT id="307"><DD>
|
|
If --datestart or --datestop are not specified, it will default to 1970-01-01
|
|
and 2038-01-19, respectively.
|
|
<DT id="308"><B>--timestart</B> <I>hh</I><B>:</B><I>mm</I>[<B>:</B><I>ss</I>]<DD>
|
|
<DT id="309"><B>--timestop</B> <I>hh</I><B>:</B><I>mm</I>[<B>:</B><I>ss</I>]<DD>
|
|
Only match during the given daytime. The possible time range is 00:00:00 to
|
|
23:59:59. Leading zeroes are allowed (e.g. "06:03") and correctly interpreted
|
|
as base-10.
|
|
<DT id="310">[<B>!</B>] <B>--monthdays</B> <I>day</I>[<B>,</B><I>day</I>...]<DD>
|
|
Only match on the given days of the month. Possible values are <B>1</B>
|
|
to <B>31</B>. Note that specifying <B>31</B> will of course not match
|
|
on months which do not have a 31st day; the same goes for 28- or 29-day
|
|
February.
|
|
<DT id="311">[<B>!</B>] <B>--weekdays</B> <I>day</I>[<B>,</B><I>day</I>...]<DD>
|
|
Only match on the given weekdays. Possible values are <B>Mon</B>, <B>Tue</B>,
|
|
<B>Wed</B>, <B>Thu</B>, <B>Fri</B>, <B>Sat</B>, <B>Sun</B>, or values from <B>1</B>
|
|
to <B>7</B>, respectively. You may also use two-character variants (<B>Mo</B>,
|
|
<B>Tu</B>, etc.).
|
|
<DT id="312"><B>--contiguous</B><DD>
|
|
When <B>--timestop</B> is smaller than <B>--timestart</B> value, match
|
|
this as a single time period instead distinct intervals. See EXAMPLES.
|
|
<DT id="313"><B>--kerneltz</B><DD>
|
|
Use the kernel timezone instead of UTC to determine whether a packet meets the
|
|
time regulations.
|
|
</DL>
|
|
<P>
|
|
|
|
About kernel timezones: Linux keeps the system time in UTC, and always does so.
|
|
On boot, system time is initialized from a referential time source. Where this
|
|
time source has no timezone information, such as the x86 CMOS RTC, UTC will be
|
|
assumed. If the time source is however not in UTC, userspace should provide the
|
|
correct system time and timezone to the kernel once it has the information.
|
|
<P>
|
|
|
|
Local time is a feature on top of the (timezone independent) system time. Each
|
|
process has its own idea of local time, specified via the TZ environment
|
|
variable. The kernel also has its own timezone offset variable. The TZ
|
|
userspace environment variable specifies how the UTC-based system time is
|
|
displayed, e.g. when you run <A HREF="/cgi-bin/man/man2html?1+date">date</A>(1), or what you see on your desktop clock.
|
|
The TZ string may resolve to different offsets at different dates, which is
|
|
what enables the automatic time-jumping in userspace. when DST changes. The
|
|
kernel's timezone offset variable is used when it has to convert between
|
|
non-UTC sources, such as FAT filesystems, to UTC (since the latter is what the
|
|
rest of the system uses).
|
|
<P>
|
|
|
|
The caveat with the kernel timezone is that Linux distributions may ignore to
|
|
set the kernel timezone, and instead only set the system time. Even if a
|
|
particular distribution does set the timezone at boot, it is usually does not
|
|
keep the kernel timezone offset - which is what changes on DST - up to date.
|
|
ntpd will not touch the kernel timezone, so running it will not resolve the
|
|
issue. As such, one may encounter a timezone that is always +0000, or one that
|
|
is wrong half of the time of the year. As such, <B>using --kerneltz is highly
|
|
discouraged.</B>
|
|
<P>
|
|
|
|
EXAMPLES. To match on weekends, use:
|
|
<DL COMPACT>
|
|
<DT id="314"><DD>
|
|
-m time --weekdays Sa,Su
|
|
</DL>
|
|
<P>
|
|
|
|
Or, to match (once) on a national holiday block:
|
|
<DL COMPACT>
|
|
<DT id="315"><DD>
|
|
-m time --datestart 2007-12-24 --datestop 2007-12-27
|
|
</DL>
|
|
<P>
|
|
|
|
Since the stop time is actually inclusive, you would need the following stop
|
|
time to not match the first second of the new day:
|
|
<DL COMPACT>
|
|
<DT id="316"><DD>
|
|
-m time --datestart 2007-01-01T17:00 --datestop 2007-01-01T23:59:59
|
|
</DL>
|
|
<P>
|
|
|
|
During lunch hour:
|
|
<DL COMPACT>
|
|
<DT id="317"><DD>
|
|
-m time --timestart 12:30 --timestop 13:30
|
|
</DL>
|
|
<P>
|
|
|
|
The fourth Friday in the month:
|
|
<DL COMPACT>
|
|
<DT id="318"><DD>
|
|
-m time --weekdays Fr --monthdays 22,23,24,25,26,27,28
|
|
</DL>
|
|
<P>
|
|
|
|
(Note that this exploits a certain mathematical property. It is not possible to
|
|
say "fourth Thursday OR fourth Friday" in one rule. It is possible with
|
|
multiple rules, though.)
|
|
<P>
|
|
|
|
Matching across days might not do what is expected. For instance,
|
|
<DL COMPACT>
|
|
<DT id="319"><DD>
|
|
-m time --weekdays Mo --timestart 23:00 --timestop 01:00
|
|
Will match Monday, for one hour from midnight to 1 a.m., and then
|
|
again for another hour from 23:00 onwards. If this is unwanted, e.g. if you
|
|
would like 'match for two hours from Montay 23:00 onwards' you need to also specify
|
|
the --contiguous option in the example above.
|
|
</DL>
|
|
<A NAME="lbCJ"> </A>
|
|
<H3>tos</H3>
|
|
|
|
This module matches the 8-bit Type of Service field in the IPv4 header (i.e.
|
|
including the "Precedence" bits) or the (also 8-bit) Priority field in the IPv6
|
|
header.
|
|
<DL COMPACT>
|
|
<DT id="320">[<B>!</B>] <B>--tos</B> <I>value</I>[<B>/</B><I>mask</I>]<DD>
|
|
Matches packets with the given TOS mark value. If a mask is specified, it is
|
|
logically ANDed with the TOS mark before the comparison.
|
|
<DT id="321">[<B>!</B>] <B>--tos</B> <I>symbol</I><DD>
|
|
You can specify a symbolic name when using the tos match for IPv4. The list of
|
|
recognized TOS names can be obtained by calling iptables with <B>-m tos -h</B>.
|
|
Note that this implies a mask of 0x3F, i.e. all but the ECN bits.
|
|
</DL>
|
|
<A NAME="lbCK"> </A>
|
|
<H3>ttl (IPv4-specific)</H3>
|
|
|
|
This module matches the time to live field in the IP header.
|
|
<DL COMPACT>
|
|
<DT id="322">[<B>!</B>] <B>--ttl-eq</B> <I>ttl</I><DD>
|
|
Matches the given TTL value.
|
|
<DT id="323"><B>--ttl-gt</B> <I>ttl</I><DD>
|
|
Matches if TTL is greater than the given TTL value.
|
|
<DT id="324"><B>--ttl-lt</B> <I>ttl</I><DD>
|
|
Matches if TTL is less than the given TTL value.
|
|
</DL>
|
|
<A NAME="lbCL"> </A>
|
|
<H3>u32</H3>
|
|
|
|
U32 tests whether quantities of up to 4 bytes extracted from a packet have
|
|
specified values. The specification of what to extract is general enough to
|
|
find data at given offsets from tcp headers or payloads.
|
|
<DL COMPACT>
|
|
<DT id="325">[<B>!</B>] <B>--u32</B> <I>tests</I><DD>
|
|
The argument amounts to a program in a small language described below.
|
|
<DT id="326"><DD>
|
|
tests := location "=" value | tests "&&" location "=" value
|
|
<DT id="327"><DD>
|
|
value := range | value "," range
|
|
<DT id="328"><DD>
|
|
range := number | number ":" number
|
|
</DL>
|
|
<P>
|
|
|
|
a single number, <I>n</I>, is interpreted the same as <I>n:n</I>. <I>n:m</I> is
|
|
interpreted as the range of numbers <B>>=n</B> and <B><=m</B>.
|
|
<DL COMPACT>
|
|
<DT id="329"><DD>
|
|
location := number | location operator number
|
|
<DT id="330"><DD>
|
|
operator := "&" | "<<" | ">>" | "@"
|
|
</DL>
|
|
<P>
|
|
|
|
The operators <B>&</B>, <B><<</B>, <B>>></B> and <B>&&</B> mean the same as in C.
|
|
The <B>=</B> is really a set membership operator and the value syntax describes
|
|
a set. The <B>@</B> operator is what allows moving to the next header and is
|
|
described further below.
|
|
<P>
|
|
|
|
There are currently some artificial implementation limits on the size of the
|
|
tests:
|
|
<DL COMPACT>
|
|
<DT id="331"> *<DD>
|
|
no more than 10 of "<B>=</B>" (and 9 "<B>&&</B>"s) in the u32 argument
|
|
<DT id="332"> *<DD>
|
|
no more than 10 ranges (and 9 commas) per value
|
|
<DT id="333"> *<DD>
|
|
no more than 10 numbers (and 9 operators) per location
|
|
</DL>
|
|
<P>
|
|
|
|
To describe the meaning of location, imagine the following machine that
|
|
interprets it. There are three registers:
|
|
<DL COMPACT>
|
|
<DT id="334"><DD>
|
|
A is of type <B>char *</B>, initially the address of the IP header
|
|
<DT id="335"><DD>
|
|
B and C are unsigned 32 bit integers, initially zero
|
|
</DL>
|
|
<P>
|
|
|
|
The instructions are:
|
|
<DL COMPACT>
|
|
<DT id="336"><B>number</B>
|
|
|
|
<DD>
|
|
B = number;
|
|
<DT id="337"><DD>
|
|
C = (*(A+B)<<24) + (*(A+B+1)<<16) + (*(A+B+2)<<8) + *(A+B+3)
|
|
<DT id="338"><B>&number</B>
|
|
|
|
<DD>
|
|
C = C & number
|
|
<DT id="339"><B><< number</B>
|
|
|
|
<DD>
|
|
C = C << number
|
|
<DT id="340"><B>>> number</B>
|
|
|
|
<DD>
|
|
C = C >> number
|
|
<DT id="341"><B>@number</B>
|
|
|
|
<DD>
|
|
A = A + C; then do the instruction number
|
|
</DL>
|
|
<P>
|
|
|
|
Any access of memory outside [skb->data,skb->end] causes the match to fail.
|
|
Otherwise the result of the computation is the final value of C.
|
|
<P>
|
|
|
|
Whitespace is allowed but not required in the tests. However, the characters
|
|
that do occur there are likely to require shell quoting, so it is a good idea
|
|
to enclose the arguments in quotes.
|
|
<P>
|
|
|
|
Example:
|
|
<DL COMPACT>
|
|
<DT id="342"><DD>
|
|
match IP packets with total length >= 256
|
|
<DT id="343"><DD>
|
|
The IP header contains a total length field in bytes 2-3.
|
|
<DT id="344"><DD>
|
|
--u32 "<B>0 & 0xFFFF = 0x100:0xFFFF</B>"
|
|
<DT id="345"><DD>
|
|
read bytes 0-3
|
|
<DT id="346"><DD>
|
|
AND that with 0xFFFF (giving bytes 2-3), and test whether that is in the range
|
|
[0x100:0xFFFF]
|
|
</DL>
|
|
<P>
|
|
|
|
Example: (more realistic, hence more complicated)
|
|
<DL COMPACT>
|
|
<DT id="347"><DD>
|
|
match ICMP packets with icmp type 0
|
|
<DT id="348"><DD>
|
|
First test that it is an ICMP packet, true iff byte 9 (protocol) = 1
|
|
<DT id="349"><DD>
|
|
--u32 "<B>6 & 0xFF = 1 &&</B> ...
|
|
<DT id="350"><DD>
|
|
read bytes 6-9, use <B>&</B> to throw away bytes 6-8 and compare the result to
|
|
1. Next test that it is not a fragment. (If so, it might be part of such a
|
|
packet but we cannot always tell.) N.B.: This test is generally needed if you
|
|
want to match anything beyond the IP header. The last 6 bits of byte 6 and all
|
|
of byte 7 are 0 iff this is a complete packet (not a fragment). Alternatively,
|
|
you can allow first fragments by only testing the last 5 bits of byte 6.
|
|
<DT id="351"><DD>
|
|
<BR> ... <B>4 & 0x3FFF = 0 &&</B> ...
|
|
<DT id="352"><DD>
|
|
Last test: the first byte past the IP header (the type) is 0. This is where we
|
|
have to use the @syntax. The length of the IP header (IHL) in 32 bit words is
|
|
stored in the right half of byte 0 of the IP header itself.
|
|
<DT id="353"><DD>
|
|
<BR> ... <B>0 >> 22 & 0x3C @ 0 >> 24 = 0</B>"
|
|
<DT id="354"><DD>
|
|
The first 0 means read bytes 0-3, <B>>>22</B> means shift that 22 bits to the
|
|
right. Shifting 24 bits would give the first byte, so only 22 bits is four
|
|
times that plus a few more bits. <B>&3C</B> then eliminates the two extra bits
|
|
on the right and the first four bits of the first byte. For instance, if IHL=5,
|
|
then the IP header is 20 (4 x 5) bytes long. In this case, bytes 0-1 are (in
|
|
binary) xxxx0101 yyzzzzzz, <B>>>22</B> gives the 10 bit value xxxx0101yy and
|
|
<B>&3C</B> gives 010100. <B>@</B> means to use this number as a new offset into
|
|
the packet, and read four bytes starting from there. This is the first 4 bytes
|
|
of the ICMP payload, of which byte 0 is the ICMP type. Therefore, we simply
|
|
shift the value 24 to the right to throw out all but the first byte and compare
|
|
the result with 0.
|
|
</DL>
|
|
<P>
|
|
|
|
Example:
|
|
<DL COMPACT>
|
|
<DT id="355"><DD>
|
|
TCP payload bytes 8-12 is any of 1, 2, 5 or 8
|
|
<DT id="356"><DD>
|
|
First we test that the packet is a tcp packet (similar to ICMP).
|
|
<DT id="357"><DD>
|
|
--u32 "<B>6 & 0xFF = 6 &&</B> ...
|
|
<DT id="358"><DD>
|
|
Next, test that it is not a fragment (same as above).
|
|
<DT id="359"><DD>
|
|
<BR> ... <B>0 >> 22 & 0x3C @ 12 >> 26 & 0x3C @ 8 = 1,2,5,8</B>"
|
|
<DT id="360"><DD>
|
|
<B>0>>22&3C</B> as above computes the number of bytes in the IP header. <B>@</B>
|
|
makes this the new offset into the packet, which is the start of the TCP
|
|
header. The length of the TCP header (again in 32 bit words) is the left half
|
|
of byte 12 of the TCP header. The <B>12>>26&3C</B> computes this length in bytes
|
|
(similar to the IP header before). "@" makes this the new offset, which is the
|
|
start of the TCP payload. Finally, 8 reads bytes 8-12 of the payload and
|
|
<B>=</B> checks whether the result is any of 1, 2, 5 or 8.
|
|
</DL>
|
|
<A NAME="lbCM"> </A>
|
|
<H3>udp</H3>
|
|
|
|
These extensions can be used if `--protocol udp' is specified. It
|
|
provides the following options:
|
|
<DL COMPACT>
|
|
<DT id="361">[<B>!</B>] <B>--source-port</B>,<B>--sport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
Source port or port range specification.
|
|
See the description of the
|
|
<B>--source-port</B>
|
|
option of the TCP extension for details.
|
|
<DT id="362">[<B>!</B>] <B>--destination-port</B>,<B>--dport</B> <I>port</I>[<B>:</B><I>port</I>]<DD>
|
|
Destination port or port range specification.
|
|
See the description of the
|
|
<B>--destination-port</B>
|
|
option of the TCP extension for details.
|
|
</DL>
|
|
<A NAME="lbCN"> </A>
|
|
<H2>TARGET EXTENSIONS</H2>
|
|
|
|
iptables can use extended target modules: the following are included
|
|
in the standard distribution.
|
|
|
|
<A NAME="lbCO"> </A>
|
|
<H3>AUDIT</H3>
|
|
|
|
This target allows creates audit records for packets hitting the target.
|
|
It can be used to record accepted, dropped, and rejected packets. See
|
|
<A HREF="/cgi-bin/man/man2html?8+auditd">auditd</A>(8) for additional details.
|
|
<DL COMPACT>
|
|
<DT id="363"><B>--type</B> {<B>accept</B>|<B>drop</B>|<B>reject</B>}<DD>
|
|
Set type of audit record. Starting with linux-4.12, this option has no effect
|
|
on generated audit messages anymore. It is still accepted by iptables for
|
|
compatibility reasons, but ignored.
|
|
</DL>
|
|
<P>
|
|
|
|
Example:
|
|
<DL COMPACT>
|
|
<DT id="364"><DD>
|
|
iptables -N AUDIT_DROP
|
|
<DT id="365"><DD>
|
|
iptables -A AUDIT_DROP -j AUDIT
|
|
<DT id="366"><DD>
|
|
iptables -A AUDIT_DROP -j DROP
|
|
</DL>
|
|
<A NAME="lbCP"> </A>
|
|
<H3>CHECKSUM</H3>
|
|
|
|
This target selectively works around broken/old applications.
|
|
It can only be used in the mangle table.
|
|
<DL COMPACT>
|
|
<DT id="367"><B>--checksum-fill</B><DD>
|
|
Compute and fill in the checksum in a packet that lacks a checksum.
|
|
This is particularly useful, if you need to work around old applications
|
|
such as dhcp clients, that do not work well with checksum offloads,
|
|
but don't want to disable checksum offload in your device.
|
|
</DL>
|
|
<A NAME="lbCQ"> </A>
|
|
<H3>CLASSIFY</H3>
|
|
|
|
This module allows you to set the skb->priority value (and thus classify the packet into a specific CBQ class).
|
|
<DL COMPACT>
|
|
<DT id="368"><B>--set-class</B> <I>major</I><B>:</B><I>minor</I><DD>
|
|
Set the major and minor class value. The values are always interpreted as
|
|
hexadecimal even if no 0x prefix is given.
|
|
</DL>
|
|
<A NAME="lbCR"> </A>
|
|
<H3>CLUSTERIP (IPv4-specific)</H3>
|
|
|
|
This module allows you to configure a simple cluster of nodes that share
|
|
a certain IP and MAC address without an explicit load balancer in front of
|
|
them. Connections are statically distributed between the nodes in this
|
|
cluster.
|
|
<DL COMPACT>
|
|
<DT id="369"><B>--new</B><DD>
|
|
Create a new ClusterIP. You always have to set this on the first rule
|
|
for a given ClusterIP.
|
|
<DT id="370"><B>--hashmode</B> <I>mode</I><DD>
|
|
Specify the hashing mode. Has to be one of
|
|
<B>sourceip</B>, <B>sourceip-sourceport</B>, <B>sourceip-sourceport-destport</B>.
|
|
<DT id="371"><B>--clustermac</B> <I>mac</I><DD>
|
|
Specify the ClusterIP MAC address. Has to be a link-layer multicast address
|
|
<DT id="372"><B>--total-nodes</B> <I>num</I><DD>
|
|
Number of total nodes within this cluster.
|
|
<DT id="373"><B>--local-node</B> <I>num</I><DD>
|
|
Local node number within this cluster.
|
|
<DT id="374"><B>--hash-init</B> <I>rnd</I><DD>
|
|
Specify the random seed used for hash initialization.
|
|
</DL>
|
|
<A NAME="lbCS"> </A>
|
|
<H3>CONNMARK</H3>
|
|
|
|
This module sets the netfilter mark value associated with a connection. The
|
|
mark is 32 bits wide.
|
|
<DL COMPACT>
|
|
<DT id="375"><B>--set-xmark</B> <I>value</I>[<B>/</B><I>mask</I>]<DD>
|
|
Zero out the bits given by <I>mask</I> and XOR <I>value</I> into the ctmark.
|
|
<DT id="376"><B>--save-mark</B> [<B>--nfmask</B> <I>nfmask</I>] [<B>--ctmask</B> <I>ctmask</I>]<DD>
|
|
Copy the packet mark (nfmark) to the connection mark (ctmark) using the given
|
|
masks. The new nfmark value is determined as follows:
|
|
<DT id="377"><DD>
|
|
ctmark = (ctmark & ~ctmask) ^ (nfmark & nfmask)
|
|
<DT id="378"><DD>
|
|
i.e. <I>ctmask</I> defines what bits to clear and <I>nfmask</I> what bits of the
|
|
nfmark to XOR into the ctmark. <I>ctmask</I> and <I>nfmask</I> default to
|
|
0xFFFFFFFF.
|
|
<DT id="379"><B>--restore-mark</B> [<B>--nfmask</B> <I>nfmask</I>] [<B>--ctmask</B> <I>ctmask</I>]<DD>
|
|
Copy the connection mark (ctmark) to the packet mark (nfmark) using the given
|
|
masks. The new ctmark value is determined as follows:
|
|
<DT id="380"><DD>
|
|
nfmark = (nfmark & ~<I>nfmask</I>) ^ (ctmark & <I>ctmask</I>);
|
|
<DT id="381"><DD>
|
|
i.e. <I>nfmask</I> defines what bits to clear and <I>ctmask</I> what bits of the
|
|
ctmark to XOR into the nfmark. <I>ctmask</I> and <I>nfmask</I> default to
|
|
0xFFFFFFFF.
|
|
<DT id="382"><DD>
|
|
<B>--restore-mark</B> is only valid in the <B>mangle</B> table.
|
|
</DL>
|
|
<P>
|
|
|
|
The following mnemonics are available for <B>--set-xmark</B>:
|
|
<DL COMPACT>
|
|
<DT id="383"><B>--and-mark</B> <I>bits</I><DD>
|
|
Binary AND the ctmark with <I>bits</I>. (Mnemonic for <B>--set-xmark
|
|
0/</B><I>invbits</I>, where <I>invbits</I> is the binary negation of <I>bits</I>.)
|
|
<DT id="384"><B>--or-mark</B> <I>bits</I><DD>
|
|
Binary OR the ctmark with <I>bits</I>. (Mnemonic for <B>--set-xmark</B>
|
|
<I>bits</I><B>/</B><I>bits</I>.)
|
|
<DT id="385"><B>--xor-mark</B> <I>bits</I><DD>
|
|
Binary XOR the ctmark with <I>bits</I>. (Mnemonic for <B>--set-xmark</B>
|
|
<I>bits</I><B>/0</B>.)
|
|
<DT id="386"><B>--set-mark</B> <I>value</I>[<B>/</B><I>mask</I>]<DD>
|
|
Set the connection mark. If a mask is specified then only those bits set in the
|
|
mask are modified.
|
|
<DT id="387"><B>--save-mark</B> [<B>--mask</B> <I>mask</I>]<DD>
|
|
Copy the nfmark to the ctmark. If a mask is specified, only those bits are
|
|
copied.
|
|
<DT id="388"><B>--restore-mark</B> [<B>--mask</B> <I>mask</I>]<DD>
|
|
Copy the ctmark to the nfmark. If a mask is specified, only those bits are
|
|
copied. This is only valid in the <B>mangle</B> table.
|
|
</DL>
|
|
<A NAME="lbCT"> </A>
|
|
<H3>CONNSECMARK</H3>
|
|
|
|
This module copies security markings from packets to connections
|
|
(if unlabeled), and from connections back to packets (also only
|
|
if unlabeled). Typically used in conjunction with SECMARK, it is
|
|
valid in the
|
|
<B>security</B>
|
|
|
|
table (for backwards compatibility with older kernels, it is also
|
|
valid in the
|
|
<B>mangle</B>
|
|
|
|
table).
|
|
<DL COMPACT>
|
|
<DT id="389"><B>--save</B><DD>
|
|
If the packet has a security marking, copy it to the connection
|
|
if the connection is not marked.
|
|
<DT id="390"><B>--restore</B><DD>
|
|
If the packet does not have a security marking, and the connection
|
|
does, copy the security marking from the connection to the packet.
|
|
<P>
|
|
</DL>
|
|
<A NAME="lbCU"> </A>
|
|
<H3>CT</H3>
|
|
|
|
The CT target sets parameters for a packet or its associated
|
|
connection. The target attaches a "template" connection tracking entry to
|
|
the packet, which is then used by the conntrack core when initializing
|
|
a new ct entry. This target is thus only valid in the "raw" table.
|
|
<DL COMPACT>
|
|
<DT id="391"><B>--notrack</B><DD>
|
|
Disables connection tracking for this packet.
|
|
<DT id="392"><B>--helper</B> <I>name</I><DD>
|
|
Use the helper identified by <I>name</I> for the connection. This is more
|
|
flexible than loading the conntrack helper modules with preset ports.
|
|
<DT id="393"><B>--ctevents</B> <I>event</I>[<B>,</B>...]<DD>
|
|
Only generate the specified conntrack events for this connection. Possible
|
|
event types are: <B>new</B>, <B>related</B>, <B>destroy</B>, <B>reply</B>,
|
|
<B>assured</B>, <B>protoinfo</B>, <B>helper</B>, <B>mark</B> (this refers to
|
|
the ctmark, not nfmark), <B>natseqinfo</B>, <B>secmark</B> (ctsecmark).
|
|
<DT id="394"><B>--expevents</B> <I>event</I>[<B>,</B>...]<DD>
|
|
Only generate the specified expectation events for this connection.
|
|
Possible event types are: <B>new</B>.
|
|
<DT id="395"><B>--zone-orig</B> {<I>id</I>|<B>mark</B>}<DD>
|
|
For traffic coming from ORIGINAL direction, assign this packet to zone
|
|
<I>id</I> and only have lookups done in that zone. If <B>mark</B> is used
|
|
instead of <I>id</I>, the zone is derived from the packet nfmark.
|
|
<DT id="396"><B>--zone-reply</B> {<I>id</I>|<B>mark</B>}<DD>
|
|
For traffic coming from REPLY direction, assign this packet to zone
|
|
<I>id</I> and only have lookups done in that zone. If <B>mark</B> is used
|
|
instead of <I>id</I>, the zone is derived from the packet nfmark.
|
|
<DT id="397"><B>--zone</B> {<I>id</I>|<B>mark</B>}<DD>
|
|
Assign this packet to zone <I>id</I> and only have lookups done in that zone.
|
|
If <B>mark</B> is used instead of <I>id</I>, the zone is derived from the
|
|
packet nfmark. By default, packets have zone 0. This option applies to both
|
|
directions.
|
|
<DT id="398"><B>--timeout</B> <I>name</I><DD>
|
|
Use the timeout policy identified by <I>name</I> for the connection. This is
|
|
provides more flexible timeout policy definition than global timeout values
|
|
available at /proc/sys/net/netfilter/nf_conntrack_*_timeout_*.
|
|
</DL>
|
|
<A NAME="lbCV"> </A>
|
|
<H3>DNAT</H3>
|
|
|
|
This target is only valid in the
|
|
<B>nat</B>
|
|
|
|
table, in the
|
|
<B>PREROUTING</B>
|
|
|
|
and
|
|
<B>OUTPUT</B>
|
|
|
|
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 the
|
|
following options:
|
|
<DL COMPACT>
|
|
<DT id="399"><B>--to-destination</B> [<I>ipaddr</I>[<B>-</B><I>ipaddr</I>]][<B>:</B><I>port</I>[<B>-</B><I>port</I>]]<DD>
|
|
which can specify a single new destination IP address, an inclusive
|
|
range of IP addresses. Optionally a port range,
|
|
if the rule also specifies one of the following protocols:
|
|
<B>tcp</B>, <B>udp</B>, <B>dccp</B> or <B>sctp</B>.
|
|
If no port range is specified, then the destination port will never be
|
|
modified. If no IP address is specified then only the destination port
|
|
will be modified.
|
|
In Kernels up to 2.6.10 you can add several --to-destination options. For
|
|
those kernels, 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 addresses.
|
|
Later Kernels (>= 2.6.11-rc1) don't have the ability to NAT to multiple ranges
|
|
anymore.
|
|
<DT id="400"><B>--random</B><DD>
|
|
If option
|
|
<B>--random</B>
|
|
is used then port mapping will be randomized (kernel >= 2.6.22).
|
|
<DT id="401"><B>--persistent</B><DD>
|
|
Gives a client the same source-/destination-address for each connection.
|
|
This supersedes the SAME target. Support for persistent mappings is available
|
|
from 2.6.29-rc2.
|
|
<DT id="402">IPv6 support available since Linux kernels >= 3.7.<DD>
|
|
</DL>
|
|
<A NAME="lbCW"> </A>
|
|
<H3>DNPT (IPv6-specific)</H3>
|
|
|
|
Provides stateless destination IPv6-to-IPv6 Network Prefix Translation (as
|
|
described by RFC 6296).
|
|
<P>
|
|
|
|
You have to use this target in the
|
|
<B>mangle</B>
|
|
|
|
table, not in the
|
|
<B>nat</B>
|
|
|
|
table. It takes the following options:
|
|
<DL COMPACT>
|
|
<DT id="403"><B>--src-pfx</B> [<I>prefix/</I><I>length]<DD>
|
|
Set source prefix that you want to translate and length
|
|
<DT id="404"></I><B>--dst-pfx</B> [<I>prefix/</I><I>length]<DD>
|
|
Set destination prefix that you want to use in the translation and length
|
|
</DL>
|
|
<P>
|
|
|
|
You have to use the SNPT target to undo the translation. Example:
|
|
<DL COMPACT>
|
|
<DT id="405"><DD>
|
|
ip6tables -t mangle -I POSTROUTING -s fd00::/64 -o vboxnet0
|
|
-j SNPT --src-pfx fd00::/64 --dst-pfx 2001:e20:2000:40f::/64
|
|
<DT id="406"><DD>
|
|
ip6tables -t mangle -I PREROUTING -i wlan0 -d 2001:e20:2000:40f::/64
|
|
-j DNPT --src-pfx 2001:e20:2000:40f::/64 --dst-pfx fd00::/64
|
|
</DL>
|
|
<P>
|
|
|
|
You may need to enable IPv6 neighbor proxy:
|
|
<DL COMPACT>
|
|
<DT id="407"><DD>
|
|
sysctl -w net.ipv6.conf.all.proxy_ndp=1
|
|
</DL>
|
|
<P>
|
|
|
|
You also have to use the
|
|
</I><B>NOTRACK</B>
|
|
|
|
target to disable connection tracking for translated flows.
|
|
<A NAME="lbCX"> </A>
|
|
<H3>DSCP</H3>
|
|
|
|
This target alters 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.
|
|
<DL COMPACT>
|
|
<DT id="408"><B>--set-dscp</B> <I>value</I><DD>
|
|
Set the DSCP field to a numerical value (can be decimal or hex)
|
|
<DT id="409"><B>--set-dscp-class</B> <I>class</I><DD>
|
|
Set the DSCP field to a DiffServ class.
|
|
</DL>
|
|
<A NAME="lbCY"> </A>
|
|
<H3>ECN (IPv4-specific)</H3>
|
|
|
|
This target selectively works around known ECN blackholes.
|
|
It can only be used in the mangle table.
|
|
<DL COMPACT>
|
|
<DT id="410"><B>--ecn-tcp-remove</B><DD>
|
|
Remove all ECN bits from the TCP header. Of course, it can only be used
|
|
in conjunction with
|
|
<B>-p tcp</B>.
|
|
</DL>
|
|
<A NAME="lbCZ"> </A>
|
|
<H3>HL (IPv6-specific)</H3>
|
|
|
|
This is used to modify the Hop Limit field in IPv6 header. The Hop Limit field
|
|
is similar to what is known as TTL value in IPv4. Setting or incrementing the
|
|
Hop Limit field can potentially be very dangerous, so it should be avoided at
|
|
any cost. This target is only valid in
|
|
<B>mangle</B>
|
|
|
|
table.
|
|
<P>
|
|
|
|
<B>Don't ever set or increment the value on packets that leave your local network!</B>
|
|
|
|
<DL COMPACT>
|
|
<DT id="411"><B>--hl-set</B> <I>value</I><DD>
|
|
Set the Hop Limit to `value'.
|
|
<DT id="412"><B>--hl-dec</B> <I>value</I><DD>
|
|
Decrement the Hop Limit `value' times.
|
|
<DT id="413"><B>--hl-inc</B> <I>value</I><DD>
|
|
Increment the Hop Limit `value' times.
|
|
</DL>
|
|
<A NAME="lbDA"> </A>
|
|
<H3>HMARK</H3>
|
|
|
|
Like MARK, i.e. set the fwmark, but the mark is calculated from hashing
|
|
packet selector at choice. You have also to specify the mark range and,
|
|
optionally, the offset to start from. ICMP error messages are inspected
|
|
and used to calculate the hashing.
|
|
<P>
|
|
|
|
Existing options are:
|
|
<DL COMPACT>
|
|
<DT id="414"><B>--hmark-tuple</B> tuple<I></I><DD>
|
|
Possible tuple members are:
|
|
<B>src</B>
|
|
|
|
meaning source address (IPv4, IPv6 address),
|
|
<B>dst</B>
|
|
|
|
meaning destination address (IPv4, IPv6 address),
|
|
<B>sport</B>
|
|
|
|
meaning source port (TCP, UDP, UDPlite, SCTP, DCCP),
|
|
<B>dport</B>
|
|
|
|
meaning destination port (TCP, UDP, UDPlite, SCTP, DCCP),
|
|
<B>spi</B>
|
|
|
|
meaning Security Parameter Index (AH, ESP), and
|
|
<B>ct</B>
|
|
|
|
meaning the usage of the conntrack tuple instead of the packet selectors.
|
|
<DT id="415"><B>--hmark-mod</B> <I>value (must be > 0)</I><DD>
|
|
Modulus for hash calculation (to limit the range of possible marks)
|
|
<DT id="416"><B>--hmark-offset</B> <I>value</I><DD>
|
|
Offset to start marks from.
|
|
<DT id="417">For advanced usage, instead of using --hmark-tuple, you can specify custom<DD>
|
|
prefixes and masks:
|
|
<DT id="418"><B>--hmark-src-prefix</B> <I>cidr</I><DD>
|
|
The source address mask in CIDR notation.
|
|
<DT id="419"><B>--hmark-dst-prefix</B> <I>cidr</I><DD>
|
|
The destination address mask in CIDR notation.
|
|
<DT id="420"><B>--hmark-sport-mask</B> <I>value</I><DD>
|
|
A 16 bit source port mask in hexadecimal.
|
|
<DT id="421"><B>--hmark-dport-mask</B> <I>value</I><DD>
|
|
A 16 bit destination port mask in hexadecimal.
|
|
<DT id="422"><B>--hmark-spi-mask</B> <I>value</I><DD>
|
|
A 32 bit field with spi mask.
|
|
<DT id="423"><B>--hmark-proto-mask</B> <I>value</I><DD>
|
|
An 8 bit field with layer 4 protocol number.
|
|
<DT id="424"><B>--hmark-rnd</B> <I>value</I><DD>
|
|
A 32 bit random custom value to feed hash calculation.
|
|
</DL>
|
|
<P>
|
|
|
|
<I>Examples:</I>
|
|
<P>
|
|
|
|
iptables -t mangle -A PREROUTING -m conntrack --ctstate NEW
|
|
<BR> -j HMARK --hmark-tuple ct,src,dst,proto --hmark-offset 10000
|
|
--hmark-mod 10 --hmark-rnd 0xfeedcafe
|
|
<P>
|
|
|
|
iptables -t mangle -A PREROUTING -j HMARK --hmark-offset 10000
|
|
--hmark-tuple src,dst,proto --hmark-mod 10 --hmark-rnd 0xdeafbeef
|
|
<A NAME="lbDB"> </A>
|
|
<H3>IDLETIMER</H3>
|
|
|
|
This target can be used to identify when interfaces have been idle for a
|
|
certain period of time. Timers are identified by labels and are created when
|
|
a rule is set with a new label. The rules also take a timeout value (in
|
|
seconds) as an option. If more than one rule uses the same timer label, the
|
|
timer will be restarted whenever any of the rules get a hit. One entry for
|
|
each timer is created in sysfs. This attribute contains the timer remaining
|
|
for the timer to expire. The attributes are located under the xt_idletimer
|
|
class:
|
|
<P>
|
|
|
|
/sys/class/xt_idletimer/timers/<label>
|
|
<P>
|
|
|
|
When the timer expires, the target module sends a sysfs notification to the
|
|
userspace, which can then decide what to do (eg. disconnect to save power).
|
|
<DL COMPACT>
|
|
<DT id="425"><B>--timeout</B> <I>amount</I><DD>
|
|
This is the time in seconds that will trigger the notification.
|
|
<DT id="426"><B>--label</B> <I>string</I><DD>
|
|
This is a unique identifier for the timer. The maximum length for the
|
|
label string is 27 characters.
|
|
</DL>
|
|
<A NAME="lbDC"> </A>
|
|
<H3>LED</H3>
|
|
|
|
This creates an LED-trigger that can then be attached to system indicator
|
|
lights, to blink or illuminate them when certain packets pass through the
|
|
system. One example might be to light up an LED for a few minutes every time
|
|
an SSH connection is made to the local machine. The following options control
|
|
the trigger behavior:
|
|
<DL COMPACT>
|
|
<DT id="427"><B>--led-trigger-id</B> <I>name</I><DD>
|
|
This is the name given to the LED trigger. The actual name of the trigger
|
|
will be prefixed with "netfilter-".
|
|
<DT id="428"><B>--led-delay</B> <I>ms</I><DD>
|
|
This indicates how long (in milliseconds) the LED should be left illuminated
|
|
when a packet arrives before being switched off again. The default is 0
|
|
(blink as fast as possible.) The special value <I>inf</I> can be given to
|
|
leave the LED on permanently once activated. (In this case the trigger will
|
|
need to be manually detached and reattached to the LED device to switch it
|
|
off again.)
|
|
<DT id="429"><B>--led-always-blink</B><DD>
|
|
Always make the LED blink on packet arrival, even if the LED is already on.
|
|
This allows notification of new packets even with long delay values (which
|
|
otherwise would result in a silent prolonging of the delay time.)
|
|
<DT id="430">Example:<DD>
|
|
<DT id="431">Create an LED trigger for incoming SSH traffic:<DD>
|
|
iptables -A INPUT -p tcp --dport 22 -j LED --led-trigger-id ssh
|
|
<DT id="432">Then attach the new trigger to an LED:<DD>
|
|
echo netfilter-ssh >/sys/class/leds/<I>ledname</I>/trigger
|
|
</DL>
|
|
<A NAME="lbDD"> </A>
|
|
<H3>LOG</H3>
|
|
|
|
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/IPv6 header fields) via the kernel log
|
|
(where it can be read with <I><A HREF="/cgi-bin/man/man2html?1+dmesg">dmesg</A>(1)</I> or read in the syslog).
|
|
<P>
|
|
|
|
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).
|
|
<DL COMPACT>
|
|
<DT id="433"><B>--log-level</B> <I>level</I><DD>
|
|
Level of logging, which can be (system-specific) numeric or a mnemonic.
|
|
Possible values are (in decreasing order of priority): <B>emerg</B>,
|
|
<B>alert</B>, <B>crit</B>, <B>error</B>, <B>warning</B>, <B>notice</B>, <B>info</B>
|
|
or <B>debug</B>.
|
|
<DT id="434"><B>--log-prefix</B> <I>prefix</I><DD>
|
|
Prefix log messages with the specified prefix; up to 29 letters long,
|
|
and useful for distinguishing messages in the logs.
|
|
<DT id="435"><B>--log-tcp-sequence</B><DD>
|
|
Log TCP sequence numbers. This is a security risk if the log is
|
|
readable by users.
|
|
<DT id="436"><B>--log-tcp-options</B><DD>
|
|
Log options from the TCP packet header.
|
|
<DT id="437"><B>--log-ip-options</B><DD>
|
|
Log options from the IP/IPv6 packet header.
|
|
<DT id="438"><B>--log-uid</B><DD>
|
|
Log the userid of the process which generated the packet.
|
|
</DL>
|
|
<A NAME="lbDE"> </A>
|
|
<H3>MARK</H3>
|
|
|
|
This target is used to set the Netfilter mark value associated with the packet.
|
|
It can, for example, be used in conjunction with routing based on fwmark (needs
|
|
iproute2). If you plan on doing so, note that the mark needs to be set in the
|
|
PREROUTING chain of the mangle table to affect routing.
|
|
The mark field is 32 bits wide.
|
|
<DL COMPACT>
|
|
<DT id="439"><B>--set-xmark</B> <I>value</I>[<B>/</B><I>mask</I>]<DD>
|
|
Zeroes out the bits given by <I>mask</I> and XORs <I>value</I> into the packet
|
|
mark ("nfmark"). If <I>mask</I> is omitted, 0xFFFFFFFF is assumed.
|
|
<DT id="440"><B>--set-mark</B> <I>value</I>[<B>/</B><I>mask</I>]<DD>
|
|
Zeroes out the bits given by <I>mask</I> and ORs <I>value</I> into the packet
|
|
mark. If <I>mask</I> is omitted, 0xFFFFFFFF is assumed.
|
|
</DL>
|
|
<P>
|
|
|
|
The following mnemonics are available:
|
|
<DL COMPACT>
|
|
<DT id="441"><B>--and-mark</B> <I>bits</I><DD>
|
|
Binary AND the nfmark with <I>bits</I>. (Mnemonic for <B>--set-xmark
|
|
0/</B><I>invbits</I>, where <I>invbits</I> is the binary negation of <I>bits</I>.)
|
|
<DT id="442"><B>--or-mark</B> <I>bits</I><DD>
|
|
Binary OR the nfmark with <I>bits</I>. (Mnemonic for <B>--set-xmark</B>
|
|
<I>bits</I><B>/</B><I>bits</I>.)
|
|
<DT id="443"><B>--xor-mark</B> <I>bits</I><DD>
|
|
Binary XOR the nfmark with <I>bits</I>. (Mnemonic for <B>--set-xmark</B>
|
|
<I>bits</I><B>/0</B>.)
|
|
</DL>
|
|
<A NAME="lbDF"> </A>
|
|
<H3>MASQUERADE</H3>
|
|
|
|
This target is only valid in the
|
|
<B>nat</B>
|
|
|
|
table, in the
|
|
<B>POSTROUTING</B>
|
|
|
|
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</I>
|
|
|
|
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).
|
|
<DL COMPACT>
|
|
<DT id="444"><B>--to-ports</B> <I>port</I>[<B>-</B><I>port</I>]<DD>
|
|
This specifies a range of source ports to use, overriding the default
|
|
<B>SNAT</B>
|
|
|
|
source port-selection heuristics (see above). This is only valid
|
|
if the rule also specifies one of the following protocols:
|
|
<B>tcp</B>, <B>udp</B>, <B>dccp</B> or <B>sctp</B>.
|
|
<DT id="445"><B>--random</B><DD>
|
|
Randomize source port mapping
|
|
If option
|
|
<B>--random</B>
|
|
is used then port mapping will be randomized (kernel >= 2.6.21).
|
|
Since kernel 5.0, <B>--random</B> is identical to <B>--random-fully</B>.
|
|
<DT id="446"><B>--random-fully</B><DD>
|
|
Full randomize source port mapping
|
|
If option
|
|
<B>--random-fully</B>
|
|
is used then port mapping will be fully randomized (kernel >= 3.13).
|
|
<DT id="447">IPv6 support available since Linux kernels >= 3.7.<DD>
|
|
</DL>
|
|
<A NAME="lbDG"> </A>
|
|
<H3>NETMAP</H3>
|
|
|
|
This target allows you to statically map a whole network of addresses onto
|
|
another network of addresses. It can only be used from rules in the
|
|
<B>nat</B>
|
|
|
|
table.
|
|
<DL COMPACT>
|
|
<DT id="448"><B>--to</B> <I>address</I>[<B>/</B><I>mask</I>]<DD>
|
|
Network address to map to. The resulting address will be constructed in the
|
|
following way: All 'one' bits in the mask are filled in from the new `address'.
|
|
All bits that are zero in the mask are filled in from the original address.
|
|
<DT id="449">IPv6 support available since Linux kernels >= 3.7.<DD>
|
|
</DL>
|
|
<A NAME="lbDH"> </A>
|
|
<H3>NFLOG</H3>
|
|
|
|
This target provides logging of matching packets. When this target is
|
|
set for a rule, the Linux kernel will pass the packet to the loaded
|
|
logging backend to log the packet. This is usually used in combination
|
|
with nfnetlink_log as logging backend, which will multicast the packet
|
|
through a
|
|
<I>netlink</I>
|
|
|
|
socket to the specified multicast group. One or more userspace processes
|
|
may subscribe to the group to receive the packets. Like LOG, this is a
|
|
non-terminating target, i.e. rule traversal continues at the next rule.
|
|
<DL COMPACT>
|
|
<DT id="450"><B>--nflog-group</B> <I>nlgroup</I><DD>
|
|
The netlink group (0 - 2^16-1) to which packets are (only applicable for
|
|
nfnetlink_log). The default value is 0.
|
|
<DT id="451"><B>--nflog-prefix</B> <I>prefix</I><DD>
|
|
A prefix string to include in the log message, up to 64 characters
|
|
long, useful for distinguishing messages in the logs.
|
|
<DT id="452"><B>--nflog-range</B> <I>size</I><DD>
|
|
This option has never worked, use --nflog-size instead
|
|
<DT id="453"><B>--nflog-size</B> <I>size</I><DD>
|
|
The number of bytes to be copied to userspace (only applicable for
|
|
nfnetlink_log). nfnetlink_log instances may specify their own
|
|
range, this option overrides it.
|
|
<DT id="454"><B>--nflog-threshold</B> <I>size</I><DD>
|
|
Number of packets to queue inside the kernel before sending them
|
|
to userspace (only applicable for nfnetlink_log). Higher values
|
|
result in less overhead per packet, but increase delay until the
|
|
packets reach userspace. The default value is 1.
|
|
|
|
</DL>
|
|
<A NAME="lbDI"> </A>
|
|
<H3>NFQUEUE</H3>
|
|
|
|
This target passes the packet to userspace using the
|
|
<B>nfnetlink_queue</B> handler. The packet is put into the queue
|
|
identified by its 16-bit queue number. Userspace can inspect
|
|
and modify the packet if desired. Userspace must then drop or
|
|
reinject the packet into the kernel. Please see libnetfilter_queue
|
|
for details.
|
|
<B>nfnetlink_queue</B>
|
|
|
|
was added in Linux 2.6.14. The <B>queue-balance</B> option was added in Linux 2.6.31,
|
|
<B>queue-bypass</B> in 2.6.39.
|
|
<DL COMPACT>
|
|
<DT id="455"><B>--queue-num</B> <I>value</I><DD>
|
|
This specifies the QUEUE number to use. Valid queue numbers are 0 to 65535. The default value is 0.
|
|
</DL>
|
|
<P>
|
|
|
|
<DL COMPACT>
|
|
<DT id="456"><B>--queue-balance</B> <I>value</I><B>:</B><I>value</I><DD>
|
|
This specifies a range of queues to use. Packets are then balanced across the given queues.
|
|
This is useful for multicore systems: start multiple instances of the userspace program on
|
|
queues x, x+1, .. x+n and use "--queue-balance <I>x</I><B>:</B><I>x+n</I>".
|
|
Packets belonging to the same connection are put into the same nfqueue.
|
|
</DL>
|
|
<P>
|
|
|
|
<DL COMPACT>
|
|
<DT id="457"><B>--queue-bypass</B><DD>
|
|
By default, if no userspace program is listening on an NFQUEUE, then all packets that are to be queued
|
|
are dropped. When this option is used, the NFQUEUE rule behaves like ACCEPT instead, and the packet
|
|
will move on to the next table.
|
|
</DL>
|
|
<P>
|
|
|
|
<DL COMPACT>
|
|
<DT id="458"><B>--queue-cpu-fanout</B><DD>
|
|
Available starting Linux kernel 3.10. When used together with
|
|
<B>--queue-balance</B> this will use the CPU ID as an index to map packets to
|
|
the queues. The idea is that you can improve performance if there's a queue
|
|
per CPU. This requires <B>--queue-balance</B> to be specified.
|
|
</DL>
|
|
<A NAME="lbDJ"> </A>
|
|
<H3>NOTRACK</H3>
|
|
|
|
This extension disables connection tracking for all packets matching that rule.
|
|
It is equivalent with -j CT --notrack. Like CT, NOTRACK can only be used in
|
|
the <B>raw</B> table.
|
|
<A NAME="lbDK"> </A>
|
|
<H3>RATEEST</H3>
|
|
|
|
The RATEEST target collects statistics, performs rate estimation calculation
|
|
and saves the results for later evaluation using the <B>rateest</B> match.
|
|
<DL COMPACT>
|
|
<DT id="459"><B>--rateest-name</B> <I>name</I><DD>
|
|
Count matched packets into the pool referred to by <I>name</I>, which is freely
|
|
choosable.
|
|
<DT id="460"><B>--rateest-interval</B> <I>amount</I>{<B>s</B>|<B>ms</B>|<B>us</B>}<DD>
|
|
Rate measurement interval, in seconds, milliseconds or microseconds.
|
|
<DT id="461"><B>--rateest-ewmalog</B> <I>value</I><DD>
|
|
Rate measurement averaging time constant.
|
|
</DL>
|
|
<A NAME="lbDL"> </A>
|
|
<H3>REDIRECT</H3>
|
|
|
|
This target is only valid in the
|
|
<B>nat</B>
|
|
|
|
table, in the
|
|
<B>PREROUTING</B>
|
|
|
|
and
|
|
<B>OUTPUT</B>
|
|
|
|
chains, and user-defined chains which are only called from those
|
|
chains. It redirects the packet to the machine itself by changing the
|
|
destination IP to the primary address of the incoming interface
|
|
(locally-generated packets are mapped to the localhost address,
|
|
127.0.0.1 for IPv4 and ::1 for IPv6, and packets arriving on
|
|
interfaces that don't have an IP address configured are dropped).
|
|
<DL COMPACT>
|
|
<DT id="462"><B>--to-ports</B> <I>port</I>[<B>-</B><I>port</I>]<DD>
|
|
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 one of the following protocols:
|
|
<B>tcp</B>, <B>udp</B>, <B>dccp</B> or <B>sctp</B>.
|
|
<DT id="463"><B>--random</B><DD>
|
|
If option
|
|
<B>--random</B>
|
|
is used then port mapping will be randomized (kernel >= 2.6.22).
|
|
<DT id="464">IPv6 support available starting Linux kernels >= 3.7.<DD>
|
|
</DL>
|
|
<A NAME="lbDM"> </A>
|
|
<H3>REJECT (IPv6-specific)</H3>
|
|
|
|
This is used to send back an error packet in response to the matched
|
|
packet: otherwise it is equivalent to
|
|
<B>DROP</B>
|
|
|
|
so it is a terminating TARGET, ending rule traversal.
|
|
This target is only valid in the
|
|
<B>INPUT</B>,
|
|
|
|
<B>FORWARD</B>
|
|
|
|
and
|
|
<B>OUTPUT</B>
|
|
|
|
chains, and user-defined chains which are only called from those
|
|
chains. The following option controls the nature of the error packet
|
|
returned:
|
|
<DL COMPACT>
|
|
<DT id="465"><B>--reject-with</B> <I>type</I><DD>
|
|
The type given can be
|
|
<B>icmp6-no-route</B>,
|
|
<B>no-route</B>,
|
|
<B>icmp6-adm-prohibited</B>,
|
|
<B>adm-prohibited</B>,
|
|
<B>icmp6-addr-unreachable</B>,
|
|
<B>addr-unreach</B>, or
|
|
<B>icmp6-port-unreachable</B>,
|
|
which return the appropriate ICMPv6 error message (<B>icmp6-port-unreachable</B> is
|
|
the default). Finally, the option
|
|
<B>tcp-reset</B>
|
|
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</I>
|
|
|
|
(113/tcp) probes which frequently occur when sending mail to broken mail
|
|
hosts (which won't accept your mail otherwise).
|
|
<B>tcp-reset</B>
|
|
can only be used with kernel versions 2.6.14 or later.
|
|
</DL>
|
|
<A NAME="lbDN"> </A>
|
|
<H3>REJECT (IPv4-specific)</H3>
|
|
|
|
This is used to send back an error packet in response to the matched
|
|
packet: otherwise it is equivalent to
|
|
<B>DROP</B>
|
|
|
|
so it is a terminating TARGET, ending rule traversal.
|
|
This target is only valid in the
|
|
<B>INPUT</B>,
|
|
|
|
<B>FORWARD</B>
|
|
|
|
and
|
|
<B>OUTPUT</B>
|
|
|
|
chains, and user-defined chains which are only called from those
|
|
chains. The following option controls the nature of the error packet
|
|
returned:
|
|
<DL COMPACT>
|
|
<DT id="466"><B>--reject-with</B> <I>type</I><DD>
|
|
The type given can be
|
|
<B>icmp-net-unreachable</B>,
|
|
<B>icmp-host-unreachable</B>,
|
|
<B>icmp-port-unreachable</B>,
|
|
<B>icmp-proto-unreachable</B>,
|
|
<B>icmp-net-prohibited</B>,
|
|
<B>icmp-host-prohibited</B>, or
|
|
<B>icmp-admin-prohibited</B> (*),
|
|
which return the appropriate ICMP error message (<B>icmp-port-unreachable</B> is
|
|
the default). The option
|
|
<B>tcp-reset</B>
|
|
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</I>
|
|
|
|
(113/tcp) probes which frequently occur when sending mail to broken mail
|
|
hosts (which won't accept your mail otherwise).
|
|
<DT id="467"><DD>
|
|
(*) Using icmp-admin-prohibited with kernels that do not support it will result in a plain DROP instead of REJECT
|
|
</DL>
|
|
<A NAME="lbDO"> </A>
|
|
<H3>SECMARK</H3>
|
|
|
|
This is used to set the security mark value associated with the
|
|
packet for use by security subsystems such as SELinux. It is
|
|
valid in the
|
|
<B>security</B>
|
|
|
|
table (for backwards compatibility with older kernels, it is also
|
|
valid in the
|
|
<B>mangle</B>
|
|
|
|
table). The mark is 32 bits wide.
|
|
<DL COMPACT>
|
|
<DT id="468"><B>--selctx</B> <I>security_context</I><DD>
|
|
</DL>
|
|
<A NAME="lbDP"> </A>
|
|
<H3>SET</H3>
|
|
|
|
This module adds and/or deletes entries from IP sets which can be defined
|
|
by <A HREF="/cgi-bin/man/man2html?8+ipset">ipset</A>(8).
|
|
<DL COMPACT>
|
|
<DT id="469"><B>--add-set</B> <I>setname</I> <I>flag</I>[<B>,</B><I>flag</I>...]<DD>
|
|
add the address(es)/port(s) of the packet to the set
|
|
<DT id="470"><B>--del-set</B> <I>setname</I> <I>flag</I>[<B>,</B><I>flag</I>...]<DD>
|
|
delete the address(es)/port(s) of the packet from the set
|
|
<DT id="471"><B>--map-set</B> <I>setname</I> <I>flag</I>[<B>,</B><I>flag</I>...] <DD>
|
|
[--map-mark] [--map-prio] [--map-queue]
|
|
map packet properties (firewall mark, tc priority, hardware queue)
|
|
<DT id="472"><DD>
|
|
where <I>flag</I>(s) are
|
|
<B>src</B>
|
|
|
|
and/or
|
|
<B>dst</B>
|
|
|
|
specifications and there can be no more than six of them.
|
|
<DT id="473"><B>--timeout</B> <I>value</I><DD>
|
|
when adding an entry, the timeout value to use instead of the default
|
|
one from the set definition
|
|
<DT id="474"><B>--exist</B><DD>
|
|
when adding an entry if it already exists, reset the timeout value
|
|
to the specified one or to the default from the set definition
|
|
<DT id="475"><B>--map-set</B> <I>set-name</I><DD>
|
|
the set-name should be created with --skbinfo option
|
|
<B>--map-mark</B>
|
|
map firewall mark to packet by lookup of value in the set
|
|
<B>--map-prio</B>
|
|
map traffic control priority to packet by lookup of value in the set
|
|
<B>--map-queue</B>
|
|
map hardware NIC queue to packet by lookup of value in the set
|
|
<DT id="476"><DD>
|
|
The
|
|
<B>--map-set</B>
|
|
option can be used from the mangle table only. The
|
|
<B>--map-prio</B>
|
|
and
|
|
<B>--map-queue</B>
|
|
flags can be used in the OUTPUT, FORWARD and POSTROUTING chains.
|
|
</DL>
|
|
<P>
|
|
|
|
Use of -j SET requires that ipset kernel support is provided, which, for
|
|
standard kernels, is the case since Linux 2.6.39.
|
|
<A NAME="lbDQ"> </A>
|
|
<H3>SNAT</H3>
|
|
|
|
This target is only valid in the
|
|
<B>nat</B>
|
|
|
|
table, in the
|
|
<B>POSTROUTING</B>
|
|
|
|
and
|
|
<B>INPUT</B>
|
|
|
|
chains, and user-defined chains which are only called from those
|
|
chains. 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 the
|
|
following options:
|
|
<DL COMPACT>
|
|
<DT id="477"><B>--to-source</B> [<I>ipaddr</I>[<B>-</B><I>ipaddr</I>]][<B>:</B><I>port</I>[<B>-</B><I>port</I>]]<DD>
|
|
which can specify a single new source IP address, an inclusive range
|
|
of IP addresses. Optionally a port range,
|
|
if the rule also specifies one of the following protocols:
|
|
<B>tcp</B>, <B>udp</B>, <B>dccp</B> or <B>sctp</B>.
|
|
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.
|
|
In Kernels up to 2.6.10, you can add several --to-source options. For those
|
|
kernels, 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 addresses.
|
|
Later Kernels (>= 2.6.11-rc1) don't have the ability to NAT to multiple ranges
|
|
anymore.
|
|
<DT id="478"><B>--random</B><DD>
|
|
If option
|
|
<B>--random</B>
|
|
is used then port mapping will be randomized through a hash-based algorithm (kernel >= 2.6.21).
|
|
<DT id="479"><B>--random-fully</B><DD>
|
|
If option
|
|
<B>--random-fully</B>
|
|
is used then port mapping will be fully randomized through a PRNG (kernel >= 3.14).
|
|
<DT id="480"><B>--persistent</B><DD>
|
|
Gives a client the same source-/destination-address for each connection.
|
|
This supersedes the SAME target. Support for persistent mappings is available
|
|
from 2.6.29-rc2.
|
|
</DL>
|
|
<P>
|
|
|
|
Kernels prior to 2.6.36-rc1 don't have the ability to
|
|
<B>SNAT</B>
|
|
|
|
in the
|
|
<B>INPUT</B>
|
|
|
|
chain.
|
|
<DL COMPACT>
|
|
<DT id="481">IPv6 support available since Linux kernels >= 3.7.<DD>
|
|
</DL>
|
|
<A NAME="lbDR"> </A>
|
|
<H3>SNPT (IPv6-specific)</H3>
|
|
|
|
Provides stateless source IPv6-to-IPv6 Network Prefix Translation (as described
|
|
by RFC 6296).
|
|
<P>
|
|
|
|
You have to use this target in the
|
|
<B>mangle</B>
|
|
|
|
table, not in the
|
|
<B>nat</B>
|
|
|
|
table. It takes the following options:
|
|
<DL COMPACT>
|
|
<DT id="482"><B>--src-pfx</B> [<I>prefix/</I><I>length]<DD>
|
|
Set source prefix that you want to translate and length
|
|
<DT id="483"></I><B>--dst-pfx</B> [<I>prefix/</I><I>length]<DD>
|
|
Set destination prefix that you want to use in the translation and length
|
|
</DL>
|
|
<P>
|
|
|
|
You have to use the DNPT target to undo the translation. Example:
|
|
<DL COMPACT>
|
|
<DT id="484"><DD>
|
|
ip6tables -t mangle -I POSTROUTING -s fd00::/64 -o vboxnet0
|
|
-j SNPT --src-pfx fd00::/64 --dst-pfx 2001:e20:2000:40f::/64
|
|
<DT id="485"><DD>
|
|
ip6tables -t mangle -I PREROUTING -i wlan0 -d 2001:e20:2000:40f::/64
|
|
-j DNPT --src-pfx 2001:e20:2000:40f::/64 --dst-pfx fd00::/64
|
|
</DL>
|
|
<P>
|
|
|
|
You may need to enable IPv6 neighbor proxy:
|
|
<DL COMPACT>
|
|
<DT id="486"><DD>
|
|
sysctl -w net.ipv6.conf.all.proxy_ndp=1
|
|
</DL>
|
|
<P>
|
|
|
|
You also have to use the
|
|
</I><B>NOTRACK</B>
|
|
|
|
target to disable connection tracking for translated flows.
|
|
<A NAME="lbDS"> </A>
|
|
<H3>SYNPROXY</H3>
|
|
|
|
This target will process TCP three-way-handshake parallel in netfilter
|
|
context to protect either local or backend system. This target requires
|
|
connection tracking because sequence numbers need to be translated.
|
|
The kernels ability to absorb SYNFLOOD was greatly improved starting with
|
|
Linux 4.4, so this target should not be needed anymore to protect Linux servers.
|
|
<DL COMPACT>
|
|
<DT id="487"><B>--mss</B> <I>maximum segment size</I><DD>
|
|
Maximum segment size announced to clients. This must match the backend.
|
|
<DT id="488"><B>--wscale</B> <I>window scale</I><DD>
|
|
Window scale announced to clients. This must match the backend.
|
|
<DT id="489"><B>--sack-perm</B><DD>
|
|
Pass client selective acknowledgement option to backend (will be disabled
|
|
if not present).
|
|
<DT id="490"><B>--timestamps</B><DD>
|
|
Pass client timestamp option to backend (will be disabled if not present,
|
|
also needed for selective acknowledgement and window scaling).
|
|
</DL>
|
|
<P>
|
|
|
|
Example:
|
|
<P>
|
|
|
|
Determine tcp options used by backend, from an external system
|
|
<DL COMPACT>
|
|
<DT id="491"><DD>
|
|
tcpdump -pni eth0 -c 1 'tcp[tcpflags] == (tcp-syn|tcp-ack)'
|
|
<BR>
|
|
|
|
<BR> port 80 &
|
|
<BR>
|
|
|
|
telnet 192.0.2.42 80
|
|
<BR>
|
|
|
|
18:57:24.693307 IP 192.0.2.42.80 > 192.0.2.43.48757:
|
|
<BR>
|
|
|
|
<BR> Flags [S.], seq 360414582, ack 788841994, win 14480,
|
|
<BR>
|
|
|
|
<BR> options [mss 1460,sackOK,
|
|
<BR>
|
|
|
|
<BR> TS val 1409056151 ecr 9690221,
|
|
<BR>
|
|
|
|
<BR> nop,wscale 9],
|
|
<BR>
|
|
|
|
<BR> length 0
|
|
</DL>
|
|
<P>
|
|
|
|
Switch tcp_loose mode off, so conntrack will mark out-of-flow
|
|
packets as state INVALID.
|
|
<DL COMPACT>
|
|
<DT id="492"><DD>
|
|
echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
|
|
</DL>
|
|
<P>
|
|
|
|
Make SYN packets untracked
|
|
<DL COMPACT>
|
|
<DT id="493"><DD>
|
|
iptables -t raw -A PREROUTING -i eth0 -p tcp --dport 80
|
|
<BR> --syn -j CT --notrack
|
|
</DL>
|
|
<P>
|
|
|
|
Catch UNTRACKED (SYN packets) and INVALID (3WHS ACK packets) states
|
|
and send them to SYNPROXY. This rule will respond to SYN packets with
|
|
SYN+ACK syncookies, create ESTABLISHED for valid client response (3WHS ACK
|
|
packets) and drop incorrect cookies. Flags combinations not expected
|
|
during 3WHS will not match and continue (e.g. SYN+FIN, SYN+ACK).
|
|
<DL COMPACT>
|
|
<DT id="494"><DD>
|
|
iptables -A INPUT -i eth0 -p tcp --dport 80
|
|
<BR> -m state --state UNTRACKED,INVALID -j SYNPROXY
|
|
<BR> --sack-perm --timestamp --mss 1460 --wscale 9
|
|
</DL>
|
|
<P>
|
|
|
|
Drop invalid packets, this will be out-of-flow packets that were not
|
|
matched by SYNPROXY.
|
|
<DL COMPACT>
|
|
<DT id="495"><DD>
|
|
iptables -A INPUT -i eth0 -p tcp --dport 80 -m state --state INVALID -j DROP
|
|
</DL>
|
|
<A NAME="lbDT"> </A>
|
|
<H3>TCPMSS</H3>
|
|
|
|
This target alters 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 for IPv4 or 60 for IPv6, respectively).
|
|
Of course, it can only be used
|
|
in conjunction with
|
|
<B>-p tcp</B>.
|
|
<P>
|
|
|
|
This target is used to overcome criminally braindead ISPs or servers
|
|
which block "ICMP Fragmentation Needed" or "ICMPv6 Packet Too Big"
|
|
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:
|
|
<DL COMPACT>
|
|
<DT id="496">1.<DD>
|
|
Web browsers connect, then hang with no data received.
|
|
<DT id="497">2.<DD>
|
|
Small mail works fine, but large emails hang.
|
|
<DT id="498">3.<DD>
|
|
ssh works fine, but scp hangs after initial handshaking.
|
|
</DL>
|
|
<P>
|
|
|
|
Workaround: activate this option and add a rule to your firewall
|
|
configuration like:
|
|
<DL COMPACT>
|
|
<DT id="499"><DD>
|
|
<BR> iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN
|
|
<BR> -j TCPMSS --clamp-mss-to-pmtu
|
|
<DT id="500"><B>--set-mss</B> <I>value</I><DD>
|
|
Explicitly sets MSS option to specified value. If the MSS of the packet is
|
|
already lower than <I>value</I>, it will <B>not</B> be increased (from Linux
|
|
2.6.25 onwards) to avoid more problems with hosts relying on a proper MSS.
|
|
<DT id="501"><B>--clamp-mss-to-pmtu</B><DD>
|
|
Automatically clamp MSS value to (path_MTU - 40 for IPv4; -60 for IPv6).
|
|
This may not function as desired where asymmetric routes with differing
|
|
path MTU exist --- the kernel uses the path MTU which it would use to send
|
|
packets from itself to the source and destination IP addresses. Prior to
|
|
Linux 2.6.25, only the path MTU to the destination IP address was
|
|
considered by this option; subsequent kernels also consider the path MTU
|
|
to the source IP address.
|
|
</DL>
|
|
<P>
|
|
|
|
These options are mutually exclusive.
|
|
<A NAME="lbDU"> </A>
|
|
<H3>TCPOPTSTRIP</H3>
|
|
|
|
This target will strip TCP options off a TCP packet. (It will actually replace
|
|
them by NO-OPs.) As such, you will need to add the <B>-p tcp</B> parameters.
|
|
<DL COMPACT>
|
|
<DT id="502"><B>--strip-options</B> <I>option</I>[<B>,</B><I>option</I>...]<DD>
|
|
Strip the given option(s). The options may be specified by TCP option number or
|
|
by symbolic name. The list of recognized options can be obtained by calling
|
|
iptables with <B>-j TCPOPTSTRIP -h</B>.
|
|
</DL>
|
|
<A NAME="lbDV"> </A>
|
|
<H3>TEE</H3>
|
|
|
|
The <B>TEE</B> target will clone a packet and redirect this clone to another
|
|
machine on the <B>local</B> network segment. In other words, the nexthop
|
|
must be the target, or you will have to configure the nexthop to forward it
|
|
further if so desired.
|
|
<DL COMPACT>
|
|
<DT id="503"><B>--gateway</B> <I>ipaddr</I><DD>
|
|
Send the cloned packet to the host reachable at the given IP address.
|
|
Use of 0.0.0.0 (for IPv4 packets) or :: (IPv6) is invalid.
|
|
</DL>
|
|
<P>
|
|
|
|
To forward all incoming traffic on eth0 to an Network Layer logging box:
|
|
<P>
|
|
|
|
-t mangle -A PREROUTING -i eth0 -j TEE --gateway 2001:db8::1
|
|
<A NAME="lbDW"> </A>
|
|
<H3>TOS</H3>
|
|
|
|
This module sets the Type of Service field in the IPv4 header (including the
|
|
"precedence" bits) or the Priority field in the IPv6 header. Note that TOS
|
|
shares the same bits as DSCP and ECN. The TOS target is only valid in the
|
|
<B>mangle</B> table.
|
|
<DL COMPACT>
|
|
<DT id="504"><B>--set-tos</B> <I>value</I>[<B>/</B><I>mask</I>]<DD>
|
|
Zeroes out the bits given by <I>mask</I> (see NOTE below) and XORs <I>value</I>
|
|
into the TOS/Priority field. If <I>mask</I> is omitted, 0xFF is assumed.
|
|
<DT id="505"><B>--set-tos</B> <I>symbol</I><DD>
|
|
You can specify a symbolic name when using the TOS target for IPv4. It implies
|
|
a mask of 0xFF (see NOTE below). The list of recognized TOS names can be
|
|
obtained by calling iptables with <B>-j TOS -h</B>.
|
|
</DL>
|
|
<P>
|
|
|
|
The following mnemonics are available:
|
|
<DL COMPACT>
|
|
<DT id="506"><B>--and-tos</B> <I>bits</I><DD>
|
|
Binary AND the TOS value with <I>bits</I>. (Mnemonic for <B>--set-tos
|
|
0/</B><I>invbits</I>, where <I>invbits</I> is the binary negation of <I>bits</I>.
|
|
See NOTE below.)
|
|
<DT id="507"><B>--or-tos</B> <I>bits</I><DD>
|
|
Binary OR the TOS value with <I>bits</I>. (Mnemonic for <B>--set-tos</B>
|
|
<I>bits</I><B>/</B><I>bits</I>. See NOTE below.)
|
|
<DT id="508"><B>--xor-tos</B> <I>bits</I><DD>
|
|
Binary XOR the TOS value with <I>bits</I>. (Mnemonic for <B>--set-tos</B>
|
|
<I>bits</I><B>/0</B>. See NOTE below.)
|
|
</DL>
|
|
<P>
|
|
|
|
NOTE: In Linux kernels up to and including 2.6.38, with the exception of
|
|
longterm releases 2.6.32 (>=.42), 2.6.33 (>=.15), and 2.6.35 (>=.14), there is
|
|
a bug whereby IPv6 TOS mangling does not behave as documented and differs from
|
|
the IPv4 version. The TOS mask indicates the bits one wants to zero out, so it
|
|
needs to be inverted before applying it to the original TOS field. However, the
|
|
aformentioned kernels forgo the inversion which breaks --set-tos and its
|
|
mnemonics.
|
|
<A NAME="lbDX"> </A>
|
|
<H3>TPROXY</H3>
|
|
|
|
This target is only valid in the <B>mangle</B> table, in the <B>PREROUTING</B>
|
|
chain and user-defined chains which are only called from this chain. It
|
|
redirects the packet to a local socket without changing the packet header in
|
|
any way. It can also change the mark value which can then be used in advanced
|
|
routing rules.
|
|
It takes three options:
|
|
<DL COMPACT>
|
|
<DT id="509"><B>--on-port</B> <I>port</I><DD>
|
|
This specifies a destination port to use. It is a required option, 0 means the
|
|
new destination port is the same as the original. This is only valid if the
|
|
rule also specifies <B>-p tcp</B> or <B>-p udp</B>.
|
|
<DT id="510"><B>--on-ip</B> <I>address</I><DD>
|
|
This specifies a destination address to use. By default the address is the IP
|
|
address of the incoming interface. This is only valid if the rule also
|
|
specifies <B>-p tcp</B> or <B>-p udp</B>.
|
|
<DT id="511"><B>--tproxy-mark</B> <I>value</I>[<B>/</B><I>mask</I>]<DD>
|
|
Marks packets with the given value/mask. The fwmark value set here can be used
|
|
by advanced routing. (Required for transparent proxying to work: otherwise
|
|
these packets will get forwarded, which is probably not what you want.)
|
|
</DL>
|
|
<A NAME="lbDY"> </A>
|
|
<H3>TRACE</H3>
|
|
|
|
This target marks packets so that the kernel will log every rule which match
|
|
the packets as those traverse the tables, chains, rules. It can only be used in
|
|
the
|
|
<B>raw</B>
|
|
|
|
table.
|
|
<P>
|
|
|
|
With iptables-legacy, a logging backend, such as <A HREF="/cgi-bin/man/man2html?6+ip">ip</A>(6)t_LOG or nfnetlink_log,
|
|
must be loaded for this to be visible.
|
|
The packets are logged with the string prefix:
|
|
"TRACE: tablename:chainname:type:rulenum " where type can be "rule" for
|
|
plain rule, "return" for implicit rule at the end of a user defined chain
|
|
and "policy" for the policy of the built in chains.
|
|
<P>
|
|
|
|
With iptables-nft, the target is translated into nftables'
|
|
<B>meta nftrace</B>
|
|
|
|
expression. Hence the kernel sends trace events via netlink to userspace where
|
|
they may be displayed using
|
|
<B>xtables-monitor --trace</B>
|
|
|
|
command. For details, refer to
|
|
<B><A HREF="/cgi-bin/man/man2html?8+xtables-monitor">xtables-monitor</A></B>(8).
|
|
|
|
<A NAME="lbDZ"> </A>
|
|
<H3>TTL (IPv4-specific)</H3>
|
|
|
|
This is used to modify the IPv4 TTL header field. The TTL field determines
|
|
how many hops (routers) a packet can traverse until it's time to live is
|
|
exceeded.
|
|
<P>
|
|
|
|
Setting or incrementing the TTL field can potentially be very dangerous,
|
|
so it should be avoided at any cost. This target is only valid in
|
|
<B>mangle</B>
|
|
|
|
table.
|
|
<P>
|
|
|
|
<B>Don't ever set or increment the value on packets that leave your local network!</B>
|
|
|
|
<DL COMPACT>
|
|
<DT id="512"><B>--ttl-set</B> <I>value</I><DD>
|
|
Set the TTL value to `value'.
|
|
<DT id="513"><B>--ttl-dec</B> <I>value</I><DD>
|
|
Decrement the TTL value `value' times.
|
|
<DT id="514"><B>--ttl-inc</B> <I>value</I><DD>
|
|
Increment the TTL value `value' times.
|
|
</DL>
|
|
<A NAME="lbEA"> </A>
|
|
<H3>ULOG (IPv4-specific)</H3>
|
|
|
|
This is the deprecated ipv4-only predecessor of the NFLOG target.
|
|
It provides userspace logging of matching packets. When this
|
|
target is set for a rule, the Linux kernel will multicast this packet
|
|
through a
|
|
<I>netlink</I>
|
|
|
|
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.
|
|
<DL COMPACT>
|
|
<DT id="515"><B>--ulog-nlgroup</B> <I>nlgroup</I><DD>
|
|
This specifies the netlink group (1-32) to which the packet is sent.
|
|
Default value is 1.
|
|
<DT id="516"><B>--ulog-prefix</B> <I>prefix</I><DD>
|
|
Prefix log messages with the specified prefix; up to 32 characters
|
|
long, and useful for distinguishing messages in the logs.
|
|
<DT id="517"><B>--ulog-cprange</B> <I>size</I><DD>
|
|
Number of bytes to be copied to userspace. A value of 0 always copies
|
|
the entire packet, regardless of its size. Default is 0.
|
|
<DT id="518"><B>--ulog-qthreshold</B> <I>size</I><DD>
|
|
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).
|
|
<BR>
|
|
|
|
<P>
|
|
</DL>
|
|
|
|
<HR>
|
|
<A NAME="index"> </A><H2>Index</H2>
|
|
<DL>
|
|
<DT id="519"><A HREF="#lbAB">NAME</A><DD>
|
|
<DT id="520"><A HREF="#lbAC">SYNOPSIS</A><DD>
|
|
<DT id="521"><A HREF="#lbAD">MATCH EXTENSIONS</A><DD>
|
|
<DL>
|
|
<DT id="522"><A HREF="#lbAE">addrtype</A><DD>
|
|
<DT id="523"><A HREF="#lbAF">ah (IPv6-specific)</A><DD>
|
|
<DT id="524"><A HREF="#lbAG">ah (IPv4-specific)</A><DD>
|
|
<DT id="525"><A HREF="#lbAH">bpf</A><DD>
|
|
<DT id="526"><A HREF="#lbAI">cgroup</A><DD>
|
|
<DT id="527"><A HREF="#lbAJ">cluster</A><DD>
|
|
<DT id="528"><A HREF="#lbAK">comment</A><DD>
|
|
<DT id="529"><A HREF="#lbAL">connbytes</A><DD>
|
|
<DT id="530"><A HREF="#lbAM">connlabel</A><DD>
|
|
<DT id="531"><A HREF="#lbAN">connlimit</A><DD>
|
|
<DT id="532"><A HREF="#lbAO">connmark</A><DD>
|
|
<DT id="533"><A HREF="#lbAP">conntrack</A><DD>
|
|
<DT id="534"><A HREF="#lbAQ">cpu</A><DD>
|
|
<DT id="535"><A HREF="#lbAR">dccp</A><DD>
|
|
<DT id="536"><A HREF="#lbAS">devgroup</A><DD>
|
|
<DT id="537"><A HREF="#lbAT">dscp</A><DD>
|
|
<DT id="538"><A HREF="#lbAU">dst (IPv6-specific)</A><DD>
|
|
<DT id="539"><A HREF="#lbAV">ecn</A><DD>
|
|
<DT id="540"><A HREF="#lbAW">esp</A><DD>
|
|
<DT id="541"><A HREF="#lbAX">eui64 (IPv6-specific)</A><DD>
|
|
<DT id="542"><A HREF="#lbAY">frag (IPv6-specific)</A><DD>
|
|
<DT id="543"><A HREF="#lbAZ">hashlimit</A><DD>
|
|
<DT id="544"><A HREF="#lbBA">hbh (IPv6-specific)</A><DD>
|
|
<DT id="545"><A HREF="#lbBB">helper</A><DD>
|
|
<DT id="546"><A HREF="#lbBC">hl (IPv6-specific)</A><DD>
|
|
<DT id="547"><A HREF="#lbBD">icmp (IPv4-specific)</A><DD>
|
|
<DT id="548"><A HREF="#lbBE">icmp6 (IPv6-specific)</A><DD>
|
|
<DT id="549"><A HREF="#lbBF">iprange</A><DD>
|
|
<DT id="550"><A HREF="#lbBG">ipv6header (IPv6-specific)</A><DD>
|
|
<DT id="551"><A HREF="#lbBH">ipvs</A><DD>
|
|
<DT id="552"><A HREF="#lbBI">length</A><DD>
|
|
<DT id="553"><A HREF="#lbBJ">limit</A><DD>
|
|
<DT id="554"><A HREF="#lbBK">mac</A><DD>
|
|
<DT id="555"><A HREF="#lbBL">mark</A><DD>
|
|
<DT id="556"><A HREF="#lbBM">mh (IPv6-specific)</A><DD>
|
|
<DT id="557"><A HREF="#lbBN">multiport</A><DD>
|
|
<DT id="558"><A HREF="#lbBO">nfacct</A><DD>
|
|
<DT id="559"><A HREF="#lbBP">osf</A><DD>
|
|
<DT id="560"><A HREF="#lbBQ">owner</A><DD>
|
|
<DT id="561"><A HREF="#lbBR">physdev</A><DD>
|
|
<DT id="562"><A HREF="#lbBS">pkttype</A><DD>
|
|
<DT id="563"><A HREF="#lbBT">policy</A><DD>
|
|
<DT id="564"><A HREF="#lbBU">quota</A><DD>
|
|
<DT id="565"><A HREF="#lbBV">rateest</A><DD>
|
|
<DT id="566"><A HREF="#lbBW">realm (IPv4-specific)</A><DD>
|
|
<DT id="567"><A HREF="#lbBX">recent</A><DD>
|
|
<DT id="568"><A HREF="#lbBY">rpfilter</A><DD>
|
|
<DT id="569"><A HREF="#lbBZ">rt (IPv6-specific)</A><DD>
|
|
<DT id="570"><A HREF="#lbCA">sctp</A><DD>
|
|
<DT id="571"><A HREF="#lbCB">set</A><DD>
|
|
<DT id="572"><A HREF="#lbCC">socket</A><DD>
|
|
<DT id="573"><A HREF="#lbCD">state</A><DD>
|
|
<DT id="574"><A HREF="#lbCE">statistic</A><DD>
|
|
<DT id="575"><A HREF="#lbCF">string</A><DD>
|
|
<DT id="576"><A HREF="#lbCG">tcp</A><DD>
|
|
<DT id="577"><A HREF="#lbCH">tcpmss</A><DD>
|
|
<DT id="578"><A HREF="#lbCI">time</A><DD>
|
|
<DT id="579"><A HREF="#lbCJ">tos</A><DD>
|
|
<DT id="580"><A HREF="#lbCK">ttl (IPv4-specific)</A><DD>
|
|
<DT id="581"><A HREF="#lbCL">u32</A><DD>
|
|
<DT id="582"><A HREF="#lbCM">udp</A><DD>
|
|
</DL>
|
|
<DT id="583"><A HREF="#lbCN">TARGET EXTENSIONS</A><DD>
|
|
<DL>
|
|
<DT id="584"><A HREF="#lbCO">AUDIT</A><DD>
|
|
<DT id="585"><A HREF="#lbCP">CHECKSUM</A><DD>
|
|
<DT id="586"><A HREF="#lbCQ">CLASSIFY</A><DD>
|
|
<DT id="587"><A HREF="#lbCR">CLUSTERIP (IPv4-specific)</A><DD>
|
|
<DT id="588"><A HREF="#lbCS">CONNMARK</A><DD>
|
|
<DT id="589"><A HREF="#lbCT">CONNSECMARK</A><DD>
|
|
<DT id="590"><A HREF="#lbCU">CT</A><DD>
|
|
<DT id="591"><A HREF="#lbCV">DNAT</A><DD>
|
|
<DT id="592"><A HREF="#lbCW">DNPT (IPv6-specific)</A><DD>
|
|
<DT id="593"><A HREF="#lbCX">DSCP</A><DD>
|
|
<DT id="594"><A HREF="#lbCY">ECN (IPv4-specific)</A><DD>
|
|
<DT id="595"><A HREF="#lbCZ">HL (IPv6-specific)</A><DD>
|
|
<DT id="596"><A HREF="#lbDA">HMARK</A><DD>
|
|
<DT id="597"><A HREF="#lbDB">IDLETIMER</A><DD>
|
|
<DT id="598"><A HREF="#lbDC">LED</A><DD>
|
|
<DT id="599"><A HREF="#lbDD">LOG</A><DD>
|
|
<DT id="600"><A HREF="#lbDE">MARK</A><DD>
|
|
<DT id="601"><A HREF="#lbDF">MASQUERADE</A><DD>
|
|
<DT id="602"><A HREF="#lbDG">NETMAP</A><DD>
|
|
<DT id="603"><A HREF="#lbDH">NFLOG</A><DD>
|
|
<DT id="604"><A HREF="#lbDI">NFQUEUE</A><DD>
|
|
<DT id="605"><A HREF="#lbDJ">NOTRACK</A><DD>
|
|
<DT id="606"><A HREF="#lbDK">RATEEST</A><DD>
|
|
<DT id="607"><A HREF="#lbDL">REDIRECT</A><DD>
|
|
<DT id="608"><A HREF="#lbDM">REJECT (IPv6-specific)</A><DD>
|
|
<DT id="609"><A HREF="#lbDN">REJECT (IPv4-specific)</A><DD>
|
|
<DT id="610"><A HREF="#lbDO">SECMARK</A><DD>
|
|
<DT id="611"><A HREF="#lbDP">SET</A><DD>
|
|
<DT id="612"><A HREF="#lbDQ">SNAT</A><DD>
|
|
<DT id="613"><A HREF="#lbDR">SNPT (IPv6-specific)</A><DD>
|
|
<DT id="614"><A HREF="#lbDS">SYNPROXY</A><DD>
|
|
<DT id="615"><A HREF="#lbDT">TCPMSS</A><DD>
|
|
<DT id="616"><A HREF="#lbDU">TCPOPTSTRIP</A><DD>
|
|
<DT id="617"><A HREF="#lbDV">TEE</A><DD>
|
|
<DT id="618"><A HREF="#lbDW">TOS</A><DD>
|
|
<DT id="619"><A HREF="#lbDX">TPROXY</A><DD>
|
|
<DT id="620"><A HREF="#lbDY">TRACE</A><DD>
|
|
<DT id="621"><A HREF="#lbDZ">TTL (IPv4-specific)</A><DD>
|
|
<DT id="622"><A HREF="#lbEA">ULOG (IPv4-specific)</A><DD>
|
|
</DL>
|
|
</DL>
|
|
<HR>
|
|
This document was created by
|
|
<A HREF="/cgi-bin/man/man2html">man2html</A>,
|
|
using the manual pages.<BR>
|
|
Time: 00:06:13 GMT, March 31, 2021
|
|
</BODY>
|
|
</HTML>
|