wietse @
wzv .
win .
tue .
nl (Wietse Venema) writes:
# You should definitely add the SunRPC services. These listen on random
# port numbers: a client typically gets that port number from the
# portmapper (port 111). Some RPC daemons listen on privileged ports
# (600-1023). Many RPC services can be accessed via both TCP and UDP.
RPC is a real bitch to filter effectively, without accidentally
filtering other stuff. Appended is the discussion of RPC from my
packet filtering paper (the full paper is available for anonymous FTP
from FTP.GreatCircle.COM, file "pub/pkt_filtering.ps.Z").
# Because of the unpredictability of RPC daemon port numbers, better not
# run RPC services on firewall hosts.
I'll agree with that sentiment...
4.6. RPC is very difficult to filter effectively
Finally, RPC-based protocols offer a special challenge,
since they don't reliably appear on a given UDP or TCP port
number. The only RPC-related service that is guaranteed to
be at a certain port is the "portmapper" service. Port-
mapper maps an RPC service number (which is a 32-bit number
assigned by Sun Microsystems to each individual RPC service,
including services created by users and other vendors) to
the particular TCP or UDP port number (which are much
smaller 16-bit numbers) that the service is currently using
on the particular machine being queried. When an RPC-based
service starts up, it registers with the portmapper to
announce what port it is living at; the portmapper then
passes this info along to anyone who requests it.
The portmapper isn't required in order to establish an
RPC connection, except to determine exactly which port to
establish the connection to; if you know (or can guess)
which port to establish the connection to, you can bypass
the portmapper altogether. What port a given RPC protocol
(such as YP/NIS, NFS, or any of a number of others) ends up
using is random enough that the administrator can't effec-
tively specify filters for it (at least, not without risking
the inadvertent filtering of something else that happened to
end up on the same port the administrator thought an RPC-
based service might end up at), but not so random that an
attacker can't easily "guess" where a given protocol lives.
Even if they can't or don't guess, a systematic search of
the entire port number space for the RPC service they're
interested in attacking is not that difficult. Since RPC-
based services might be on any port, the filtering implemen-
tation has no sure way of recognizing what is and what isn't
RPC; as far as the router is concerned, it's all just UDP or
TCP traffic.
Two fortuitous characteristics of most RPC-based ser-
vices can be used to save us from this morass, however.
First, most RPC-based services are offered as only on UDP
ports; we can simply drop UDP packets altogether except for
DNS, as described above. Second, almost all of those that
are offered on TCP ports use ports below 1024, which can be
protected by an "deny all ports below 1024 except specific
services like SMTP" type of filter, such as shown in the
example in Section 4.2.
-Brent
--
Brent Chapman Great Circle Associates
Brent @
GreatCircle .
COM 1057 West Dana Street
+1 415 962 0841 Mountain View, CA 94041
|
|
