disabling rexec, rsh, rlogin, and rcp on Debian
 

Hello all, I just want to make sure a server i'm setting up does not have any of the "r" daemons enabled (ie rexec, rsh, rlogin, and rcp)

Not sure if debian has them disabled by default or if someone can point me in the right direction to disable them

Distro is debian version 6 32bit

thanks
Moses

So long as you have a relatively recent version of Debian I'd think these would be disabled by default in favor of ssh/scp/sftp.

Typically these r commands, if enabled, are enabled in either inetd or xinetd. I haven't used a new version of Debian for a while but my recollection is it used inetd. If you run "man inetd" or "man xinetd" you should see which is used and the location of conf files (typically /etc/inetd.conf or /etc/xinetd.conf or even /etc/xinetd.d as a directory of individual configuration files). You could also simply run "ps -ef |grep inetd" to see what process is running (if any - some distros don't even install inetd/xinetd by default). Of course you can also look for other stand alone daemons like rshd.

Since the commands listen on ports 513/514 you could simply run "lsof -i :513" and "lsof -i :514" to verify nothing is listening on those ports.

VERY helpful info! thank you for the quick reply as well
looks like my first quess was right and with your info it is now confirmed. the "r" versions of cp, ftp,etc were replaced with the "s" secured versions

ftp by the way isn't one of the r commands. The equivalent r command is rcp. ftp itself is also considered somewhat insecure. It listens on port 21 (and 20 for data). Since much of the world uses ftp for site to site transfers id does become necessary sometimes to enable but if so it is usually a good idea to insure the ftp directories are secured via jails or other methods. However, unless there is a specific need to use ftp then scp/sftp are the best to use as they encrypt the entire connection (login/password/data).

While you're at it you might want to verify telnet port 23 is not listening either. It is generally better to use ssh for transfers because here again ssh encrypts the entire connection.