Man Linux: Main Page and Category List


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


       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.

       The xt_SYSRQ implementation uses a salted hash and a sequence number to
       prevent network sniffers from either guessing the password or replaying
       earlier  requests.  The  initial sequence number comes from the time of
       day so you will have 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 and update the current sequence number. 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

              -A INPUT -s -m mac --mac-source aa:bb:cc:dd:ee:ff  -d
     -p udp --dport 9 -j SYSRQ

              (with  IPsec)  -A  INPUT  -s -d -m policy
              --dir  in  --pol  ipsec  --proto  esp  --tunnel-src
              --tunnel-dst -p udp --dport 9 -j SYSRQ

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

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

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

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

              echo -n "password" >/sys/module/xt_SYSRQ/parameters/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 e.g. /etc/modprobe.d/xt_sysrq if it is properly guarded,
       that is, only readable by root.

              options xt_SYSRQ password=cookies

       The hash algorithm can also  be  specified  as  a  module  option,  for
       example, to use 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 a seemingly correct request is not being processed.

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

       sysrq_key="s"  # the SysRq key(s)
       seqno="$(date +%s)"
       salt="$(dd bs=12 count=1 if=/dev/urandom 2>/dev/null |
           openssl enc -base64)"
       req="$req,$(echo -n "$req,$password" | sha1sum | cut -c1-40)"

       echo "$req" | socat stdin udp-sendto:
       # or
       echo "$req" | netcat -uw1 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 one sysrq key can be used at once, but bear in mind
       that, for example, a sync may not complete before a  subsequent  reboot
       or poweroff.

       The hashing scheme should be enough to prevent mis-use of SYSRQ in many
       environments, but it is not perfect:  take  reasonable  precautions  to
       protect your machines.  Most importantly ensure that each machine has a
       different password; there is scant protection for a SYSRQ packet  being
       applied to a machine that happens to have the same password.

       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

       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
       <>  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" 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

       The  TEE  target will clone a packet and redirect this clone to another
       machine on the local 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.

       --gateway ipaddr
              Send the cloned packet to the host reachable  at  the  given  IP
              address.   Use  of  (for  IPv4 packets) or :: (IPv6) is

       To forward all incoming traffic on eth0 to  an  Network  Layer  logging

       -t mangle -A PREROUTING -i eth0 -j TEE --gateway 2001:db8::1

       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": is 0xc0a80001. At  first  the  "AND"  operation  is
       performed, then "OR".


       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  are
       directed to 1:0502 queue, -> 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 -j MARK
              --set-mark 0x10502

              iptables -t mangle -A POSTROUTING -o eth3 -d -j MARK
              --set-mark 0x10503

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

              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

       Like  the  DROP target, but does not throw an error like DROP when used
       in the OUTPUT chain.

       The RAWDNAT target will rewrite  the  destination  address  in  the  IP
       header, much like the NETMAP target.

       --to-destination addr[/mask]
              Network  address  to  map  to.  The  resulting  address  will be
              constructed 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.

       See the RAWSNAT help entry for examples and constraints.

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

       --set-mac aa:bb:cc:dd:ee:ff[/mask]
              Replace the client host MAC address field in  the  DHCP  message
              with  the  given MAC address. This option is mandatory. The mask
              parameter specifies the prefix 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

       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 will also need to add appropriate ebtables rules to change the  MAC
       address of the Ethernet headers.)

       The  ACCOUNT  target  is a high performance accounting system for large
       local networks. It allows per-IP accounting in whole prefixes  of  IPv4
       addresses  with  size  of  up  to /8 without the need to add individual
       accouting rule for each IP address.

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

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

       To optimize the kernel<->userspace data transfer a bit more, the kernel
       module  only  transfers information about IPs, where the src/dst packet
       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 data snapshot needs to be created&copied for all data. Use the
       "read" operation without flush only for debugging purposes!


       ACCOUNT takes two mandatory parameters:

       --addr network/netmask
              where  network/netmask  is  the  subnet  to account for, in CIDR

       --tname NAME
              where NAME is  the  name  of  the  table  where  the  accounting
              information should be stored

       The subnet is a special case: all data are then stored in the
       src_bytes and src_packets structure of slot "0". This is useful if  you
       want to 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, which features following options:

       [-u] show kernel handle usage

       [-h] free all kernel handles (experts only!)

       [-a] list all table names

       [-l name] show data in table name

       [-f] flush data after showing

       [-c] loop every second (abort with CTRL+C)

       Here is an example of use:

       iptables  -A  FORWARD -j ACCOUNT --addr --tname all_outgoing;
       iptables -A FORWARD -j ACCOUNT --addr --tname sales;

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

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

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

       For             more            information            go            to

       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.

       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:

              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.

              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

       See     for    more
       information about CHAOS, DELUDE and lscan.

       The RAWSNAT and  RAWDNAT  targets  provide  stateless  network  address

       The  RAWSNAT  target  will rewrite the source address in the IP header,
       much like the NETMAP target. RAWSNAT (and RAWDNAT) may only be used  in
       the  raw  or rawpost tables, but can be used in all chains, which makes
       it possible to change the source address either when the packet  enters
       the  machine or when it leaves it. The reason for this table constraint
       is that RAWNAT must happen outside of connection tracking.

       --to-source addr[/mask]
              Network address  to  map  to.  The  resulting  address  will  be
              constructed  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.

       As  an  example, changing the destination for packets forwarded from an
       internal LAN to the internet:

              -t raw -A PREROUTING  -i  lan0  -d  -j  RAWDNAT
              --to-destination;  -t rawpost -A POSTROUTING -o
              lan0 -s -j RAWSNAT --to-source;

       Note  that  changing  addresses  may  influence  the  route  selection!
       Specifically,  it  statically  NATs  packets, not connections, like the
       normal DNAT/SNAT targets would do. Also  note  that  it  can  transform
       already-NATed  connections  --  as  said,  it is completely external to
       Netfilter's connection tracking/NAT.

       If the machine itself generates packets that are to be  rawnat'ed,  you
       need  a  rule in the OUTPUT chain instead, just like you would with the
       stateful NAT targets.

       It may be necessary that in doing so, you also need  an  extra  RAWSNAT
       rule,  to  override  the  automatic  source  address selection that the
       routing code does before passing packets to iptables. If the connecting
       socket  has  not  been explicitly bound to an address, as is the common
       mode of operation, the address that  will  be  chosen  is  the  primary
       address of the device through which the packet would be routed with its
       initial destination address - the address as  seen  before  any  RAWNAT
       takes place.

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

       ECHO takes no options.


       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.

              Makes  it  so  the  counter  or quota amount is never changed by
              packets matching this  rule.  This  is  only  really  useful  in
              "quota"  mode,  as  it  will allow you to use complex prerouting
              rules in association with the quota system, without  counting  a
              packet twice.

       --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.

              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;

       Pknock  match  implements  so-called "port knocking", a stealthy system
       for network authentication: a client sends packets to selected ports in
       a  specific  sequence  (=  simple mode, see example 1 below), or a HMAC
       payload to a single port (= complex mode, see example 2  below),  to  a
       target  machine  that  has pknock rule(s) installed. The target machine
       then decides whether to unblock or block (again)  the  pknock-protected
       port(s).   This can be used, for instance, to avoid brute force attacks
       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

       The rule will allow tcp port 22 for the attempting IP address after the
       successful  reception  of TCP SYN packets to ports 4002, 4001 and 4004,
       in this order (a.k.a. port-knocking).   Port  numbers  in  the  connect
       sequence  must  follow  the  exact specification, no other ports may be
       "knocked" inbetween. The rule is named 'SSH' -- a file of the 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) will be automatiaclly
       dropped after 60 minutes after it was previously allowed.

       Example 2 (UDP mode -- non-replayable and non-spoofable, manual closing
       of  opened  port  possible,  secure,  also  called  "SPA" = Secure Port

              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 after the successful reception of an UDP packet
       to port 4000. The packet payload must be constructed 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 IP address will cause
       such packets to be accepted in the second rule.

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

       Things worth noting:


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

       xt_pknock  is  capable  of sending information about successful matches
       via a netlink socket to userspace, should you need  to  implement  your
       own  way of receiving and handling portknock notifications.  Be sure to
       read the documentation in  the  doc/pknock/  directory,  or  visit  the
       original site -- .

       TCP mode:

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

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

       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  table  that  xt_pknock  internally keeps, should
       there be a DDoS on the first-in-row knock port  from  more  hostile  IP
       addresses  than  what the actual size of 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 --time for this
       very reason. You may also consider increasing  the  size  of  the  peer
       knock-state  tracking  table. Using --strict also helps, as it requires
       the knock sequence to be exact. This means that if the  hostile  client
       sends more knocks to the same port, xt_pknock will mark such attempt as
       failed knock sequence and will forget it  immediately.   To  completely
       thwart  this kind of DDoS, knock-ports would need to have an 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
       server must be below 1 minute. Synchronizing time on both ends by means
       of NTP or rdate is strongly suggested.

       There  is  a  rate  limiter  built  into  xt_pknock  which  blocks  any
       subsequent open attempt in UDP mode should the  request  arrive  within
       less  than  one  minute  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 or knock- These may be found in doc/pknock/util.

       --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.

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

       --psd-weight-threshold threshold
              Total  weight  of  the  latest  TCP/UDP  packets  with different
              destination ports coming from the same host  to  be  treated  as
              port scan sequence.

       --psd-delay-threshold delay
              Delay  (in  hundredths of second) for the packets with different
              destination ports coming from the same host  to  be  treated  as
              possible 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.

       Allows you to check interface states.

       --iface name
              Check  the  states  on  the  given  interface.  This  option  is

       [!] --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.

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

       --flags [!]symbol[,[!]symbol...]
              Specify the options that shall  appear  or  not  appear  in  the
              header. Each symbol specification is delimited by a comma, and a
              '!' can be prefixed to a symbol to negate its presence.  Symbols
              are  either  the  name  of  an  IPv4  option  or its number. See
              examples below.

       --any  By default, all of the flags specified must  be  present/absent,
              that  is, they form an AND condition. Use the --any flag instead
              to use an OR condition where 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 \m 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


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

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

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

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

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

       [!] --length length[:length]
              Match exact length or length range.

              Match  the layer3 frame size (e.g. IPv4/v6 header plus payload).

              Match the layer4 frame size (e.g. TCP/UDP header plus  payload).

              Match  the layer5 frame size (e.g. TCP/UDP payload, often called

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

       This  module  matches  a  rate  limit based on a fuzzy logic controller

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

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

       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 ISO-3166 code.

       The extra files you will need is the binary database  files.  They  are
       generated  from  a  country-subnet  database  with the
       tool, available at  .  The  files
       MUST  be  moved  to  /usr/share/xt_geoip/  as  the  shared  library  is
       statically      looking       for       this       pathname       (e.g.

       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.

       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, of  which  one  or  more  may  be
       specified on the command line:

       --edk  Matches as many eDonkey/eMule packets as possible.

              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.

              Matches AppleJuice packets.

       --soul Matches  some SoulSeek packets. Considered as beta, use careful!

              Matches some WinMX packets. Considered as beta, use careful!

       --ares Matches Ares and AresLite packets. Use  together  with  -j  DROP

              Prints  some information about each hit into kernel logfile. May
              produce huge logfiles so beware!

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

       There  is  more  information on , but it has not been
       updated since September 2006, and the syntax there  is  different  from
       the  ipp2p.c  provided in Xtables-addons; most importantly, the --ipp2p
       flag was removed due to its ambiguity to match "all known" protocols.

       Detects simple low-level 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.

              Match if the packet did not belong to any known  TCP  connection
              (Stealth/FIN/XMAS/NULL scan).

              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.

              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.

              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,
              smtp, ftpd.) This  may  falsely  trigger  on  warranted  single-
              direction  data  flows,  usually bulk data transfers such as FTP
              DATA connections or IRC DCC. Grab Scan Detection should only  be
              used  on  ports where a protocol runs that is guaranteed to do a
              bidirectional exchange of 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.


       iptables(8), ip6tables(8)

       For   developers,   the   book   "Writing   Netfilter    modules"    at      provides
       detailed information on how to write such modules/extensions.

                              v1.26 (2010-04-30)             xtables-addons(8)