KBTAG: kben10000135
URL: http://www.securityportal.com/lskb/10000100/kben10000135.html
Date created: 07/08/2000
Date modified: 10/08/2000
Date removed:
Authors(s): Kurt Seifried seifried@securityportal.com
Topic: Overview of Telnet
Keywords: Network/Telnet
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, susceptible to sniffing, hijacking, etc. If you have clients using telnet to come into the server you should definitely chroot their accounts if possible, as well as restricting telnet to the hosts they use with TCP_WRAPPERS. The best solution for securing telnet is to disable it and use SSL'ified telnet or ssh.
Problems with telnet include:
The best solution is to turn telnet off and use ssh or some other secure replacement.
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 efficient 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 -D 0.0.0.0/0 23 ipfwadm -I -a deny -P tcp -S 0.0.0.0/0 -D 0.0.0.0/0 23
or in ipchains:
ipchains -A input -p all -j ACCEPT -s 10.0.0.0/8 -d 0.0.0.0/0 23 ipchains -A input -p all -j ACCEPT -s some.trusted.host -d 0.0.0.0/0 23 ipchains -A input -p all -j DENY -s 0.0.0.0/0 -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
most distributions root is restricted to logging on from the
console (a good thing). For a user to successfully login their
shell has to be valid (this is determined by the list of shells
in /etc/shells), so setting up user accounts that are allowed to
login is simply a matter of setting their shell to something
listed in /etc/shells, and keeping users out as simple as setting
their shell to /bin/false (or something else 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, I wonder why).
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, is prompted for
their username and password, and is
then prompted to change their password. If they do so
successfully passwd then exits and they are disconnected. If they
are unsuccessful passwd exits and they are disconnected. The
following is a transcript of such a setup when a user telnets in:
Trying 1.2.3.4 Connected to localhost. Escape character is '^]'. Red Hat Linux release 5.2 (Apollo) Kernel 2.2.5 on an i586 login: tester Password: Changing password for tester (current) UNIX password: New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully Connection closed by foreign host.
Telnet also displays a banner by default when someone connects. This banner typically contains systems information like the name, OS, release and sometimes other detailed information such as the kernel version. Historically this was useful if you had to work on multiple OS's, however in today's hostile Internet it is generally more harmful then useful. Telnetd displays the contents of the file /etc/issue.net (typically it is identical to /etc/issue which is displayed on terminals and so forth), this file is usually recreated at boot time in most Linux distributions, from the rc.local startup file. Simply edit the rc.local file, either modifying what it puts into /etc/issue and /etc/issue.net, or comment out the lines that create those files, then edit the files with some static information.
Typical Linux rc.local contents pertaining to /etc/issue and /etc/issue.net:
# This will overwrite /etc/issue at every boot. So, make any changes you # want to make to /etc/issue here or you will lose them when you reboot. echo "" > /etc/issue echo "$R" >> /etc/issue echo "Kernel $(uname -r) on $a $(uname -m)" >> /etc/issue cp -f /etc/issue /etc/issue.net echo >> /etc/issue
simply comment out the lines or remove the uname commands. If you absolutely must have telnet enabled for user logins make sure you have a disclaimer printed:
This system is for authorized users only. Trespassers will be prosecuted.
or something like the above. Legally you are in a stronger position if someone cracks into the system or otherwise abuses your telnet daemon.