netfilter project logo

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

patch-o-matic extra repository

ROUTE TARPIT conntrack_nonat directx8-conntrack-nat eggdrop-conntrack layer2-hooks mms-conntrack-nat msnp-conntrack-nat quake3-conntrack-nat rpc rsh rtsp-conntrack talk-conntrack-nat

ROUTE - iptables ROUTE target

Author: Cédric de Launois <delaunois@info.ucl.ac.be>
Status: Experimental

  
  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



TARPIT - iptables TARPIT target

Author: "Aaron Hopkins" <lists@die.net>
Status: Works for me


Adds a TARPIT target to iptables, which 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 doesn't 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:

  iptables -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:

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

You probably don't want the conntrack module loaded while you are using
TARPIT, or you will be using resources per connection.



conntrack_nonat

Author: Jozsef Kadlecsik
Status: Testing

The patch introduces an optimization in the per bucket locking
for the conntrack-only (i.e. no NAT at all) case.

The patch depends on the conntrack_locking.patch.


directx8-conntrack-nat - DirectX8 Conntrack/NAT helpers

Author: Eddie Shi <eddieshi@broadcom.com>
Status: untested, ripped from USR9106 source code


eggdrop-conntrack - eggdrop connection tracking helper

Author: Magnus Sandin <magnus@sandin.cx>
Status: Development

This adds CONFIG_IP_NF_EGG:
Connection tracking for eggdrop bot networks.
It now also supports eggdrop v1.6.x


layer2-hooks - netfilter hooks for layer 2

Author: Marc Zyngier <Marc.Zyngier@evidian.com>
Status: Testing

This adds netfilter hooks to layer 2 packet processing.


mms-conntrack-nat

Author: Filip Sneppe <filip.sneppe@cronos.be>
Status: WorksForMe(tm)

This adds CONFIG_IP_NF_MMS: support for Microsoft Streaming Media 
Services. This allows client (Windows Media Player) and server
to negotiate protocol (UDP, TCP) and port for the media stream.

A partially reverse engineered protocol analysis is available 
from http://get.to/sdp, together with a link to a Linux client.

By default, the helper module tracks TCP traffic over port 1755
and adds the necessary UPD or TCP expectation. It is recommended 
to also open UDP port 1755 to the server, as this port is used 
for retransmission requests.

This helper has been tested in SNAT and DNAT setups.

Note that this helper has *nothing* to do with ip_masq_mms for 
2.2 kernels!


msnp-conntrack-nat - MSNP connection tracking and NAT helper

Author: Unknown, taken from Gigabyte B49G GPL-1.23 download
Status: Testing


quake3-conntrack-nat - quake3 connection tracking and NAT helper

Author: Filip Sneppe <filip.sneppe@cronos.be>
Status: WorksForMe (tm)

This adds CONFIG_IP_NF_QUAKE3: a Quake III Arena support module for
netfilter connection tracking/NAT. 

Quake III Arena Internet multiplayer works by querying an Internet
master server on UDP port 27950 for specific Quake III servers. The
master server responds with the IP addresses and UDP ports of
registered game servers. Those UDP ports can be randomly chosen
(although 27960 is often used).

This connection tracking module will listen for UDP replies
from a master server, and will add the necessary expectations
for connections from client to game servers.


rpc - rpc connection tracking helper

Author: "Marcelo Barbosa Lima" <marcelo.lima@dcc.unicamp.br>
Status: maintained by David Stes <stes@pandora.be>

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

This option supplies two connection tracking 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
"procedure 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 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.

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.


Usage:

  The intended usage of these modules would be with a ruleset like;

    # New session from client to server (portmapper get)
    -A PREROUTING -t nat -i eth0 -p udp -m rpc --rpcs 100002
           -s ${client} --sport 0:1023 -d ${server} --dport 111
           -j ACCEPT

    # Continued session from client to server (portmapper answer)
    -A PREROUTING -t nat -i eth1 -m state -p udp
           -s ${server} --sport 111 -d ${client} --dport 0:1023
           --state ESTABLISHED -j ACCEPT

    # New session from client to server (procedure call)
    -A PREROUTING -t nat -i eth0 -m state -p udp
          -s ${client} --sport 0:65535
          -d ${server} --dport 32000:34000
          --state ESTABLISHED,RELATED -j ACCEPT

    # Continued session from client to server (procedure response)
    -A PREROUTING -t nat -i eth1 -m state -p udp
           -s ${server} --sport 32000:34000
           -d ${client} --dport 0:65535
           --state ESTABLISHED -j ACCEPT


  Which would allow rusers to execute from client to server;

     user@client# rusers $server

The RPC module also supports Legato NetWorker backup.
Legato NetWorker is based on both Sun RPC and REXEC (see RSH module).

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



rsh - rsh conntrack and nat helper

Author: Ian (Larry) Latter <Ian.Latter@mq.edu.au>
Status: pending kernel inclusion after 2.6.11 port

This adds the CONFIG_IP_NF_RSH option, which is the RSH connection
tracker.

An RSH connection tracker is required if the dynamic stderr "Server
to Client" connection is to occur during a normal RSH session.  This
typically operates as follows;

    Client 0:1023 --> Server 514    (stream 1 - stdin/stdout)
    Client 0:1023 <-- Server 0:1023 (stream 2 - stderr)

This connection tracker will identify new RSH sessions, extract the
outbound session details, and notify netfilter of pending "related"
sessions.


Usage:

The intended usage of this modules would be with a ruleset such as;

    # New session from client to server (stream 1)
    -A PREROUTING -t nat -m state -i eth0 -p tcp -s ${client}
           --sport 0:1023 -d ${server} --dport 514 --state 
           NEW,ESTABLISHED -j ACCEPT

    # Continued session from server to client (stream 1)
    -A PREROUTING -t nat -m state -i eth1 -p tcp -s ${server}
           --sport 514 -d ${client} --dport 0:1023 ! --syn
           --state ESTABLISHED -j ACCEPT

    # New session from server to client (stream 2)
    -A PREROUTING -t nat -m state -i eth1 -p tcp -s ${server}
           --sport 0:1023 -d ${client} --dport 0:1023 --state
           RELATED,ESTABLISHED -j ACCEPT

    # Continued session from client to server (stream 2)
    -A PREROUTING -t nat -m state -i eth0 -p tcp -s ${client}
           --sport 0:1023 -d ${server} --dport 0:1023 ! --syn
           --state ESTABLISHED -j ACCEPT

The RSH module also supports Legato NetWorker backup.
Legato NetWorker is based on both Sun RPC and REXEC (see RPC module).

Warning:

  This module could be dangerous. It is not "best practice" to use
RSH, use SSH in all instances.  (rfc1244, rfc1948, rfc2179, etc
ad-nauseum)



rtsp-conntrack - RTSP connection tracking and nat helper

Author: Tom Marshall <tmarshall@real.com>
Status: Beta - needs some testing and porting to 2.6.x

This patch adds CONFIG_IP_NF_RTSP: support for the RTSP protocol.

This allows UDP transports to be setup properly, including RTP and RDT.



talk-conntrack-nat - talk connection tracking and NAT helper

Author: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Status: Alpha, needs porting to 2.6.x

This adds CONFIG_IP_NF_TALK: talk support module for netfilter
connection tracking and NAT.  This allows both the callee client -
caller server and callee client - caller client connections to work
through connection tracking and NAT.

Default both talk (UDP port 517) and ntalk/ntalk2 (UDP port 518) are
supported. talk/ntalk/ntalk2 supports can selectively be enabled/disabled 
by the module parameters of the ip_conntrack_talk and ip_nat_talk
modules:

	talk=0|1
        ntalk=0|1
        ntalk2=0|1

where '0' means 'don't support' while '1' means 'do support'
the given protocol flavour.




Copyright © 1999-2007 The netfilter webmaster . Harald Welte and Pablo Neira Ayuso