لطفا منتظر باشید ...
Configuring
Telnet
Telnet may be the most common login protocol
on the Internet. Most OSs, including Linux, ship with Telnet client programs
(usually called telnet ). There are Telnet clients available for those few OSs that don't
ship with them. Telnet servers are also quite common, although they're most
common on OSs that support multiple simultaneous users, such as Linux, UNIX,
and VMS. In many ways, Telnet is a more complex protocol than is that used by rlogind , but
it's still fairly simple as TCP/IP protocols go. Configuring Telnet on Linux
usually involves installing a package and ensuring that the protocol is enabled
in your super server, although in some cases you'll want to investigate startup
options. You can also configure a few other elements of Telnet's operation,
such as the login message it returns to clients.Telnet's security is weak by modern
standards, but it's not quite as bad as is rlogind 's. Understanding
precisely how Telnet's security is weak can help you know where it is and is
not appropriate to use this protocol, and how to minimize risks if you must use
it in situations where it's less than ideal to do so. As with rlogind , you can improve Telnet's security
by using a Kerberized version of the client and server, if your network
supports Kerberos.
Setting
Telnet Startup Options
The Telnet server may or may not be installed in your Linux
distribution by default. There's little standardization in terms of the package
names under which this server is distributed. For instance, it's included in
Caldera's netkit-telnet ,
Debian's telnetd , Mandrake's telnet-server , Red Hat's telnet-server , Slackware's tcpip1 , SuSE's nkitserv , and TurboLinux's telnet .
Some of these, like Debian's telnetd ,
contain the Telnet server only; others, like TurboLinux's telnet , include the client and server
together in one package. Most distributions install the relevant packages by
default with most installation options, but the server may or may not be
configured to run by default. Consult
Telnet server (which is usually called telnetd
or in.telnetd ) via your
distribution's super server.The Telnet server accepts a number of arguments that can
modify the way it operates. Some of these, however, relate to optional security
features that aren't available on most standard Telnet servers. The more useful
options include the following: -D debugmode This option is intended
for debugging Telnet or its connections. To use it, you launch telnetd from the console, rather than via
a super server. Depending on what you enter as debugmode , the server displays information on the
connection or the data it receives. Possible debugmode values include options and report
(both of which show information about the negotiation of connections), and netdata and ptydata (which display the incoming and outgoing data
streams, respectively). -h
Normally, telnetd sends a login banner to clients, identifying the computer for the
user's benefit. This banner sometimes contains information you'd prefer that
random outsiders not have, such as the version of the OS you're running. Using -h suppresses the display of this banner,
thus giving a would-be intruder less information on your system. -L loginprog By default, telnetd uses /bin/login to handle login interactions. You can specify
some other program if you like, though. -n Like rlogind , telnetd
uses keepalive messages to check that a client is still active, and to close a
link if a client becomes inaccessible. This option disables the use of
keepalive messages.The server supports several additional options, mostly related
to data encryption and security, but most of these options aren't useful except
on comparatively rare Telnet servers that include these features. Although
encrypted versions of Telnet exist, and in theory can be a good solution for
secure text-mode logins, these Telnet variants haven't become very popular;
that role has been filled largely by SSH. If your network uses Kerberos,
though, the Kerberized version of Telnet that ships with Kerberos is well worth
investigating, as described in
Adjusting
the Telnet Login Display
The telnetd
server reads the contents of the /etc/issue.net
file and displays it to clients when they first connect. This file is displayed
before the user has a chance to log into the
system, and it's what is suppressed by inclusion of the -h startup option to telnetd . The intent is that this message
announce something about the computer to let users know that they've connected
to the correct system. The default message, though, usually announces the Linux
distribution name, and often additional information such as the kernel version.
Most users don't need or want this information, but it can be very helpful to
those who would break into your computer because it may give them clues about
what other software may be running on your system, some of which may have
security-related bugs.NOTE
align=left border=0> A similar file, /etc/issue ,
displays a login message for console
loginsthose done at the keyboard and display connected directly to the
computer. (X-based logins don't use either file, though; they're handled
through a display manager program such as those discussed in
On many systems, you can edit /etc/issue.net
directly. Change the text to whatever you'd like. You can include several
variables in your text, which telnetd
replaces with system-specific information. These are summarized in
If your computer were called maple.threeroomco.com , this might result the following
login banner: $ telnet maple.threeroomco.com Trying 172.21.32.43... Connected to maple.threeroomco.com. Escape character is '^]'. Welcome to maple.threeroomco.com. Current time is 10:57 on Monday, 12 August 2002. Notice: For authorized users only!
Table 13.1. Variables Usable in /etc/issue.net
Variable
Meaning
%t
The current tty (a number corresponding to a text input/output
device)
%h
The computer's FQDN
%D
The name of the NIS domain, if the computer uses NIS
%d
The current date and time
%s
The name of the operating system ( Linux )
%m
The hardware (CPU) type
%r
The kernel version number
%v
The OS version (generally not a useful value)
%%
Displays a single percent symbol ( % )
Unfortunately, there's a potentially major wrinkle in this picture.
Some distributions (notably Caldera, Mandrake, and some versions of Red Hat)
recreate /etc/issue and /etc/issue.net on every boot. They do this
via the /etc/rc.d/rc.local
script, which includes lines resembling the following (in Mandrake 8.1): # 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. if [ -x /usr/bin/linux_logo ];then /usr/bin/linux_logo -c -n -f > /etc/issue echo "" >> /etc/issue else > /etc/issue fi echo "$R" >> /etc/issue echo "Kernel $(uname -r) on $a $SMP$(uname -m) / \l" >> /etc/issue if [ "$SECURITY" -le 3 ];then echo "Welcome to %h" > /etc/issue.net echo "$R" >> /etc/issue.net echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue.net else echo "Welcome to Mandrake Linux" > /etc/issue.net echo "-------------------------" >> /etc/issue.net fi
NOTE
align=left border=0> Red Hat has shifted to static issue and issue.net
files with version 7.2, but Caldera 3.1 and Mandrake 8.1 continue to create
these files from the /etc/rc.d/rc.local
files.
Some of these lines reference variables that are defined
earlier in the script. This procedure allows the system to create a login
banner that's slightly more dynamic than might otherwise be possible, such as
specifying the number of CPUs in the computer. On the other hand, it means that
if you want to change your login banner, you must modify the /etc/rc.d/ rc.local script. You can either
comment out or delete the lines that modify /etc/issue
and /etc/issue.net and adjust
those files directly, as just described, or you can modify the lines in /etc/rc.d/rc.local to better reflect your
intended message.
Understanding Telnet Security
After telnetd sends the
contents of /etc/issue.net (with any applicable variable substitutions) back to the client, it
passes control of the connection to /bin/login , or whatever
program was specified by the -L loginprog parameter to telnetd . The /bin/login program is used for local text- mode logins, as well as remote
logins. It presents two prompts, login: and Password: , at which users
should enter their usernames and passwords, respectively. Assuming these are
entered correctly, /bin/login notes when the last login occurred and passes control to the user's
default shell.One very important consequence of this
sequence, in conjunction with the fact that most Telnet servers are not
configured to encrypt data transfers, is that both the username and the password
are sent unencrypted over the network. This is true even though the user won't
see the password echo to the screen. Unless you use -L loginprog to change the login program that telnetd uses, this unencrypted
username/password pair is the only authentication method used by telnetd ; it
does not use a trusted hosts model like rlogind , and
it doesn't even rely upon the client to automatically transmit the username
(although this information does ultimately come from the client computer, and
some Telnet client programs can be configured to send the username and even the
password automatically).The unencrypted nature of Telnet logins is a
potential threat because the data stream might be intercepted between the
client and the server. In most Internet transfers, packets pass between a dozen
or more routers. If any of these routers has been compromised, the cracker
who's done so might note the password that's passed over the Telnet session and
use it to gain access to your computer. A threat that's at least as great is
the potential for packet sniffing on the
network that's local to either the client or the server. In this approach, a
computer (which may not be directly involved in the data transfer)
"sniffs" the network wires for data such as passwords. Again, the
result is a compromised password.In addition to risking login passwords,
Telnet's unencrypted nature means that all the data passing over the connection
after it's established may be compromised. This includes private e-mail that's
read, confidential files that are edited, and any additional passwords that
might be typed (for instance, if the user connects to another computer or uses su to acquire
superuser privileges). The same comments apply to rlogind and other
unencrypted protocols (which includes most protocols in common use today). The
unencrypted nature of Telnet and rlogind is potentially more serious than,
say, unencrypted e-mail transmission because Telnet and rlogind are
general-purpose protocolsin one connection, you can give away your login
password, the contents of private e-mail, the contents of sensitive files, and
more.Short of switching to an encrypted protocol,
what can you do to minimize your risks with Telnet? The basic rule of thumb is
to transfer as little sensitive data as possible. Don't read confidential or
otherwise sensitive files or e-mail using Telnet. Don't log directly into
another computer, even if you use Telnet to reach the first computer but then
use SSH or some other secure channel. Don't use su to acquire root privileges.
Don't use the password for any computer you access via Telnet on any other
computer. Telnet is best used on small private networks that you're confident
haven't been compromised, like a private LAN with no Internet connectivity. If
you must use Telnet, change your password frequently (preferably not over a Telnet link) to give any would-be
attackers a limited window of opportunity for doing more damage should they
abscond with your password.
