|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] sunrpc..a few questions
|
> Okay...so do I need it?
We probably can't tell you that, only you can. If you're not going to
use NFSD, then you probably don't need it IMO. You may be running
software that requires portmapper for some other reason that I'm not
aware of. Try running your system without it and see what happens. I
can't really give you any better advice than that.
> How can I block access to it from the internet?
Use a packet filtering filewall and start out with a restrictive
policy only allowing specified ports to specified internal machines.
Do what you'd usualy do. Again, only you can determine your needs.
> Can I use inetd.conf or hosts allow/deny to block those ports from the
> internet?
I don't know. You can probably learn more from
hosts.allow(5) and
hosts.deny(5) as well as
inetd(8)
> In the past, these things were not detected by Saint. But Saint-2.2 with
> NMAP indicates that the services are running. But, it doesn't flag them as
> a vulnerability. Yet, everything I've read indicates that the "r" commands
> are bad news. Aren't the "r" commands part of sunrpc?
No, if you look at your /etc/inetd.conf file, you'll see that the 'r'
commands each use their own server side programs -- which are not
rpc. 'man -k rpc' gave me this list:
f4rpcgen (1) - an RPC protocol compiler
getrpcent, getrpcbyname, getrpcbynumber (3) - get RPC entry
getrpcport (3) - get RPC port number
grpck (8) - verify integrity of group files
pmap_dump (8) - print a list of all registered RPC programs
pmap_set (8) - set the list of registered RPC programs
portmap (8) - DARPA port to RPC program number mapper
pwconv, pwunconv, grpconv, grpunconv (8) - convert to and from shadow passwords
and groups.
rpc (3) - library routines for remote procedure calls
rpc (5) - rpc program number data base
rpc.mountd (8) - NFS mount daemon
rpc.nfsd (8) - NFS server process
rpc.rusersd (8) - logged in users server
rpc.rwalld (8) - write messages to users currently logged in server
rpc.statd (8) - NSM status monitor
rpc.yppasswdd (8) - NIS password update daemon
rpc.ypxfrd (8) - NIS map transfer server
rquotad, rpc.rquotad (8) - remote quota server
rstatd, rpc.rstatd (8) - kernel statistics server
ypserv.conf (5) - configuration file for ypserv and rpc.ypxfrd
You can probably get a good idea of what RPC is and is used for from these
sources -- or by reading the late Richard Steven's books on Unix Network
Programming.
The 'r' commands are generaly considered to be bad news for a few reasons,
they thend to lower the bar for an attacker trying to gain access to
your system (if they're running), and they transmit all of their network
information (including login) in clear text across the network. If
misconfigured, the 'r' commands are too trusting -- when we worked togeather,
I broke into one of the unix boxes simply by creating an account on my
workstaion (running Linux), and running rlogin from that account against the
other box. The way the 'r' commands were configured there, they just
trusted you were who you said you were. Personaly, I turn off ftp, telnet,
and all of the rcommands as a general rule, and use ssh in their place,
as it doesn't suffer from the inherrent issues relating to the 'r' commands.
Through the use of ssh-agent, you can even acheive the kind of automation
that most people start out using the 'r' commands for in the first place.
k
--
------------------------------------------------------------------------------
"From a certain point onward there is no longer any turning back. That is the
point that must be reached." -- Kafka
mortis@voicenet.com http://www.voicenet.com/~mortis
------------------------------------------------------------------------------
______________________________________________________________________
Philadelphia Linux Users Group - http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion - http://lists.phillylinux.org/mail/listinfo/plug
|
|