Re: tcpwrapped rpcbind/portmap?

From: Chris Ess (
Date: 08/21/01

Date: Mon, 20 Aug 2001 19:32:13 -0400 (EDT)
From: Chris Ess <>
To: <>
Subject: Re: tcpwrapped rpcbind/portmap?
Message-ID: <>

> Perhaps I'm just a draconian BOFH type, but for systems that are
> production and in a DMZ, the only good rpc is no rpc.

Hear, hear.

Now, if you remove RPC from a webserver, what will you lose? NFS and
NIS/YP. (Any others? These are the only two I know of.)

NFS is, in general, weak and kludge-y in its implementations. And
inherently secure. NIS/YP is even less secure. (Yes, yes, NIS+ is
better... But not by much.)

Neither of these have a place on a dedicated webserver. In fact, aside
from port 80 and 443, should a dedicated webserver allow connections from
anyone on a port? Certainly not. SSH and FTP (if you really want to use
it) should be restricted to a group of IPs.

Let's say you don't have the resources to run a dedicated webserver. (I
know I don't.) From my understanding of RPC/portmap, you can in general
be safe if you drop port 111 requests coming from outside. But this
shouldn't be taken as a definite cure. It's just removing or deflecting a
vector of attack, such as removing the .ida and .idq bindings in IIS for
the Code Red worms. (If any of you followed that.)

If you *absolutely* have to use RPC for whatever reason, get a firewall
and drop your machine behind it. (It doesn't need to be a commercial
firewall. A BSD machine running ipf, a Linux machine with ipchains or
iptables, a pair of wirecutters (best firewall yet! <snip>), what have

Unfortunately, RPC like many other internel protocols wasn't designed with
security in mind. It might be possible to make RPC secure, but by the
time you do so, it's not RPC anymore.

Christopher Ess
System Administrator / CDTT (Certified Duct Tape Technician)