On Sat, Oct 27, 2007 at 04:40:27PM -0700, Darren Reed wrote: > > Hi David, > > Interesting approach... > > Just to ponder the RPC problem... > - each RPC name has an assigned number > - the port on which an RPC lives is dynamic and determined at runtime > - the start of each RPC call includes the RPC number > - determining the correct port is done by asking the portmapper
Also, the portmapper calls themselves are RPC calls (RPC program 100000). > For UDP, the RPC# must be included in the packet sent to the port, > but for TCP, in order to get the RPC# you need to allow the connection > to establish first. This connection establishment might be more than > what people are comfortable with (or expect.) Currently many users of RPC products (such as Sun StorageTek ACSLS, which is robot management software or EMC NetWorker, for backups) open "ranges" of tcp ports (because the assignment of ports in such ranges is dynamic). > A different approach might be to work it like this: > pass in quick proto udp from any to any port = 111 keep state (rpcmap) > ..and use that with your rules like this: > > pass in quick proto udp all rpc 390100:390120 keep state > > and to then build up a mapping of port#'s to RPC#'s per IP# by monitoring > the conversation with the portmapper (it's been a long time since I looked > at the proxy, so I don't know if this is how it works.) > > What do you think? This is correct and ideally the approach that you indicate there (and which I think is the approach of the proxy rpc code) should be followed. There's a practical problem namely that I currently lack sufficient know-how on ipfilter and the RPC proxy to get the RPC proxy to work ... On the other hand, I was also pondering on the *theoretical* possibility of just allowing RPC calls/responses without even considering the use of the portmapper. Suppose I know that a RPC service runs on TCP port ABC (fixed). I send a RPC request to ABC without even asking a portmapper, then the RFC on RPC still indicates how the XDR encoded RPC request should look like, so the ipfilter could "decode" the XDR encoded RPC request and say, "hey, this is a rpc request to program XYZ" or "hey, this is not a valid RPC request". Theoretically it could be interesting to have a function in the firewall to allow "something that resembles a RPC call". I'm going to tinker a little bit around, but as I've said that patch with the #ifdef STES code is highly experimental so don't apply it :-) Regards, David Stes
