By Kurt Seifried Rev 0.1
Securing specific services - Telnet (S07.C01)
Telnet was one of the first services on what is now the Internet, it allows you to login to a remote machine interactively, issue commands and see their results. It is still the primary default tools for remote administration in most environments, and has nearly universal support (even NT has a telnet daemon and client). It is also one of the most insecure protocols, suspectible to sniffing, hijacking, etc. If you have clients using telnet to come into the server you should definately chroot their accounts if possible, as well as restricting telnet to the hosts they use with tcp_wrappers. The best solution for securing telnetis to disable it and use ssh.
Problems with telnet include:
The best solution is to turn telnet off and use ssh. This is however not practicle in all situations. If you must use telnet then I strongly suggest firewalling it, have rules to allow hosts/networks access to port 23, and then a general rule denying access to port 23, as well as using tcp_wrappers (which is more effecient because the system only checks each telnet connection and not every packet against the firewall rules) however using tcp_wrappers will allow people to establish the fact that you are running telnet, it allows them to connect, evaluates the connection, and then closes it if they are not listed as being allowed in.
An example of firewalling rules:
ipfwadm -I -a accept -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 23 ipfwadm -I -a accept -P tcp -S some.trusted.host/32 -D 0.0.0.0/0 23 ipfwadm -I -a deny -P tcp -S 10.0.0.0/8 -D 0.0.0.0/0 23
An example of the same using tcp_wrappers:
In /etc/hosts.allow in.telnetd: 10.0.0.0/255.0.0.0, some.trusted.host And in /etc/hosts.deny in.telnetd: ALL
There are several encrypted alternatives to telnet as mentioned before, ssh, SSLeay Telnet, and other third party utils, I personally feel that the 'best' alternative if you are going to go to the bother of ripping telnet out and replacing it with something better is to use ssh.
To secure user accounts with respect to telnet there are several things you can do. Number one would be not letting root login via telnet, this is controlled by /etc/securetty and by default in RedHat Linux 5.X root is restricted to logging on from the console (a good thing). For a user to succesfully login their shell has to be valid (and a shell is evaluated against the list in /bin/shells) so setting up user accounts that are allowed to login is simply a matter of setting their shell to something valid, and for keeping users out as simple as setting their shell to /bin/false and making sure that is not listed in /etc/shells. Now for some practical examples of what you can accomplish by setting the user shell to things other then shells.
For an isp that wishes to allow customers to change their password easily, but not allow them access to the system (my isp uses ultrasparcs and refuses to give out user accounts for some reason).
in /etc/shells list: /usr/bin/passwd and set the users shell to /usr/bin/passwd so you end up with something like: username:x:1000:1000::/home/username:/usr/bin/passwd and voila, the user telnets to the server, logs in, and is prompted to change his password, if he does so succesfully he gets the boot, if not, he gets the boot and everyone is happy.
Securing FTPD | Back to Section 7
Contact Kurt Seifried, All rights reserved Kurt Seifried 1998, content and information may not be reposted physically or electronically without the express permission of the author, this includes but is not limited to www mirror sites, email, usenet news, etc.