Unable to Specify Interface for TCP Portmapper

I'm crushed. Today while working on a FreeBSD system with multiple interfaces, I noticed the portmapper (rpcbind) listening where I didn't think it should be.

# sockstat -4 | grep rpcbind
root     rpcbind    354   10 udp4   127.0.0.1:111         *:*
root     rpcbind    354   11 udp4   10.0.0.1:111          *:*
root     rpcbind    354   12 udp4   *:1007                *:*
root     rpcbind    354   13 tcp4   *:111                 *:*

The UDP version was listening on interface 10.0.0.1 as I expected. What was the TCP version doing listening on all interfaces? Also, what was port 1007 UDP doing?

I checked my /etc/rc.conf file to see if I had messed up the synatx.

rpcbind_enable="YES"
rpcbind_flags="-h 10.0.0.1"

That looked ok to me. I double-checked with /etc/defaults/rc.conf.

# grep "^rpcbind" /etc/defaults/rc.conf
rpcbind_enable="NO"             # Run the portmapper service (YES/NO).
rpcbind_program="/usr/sbin/rpcbind"     # path to rpcbind, if you want a different one.
rpcbind_flags=""                # Flags to rpcbind (if enabled).

I finally looked at the man page and clarified the -h switch.

     -h      Specify specific IP addresses to bind to for UDP requests.  This
             option may be specified multiple times and is typically necessary
             when running on a multi-homed host.  If no -h option is speci-
             fied, rpcbind will bind to INADDR_ANY, which could lead to prob-
             lems on a multi-homed host due to rpcbind returning a UDP packet
             from a different IP address than it was sent to.  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.

OH NO. It only mentions UDP and not TCP. That's why I'm crushed. One of the characteristics I like about FreeBSD (and Unix in general) is the granular control over services enabled via simple text files. I should have been able to tell both UDP and TCP rpcbind versions to listen on a specified interface. That doesn't seem possible.

Now my only alternative is to firewall the interfaces where I do not want rpcbind to listen. That's a lousy solution in the Unix world. :(

Comments

Anonymous said…
I had the same fun trying to secure it on my laptop.

You can use tcpwrappers to lock down access, however IMHO anything hard binding to INADDR_ANY is inexcusable in this day and age.

It's not just rpcbind, there are other culprits.

I can point the finger at

Sambas nmbd,
isc dhcpd,
& Symon

To name a few, utterly ridiculous.

I do not want to have to rely exclusively on access control in the application doing the 'right' thing.

They shouldnt have their drawers round their metaphorical ankles in the 1st place.

Especially given the propensity of the ports system to update startup scripts which themselves do not utilise rc.conf properly.

It wouldnt be the 1st time I've seen something like mysql comeup on everything, after a hand hacked lockdown of it's startup script got nuked by portupgrade.





Greg
3:47 PM
Anonymous said…
For what it's worth, this page is the first Google hit for "freebsd rpcbind bind to specific IP". I'm trying to set up FAM on a imap server on the public internet. It amazes me that there is no way to specify what interface that rpcbind sits on... I guess I'm going to have to resort to running ipfw and allowing only specific ports. Guh.
4:19 PM
Richard Bejtlich said…
I just posted this PR:

http://www.freebsd.org/cgi/query-pr.cgi?pr=84494

>Category: bin
>Responsible: freebsd-bugs
>Synopsis: rpcbind TCP cannot be told to bind to a specific IP
>Arrival-Date: Tue Aug 02 20:40:08 GMT 2005
4:52 PM
Post a Comment

Popular posts from this blog

Zeek in Action Videos

Image
This is a quick note to point blog readers to my Zeek in Action YouTube video series for the Zeek network security monitoring project .  Each video addresses a topic that I think might be of interest to people trying to understand their network using Zeek and adjacent tools and approaches, like Suricata, Wireshark, and so on.  I am especially pleased with Video 6 on monitoring wireless networks . It took me several weeks to research material for this video. I had to buy new hardware and experiment with a Linux distro that I had not used before -- Parrot .  Please like and subscribe, and let me know if there is a topic you think might make a good video.
Read more

MITRE ATT&CK Tactics Are Not Tactics

Image
Just what are "tactics"? Introduction MITRE ATT&CK  is a great resource, but something about it has bothered me since I first heard about it several years ago. It's a minor point, but I wanted to document it in case it confuses anyone else. The MITRE ATT&CK Design and Philosophy document from March 2020 says the following: At a high-level, ATT&CK is a behavioral model that consists of the following core components: • Tactics, denoting short-term, tactical adversary goals during an attack; • Techniques, describing the means by which adversaries achieve tactical goals; • Sub-techniques, describing more specific means by which adversaries achieve tactical goals at a lower level than techniques; and • Documented adversary usage of techniques, their procedures, and other metadata. My concern is with MITRE's definition of "tactics" as "short-term, tactical adversary goals during an attack," which is oddly recursive. The key word in the tacti
Read more

New Book! The Best of TaoSecurity Blog, Volume 4

Image
  I've completed the TaoSecurity Blog book series . The new book is  The Best of TaoSecurity Blog, Volume 4: Beyond the Blog with Articles, Testimony, and Scholarship .  It's available now for Kindle , and I'm working on the print edition.  I'm running a 50% off promo on Volumes 1-3 on Kindle through midnight 20 April. Take advantage before the prices go back up. I described the new title thus: Go beyond TaoSecurity Blog with this new volume from author Richard Bejtlich. In the first three volumes of the series, Mr. Bejtlich selected and republished the very best entries from 18 years of writing and over 18 million blog views, along with commentaries and additional material.  In this title, Mr. Bejtlich collects material that has not been published elsewhere, including articles that are no longer available or are stored in assorted digital or physical archives. Volume 4 offers early white papers that Mr. Bejtlich wrote as a network defender, either for technical or pol
Read more