Xtables-addons - additional extensions for iptables, ip6tables, etc.
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 deferred connection reset, fooling some network scanners to return non-deterministic (randomly open/closed) results, and in case it is deemed open, it is actually closed/filtered.
--tarpit
Use the REJECT and TARPIT target as a base to hold the connection until it times out. This consumes conntrack entries when connection tracking is loaded (which usually is on most machines), and routers inbetween you and the Internet may fail to do their connection tracking if they have to handle more connections than they can.
The randomness factor of not replying vs. replying can be set during load-time of the xt_CHAOS module or during runtime in /sys/modules/xt_CHAOS/parameters.
See http://jengelh.medozas.de/projects/chaostables/ for more information about CHAOS, DELUDE and portscan.
The DELUDE target will reply to a SYN packet with SYN-ACK, and to all other packets with an RST. This will terminate the connection much like REJECT, but network scanners doing TCP half-open discovery can be spoofed to make them belive the port is open rather than closed/filtered.
Allows you to mark a received packet basing on its IP address. This
can replace many mangle/mark entries with only one, if you use
firewall 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 it as a mark. (This is done before ANDing or ORing it.) This option is needed to 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 adequate to the IP address of the user, e.g.: all packets going to/from 192.168.5.2 are 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 load decrease (e.g. twice).
(IPv6 example) If the source address is of the form 2001: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 --shift 16 --and-mask 0xFFFF
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 useful for distinguishing messages in the logs.
--log-nfmark
Include the packet mark in the log.
--log-ctmark
Include the connection mark in the log.
--log-secmark
Include the packet secmark in the log.
The SYSRQ target allows to remotely trigger sysrq on the local machine over the network. This can be useful when vital parts of the machine hang, for example an oops in a filesystem causing locks to be not released and processes to get stuck as a result -- if still possible, use /proc/sysrq-trigger. Even when processes are stuck, interrupts are likely to be still processed, and as such, sysrq can be triggered through incoming network packets.
This xt_SYSRQ implementation does not use any encryption, so you should change the SYSRQ password after use unless you have made sure it was transmitted securely and no one sniffed the network, e.g. by use of an IPsec tunnel whose endpoint is at the machine where you want to trigger the sysrq. Also, you should limit as to who can issue commands using -s and/or -m mac, and also that the destination is correct 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 -d 10.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-dst 10.10.25.7 -p udp --dport 9 -j SYSRQ
This extension does not take any options. The -p udp options are required.
The SYSRQ password can be changed through /sys/module/xt_SYSRQ/parameters/password; note you need to use `echo -n` to not add a newline to the password, i.e.
echo -n "password" >/sys/.../password
Alternatively, the password may be specified at modprobe time, but this is insecure as people can possible see it through ps(1). You can use an option line in /etc/modprobe.d/sysrq if it is properly guarded, that is, only readable by root.
options xt_SYSRQ password=cookies
To trigger SYSRQ from a remote host, just use netcat or socat, specifying the action (only one) as first character, followed by the password:
echo -n "scookies" | socat stdin udp-sendto:10.10.25.7:9
echo -n "scookies" | netcat -u 10.10.25.7 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.
Captures and holds incoming TCP connections using no local per-connection
resources. Connections are accepted, but immediately switched to the persist
state (0 byte window), in which the remote side stops sending data and asks to
continue every 60-240 seconds. Attempts to close the connection are ignored,
forcing the remote side to time out the connection in 12-24 minutes.
This offers similar functionality to LaBrea
<http://www.hackbusters.net/LaBrea/> but does not require dedicated hardware or
IPs. Any TCP port that you would normally DROP or REJECT can instead become a
tarpit.
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. "ip route 10.0.0.0 255.0.0.0 ip.of.linux.box" on a Cisco), enable IP forwarding on the 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 use the NOTRACK target, or the kernel will unnecessarily allocate resources for each TARPITted connection. To TARPIT incoming connections to the standard IRC port while using conntrack, you could:
-t raw -A PREROUTING -p tcp --dport 6667 -j NOTRACK
-A INPUT -p tcp --dport 6667 -j TARPIT
This matches if a specific condition variable is (un)set.
[!] --condition name
Match on boolean value stored in /proc/net/nf_condition/name.
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 ISO3166 code.
The extra files you will need is the binary database files. They are generated from a country-subnet database with the geoip_csv_iv0.pl tool, available at http://jengelh.hopto.org/files/geoip/ . The files MUST be moved to /var/geoip/ as the shared library is statically looking for this pathname (e.g. /var/geoip/LE/de.iv0).
This module matches certain packets in P2P flows. It is not
designed to match all packets belonging to a P2P connection -
use IPP2P together with CONNMARK for this purpose. Also visit
http://www.ipp2p.org for detailed information.
Use it together with -p tcp or -p udp to search these protocols
only or without -p switch to search packets of both protocols.
IPP2P provides the following options:
--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. May produce huge logfiles so beware!
Detects simple port scan attemps based upon the packet's contents. (This is different from other implementations, which also try to match the rate of new connections.) Note that an attempt is only discovered after it has been carried out, but this information can be used in conjunction with other rules to block the 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. the connection 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. the connection 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 its identification. (e.g. openssh)
NOTE: Some clients (Windows XP for example) may do what looks like a SYN scan, so be advised to carefully use xt_portscan in conjunction with blocking rules, as it may lock out your very own internal network.
The "quota2" implements a named counter which can be increased or decreased on 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 making this match a minimalist accounting tool.
When counting down from the initial quota, the counter will stop at 0 and the 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.
--name name
Assign the counter a specific name. This option must be present, as an empty name is not allowed. Names starting with a dot or names containing a slash are prohibited.
[!] --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. The negation 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 various purposes, for example, a bytebucket filter that only lets as much traffic go out 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
iptables(8), ip6tables(8)
For developers, the book "Writing your own Netfilter modules" at http://jengelh.medozas.de/documents/Netfilter_Modules.pdf provides detailed information on how to write such modules/extensions.