rpcbind opens two sockets on all interfaces on random ports when specified the -h flag, one socket for udp4 and one for udp6. How-To-Repeat: overnight# sockstat | grep rpcbind overnight# rpcbind -h 192.168.0.3 overnight# sockstat | grep rpcbind root rpcbind 2696 4 udp6 *:* *:* root rpcbind 2696 5 stream /var/run/rpcbind.sock root rpcbind 2696 6 udp6 ::1:111 *:* root rpcbind 2696 7 udp6 *:* *:* root rpcbind 2696 8 udp6 *:617 *:* root rpcbind 2696 9 tcp6 ::1:111 *:* root rpcbind 2696 10 tcp6 *:* *:* root rpcbind 2696 11 udp4 127.0.0.1:111 *:* root rpcbind 2696 12 udp4 192.168.0.3:111 *:* root rpcbind 2696 13 udp4 *:944 *:* root rpcbind 2696 14 tcp4 127.0.0.1:111 *:* root rpcbind 2696 15 tcp4 192.168.0.3:111 *:* overnight# killall rpcbind overnight# rpcbind -h 192.168.0.3 overnight# sockstat | grep rpcbind root rpcbind 2701 4 udp6 *:* *:* root rpcbind 2701 5 stream /var/run/rpcbind.sock root rpcbind 2701 6 udp6 ::1:111 *:* root rpcbind 2701 7 udp6 *:* *:* root rpcbind 2701 8 udp6 *:943 *:* root rpcbind 2701 9 tcp6 ::1:111 *:* root rpcbind 2701 10 tcp6 *:* *:* root rpcbind 2701 11 udp4 127.0.0.1:111 *:* root rpcbind 2701 12 udp4 192.168.0.3:111 *:* root rpcbind 2701 13 udp4 *:804 *:* root rpcbind 2701 14 tcp4 127.0.0.1:111 *:* root rpcbind 2701 15 tcp4 192.168.0.3:111 *:*
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
Isn't this just behaviour of RPCbind which selects some random sockets by default? the -h is used to bind it to a specific IP address, not to bind it to specific ports (as far as i can recall), so what you are printing is really what I would expect it to be. Matteo, you worked on this recently, can you shed a light on this? and if my reasoning above is correct, can you please close the ticket since it's desired behaviour? Thanks remko -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */
On Wed, Oct 31, 2007 at 10:55:13AM +0100, Remko Lodder wrote: > Matteo, you worked on this recently, can you shed a light on this? and > if my reasoning above is correct, can you please close the ticket since > it's desired behaviour? I know there are problems with the implementation of "-h" in rpcbind, and I'm working on them. I'll assign this PR to me and look at it with more attention. Thanks and Best Regards -- Matteo Riondato FreeBSD Volunteer (http://www.FreeBSD.org/) FreeSBIE Developer (http://www.FreeSBIE.org/) GUFI Staff Member (http://www.GUFI.org/)
Responsible Changed From-To: freebsd-net->matteo I'll take care of this PR
Just so that it is clear on the PR, the desired behaviour would be to have those random ports bind to the interface specified by -h. The problem is not that random ports are being opened, but that they are being opened on all interfaces. From my sockstat output: (first run) root rpcbind 2696 8 udp6 *:617 *:* root rpcbind 2696 13 udp4 *:944 *:* (second run) root rpcbind 2701 8 udp6 *:943 *:* root rpcbind 2701 13 udp4 *:804 *:* Those should be binding to 192.168.0.3:<port> instead of *:<port> Thanks for you work on this, Matteo, let me know if you want me to try anything or any other help I can provide. Regards, Carlos.
State Changed From-To: open->feedback Can you please try the patch (against -CURRENT) at http://people.freebsd.org/~matteo/diff/117711rpcbind.diff Thanks
Responsible Changed From-To: matteo->freebsd-bugs Reset PR assigned to inactive committer. To submitter: is this problem report still relevant to recent versions of FreeBSD? Hat: gnats-admin
% sockstat -4l | grep rpcbind % grep rpcbind /etc/rc.conf.local rpcbind_flags="-h 192.168.119.6" rpcbind_enable="YES" % sudo /etc/rc.d/rpcbind start Starting rpcbind. % sockstat -4l | grep rpcbind root rpcbind 4265 9 udp4 127.0.0.1:111 *:* root rpcbind 4265 10 udp4 192.168.119.6:111 *:* root rpcbind 4265 11 udp4 *:768 *:* root rpcbind 4265 12 tcp4 127.0.0.1:111 *:* root rpcbind 4265 13 tcp4 192.168.119.6:111 *:* % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #31 r239793: Wed Aug 29 03:00:30 SAMT 2012 bsam@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
State Changed From-To: feedback->open Submitter provided requested information http://www.freebsd.org/cgi/query-pr.cgi?pr=117711 Date: Wed, 27 Feb 2013 17:46:35 -0800
Hi, I've just run into this issue under FreeBSD 10 - rpcbind '-h' provides a false sense of security, as by default although some of the ports it sets up do indeed bind to the requested IP - there's one or more random ports opened on UDP - that ignore the '-h' IP address, and are open to the world. Is anyone able to look at this - this PR seems pretty ancient (filed in 2007, and the issue still kicking along in 2014? - 7 years?). As the ports opened are random they are also hard to protect with ipfw - so all in all, it's a bit of a PITA :( At the very least can someone flick it from 'Normal Affects Only Me' to 'Affects a Few people'? -Karl
I just also encountered this on 10.0-RELEASE issue while setting up a jail. 7 years is a pretty long time...
I will look into this.
This issue came up tonight on #dragonflybsd on EFNet, since rpcbind on DragonflyBSD behaves the same. I spent some time throwing in tons of debugging code to try and figure the cause. I only did testing/checking with an IPv4-only system (IPv6 is completely removed from kernel/userland) so that may need additional testing. Some details are below, mainly for Hiroki-san or whoever wants to tackle this. IMPORTANT: I do not have much familiarity with RPC behaviour or design, so fixing this may or may not be proper when compared to what the RFC specifies. I do not recommend fixing this until someone familiar with RPC and those RFCs is able to confirm that addressing this problem is acceptable. The "mysterious UDP port" that's bound to INADDR_ANY, even when using rpcbind -h is caused by the call to create_rmtcall_fd() in rpcb_svc_com.c -- which only happens when nconf->nc_semantics == NC_TPI_CLTS (no clue what that is/means). create_rmtcall_fd() makes a call to svc_tli_create() which is a libc function for making an RPC server handle. It calls the function like so: xprt = svc_tli_create(fd, 0, (struct t_bind *) 0, 0, 0); Per man page: SVCXPRT * svc_tli_create(const int fildes, const struct netconfig *netconf, const struct t_bind *bindaddr, const u_int sendsz, const u_int recvsz); svc_tli_create() This routine creates an RPC server handle, and returns a pointer to it. The fildes argument is the file descriptor on which the service is listening. If fildes is RPC_ANYFD, it opens a file descriptor on the transport specified by netconf. If the file descriptor is unbound and bindaddr is not NULL, fildes is bound to the address specified by bindaddr, otherwise fildes is bound to a default address chosen by the transport. An fd is already allocated (so RPC_ANYFD is not used), netconf is not specified (NULL/0), and -- here's the cause -- bindaddr is NULL/0, which is why INADDR_ANY is being chosen. Fixing this by passing create_rmtcall_fd() some stuff from outside of it (such as sa and addrlen) may be possible.
This is still present in 10.1-p3. # procstat -c 452 PID COMM ARGS 452 rpcbind /usr/sbin/rpcbind -h 10.0.0.8 # procstat -f 452 PID COMM FD T V FLAGS REF OFFSET PRO NAME 452 rpcbind text v r r------- - - - /usr/sbin/rpcbind 452 rpcbind cwd v d r------- - - - / 452 rpcbind root v d r------- - - - / 452 rpcbind 0 v c rw------ 3 0 - /dev/null 452 rpcbind 1 v c rw------ 3 0 - /dev/null 452 rpcbind 2 v c rw------ 3 0 - /dev/null 452 rpcbind 3 v r r------l 1 0 - - 452 rpcbind 4 s - rw------ 1 0 UDP ::.0 ::.0 452 rpcbind 5 s - rw------ 1 0 UDS /var/run/rpcbind.sock 452 rpcbind 6 s - rw------ 1 0 UDP ::1.111 ::.0 452 rpcbind 7 s - rw------ 1 0 UDP ::.961 ::.0 ^^^^^^^^^^^ 452 rpcbind 8 s - rw------ 1 0 TCP ::1.111 ::.0 452 rpcbind 9 s - rw------ 1 0 UDP 127.0.0.1:111 0.0.0.0:0 452 rpcbind 10 s - rw------ 1 0 UDP 10.0.0.8:111 0.0.0.0:0 452 rpcbind 11 s - rw------ 1 0 UDP 0.0.0.0:903 0.0.0.0:0 ^^^^^^^^^^^ 452 rpcbind 12 s - rw------ 1 0 TCP 127.0.0.1:111 0.0.0.0:0 452 rpcbind 13 s - rw------ 1 0 TCP 10.0.0.8:111 0.0.0.0:0
It is an interesting situation when you have both the host and a jail running NFS servers. I wonder what is rpcbind binding to the jail IP address causes any issues.
This is still present in 11.0-RELEASE-p1 root 675 0.0 0.0 10424 1912 - Ss 22:48 0:00.05 /usr/sbin/rpcbind -h 10.141.254.2 root rpcbind 675 4 udp6 *:* *:* root rpcbind 675 5 stream /var/run/rpcbind.sock root rpcbind 675 6 udp6 ::1:111 *:* root rpcbind 675 7 udp6 *:663 *:* root rpcbind 675 8 tcp6 ::1:111 *:* root rpcbind 675 9 udp4 127.0.0.1:111 *:* root rpcbind 675 10 udp4 10.141.254.2:111 *:* root rpcbind 675 11 udp4 *:922 *:* root rpcbind 675 12 tcp4 127.0.0.1:111 *:* root rpcbind 675 13 tcp4 10.141.254.2:111 *:*
The problem is, that rpcinfo *always* binds to 127.0.0.1 and ::1, regardless whether you have given these with a "-h" option. In a FreeBSD jail, binds to the loopback are always remapped to the primary jail address, and if this address is a public IP address, your jailed rpcbind will be available from extern! Either rpcbind should detect that it is running inside a jail, and then skip the implicit binding to localhost. Or, it should check whether the primary jail ip address is a public or private IP address and act accordingly (that is, not binding to 127.0.0.1 / ::1)
(In reply to Armin Gruner from comment #17) The behaviour you see is documented: rpcbind(8) > Note that when specifying IP addresses with -h, rpcbind will automatically add > 127.0.0.1 and if IPv6 is enabled, ::1 to the list. The actual topic of this PR is different: rpcbind binds to 0.0.0.0 even when a specific set of addresses is given as argument to -h. 0.0.0.0 means ANY address, this must not be confused with the mapping that occurs for 127.0.0.1 (-> primary jail ip) in a jailed environment. regards, Robert Schulze
Whops, yes, I stand corrected. I may open another ticket for this. Actually, I've worked around it by flipping the assignment of jail interfaces and adresses, if one uses a private IP address as the primary jail address, this one is used when 127.0.0.1 is remapped.
This is still present in 12.1-p10: # grep rpcbind /etc/rc.conf rpcbind_enable="YES" rpcbind_flags="-h 10.10.1.40" # ps auxwww | grep rpcbind root 6191 0.0 0.0 11332 2792 - Ss 16Sep20 1:19.83 /usr/sbin/rpcbind -h 10.10.1.40 # sockstat -l4 | grep rpcbind root rpcbind 6191 9 udp4 127.0.0.1:111 *:* root rpcbind 6191 10 udp4 10.10.1.40:111 *:* root rpcbind 6191 11 udp4 *:1011 *:* root rpcbind 6191 12 tcp4 127.0.0.1:111 *:* root rpcbind 6191 13 tcp4 10.10.1.40:111 *:*
Same issue here on stable/12:f2a88e744.