netfilter/iptables - Patch-o-Matic Listing - external

This patch adds the ACCOUNT target

The ACCOUNT target is a high performance accounting system for local networks.
It takes two parameters: --addr network/netmask and --tname NAME.

--addr is the subnet which is accounted for
--tname is the table name where the information is stored

The data can be queried later using the libipt_ACCOUNT userspace library
or by the "iptaccount" tool which is part of the libipt_ACCOUNT package.

A special subnet is "0.0.0.0/0": All data is 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.

For more information go to http://www.intra2net.com/de/produkte/opensource/ipt_account/

  This option adds a `IPMARK' target, which allows you to mark
  a received packet basing on its IP address. This can replace even
  thousands of mangle/mark or tc entries with only one.

  This target is to be used inside the mangle table, in the PREROUTING,
  POSTROUTING or FORWARD hooks.

  IPMARK target options:
    --addr src/dst      Use source or destination IP address.
    --and-mask mask     Perform bitwise `and' on the IP address and this mask.
    --or-mask mask      Perform bitwise `or' on the IP address and this mask.

  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.


  Earlier we had thousands of tc filter rules:
  tc filter add dev eth3 parent 1:0 prio 10 u32 match ip dst 192.168.5.2 flowid 1:502
  tc filter add dev eth3 parent 1:0 prio 10 u32 match ip dst 192.168.5.3 flowid 1:503
  ...
  or thousands of MARK rules (with tc fw classifier):
  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
  and all previous tc filter classifier rules with ONLY ONE:
  tc filter add dev eth3 parent 1:0 protocol ip fw


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

  
  This option adds a `ROUTE' target, which enables you to setup unusual
  routes. For example, the ROUTE lets you route a received packet through 
  an interface or towards a host, even if the regular destination of the 
  packet is the router itself. The ROUTE target is also able to change the 
  incoming interface of a packet.

  The target can be or not a final target. It has to be used inside the 
  mangle table.

  ROUTE target options:
  --oif   ifname    Send the packet out using `ifname' network interface.
  --iif   ifname    Change the packet's incoming interface to `ifname'.
  --gw    ip        Route the packet via this gateway.
  --continue        Route the packet and continue traversing the rules.
  --tee             Route a copy of the packet, but continue traversing
                    the rules with the original packet, undisturbed.

  Note that --iif, --continue, and --tee, are mutually exclusive.

  Examples :

  # To force all outgoing icmp packet to go through the eth1 interface 
  # (final target) :
  iptables -A POSTROUTING -t mangle -p icmp -j ROUTE --oif eth1
 
  # To tunnel outgoing http packets and continue traversing the rules :
  iptables -A POSTROUTING -t mangle -p tcp --dport 80 -j ROUTE --oif tunl1 --continue
 
  # To forward all ssh packets to gateway w.x.y.z, and continue traversing
  # the rules :
  iptables -A POSTROUTING -t mangle -p tcp --dport 22 -j ROUTE --gw w.x.y.z --continue
 
  # To change the incoming network interface from eth0 to eth1 for all icmp
  # packets (final target) :
  iptables -A PREROUTING -t mangle -p icmp -i eth0 -j ROUTE --iif eth1

  # To copy (duplicate) all traffic from and to a local ECHO server
  # to a second box (nonfinal target)
  iptables -A PREROUTING -t mangle -p tcp --dport 7 -j ROUTE --gw 1.2.3.4 --tee
  iptables -A POSTROUTING -t mangle -p tcp --sport 7 -j ROUTE --gw 1.2.3.4 --tee

This option allows you to match firewall rules against condition variables
stored in the /proc/net/ipt_condition directory. Multiple rules can match on a
single condition variable.

Example:
iptables -A INPUT -p tcp -m condition --condition web_ok --dport 80 -j ACCEPT

To allow this rule to match:
echo 1 > /proc/net/nf_condition/web_ok

To disable this rule: 
echo 0 > /proc/net/nf_condition/web_ok

NB: it was /proc/net/ipt_condition on 2.4.

This adds an iptables match which allows you to restrict the
number of parallel TCP connections to a server per client IP address
(or address block).

Examples:

# allow 2 telnet connections per client host
iptables -p tcp --syn --dport 23 -m connlimit --connlimit-above 2 -j REJECT

# you can also match the other way around:
iptables -p tcp --syn --dport 23 -m connlimit ! --connlimit-above 2 -j ACCEPT

# limit the nr of parallel http requests to 16 per class C sized
# network (24 bit netmask)
iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 16 \
	--connlimit-mask 24 -j REJECT

This patch makes possible to match a packet
by its source or destination country.

GeoIP options:
        [!]   --src-cc, --source-country country[,country,country,...]

                        Match packet coming from (one of)
                        the specified country(ies)


        [!]   --dst-cc, --destination-country country[,country,country,...]
                                              
                        Match packet going to (one of)
                        the specified country(ies)

           NOTE: The country is inputed by its ISO3166 code.

The only extra files you need is a binary db (geoipdb.bin) & its index file (geoipdb.idx).
Take a look at http://people.netfilter.org/acidfu/geoip/howto/geoip-HOWTO.html
for a quick HOWTO.

This option makes possible to match some P2P packets
therefore helps controlling such traffic. Dropping all
matches prohibits P2P networks. Combined with conntrack,
CONNMARK and a packet scheduler it can be used for
accounting or shaping of P2P traffic.

Examples:
iptables -A FORWARD -m ipp2p --edk --kazaa --bit -j DROP
iptables -A FORWARD -p tcp -m ipp2p --ares -j DROP
iptables -A FORWARD -p udp -m ipp2p --kazaa -j DROP

This patch allows you to implement Port Knocking and SPA (Simple Packet
Authentication) in kernel space.

pknock options:

	--knockports port[,port,port,...]	Matches destination port(s).
	--time seconds
	--t seconds				Time between port match.
	--opensecret [secret]			hmac must be in the packets.
	--closesecret [secret]
	--strict				Knocks sequence must be exact.
	--name [rule_name]			Rule name.
	--checkip				Matches if the source ip is in the list.
	--chkip


Example:

iptables -P INPUT DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -p tcp -m state --state NEW 				\
	-m pknock --knockports 3000,2000,5000 --time 10 --name SSH 	\
	-m tcp --dport 22 -j ACCEPT

For more information go to http://portknocko.berlios.de/

This adds CONFIG_IP_NF_MATCH_RPC, which is the RPC connection
matcher and tracker.

This option supplies two connection tracking (helper) modules;
ip_conntrack_rpc_udp and ip_conntrack_rpc_tcp, which track
portmapper requests using UDP and TCP respectively.

This option also adds an RPC match module for iptables, which
matches both via the old "record match" method and a new
"RPC program match" method. The older method matches all RPC
procedure packets that relate to previously recorded packets
seen querying a portmapper. The newer method matches only
those RPC procedure packets that query RPC programs explicitly
specified by the user, and that can then be related to previously
recorded packets seen querying a portmapper.

These three modules are required if RPCs are to be filtered
accurately; as RPCs are allocated pseudo-randomly to UDP and
TCP ports as they register with the portmapper.

Besides tracking of standard RPC GETPORT queries it supports the
following special features:
   - support for Legato networker RPC traffic
   - support for ClearCase propriatary RPC traffic to the albd
   - extraction of portmappings from RPC DUMP replies
     This is especialy useful for Linux clients, e.g. NFS clients

Up to 8 portmapper ports per module, and up to 128 RPC
procedures per iptables rule, may be specified by the user,
to enable effective RPC management.

Please consult the C-code of the modules for a description of the
modules load syntax and options.

Warning:

  RPCs should not be exposed to the internet - ask the Pentagon;
    See: Wired News; "Pentagon Kids Kicked Off Grid" - Nov 6, 1998
    URL: http://www.wired.com/news/politics/0,1283,16098,00.html

Usage:

  Suppose you have defined two sub-chains of chain FORWARD:

  forward_cells:
	a chain to filter traffic from the network where your server
	for the RPC services (like NFS server) is located.
	In the example the IP address of the server is $IP_SRV
  forward_clients:
	a chain to filter traffic from the network where your clients
	for the RPC services (like NFS clients) are located.

  In the most simple setup the intended usage of these modules would be
  with a ruleset like the following.

######################################################################
# Example for the most simple case:
# We only filter conventional RPC traffic
#---------------------------------------------------------------------

#
# chain forward_cells:
#

#------------
# RPC matcher
#------------
# Track conventional RPC traffic from the portmapper on servers in the cell.
#
# In the most simple setup there is no need to use the --rpcs match
# in chain forward_cells.
#
# None

#------------
# NEW
#------------
# None

#------------
# ESTABLISHED
#------------

${IPTABLES} -A forward_cells -m state --state ESTABLISHED -j ACCEPT

#------------
# RELATED
#------------
# None

#-----------------------
# LOG and DROP the rest
#-----------------------

${IPTABLES} -A forward_cells \
	$loglimit -j LOG --log-level info --log-prefix "Chain forward_cells DROP:"
${IPTABLES} -A forward_cells -j DROP

#
# chain forward_clients:
#

#------------
# RPC matcher
#------------
# Track conventional RPC traffic to the portmapper on the server in the server cell
#
# Note:
# You may also use symbolic names for RPC programs like
# nfs,mountd,rquotad instead of 100003,100005,100011
# However, the names must be defined in /etc/rpc
#
# Please note as well how we shield the -rpc match with the prior
# matches '-d $IP_SRV -p tcp --dport 111'.
# This saves performance since the -rpc match is only activated for the
# packets that it is interested in.
#
# The tracking of RPC GETPORT calls for RPC programs is only activated for
# those RPC program numbers that are listed in the --rpcs list. The replies from
# the portmapper are analysed by the helpers and expectations are setup
# for the server ports contained in the replies.
#
# Other GETPORT calls are ignored. Note that these calls are allowed to reach
# the portmapper and the replies are allowed to reach the caller.
# However, the matcher prevents the helper modules from tracking the corresponding
# GETPORT replies. No expectations for related connections are setup.
#
# The helper modules simply try to track all RPC traffic to any registered portmapper
# (see module load syntax for registering portmappers).
# The matcher is used to restrict the work done by the helpers. It
# narrows the focus of the helper modules to just the RPC program numbers that
# are specified via the --rpcs syntax.
#

${IPTABLES} -A forward_clients -d $IP_SRV -p tcp --dport 111 \
	-m rpc --rpcs 100003,100005,100011 -j ACCEPT
${IPTABLES} -A forward_clients -d $IP_SRV -p udp --dport 111 \
	-m rpc --rpcs 100003,100005,100011 -j ACCEPT

#------------
# NEW 
#------------
# Connections are allowed to the conventional portmapper (111)

${IPTABLES} -A forward_clients -d $IP_SRV -p tcp -dport 111 \
            -m state --state NEW -j ACCEPT
${IPTABLES} -A forward_clients -d $IP_SRV -p udp -dport 111 \
            -m state --state NEW -j ACCEPT

#-------------
# ESTABLISHED
#-------------

${IPTABLES} -A forward_clients -m state --state ESTABLISHED -j ACCEPT


#-------------
# RELATED
#-------------

${IPTABLES} -A forward_clients -m state --state RELATED -j ACCEPT

#-----------------------
# LOG and DROP the rest
#-----------------------

${IPTABLES} -A forward_clients \
	$loglimit -j LOG --log-level info --log-prefix "Chain forward_clients DROP:"
${IPTABLES} -A forward_clients -j DROP

# END example for the most simple case
######################################################################

######################################################################
# Example for handling DUMP replies
# 
# Linux NFS clients have the bad habit to use the RPC DUMP procedure
# instead of the usual GETPORT procedure when they query the portmapper
# for server ports. This is an optimization.
# However, it makes RPC connection tracking considerably more difficult.
#
# In order to support the connection tracking for DUMP replies you have
# to place an additional -rpc match in the chain that filters the
# replies from the portmapper.
#
# Just add the following rule to the simple example above

#
# chain forward_cells:
#

#------------
# RPC matcher
#------------
# Track conventional RPC traffic from the portmapper on servers in the cell.
# We match it via the -rpc module in order to process DUMP replies as well.
#
# Please note how we shield the -rpc match with the prior
# matches '-s $IP_SRV -p tcp --sport 111'
# This saves performance since the -rpc match is only activated for the
# packets that it is interested in.
#
# Only server ports that correspond to RPC program numbers listed in
# the --rpcs list are used to setup expectations!
# The other ports in the DUMP reply (the map list) are ignored and are not
# used for relating connections.
#
# Note: DUMP replies are exclusively handled by the matcher. The helper
# modules ignore DUMP calls/replies alltogether.

${IPTABLES} -A forward_cells -s $IP_SRV -p tcp --sport 111 \
            -m rpc --rpcs 100003,100005,100011 -j ACCEPT
${IPTABLES} -A forward_cells -s $IP_SRV -p udp --sport 111 \
            -m rpc --rpcs 100003,100005,100011 -j ACCEPT

# END example for handling DUMP replies
######################################################################

######################################################################
# Example for handling ClearCase traffic
#
# ClearCase uses a proprietary portmapper that listens at port 371 (udp/tcp)
# The portmapper is registered with program number 390512 instead of the normal 100000.
# The GETPORT procedure call for program number 390512 and the corresponding
# reply use a proprietary format. They are exclusively handled by the
# helper modules.
#
# In order to activate the ClearCase support you need to use the load syntax
# 	ports=111,371
# for both UDP and TCP helper modules and the matcher module.
#
# There is no need and no way to match the RPC traffic to 371 (udp/tcp)
# via the -rpc match. The -rpc match supports only regular RPC calls
# to the portmapper program (100000).
#
# However, a few additions to the simple rule set are needed to make
# RPC connection tracking work for ClearCase traffic.
#
# Please note: for Solaris 10 NFS clients you even need more extensions
#              See the example config for NFS clients below.


#
# chain forward_clients:
#
 
#------------
# NEW 
#------------
# Connections are allowed to the conventional portmapper (111) and the CC portmapper (371)
#

${IPTABLES} -A forward_clients -d $IP_SRV -p tcp -m multiport --dports 111,371 \
            -m state --state NEW -j ACCEPT
${IPTABLES} -A forward_clients -d $IP_SRV -p udp -m multiport --dports 111,371 \
            -m state --state NEW -j ACCEPT


# END Example for handling ClearCase traffic
######################################################################

######################################################################
# Example for handling Solaris 10 NFS clients
# This is also related to handling ClearCase NFS traffic for Solaris 10 clients.
#
# If your firewall is supposed to handle traffic for Solaris 10 NFS clients
# it will be the victim of some Solaris 10 optimization.
#
# Solaris does not always do the standard RPC call GETPORT 100003 for
# the nfsd RPC program since the nfsd server port is fixed to port 2049.
# Instead, Solaris directly addresses the nfsd port 2049.
#
# In addition for NFS via UDP, Solaris 10 sends two consecutive UPD packets
# to the mountd after it learnt the mountd server port via a GETPORT to the portmapper.
# The first UDP packet is permitted to pass since the connection is expected due
# to the RPC GETPORT call. However, the second UDP packet from the server is
# dropped since the pass permission (related state) is already consumed by the
# first UDP packet.
#
# As a counter messure I added the 'second chance' feature for UDP connections.
# For the special case where the NFS client addresses the mountd (RPC prog 100005)
# we renew the expectation once which gives the client a second chance to connect via UDP.
#
# The following additions are needed for tracking NFS related RPC traffic of
# Solaris 10 clients.
# You have to permit NEW connections to port 2049 (udp/tcp).
# The 'second chance' feature for UDP is transparently handled by the helper modules.

#
# chain forward_clients:
#



${IPTABLES} -A forward_clients -d $IP_SRV -p tcp -m multiport --dports 111,2049 \
            -m state --state NEW -j ACCEPT
${IPTABLES} -A forward_clients -d $IP_SRV -p udp -m multiport --dports 111,2049 \
            -m state --state NEW -j ACCEPT
 

# END Example for handling Solaris 10 NFS clients
######################################################################

######################################################################
# Example for handling Legato networker traffic
#
# Apart from the normal RPC call/reply tracking of Legato's RPC traffic via
# the Legato portmapper listening on port 7938/tcp the RPC conntrack helpers
# contain only a tiny tweak with respect to Legato traffic.
# The TCP helper module actively ignores the GETPORT call for the nsrexec.
# It is intended that the server port of the nsrexec is NOT registered for an
# expected connection.
#
# In order to activate the Legato support you need to use the load syntax
# 	nsrexec=7937 ports=111,7938
# for the TCP helper. For the UDP helper and the matcher you just need to
# provide
#	ports=111,7938
#
# For a complete support of the Legato traffic you need the help of just another
# connection tracking module: the RSH connection tracking module.
# Its usage is documented elsewhere (see the patch-o-matic documentation
# for the RSH module).
# Please consult as well the pages by David Stes
#    http://users.pandora.be/stes
# which are dedicated to the connection tracking of the Leagto Networker traffic.
#
# Regarding the matcher module you will like to specify all the RPC
# programs needed for the Legato traffic.
# 


#
# chain forward_clients:
#

#------------
# RPC matcher
#------------

${IPTABLES} -A forward_clients -d $IP_SRV -p tcp --dport 111 \
	-m rpc --rpcs nsrd,nsrexec,nsrmmd,nsrindexd,nsrmmdbd,\
	nsrstat,nsrjobd,nsrlcpd,nsrmmgd,390436,390435,390120 \
	-j ACCEPT
${IPTABLES} -A forward_clients -d $IP_SRV -p udp --dport 111 \
	-m rpc --rpcs nsrd,nsrexec,nsrmmd,nsrindexd,nsrmmdbd,\
	nsrstat,nsrjobd,nsrlcpd,nsrmmgd,390436,390435,390120 \
	-j ACCEPT

#------------
# NEW 
#------------

${IPTABLES} -A forward_clients -d $IP_SRV -p tcp -m multiport --dports 111,7937,7938 \
            -m state --state NEW -j ACCEPT
${IPTABLES} -A forward_clients -d $IP_SRV -p udp -m multiport --dports 111,7938 \
            -m state --state NEW -j ACCEPT


# END Example for handling Legato netwroker traffic
######################################################################

This option adds CONFIG_IP_NF_MATCH_TIME, which supplies a time match module.
This match allows you to filter based on the packet arrival time/date
(arrival time/date at the machine which the netfilter is running on) or
departure time/date (for locally generated packets).

Supported options are:
[ --timestart value ]
    Match only if it is after `value' (Inclusive, format: HH:MM ; default 00:00).

[ --timestop  value ]
    Match only if it is before `value' (Inclusive, format: HH:MM ; default 23:59).

[ --days listofdays ]
    Match only if today is one of the given days. (format: Mon,Tue,Wed,Thu,Fri,Sat,Sun ; default everyday)

[ --datestart date ]
    Match only if it is after `date' (Inclusive, format: YYYY[:MM[:DD[:hh[:mm[:ss]]]]]
    h,m,s start from 0 ; default to 1970)

[ --datestop date ]
    Match only if it is before `date' (Inclusive, format: YYYY[:MM[:DD[:hh[:mm[:ss]]]]]
    h,m,s start from 0 ; default to 2037)

Example:
  -A INPUT -m time --timestart 8:00 --timestop 18:00 --days Mon,Tue,Wed,Thu,Fri
  will match packets that have an arrival timestamp in the range 8:00->18:00 from Monday
  to Friday.

  -A OUTPUT -m time --timestart 8:00 --timestop 18:00 --Days Mon --date-stop 2010
  will match the packets (locally generated) that have a departure timestamp
  in the range 8:00->18:00 on Monday only, until 2010

NOTE: the time match does not track changes in daylight savings time