MAN page from CentOS 7 xtables-addons-2.6-1cnt7.x86_64.rpm

xtables-addons

Section: v2.6 (2014-09-29) (8)
Updated: Red October
Index

Name

Xtables-addons --- additional extensions for iptables, ip6tables, etc.

Targets

ACCOUNT

The ACCOUNT target is a high performance accounting system for largelocal networks. It allows per-IP accounting in whole prefixes of IPv4addresses with size of up to /8 without the need to add individualaccouting rule for each IP address.

The ACCOUNT is designed to be queried for data every second or atleast every ten seconds. It is written as kernel module to handle highbandwidths without packet loss.

The largest possible subnet size is 24 bit, meaning for example 10.0.0.0/8network. ACCOUNT uses fixed internal data structureswhich speeds up the processing of each packet. Furthermore,accounting data for one complete 192.168.1.X/24 network takes 4 KB ofmemory. Memory for 16 or 24 bit networks is only allocated whenneeded.

To optimize the kernel<->userspace data transfer a bit more, thekernel module only transfers information about IPs, where the src/dstpacket counter is not 0. This saves precious kernel time.

There is no /proc interface as it would be too slow for continuous access.The read-and-flush query operation is the fastest, as no internal datasnapshot needs to be created&copied for all data. Use the "read"operation without flush only for debugging purposes!

Usage:

ACCOUNT takes two mandatory parameters:

--addr network/netmask: where network/netmask is the subnet to account for, in CIDR syntax
--tname NAME: where NAME is the name of the table where the accounting informationshould be stored

The subnet 0.0.0.0/0 is a special case: all data are then stored in the src_bytesand src_packets structure of slot "0". This is useful if you wantto account the overall traffic to/from your internet provider.

The data can be queried using the userspace libxt_ACCOUNT_cl library,and by the reference implementation to show usage of this library,the iptaccount(8) tool.

Here is an example of use:

iptables -A FORWARD -j ACCOUNT --addr 0.0.0.0/0 --tname all_outgoing;iptables -A FORWARD -j ACCOUNT --addr 192.168.1.0/24 --tname sales;

This creates two tables called "all_outgoing" and "sales" which can bequeried using the userspace library/iptaccount tool.

Note that this target is non-terminating --- the packet destined to itwill continue traversing the chain in which it has been used.

Also note that once a table has been defined for specific CIDR address/netmaskblock, it can be referenced multiple times using -j ACCOUNT, providedthat both the original table name and address/netmask block are specified.

For more information go to http://www.intra2net.com/en/developer/ipt_ACCOUNT/

CHAOS

Causes confusion on the other end by doing odd things with incoming packets.CHAOS will randomly reply (or not) with one of its configurable subtargets:

--delude: Use the REJECT and DELUDE targets as a base to do a sudden or deferredconnection reset, fooling some network scanners to return non-deterministic(randomly open/closed) results, and in case it is deemed open, it is actuallyclosed/filtered.
--tarpit: Use the REJECT and TARPIT target as a base to hold the connection until ittimes out. This consumes conntrack entries when connection tracking is loaded(which usually is on most machines), and routers inbetween you and the Internetmay fail to do their connection tracking if they have to handle moreconnections than they can.

The randomness factor of not replying vs. replying can be set during load-timeof the xt_CHAOS module or during runtime in /sys/modules/xt_CHAOS/parameters.

See http://inai.de/projects/chaostables/ for more informationabout CHAOS, DELUDE and lscan.

DELUDE

The DELUDE target will reply to a SYN packet with SYN-ACK, and to all otherpackets with an RST. This will terminate the connection much like REJECT, butnetwork scanners doing TCP half-open discovery can be spoofed to make thembelive the port is open rather than closed/filtered.

DHCPMAC

In conjunction with ebtables, DHCPMAC can be used to completely change all MACaddresses from and to a VMware-based virtual machine. This is needed becauseVMware does not allow to set a non-VMware MAC address before an operatingsystem is booted (and the MAC be changed with `ip link set eth0 addressaa:bb..`).

--set-mac aa:bb:cc:dd:ee:ff[/mask]: Replace the client host MAC address field in the DHCP message with the givenMAC address. This option is mandatory. The mask parameter specifies theprefix length of bits to change.

EXAMPLE, replacing all addresses from one of VMware's assigned vendor IDs(00:50:56) addresses with something else:

iptables -t mangle -A FORWARD -p udp --dport 67 -m physdev--physdev-in vmnet1 -m dhcpmac --mac 00:50:56:00:00:00/24 -j DHCPMAC--set-mac ab:cd:ef:00:00:00/24

iptables -t mangle -A FORWARD -p udp --dport 68 -m physdev--physdev-out vmnet1 -m dhcpmac --mac ab:cd:ef:00:00:00/24 -j DHCPMAC--set-mac 00:50:56:00:00:00/24

(This assumes there is a bridge interface that has vmnet1 as a port. You willalso need to add appropriate ebtables rules to change the MAC address of theEthernet headers.)

DNETMAP

The DNETMAP target allows dynamic two-way 1:1 mapping of IPv4 subnets. Asingle rule can map a private subnet to a shorter public subnet, creating andmaintaining unambiguous private-public IP address bindings. The second rule canbe used to map new flows to a private subnet according to maintained bindings.The target allows efficient public IPv4 space usage and unambiguous NAT at thesame time.

The target can be used only in the nat table in POSTROUTING orOUTPUT chains for SNAT, and in PREROUTING for DNAT. Only flowsdirected to bound addresses will be DNATed. The packet continues chaintraversal if there is no free postnat address to be assigned to the prenataddress. The default binding TTL is 10 minutes and can be changedusing the default_ttl module option. The default address hash size is 256and can be changed using the hash_size module option.

--prefix addr/mask: The network subnet to map to. If not specified, all existing prefixes are used.
--reuse: Reuse the entry for a given prenat address from any prefix even if thebinding's TTL is < 0.
--persistent: Set the prefix to be persistent. It will not be removed after deleting the lastiptables rule. The option is effective only in the first rule for a givenprefix. If you need to change persistency for an existing prefix, please usethe procfs interface described below.
--static: Do not create dynamic mappings using this rule. Use static mappings only. Notethat you need to create static mappings via the procfs interface for this rulefor this option to have any effect.
--ttl seconds: Reset the binding's TTL value to seconds. If a negative value isspecified, the binding's TTL is kept unchanged. If this option is notspecified, then the default TTL value (600s) is used.

* /proc interface

The module creates the following entries for each new specified subnet:

/proc/net/xt_DNETMAP/subnet_mask: Contains the binding table for the given subnet/mask. Each line containsprenat address, postnat address, ttl (seconds until the entrytimes out), lasthit (last hit to the entry in seconds relative to systemboot time). Please note that the ttl and lasthit entries contain anS' in case of a static binding.
/proc/net/xt_DNETMAP/subnet_mask_stat: Contains statistics for a given subnet/mask. The line contains fournumerical values separated by spaces. The first one is the number of currentlyused dynamic addresses (bindings with negative TTL excluded), the second one isthe number of static assignments, the third one is the number of all usableaddresses in the subnet, and the fourth one is the mean TTL value for allactive entries. If the prefix has the persistent flag set, it will be noted asfifth entry.

The following write operations are supported via the procfs interface:

echo "+prenat-address:postnat-address" >/proc/net/xt_DNETMAP/subnet_mask: Adds a static binding between the prenat and postnap address. Ifpostnat_address is already bound, any previous binding will be timed outimmediately. A static binding is never timed out.
echo "-address" >/proc/net/xt_DNETMAP/subnet_mask: Removes the binding with address as prenat or postnat address. If theremoved binding is currently static, it will make the entry available fordynamic allocation.
echo "+persistent" >/proc/net/xt_DNETMAP/subnet_mask: Sets the persistent flag for the prefix. It is useful if you do not wantbindings to get flushed when the firewall is restarted. You can check if theprefix is persistent by printing the contents of/proc/net/xt_DNETMAP/subnet_mask_stat.
echo "-persistent" >/proc/net/xt_DNETMAP/subnet_mask: Unsets the persistent flag for the prefix. In this mode, the prefix will bedeleted if the last iptables rule for that prefix is removed.
echo "flush" >/proc/net/xt_DNETMAP/subnet_mask: Flushes all bindings for the specific prefix. All static entries are alsoflushed and become available for dynamic bindings.

Note! Entries are removed if the last iptables rule for a specific prefix isdeleted unless the persistent flag is set.

* Logging

The module logs binding add/timeout events to klog. This behaviour can bedisabled using the disable_log module parameter.

* Examples

1. Map subnet 192.168.0.0/24 to subnets 20.0.0.0/26. SNAT only:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 20.0.0.0/26

Active hosts from the 192.168.0.0/24 subnet are mapped to 20.0.0.0/26. If thepacket from a not yet bound prenat address hits the rule and there are no freeor timed-out (TTL<0) entries in prefix 20.0.0.0/28, then a notice is logged toklog and chain traversal continues. If packet from an already-bound prenataddress hits the rule, the binding's TTL value is reset to default_ttl and SNATis performed.

2. Use of --reuse and --ttl switches, multiple ruleinteraction:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix20.0.0.0/26 --reuse --ttl 200

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 30.0.0.0/26

Active hosts from 192.168.0.0/24 subnet are mapped to 20.0.0.0/26 with TTL =200 seconds. If there are no free addresses in first prefix, the next one(30.0.0.0/26) is used with the default TTL. It is important to note that thefirst rule SNATs all flows whose source address is already actively bound(TTL>0) to ANY prefix. The --reuse parameter makes this functionalitywork even for inactive (TTL<0) entries.

If both subnets are exhausted, then chain traversal continues.

3. Map 192.168.0.0/24 to subnets 20.0.0.0/26 in a bidirectional way:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 20.0.0.0/26

iptables -t nat -A PREROUTING -j DNETMAP

If the host 192.168.0.10 generates some traffic, it gets bound to first freeaddress in the subnet --- 20.0.0.0. Now, any traffic directed to 20.0.0.0 getsDNATed to 192.168.0.10 as long as there is an active (TTL>0) binding. There isno need to specify --prefix parameter in a PREROUTING rule, becausethis way, it DNATs traffic to all active prefixes. You could specify the prefixyou would like to make DNAT work for a specific prefix only.

4. Map 192.168.0.0/24 to subnets 20.0.0.0/26 with static assignmentsonly:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 20.0.0.0/26--static

echo "+192.168.0.10:20.0.0.1" >/proc/net/xt_DNETMAP/20.0.0.0_26
echo "+192.168.0.11:20.0.0.2" >/proc/net/xt_DNETMAP/20.0.0.0_26
echo "+192.168.0.51:20.0.0.3" >/proc/net/xt_DNETMAP/20.0.0.0_26

This configuration will allow only preconfigured static bindings to work due tothe static rule option. Without this flag, dynamic bindings would becreated using non-static entries.

5. Persistent prefix:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 20.0.0.0/26--persistent
or
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j DNETMAP --prefix 20.0.0.0/26
echo "+persistent" >/proc/net/xt_DNETMAP/20.0.0.0_26

Now, we can check the persistent flag of the prefix:
cat /proc/net/xt_DNETMAP/20.0.0.0_26
0 0 64 0 persistent

Flush the iptables nat table and see that prefix is still in existence:
iptables -F -t nat
ls -l /proc/net/xt_DNETMAP
-rw-r--r-- 1 root root 0 06-10 09:01 20.0.0.0_26
-rw-r--r-- 1 root root 0 06-10 09:01 20.0.0.0_26_stat

ECHO

The ECHO target will send back all packets it received. It serves as anexamples for an Xtables target.

ECHO takes no options.

IPMARK

Allows you to mark a received packet basing on its IP address. Thiscan replace many mangle/mark entries with only one, if you usefirewall based classifier.

This target is to be used inside the mangle table.

--addr {src|dst}: Select source or destination IP address as a basis for the mark.
--and-mask mask: Perform bitwise AND on the IP address and this bitmask.
--or-mask mask: Perform bitwise OR on the IP address and this bitmask.
--shift value: Shift addresses to the right by the given number of bits before taking itas a mark. (This is done before ANDing or ORing it.) This option is neededto select part of an IPv6 address, because marks are only 32 bits in size.

The order of IP address bytes is reversed to meet "human order of bytes":192.168.0.1 is 0xc0a80001. At first the "AND" operation is performed, then"OR".

Examples:

We create a queue for each user, the queue number is adequateto the IP address of the user, e.g.: all packets going to/from 192.168.5.2are directed to 1:0502 queue, 192.168.5.12 -> 1:050c etc.

We have one classifier rule:

: tc filter add dev eth3 parent 1:0 protocol ip fw

Earlier we had many rules just like below:

: iptables -t mangle -A POSTROUTING -o eth3 -d 192.168.5.2 -j MARK--set-mark 0x10502
: iptables -t mangle -A POSTROUTING -o eth3 -d 192.168.5.3 -j MARK--set-mark 0x10503

Using IPMARK target we can replace all the mangle/mark rules with only one:

: iptables -t mangle -A POSTROUTING -o eth3 -j IPMARK --addr dst--and-mask 0xffff --or-mask 0x10000

On the routers with hundreds of users there should be significant loaddecrease (e.g. twice).

(IPv6 example) If the source address is of the form2001:db8:45:1d:20d:93ff:fe9b:e443 and the resulting mark should be 0x93ff,then a right-shift of 16 is needed first:

: -t mangle -A PREROUTING -s 2001:db8::/32 -j IPMARK --addr src --shift16 --and-mask 0xFFFF

LOGMARK

The LOGMARK target will log packet and connection marks to syslog.

--log-level level: A logging level between 0 and 8 (inclusive).
--log-prefix string: Prefix log messages with the specified prefix; up to 29 bytes long, and usefulfor distinguishing messages in the logs.

SYSRQ

The SYSRQ target allows to remotely trigger sysrq on the local machine over thenetwork. This can be useful when vital parts of the machine hang, for examplean oops in a filesystem causing locks to be not released and processes to getstuck as a result --- if still possible, use /proc/sysrq-trigger. Even whenprocesses are stuck, interrupts are likely to be still processed, and as such,sysrq can be triggered through incoming network packets.

The xt_SYSRQ implementation uses a salted hash and a sequence number to preventnetwork sniffers from either guessing the password or replaying earlierrequests. The initial sequence number comes from the time of day so you willhave a small window of vulnerability should time go backwards at a reboot.However, the file /sys/module/xt_SYSREQ/seqno can be used to both query andupdate the current sequence number. Also, you should limit as to who can issuecommands using -s and/or -m mac, and also that the destination iscorrect using -d (to protect against potential broadcast packets),noting that it is still short of MAC/IP spoofing:

: -A INPUT -s 10.10.25.1 -m mac --mac-source aa:bb:cc:dd:ee:ff -d10.10.25.7 -p udp --dport 9 -j SYSRQ
: (with IPsec) -A INPUT -s 10.10.25.1 -d 10.10.25.7 -m policy --dir in--pol ipsec --proto esp --tunnel-src 10.10.25.1 --tunnel-dst10.10.25.7 -p udp --dport 9 -j SYSRQ

You should also limit the rate at which connections can be received to limitthe CPU time taken by illegal requests, for example:

: -A INPUT -s 10.10.25.1 -m mac --mac-source aa:bb:cc:dd:ee:ff -d10.10.25.7 -p udp --dport 9 -m limit --limit 5/minute -j SYSRQ

This extension does not take any options. The -p udp options arerequired.

The SYSRQ password can be changed through/sys/module/xt_SYSRQ/parameters/password, for example:

: echo -n "password" >/sys/module/xt_SYSRQ/parameters/password

The module will not respond to sysrq requests until a password has been set.

Alternatively, the password may be specified at modprobe time, but this isinsecure as people can possible see it through ps(1). You can use an optionline in e.g. /etc/modprobe.d/xt_sysrq if it is properly guarded, that is, onlyreadable by root.

: options xt_SYSRQ password=cookies

The hash algorithm can also be specified as a module option, for example, touse SHA-256 instead of the default SHA-1:

: options xt_SYSRQ hash=sha256

The xt_SYSRQ module is normally silent unless a successful request is received,but the debug module parameter can be used to find exactly why aseemingly correct request is not being processed.

To trigger SYSRQ from a remote host, just use socat:

sysrq_key="s"  # the SysRq key(s)password="password"seqno="$(date +%s)"salt="$(dd bs=12 count=1 if=/dev/urandom 2>/dev/null |    openssl enc -base64)"ipaddr="2001:0db8:0000:0000:0000:ff00:0042:8329"req="$sysrq_key,$seqno,$salt"req="$req,$(echo -n "$req,$ipaddr,$password" | sha1sum | cut -c1-40)"echo "$req" | socat stdin udp-sendto:$ipaddr:9

See the Linux docs for possible sysrq keys. Important ones are: re(b)oot,power(o)ff, (s)ync filesystems, (u)mount and remount readonly. More than onesysrq key can be used at once, but bear in mind that, for example, a sync maynot complete before a subsequent reboot or poweroff.

An IPv4 address should have no leading zeros, an IPv6 address shouldbe in the full expanded form (as shown above). The debug option will causeoutput to be emitted in the same form.

The hashing scheme should be enough to prevent mis-use of SYSRQ in manyenvironments, but it is not perfect: take reasonable precautions toprotect your machines.

TARPIT

Captures and holds incoming TCP connections using no local per-connectionresources.

TARPIT only works at the TCP level, and is totally application agnostic. Thismodule will answer a TCP request and play along like a listening server, butaside from sending an ACK or RST, no data is sent. Incoming packets are ignoredand dropped. The attacker will terminate the session eventually. This moduleallows the initial packets of an attack to be captured by other software forinspection. In most cases this is sufficient to determine the nature of theattack.

This offers similar functionality to LaBrea<http://www.hackbusters.net/LaBrea/> but does not require dedicated hardware orIPs. Any TCP port that you would normally DROP or REJECT can instead become atarpit.

--tarpit: This mode completes a connection with the attacker but limits the window sizeto 0, thus keeping the attacker waiting long periods of time. While he ismaintaining state of the connection and trying to continue every 60-240seconds, we keep none, so it is very lightweight. Attempts to close theconnection are ignored, forcing the remote side to time out the connection in12-24 minutes. This mode is the default.
--honeypot: This mode completes a connection with the attacker, but signals a normal windowsize, so that the remote side will attempt to send data, often with some verynasty exploit attempts. We can capture these packets for decoding and furtheranalysis. The module does not send any data, so if the remote expects anapplication level response, the game is up.
--reset: This mode is handy because we can send an inline RST (reset). It has no otherfunction.

To tarpit connections to TCP port 80 destined for the current machine:

: -A INPUT -p tcp -m tcp --dport 80 -j TARPIT

To significantly slow down Code Red/Nimda-style scans of unused address space,forward unused ip addresses to a Linux box not acting as a router (e.g. "iproute 10.0.0.0 255.0.0.0 ip.of.linux.box" on a Cisco), enable IP forwarding onthe Linux box, and add:

: -A FORWARD -p tcp -j TARPIT
: -A FORWARD -j DROP

NOTE:If you use the conntrack module while you are using TARPIT, you should also useunset tracking on the packet, or the kernel will unnecessarily allocateresources for each TARPITted connection. To TARPIT incoming connections to thestandard IRC port while using conntrack, you could:

: -t raw -A PREROUTING -p tcp --dport 6667 -j CT --notrack
: -A INPUT -p tcp --dport 6667 -j NFLOG
: -A INPUT -p tcp --dport 6667 -j TARPIT

Matches

condition

This matches if a specific condition variable is (un)set.

[!] --condition name: Match on boolean value stored in /proc/net/nf_condition/name.

dhcpmac

--mac aa:bb:cc:dd:ee:ff[/mask]: Matches the DHCP "Client Host" address (a MAC address) in a DHCP message.mask specifies the prefix length of the initial portion to match.

fuzzy

This module matches a rate limit based on a fuzzy logic controller (FLC).

--lower-limit number: Specifies the lower limit, in packets per second.
--upper-limit number: Specifies the upper limit, also in packets per second.

geoip

Match a packet by its source or destination country.

[!] --src-cc, --source-country country[,country...]: Match packet coming from (one of) the specified country(ies)
[!] --dst-cc, --destination-country country[,country...]: Match packet going to (one of) the specified country(ies)
NOTE:: The country is inputed by its ISO-3166 code.

The extra files you will need is the binary database files. They are generatedfrom a country-subnet database with the geoip_build_db.pl tool that is shippedwith the source package, and which should be available in compiled packages in/usr/lib(exec)/xtables-addons/. The first command retrieves CSV files fromMaxMind, while the other two build packed bisectable range files:

mkdir -p /usr/share/xt_geoip; cd /tmp; $path/to/xt_geoip_dl;

$path/to/xt_geoip_build -D /usr/share/xt_geoip GeoIP*.csv;

The shared library is hardcoded to look in these paths, so use them.

gradm

This module matches packets based on grsecurity RBAC status.

[!] --enabled: Matches packets if grsecurity RBAC is enabled.
[!] --disabled: Matches packets if grsecurity RBAC is disabled.

iface

Allows you to check interface states. First, an interface needs to be selectedfor comparison. Exactly one option of the following three must be specified:

--iface name: Check the states on the given interface.
--dev-in: Check the states on the interface on which the packet came in. If the inputdevice is not set, because for example you are using -m iface in the OUTPUTchain, this submatch returns false.
--dev-out: Check the states on the interface on which the packet will go out. If theoutput device is not set, because for example you are using -m iface in theINPUT chain, this submatch returns false.

Following that, one can select the interface properties to check for:

[!] --up, [!] --down: Check the UP flag.
[!] --broadcast: Check the BROADCAST flag.
[!] --loopback: Check the LOOPBACK flag.
[!] --pointtopoint: Check the POINTTOPOINT flag.
[!] --running: Check the RUNNING flag. Do NOT rely on it!
[!] --noarp, [!] --arp: Check the NOARP flag.
[!] --promisc: Check the PROMISC flag.
[!] --multicast: Check the MULTICAST flag.
[!] --dynamic: Check the DYNAMIC flag.
[!] --lower-up: Check the LOWER_UP flag.
[!] --dormant: Check the DORMANT flag.

ipp2p

This module matches certain packets in P2P flows. It is notdesigned to match all packets belonging to a P2P connection ---use IPP2P together with CONNMARK for this purpose.

Use it together with -p tcp or -p udp to search these protocolsonly or without -p switch to search packets of both protocols.

IPP2P provides the following options, of which one or more may be specifiedon the command line:

--edk: Matches as many eDonkey/eMule packets as possible.
--kazaa: Matches as many KaZaA packets as possible.
--gnu: Matches as many Gnutella packets as possible.
--dc: Matches as many Direct Connect packets as possible.
--bit: Matches BitTorrent packets.
--apple: Matches AppleJuice packets.
--soul: Matches some SoulSeek packets. Considered as beta, use careful!
--winmx: Matches some WinMX packets. Considered as beta, use careful!
--ares: Matches Ares and AresLite packets. Use together with -j DROP only.
--debug: Prints some information about each hit into kernel logfile. Mayproduce huge logfiles so beware!

Note that ipp2p may not (and often, does not) identify all packets that areexchanged as a result of running filesharing programs.

There is more information on http://ipp2p.org/ , but it has not been updatedsince September 2006, and the syntax there is different from the ipp2p.cprovided in Xtables-addons; most importantly, the --ipp2p flag was removeddue to its ambiguity to match "all known" protocols.

ipv4options

The "ipv4options" module allows to match against a set of IPv4 header options.

--flags [!]symbol[,[!]symbol...]: Specify the options that shall appear or not appear in the header. Eachsymbol specification is delimited by a comma, and a '!' can be prefixed toa symbol to negate its presence. Symbols are either the name of an IPv4 optionor its number. See examples below.
--any: By default, all of the flags specified must be present/absent, that is, theyform an AND condition. Use the --any flag instead to use an OR conditionwhere only at least one symbol spec must be true.

Known symbol names (and their number):

1 --- nop

2 --- security --- RFC 1108

3 --- lsrr --- Loose Source Routing, RFC 791

4 --- timestamp --- RFC 781, 791

7 --- record-route --- RFC 791

9 --- ssrr --- Strict Source Routing, RFC 791

11 --- mtu-probe --- RFC 1063

12 --- mtu-reply --- RFC 1063

18 --- traceroute --- RFC 1393

20 --- router-alert --- RFC 2113

Examples:

Match packets that have both Timestamp and NOP:-m ipv4options --flags nop,timestamp

~ that have either of Timestamp or NOP, or both:--flags nop,timestamp --any

~ that have Timestamp and no NOP: --flags '!nop,timestamp'

~ that have either no NOP or a timestamp (or both conditions):--flags '!nop,timestamp' --any

length2

This module matches the length of a packet against a specific value or range ofvalues.

[!] --length length[:length]: Match exact length or length range.
--layer3: Match the layer3 frame size (e.g. IPv4/v6 header plus payload).
--layer4: Match the layer4 frame size (e.g. TCP/UDP header plus payload).
--layer5: Match the layer5 frame size (e.g. TCP/UDP payload, often called layer7).

If no --layer* option is given, --layer3 is assumed by default. Note thatusing --layer5 may not match a packet if it is not one of the recognizedtypes (currently TCP, UDP, UDPLite, ICMP, AH and ESP) or which has no 5thlayer.

lscan

Detects simple low-level scan attempts based upon the packet's contents.(This isdifferent from other implementations, which also try to match the rate of newconnections.) Note that an attempt is only discovered after it has been carriedout, but this information can be used in conjunction with other rules to blockthe remote host's future connections. So this match module will match on the(probably) last packet the remote side will send to your machine.

--stealth: Match if the packet did not belong to any known TCP connection(Stealth/FIN/XMAS/NULL scan).
--synscan: Match if the connection was a TCP half-open discovery (SYN scan), i.e. theconnection was torn down after the 2nd packet in the 3-way handshake.
--cnscan: Match if the connection was a TCP full open discovery (connect scan), i.e. theconnection was torn down after completion of the 3-way handshake.
--grscan: Match if data in the connection only flew in the direction of the remote side,e.g. if the connection was terminated after a locally running daemon sent itsidentification. (E.g. openssh, smtp, ftpd.) This may falsely trigger onwarranted single-direction data flows, usually bulk data transfers such asFTP DATA connections or IRC DCC. Grab Scan Detection should only be used onports where a protocol runs that is guaranteed to do a bidirectional exchangeof bytes.

NOTE: Some clients (Windows XP for example) may do what looks like a SYN scan,so be advised to carefully use xt_lscan in conjunction with blocking rules,as it may lock out your very own internal network.

psd

Attempt to detect TCP and UDP port scans. This match was derived fromSolar Designer's scanlogd.

--psd-weight-threshold threshold: Total weight of the latest TCP/UDP packets with differentdestination ports coming from the same host to be treated as portscan sequence.
--psd-delay-threshold delay: Delay (in hundredths of second) for the packets with differentdestination ports coming from the same host to be treated aspossible port scan subsequence.
--psd-lo-ports-weight weight: Weight of the packet with privileged (<=1024) destination port.
--psd-hi-ports-weight weight: Weight of the packet with non-priviliged destination port.

quota2

The "quota2" implements a named counter which can be increased or decreasedon a per-match basis. Available modes are packet counting or byte counting.The value of the counter can be read and reset through procfs, thereby makingthis match a minimalist accounting tool.

When counting down from the initial quota, the counter will stop at 0 andthe match will return false, just like the original "quota" match. In growing(upcounting) mode, it will always return true.

--grow: Count upwards instead of downwards.
--no-change: Makes it so the counter or quota amount is never changed by packets matchingthis rule. This is only really useful in "quota" mode, as it will allow you touse complex prerouting rules in association with the quota system, withoutcounting a packet twice.
--name name: Assign the counter a specific name. This option must be present, as an emptyname is not allowed. Names starting with a dot or names containing a slash areprohibited.
[!] --quota iq: Specify the initial quota for this counter. If the counter already exists,it is not reset. An "!" may be used to invert the result of the match. Thenegation has no effect when --grow is used.
--packets: Count packets instead of bytes that passed the quota2 match.

Because counters in quota2 can be shared, you can combine them for variouspurposes, for example, a bytebucket filter that only lets as much traffic goout as has come in:

-A INPUT -p tcp --dport 6881 -m quota --name bt --grow;-A OUTPUT -p tcp --sport 6881 -m quota --name bt;

pknock

Pknock match implements so-called "port knocking", a stealthy systemfor network authentication: a client sends packets to selectedports in a specific sequence (= simple mode, see example 1 below), or a HMACpayload to a single port (= complex mode, see example 2 below),to a target machine that has pknock rule(s) installed. The target machinethen decides whether to unblock or block (again) the pknock-protected port(s).This can be used, for instance, to avoid brute forceattacks on ssh or ftp services.

Example prerequisites:

: modprobe cn
: modprobe xt_pknock

Example 1 (TCP mode, manual closing of opened port not possible):

: iptables -P INPUT DROP
: iptables -A INPUT -p tcp -m pknock --knockports 4002,4001,4004 --strict--name SSH --time 10 --autoclose 60 --dport 22 -j ACCEPT

The rule will allow tcp port 22 for the attempting IP address after the successful reception of TCP SYN packetsto ports 4002, 4001 and 4004, in this order (a.k.a. port-knocking).Port numbers in the connect sequence must follow the exact specification, noother ports may be "knocked" inbetween. The rule is named 'SSH' --- a file ofthe same name for tracking port knocking states will be created in/proc/net/xt_pknock .Successive port knocks must occur with delay of at most 10 seconds. Port 22 (from the example) willbe automatiaclly dropped after 60 minutes after it was previously allowed.

Example 2 (UDP mode --- non-replayable and non-spoofable, manual closingof opened port possible, secure, also called "SPA" = Secure PortAuthorization):

: iptables -A INPUT -p udp -m pknock --knockports 4000 --name FTP--opensecret foo --closesecret bar --autoclose 240 -j DROP
: iptables -A INPUT -p tcp -m pknock --checkip --name FTP --dport 21 -j ACCEPT

The first rule will create an "ALLOWED" record in /proc/net/xt_pknock/FTP afterthe successful reception of an UDP packet to port 4000. The packet payload must beconstructed as a HMAC256 using "foo" as a key. The HMAC content is the particular client's IP address as a 32-bit network byteorder quantity,plus the number of minutes since the Unix epoch, also as a 32-bit value.(This is known as Simple Packet Authorization, also called "SPA".)In such case, any subsequent attempt to connect to port 21 from the client's IPaddress will cause such packets to be accepted in the second rule.

Similarly, upon reception of an UDP packet constructed the same way, but withthe key "bar", the first rule will remove a previously installed "ALLOWED" staterecord from /proc/net/xt_pknock/FTP, which means that the second rule willstop matching for subsequent connection attempts to port 21.In case no close-secret packet is received within 4 hours, the first rulewill remove "ALLOWED" record from /proc/net/xt_pknock/FTP itself.

Things worth noting:

General:

Specifying --autoclose 0 means that no automatic close will be performed at all.

xt_pknock is capable of sending information about successful matchesvia a netlink socket to userspace, should you need to implement your ownway of receiving and handling portknock notifications.Be sure to read the documentation in the doc/pknock/ directory,or visit the original site --- http://portknocko.berlios.de/ .

TCP mode:

This mode is not immune against eavesdropping, spoofing andreplaying of the port knock sequence by someone else (but its use may stillbe sufficient for scenarios where these factors are not necessarilythis important, such as bare shielding of the SSH port from brute-force attacks).However, if you need these features, you should use UDP mode.

It is always wise to specify three or more ports that are not monotonicallyincreasing or decreasing with a small stepsize (e.g. 1024,1025,1026)to avoid accidentally triggeringthe rule by a portscan.

Specifying the inter-knock timeout with --time is mandatory in TCP mode,to avoid permanent denial of services by clogging up the peer knock-state tracking tablethat xt_pknock internally keeps, should there be a DDoS on thefirst-in-row knock port from more hostile IP addresses than what the actual sizeof this table is (defaults to 16, can be changed via the "peer_hasht_ents" module parameter).It is also wise to use as short a time as possible (1 second) for --timefor this very reason. You may also consider increasing the sizeof the peer knock-state tracking table. Using --strict also helps,as it requires the knock sequence to be exact. This means that if thehostile client sends more knocks to the same port, xt_pknock willmark such attempt as failed knock sequence and will forget it immediately.To completely thwart this kind of DDoS, knock-ports would need to havean additional rate-limit protection. Or you may consider using UDP mode.

UDP mode:

This mode is immune against eavesdropping, replaying and spoofing attacks.It is also immune against DDoS attack on the knockport.

For this mode to work, the clock difference on the client and on the servermust be below 1 minute. Synchronizing time on both ends by meansof NTP or rdate is strongly suggested.

There is a rate limiter built into xt_pknock which blocks any subsequentopen attempt in UDP mode should the request arrive within less than oneminute since the first successful open. This is intentional;it thwarts eventual spoofing attacks.

Because the payload value of an UDP knock packet is influenced by client's IP address,UDP mode cannot be used across NAT.

For sending UDP "SPA" packets, you may use either knock.sh orknock-orig.sh. These may be found in doc/pknock/util.

Index

Name

Targets

ACCOUNT
CHAOS
DELUDE
DHCPMAC
DNETMAP
ECHO
IPMARK
LOGMARK
SYSRQ
TARPIT

Matches

condition
dhcpmac
fuzzy
geoip
gradm
iface
ipp2p
ipv4options
length2
lscan
psd
quota2
pknock

See also

This document was created byman2html,using the manual pages.