Re:Interesting failure with RPC state tracker

Re:Interesting failure with RPC state tracker

[Ian Latter]

Hello Brian and Dev ppls,

  I have been thinking about this recently ... after being informed of a
pointer error on the module name I've taken to doing a bit of research
on the whole kernel module thing.

  I'll post a link on it later, but I found a site that discussed the RPC
module within Firewall-1 in greater detail than I had seen previously.

  One of the things that Firewall-1's RPC code did, that I didn't like, was
that if you choose to "match" an RPC, then the matching module will
automatically allow RPC portmapper requests through the firewall.  I
don't like the idea of "hidden rules", and hence in the Netfilter version,
you need to permit the RPC portmapper requests explicitly.  So what
you've seen is correct ... and this sort of ruleset;

  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


... should work ... (was this what you found?) .. except for the "DUMP"
request.  I'll need to read up on this one (I remember reading it through
when I rejigged the module, but I ended up discarding it).


  There are two other features in the Firewall-1 RPC code that I want
to add to the Netfilter RPC module;

  1)  Cached portmapper resolution -- establishing a slab cache the
          dynamically stores the port vs the procedure number in memory
          such that future RPC portmapper requests are redundant

  2)  A kernel socket call to the RPC portmapper -- in case the RPC
          module or rule is only activated after the client has already 
          performed a portmapper resolution request, currently the RPC
          module would fail to permit the valid RPC request.  If, however,
          the RPC port range was treated as a possible set of RPC "targets",
          but for which a valid (matched) IP address had failed to resolve a
          port for a given procedure; then the RPC module would make its 
          own request to the portmapper to resolve the port and validate the
          match.  The resolution could then be added to the local slab cache
          to accelerate future matches.


  While it *sounds* like  I'm a great guy ready to do big things, the truth is
that I haven't fixed my pointer module name problem in three weeks, so 
these mods might be a little way off ;-)

  I am very appreciative of feedback on the use of this module and your
successes/failures.  Of particular interest is performance ... let me know
how you go with thrashing this thing under NFS ... because that is one
of the big unanswered questions here ..

  Thanks for the feedback ... I'll check out that DUMP command and see
what I can do ... which kernel version are you using?

(Cool database software, btw, I implemented it for an ISP in AU who
had heard of it and used it before).



----- Original Message -----
>From: "Brian J. Murrell" <netfilter@interlinx.bc.ca>
>To: <netfilter-devel@lists.netfilter.org>
>Subject:  Interesting failure with RPC state tracker
>Date: Wed, 21 May 2003 17:58:55 -0400
>
> I have been trying to get NFS to work through Netfilter with the rpc
> mdoule in p-o-m/extra.
> 
> I have finally gotten it to work successfully, but the struggle I had
> getting it to work had an interesting outcome.
> 
> The reason my initial attempts failed is because the RPC tracking module
> depends on intercepting GETPORT calls and opening expectations on the
> assumption that if a client asks for the port for a given service on a
> given server, it will want to connect to it.
> 
> The problem that this causes with Linux's "mount" command is that the
> mount command (in util-linux) does a RPC portmap "DUMP" (tcp:111 on the
> server) just like "rpcinfo -p" does.  It then extracts the port number
> from there.
> 
> If you put a rule in the filter to block access to the portmapper's TCP
> port on the server, the above process fails and then normal RPC
> processing continues, with a GETPORT call to determine the port number.
> 
> Thots?
> 
> b.
> 
> -- 
> Brian J. Murrell <netfilter@interlinx.bc.ca>
> 

--
Ian Latter
Internet and Networking Security Officer
Macquarie University

Re: Re:Interesting failure with RPC state tracker

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 6501 bytes --]

On Wed, 2003-05-21 at 19:24, Ian Latter wrote:
> Hello Brian and Dev ppls,

Hi All,

>   I'll post a link on it later, but I found a site that discussed the RPC
> module within Firewall-1 in greater detail than I had seen previously.

Cool.

>   One of the things that Firewall-1's RPC code did, that I didn't like, was
> that if you choose to "match" an RPC, then the matching module will
> automatically allow RPC portmapper requests through the firewall.

Hmmmm.  What does this mean exactly?  Simply an implicit:

iptables -I FORWARD -s $client/32 -d $server/32 -p tcp --dport 111 -j ACCEPT
iptables -I FORWARD -s $client/32 -d $server/32 -p udp --dport 111 -j ACCEPT

is installed if a rule that allowed $client to use RPC service 100003 on
$server was created?

This seems straightforward enough.  Afterall, the rule the user created
will not work work without (at least) the above UDP rule in place.

> I
> don't like the idea of "hidden rules", and hence in the Netfilter version,
> you need to permit the RPC portmapper requests explicitly.  So what
> you've seen is correct ... and this sort of ruleset;
> 
>   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

I wish the example did not use PREROUTING -t nat but rather simply
FORWARD or INPUT.  IMHO, it would be more clear what the module is all
about.

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

Why is this needed?  Does conntrack not automatically do this for me
(i.e. just like any other udp rule)?  I don't have any rule of this sort
in my policy and RPCs are working just fine here in my FORWARD chain.


> ... should work ... (was this what you found?) .. except for the "DUMP"
> request.

Yes, an application using the DUMP (i.e rpcinfo -p) request to find port
numbers is kinda cheating.  But it works and there are application(s)
using it.  Linux's mount command is one.

>   I'll need to read up on this one (I remember reading it through
> when I rejigged the module, but I ended up discarding it).

It's simply call that rpcinfo -p uses to get a dump of all registered
RPC routines and their port numbers.

>   There are two other features in the Firewall-1 RPC code that I want
> to add to the Netfilter RPC module;
> 
>   1)  Cached portmapper resolution -- establishing a slab cache the
>           dynamically stores the port vs the procedure number in memory
>           such that future RPC portmapper requests are redundant

Once you have an RPC GETPORT (which the client will do when it wants to
know a port on the server) is there really much to be saved looking up
the port in a table vs. just parsing the GETPORT reply?

>   2)  A kernel socket call to the RPC portmapper -- in case the RPC
>           module or rule is only activated after the client has already 
>           performed a portmapper resolution request, currently the RPC
>           module would fail to permit the valid RPC request.

Indeed.  But how is this situation any different than a regular UDP/TCP
session that is ESTABLISHED when a rule is put in place that affects
it's port?

Omce the client has used RPC to find the port of an RPC service it's
just regular TCP/UDP business as usual, is it not?

>   If, however,
>           the RPC port range

"the RPC port range"?  I will have to dig my TCP/IP Illustrated Volume I
out of storage, but IIRC, RPC servers just use ephemeral port numbers
and register them with the portmapper don't they?  I don't recall there
being any "range" of ports reserved for RPC servers.

>  was treated as a possible set of RPC "targets",
>           but for which a valid (matched) IP address had failed to resolve a
>           port for a given procedure; then the RPC module would make its 
>           own request to the portmapper to resolve the port and validate the
>           match.  The resolution could then be added to the local slab cache
>           to accelerate future matches.

But the problem is if the RPC netfilter module does not catch the
GETPORT call, there is nothing afterwards that can indicate to netfilter
that an ESTABLISHED session on a given port is to an RPC server vs. just
any other TCP/UDP server.

>   While it *sounds* like  I'm a great guy ready to do big things, the truth is
> that I haven't fixed my pointer module name problem in three weeks, so 
> these mods might be a little way off ;-)

I hear ya!

>   I am very appreciative of feedback on the use of this module and your
> successes/failures.  Of particular interest is performance ... let me know
> how you go with thrashing this thing under NFS ... because that is one
> of the big unanswered questions here ..

Well, beyond initially mounting an NFS filesystem, the RPC module has
nothing to do with NFS.  Once the filesystem is mounted, it's just
regular ol' UDP on whatever port the portmapper told the client (usually
2049).

This does bring up an interesting issue however.  The normal timeouts
for UDP sessions are not nearly long enough for NFS.  NFS can go quite a
long while without sending any traffic back and forth (no accesses to
the filesystem).  Other than a "hard" rule allowing the client to talk
to the server on port 2049, I am not sure how to handle this though.

>   Thanks for the feedback ... I'll check out that DUMP command and see
> what I can do ...

Well, it's an interesting problem because just because a client asks for
the list of service/ports a server is providing, it does not really mean
the client will want to use a service/port, and even if it does, the
netfilter RPC module cannot possibly know which one of the list the
client retrieves that it will want to use.  What expectation do you
install for a port dump?

>  which kernel version are you using?

2.4.20ish.

> (Cool database software, btw, I implemented it for an ISP in AU who
> had heard of it and used it before).

Which database software is that?

b.

-- 
Brian J. Murrell <netfilter@interlinx.bc.ca>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]