RPC portscanning

[Lamont Granquist <lamontg () raven genome washington edu>]

On Thu, 17 Dec 1998, Evan Brewer wrote:
> On Thu, Dec 17, 1998 at 10:54:43AM -0800, Lamont Granquist wrote:
> > I talked with Fyodor about adding RPC service portscanning to NMAP, so
> > that NMAP would be able to query ports with null RPC commands to figure
> > out which RPC service was listening, if any (I haven't looked at RPC
> > closely enough to figure out if you could do this with one query, or if
> > you'd need to send queries for every service that you'd be interested in
> > knowing about, anyway...).  Fyodor's opinion was that NMAP should try to
> > stay away from doing 'application' level stuff as much as possible and
> > that the identd scanning and such in the current version was pushing it.
>
> An interesting idea, however anything extrapolated from rpc may also (under
> most conditions) be determined by a normal port scan.  There is nothing that
> (Most of the time,) rpcinfo will tell you that a port scan wont.  Lets say
> port 2049/tcp is open.  Odds are this guy has NFS.  

That's only a characteristic of NFS.  To my knowledge it (and the
portmapper) are the only ones that you can assume that a given port
corresponds to a given service -- and even with NFS the RFC states that
programs should not assume that port 2049 is NFS and that this is
potentially subject to change.  To give you an example, here are the ports
that I just found mountd running on on a dozen machines that I just ran
rpcinfo -p over:

UDP: 3796 1122 1075 725 812 635 12441 12442 1126 1127 32929 33010 716 722 
TCP: 908 976 932 727 814 635 27972 27975  1024 1025 32776 32788 719 725

(okay, it was 15 machines with 14 different port numbers)

> > Anyway, I'd certainly think that RPC service scanning would be a hell of a
> > lot more generally useful than teaching NMAP about SNMP, but can
> > appreciate the sentiment behind not wanting to promote code bloat and not
> > wanting to do either of them.
>
> May be useful yes, however getting this info in a stealthlike matter requires
> a connection to portmap.  

I'm not sure what you mean here.  That's actually *not* a stealthy way to
do it, since the portmap could be wrapped against libwrap.a (from
tcp_wrappers) and queries from foreign hosts could be denied and logged.
On the other hand, many RPC services themselves have no access control and
very limited logging capabilities.  I'd personally feel a whole lot
stealthier in scanning a network from 600-1024 using stealth scan and then
querying the service directly to figure out what it was.  Tripwiring
against that kind of a scan is more difficult, requiring either the
sources to the RPC programs, some kind of kludgy hack like securelib, or
a firewall with logging.

-- 
Lamont Granquist                       lamontg () raven genome washington edu
Dept. of Molecular Biotechnology       (206)616-5735  fax: (206)685-7344
Box 352145 / University of Washington / Seattle, WA 98195
PGP pubkey: finger lamontg () raven genome washington edu | pgp -fka