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