UNIX for Dummies Questions & Answers

It varies by implementation. On solaris, scp is using -C for compression and on HPUX +C. But generally, the options for rcp match scp/scp2 and ssh/ssh2 matches rlogin and rsh. There is even sftp for ftp, but the options and commands are a bit less well matched.

Of course, the passwordless .rlogin is gone, and you need correct .ssh/ or .ssh2/ subtrees either in your home dir or the substitute dir (needed when home dirs are NFS) with keys and known hosts. For one id, once you get one host working, you can scp -p the subtree to the next host and everything but localhost/127.0.0.1 will work, give or take any funny hosts file entry contradictions.

"Server hardening" means to make the servers operation more secure. As you have already beeen advised you should disable the server part of some unsecure protocols, which is done by disabling them in inetd.conf. Deleting some binaries (which are not the server-, but the client parts of the protocol) will

1) accomplish nothing because incoming connections would still be possible

2) alter the system because before this change you had a system where these binaries were present and afterwards you have a system where these binaries are not present. Altering the system is not advisable generally.

If you still think you have to change the system you should do so at least by using a package instead of doing it by hand.

??

I don't know who (or what) you mean by "they". If you mean "the binaries": "they" are not going to change the system, but YOU are going to change the system if you change their permissions.

Before this change you have: a set of files, directories, etc., all with some specific permissions. This is called "your system". If you alter the permission of a binary which is part of this system, you are altering it.

As I said above altering the system should be done only by applying/removing packages. The reason is that manual changes to the system are not documented well and usually not redoable. Imagine that your hardware breaks and you have to rebuild your server in exactly the same way it was: if you have done your change via a package you would obtain a list of all the packages installed on the old machine, apply all the packages (including yours) one after the other onto your new hardware and end up with the same server state as before.

If you have done that manually, you may or may not end up with the same system state as before, depending on if you can find the documentation of the change, if you remember that change having to be applied, etc., etc..

I hope this helps.

bakunin

Hello
You have many options , if not needed uninstall them ...
Deactivate them via inetd.conf and the likes ...
If still needed by you, do a chmod 700 on them, so only root can run them .(the clients binaries , not the service )
But beware that if a user has a shell on the machine, he/she can upload its own client binaries and run them ...

The consensus from posts #14 and #16 is to disable the service daemons such as "rlogind" by controlling "inetd" rather than messing with the binaries for outgoing programs such as "rlogin". It is inadvisible to change the permissions on the deamons because you could crash inetd .

Always have a known good backup and a regression plan before making changes.

So, there are no available daemons for direct listening to spawn rsh, rlogin and rcp (rsync, remsh, rexec, . . . ?)? Still, just removing/commenting inetd and maybe services lines seems fragile.

All the system distributions should deliver these commands as an optional package that you do not install, unless you accept the vulnerabilities and have some need to support them, way yesterday dude!

These vulnerabilities should be down to near the same level as ftp and telnet if properly configured: plain text data on the network, but with the added concern of passwordless login between hosts. If there are not configurable controls to block * user or host, then as root, you can scan for dumb .rhosts files on every host. They are not so bad on well firewalled subnets of an intranet.

If by 'fragile' you mean 'does not lobotomize it to the point it'll never work again' then yes, it's fragile, and we are weak-minded cowards for suggesting it.

By broader standards, well: All it amounts to is an init system, if you're willing to rely on your init scripts to boot the machine you can rely on this to not boot RCP. Comment out the RCP settings and it won't understand how to use RCP any more. It's also the correct way; disabling RCP just by blasting holes in the executables doesn't warn inetd of this, so could cause weird error messages. An attacker would have to modify arbitrary files as root, or induce inetd to run and/or modify arbitrary files as root, in order to kick RCP on; if he could do that you're screwed with or without RCP.

(I don't like inetd either, but because of how complicated it makes everything, not any particular security complications. It just runs daemons, the daemons run as per usual.)

Part of security is making it hard to open a vulnerability, and enabling easy detection of newly established holes. Once your sysytem is compromised, how hard it is to discover the trap door? An insider might put a listener on a cron somewhere so he can connect and get some sort of access without these executables, or with them renamed and running on odd ports. A PERL script could do this. You might need a port scanner to ensure you like all the listeners. Wherever you lock out the unwanted, now you need ways to ensure the lock has not been removed.

Many simple minded or strict security audits look for these commands installed, so removal becomes a political necessity.

(For one audit, I used a binary replace to make a new shared lib with a different trap door password, as we did not have the source or a clean, compatible version! However, the install default master password was still in use!)