Security problem in telnet
(Li Suke July 30, 2001 10:50) 1, Telnet facing the main security issues
User Certification Data Transfer Privacy Prevent Telnet of Telnet is not a good protection mechanism, so it is necessary to protect it with other external protection. Telnet itself is:
There is no password protection, and the account and password of the remote user's landing transfer are clear text, and the use of ordinary Sniffer can be intercepted without a powerful certification process. Just verify the connector's account and password. No integrity check. The transmitted data has no way to know if it is complete, not the data that is tampered. The transmitted data is not encrypted. SSH is a good Telnet security system, but if it is more stringent, you must use other Telnet security products. SSH has been introduced in detail in the previous introduction, mainly introducing security principles and safety products. 1.1 The user authentication has the following ways to the user's certification:
NULL does not use authentication kerberos_v4 Use Kerberos_V4kerberos_v5 to use Kerberos_V5SPX to use SPXRSA to use RSA public key private key authentication LOKI use Lokl
See the related RFC documentation for the relevant content of the certified. Related RFC documents and connections are: RFC1409 http://andrew2.ndrew.cmu.edu/rfc/rfc1409.html RFC1411 http://andrew2.ndrew.cmu.edu/rfc/rfc1411.html Kerberos Version4 authenticated RFC document RFC1416 http: // www.faqs.org/rfcs/rfc1416.html, this is an RFC documentation about the Telnet authentication option. There is a relationship with the user's authentication and the security level of your own network. Different security levels use different authentication methods. The specific authentication agreement is not the scope of this book discussion. 1.2 Data Transfer Method for safe delivery of data in Telnet session is: • Use DES, TrIPLEDES, IDEA Random Encryption Session · Use DI
FF
IE-Hellman performs key exchange. · Use the public key private key encrypted signature. 1.3 Prevention of attacks against Telnet and saying attacks on telnet, but not too saying that use Telnet attacks. Telnet is a good tool. Early attack is mainly for the use of environmental variables. For example, in a system that supports RFC1048 or RFC1572, if the user login server Telnetd supports the shared object library, the environment variable can be passed, which is the call and login of the Telnet daemon. The original intention of using environment variables is to test the binary library used, for example, you can change the path without having to change the position of the original library. However, if an attacker adds its own library to it, then change the environment variable, set the ROOT permission according to the parameters of the relevant path in the environment variable according to your own library. Fortunately, the current security experts have realized this problem, for example, using the SETUID, which ignores environment variables. Users can use Telnet to get a lot of situations on the service host. For example, the type of the operating system of the server, etc. Moreover, the Telnet can not only use the port 23, but also ports to other services. For example, port 21 is FTP, and port 25 is SMTP, and port 80 is HTTP, and the like. For example, an example of logging in to its own port 25:
$ telnet localhost 25tring 127.0.0.1 ... connection to localhost, localdomain.escape characterhost.localdomain Esmtp sendmail 8.9.3 / 8.9.3; Tue
19 OCT 1999
10: 31: 540EHLO localhost250-localhost.localdomain HelloIDENT: host@localhost.localdomain [127.0.0.1] u250-EXPN250-VERB250-8BITNIME250-SIZE250-DSN250-ONEX250-ETRN250-XUSR250 HELPMAIL FROM: host @ localhost250 host @ localhost ... send okRCPT TO: "." root @ localhost250 root @ localhost ... recipient okDATA354 Enter mail, end with On a line by itselfthe content of the mail ... ..250 KAA00615 Message accepted for deliveryQUIT221 localhost.localdomian closing connectionConnection closed by foreing host we can. Seeing, as long as the port is open, it is possible to use Telnet to get information. Even you can send a request to port 80, as long as the request is correct, port 80 can get a response, or even a wrong GET instruction can be responded. Early attacks on Telnet also have kernel transfer. This method shows the password already masked. It should be noted that the server side should set the login number and the login delay restriction, prevent the user from trying to use a strong attack decipherous password. 2. Common Safety Telnet Software 2.1 Stanford University's SRP SRP Software is a security software in FTP / Telnet. The guarantee password can be safely transmitted over the network. Basic ideas are to prevent passive or active network invaders from using a dictionary attack. Adding encryption protection for password data, even if the intruder gets a password database, it cannot be used directly. Now Sweet Hall Clusrter, use the Kerberos certified protocol, can be accessed by "Macleland" and "PCleland", or create an encrypted login session. Standford University Computer System developed an SRP package, providing security mechanisms based on password authentication and session encryption, without user or distribution of network management participation in key. SRP provides transparent password security for everyone, without other expensive starting overhead, such as preventing other security suite software. Unlike other security software, the SRP kit is a completely password-certified package, not a temporary solution. And standard / etc / shadow-style security comparison, SRP is better in every aspect. Use SRP has the following benefits to users and managers: SRP resistance "Password SNI
FF
ING "(Password monitor) attack. In a session using SRP authentication, the listener does not monitor any password transmitted in the network. In remote login software, the expressword transfer is the biggest security vulnerability. Anyone can Use a simple SNI
FF
The ER tool gets the key you log in to the remote system. SRP resists dictionary attacks. A system protects simple password monitoring is not enough. If an attacker uses a powerful attack, such as a Dictionary attack, they are not a simple direct listening password, but track the entire session process, then control the entire information and a normal password in the dictionary. Even if the Kerberos system is also fragile for such an attack. SRP is safely handled by the password before boycotting a dictionary attack. The algorithm used is to require an attacker to perform an impossible large calculation before the attacker has a powerful attack. SRP even protects the "Active" attack for your password. Therefore, even if the intruder has the ability and the network contact, it cannot attack SRP. So even if the user uses a very fragile password, it will not make the invaders easily crack. SRP is completely transparent to end users. Because there is no so-called "Keyrings" and "certificate", or "ticket". Your password is the key. SRP simply protects this key, but it is better than the old, weak key protection mechanism. SRP is also easy to implement from managers' perspectives. There is no such concept such as "Key Server", "Certificate Certification", and "Authentication Server". The SRP password file is next to the standard UNIX password file, the software itself coincides with the consistency of these two system passwords and SRP password files, without excessive maintenance systems. SRP exchanges an encrypted key when authenticating a user. This means that a landing session can be encrypted, but resisting so-called network monitors and malicious tampering. The user reads their letter on the remote, is the use of 128-bit encryption information, which is automatically processed when the user logs in, and the user itself does not have to care if it needs to be encrypted. The system completes encryption and then sent to the user. 2.1.1 How is SRP work? Detailed SRP works can be found at SRP sites. The address is http://srp.stanford.edu/srp, where you can get online instructions for the protocol http://srp.standford.edu/srp/design.html or a published technical white paper HTTP : //srp.standford.edu/srp/ftp. The Standford Telnet Software Suite is an extension of the standard Telnet protocol. The standard Telnet protocol is defined in RFC 845 (http://srp.stanford.edu/srp/rfc845.txt). If you want more information, please get more RFC information at http://www.ietf.org. The SRP's Telnet package Telnet authentication process is implemented under a framework of RFC1416 (http://srp.standford.edu/srp/rfc1416.text). But SRP also has its own alternative number. If you want to know the specific number of allocation, you can get to http://srp.stanford.edu/srp/ftp. When a Telnet session begins, this authentication framework automatically executes an authentication mechanism negotiation including SRP. If you find that they support SRP on both sides, for example, if someone does not support SRP, then the authentication will use the relatively weak part to use the authentication method. Or if there is no authentication agreement at all, use standard expressive certification. Unlike the general security Telnet software, SRP does not need user memory more online commands, such as various complex commands used in SSH, but completely and standard Telnet compatible, users are just simply enter his command. And the password is OK. Because SRP and standard Telnet are completely compatible, it can replace the existing system binary files. A secure Telnet session can be the same as described below:
$ Telnet xenon.stanford.eduTrying 171.64.64.24 ... Connected to xenon.stanford.edu.Escape character is '^]'. [Trying SRP ...] * Unauthorized access to this computer system is prohibited. ** Violators are . subject to criminal and civil penalties * [Using 1024-bit modulus for 'tjw'] SRP Password: (Password is typed locally) [SRP authentication successful] [Output is now encrypted with type CAST128_CFB64] (Encryption enabled) [Input is now Decrypted with Type Cast128_cfb64] Sun Microsystems Inc. Sunos 5.5.1 Generic May 1996xenon $ (User Now Has A Secure Session) SRP Default 128-bit encryption algorithm. CAST-128 is defined in RFC2144 (http://srp.stanford.edu/srp/rfc2144.txt). Standard SRP also supports 56-Bit DES and 48-bit DES. Advanced support Triple-DES encryption means. The platform supported by the SRP is: Solaris 2.x / sparc Solaris 2.x / i386 Sunos 4.x / SPARC SGI Irix 5.2, 5.3, 6.x / MIPS DEC OSF / 1 2.x, 3.x / alpha decix 4.X HP-UX 9.x, 10.x Linux 1.x, 2.x / i386 Getting software is: http: //srp.standford.edu/srp/download.html#srp Download included source code section. 2.2 SRA Telnet This is a software developed by Texas A & M University. The authentication standard used is also RFC1416. Although it can be implemented as transparent as SRP, it still has a lot of shortcomings. SRA's security is without authentication using a fixed, short module (192 bits) DI
FF
IE-Hellman key exchange algorithm. This means that the certification will be broken by the Man-In-Middle-Middle attack method, or use calculation discrete Computing Discrete logs against the 192-bit modulus, and this only takes a few hours on the personal computer to be crackdown. . It does not have an encrypted session itself, so it is still a TCP session attack is defective. In fact, RSA is just a temporary software that solves Telnet security. But in all the Telnet security software provided, SRA is the easiest to implement. It requires the user's behavior and system changes minimal. Unfortunately, this transparency also reduces the security level of the system itself. 2.3 STEL This software is developed by Milan University, Italy. STEL is a complete protocol provided remotely. It provides secure authentication and session encryption mechanisms. Like SRA Telnet, STEL can deal with password listening from the network. Unfortunately, Stel is still a very weakness. STEL is also using DI
FF
IE-Hellman key exchange is created a security session. Although STEL allows a long module MODULUS than RSA, it is still limited by its own protocol. For example, it is still a bundle of man-h-the-middle attacks. Stel tried to use a secret document that was distributed in advance to slow down this problem, but this only changed the problem into a Deployment Issue. STEL protocol is not compatible with the standard Telnet protocol, requiring users to remember new commands and new command line options . In order to resist man-in-the-middle attack, Stel is an internal agreement (Interlock), which is required that the user has a secret file under his own home directory. The secret file is shared between the terminals in the connection. . Of course, Stel does not provide users with any secure ways to distribute this file. Since there is no safety protection mechanism, a secure channel implementation file is required. Some people use CATCH-22 as a secure channel transferred as a file (????) but some people use floppy disk directly to copy files, but this is to say that physical security issues have made a problem to consider. Another important issue is that Stel himself is not authenticated. In fact it is just transmitting passwords and data blocks on a hypothetical secure connection. When using a standard UNIX authentication, it may be the most commonly used Scenario, which will have the server-side password capturing attacks. Then, Stel's Telnet security solution is just a temporary solution, not for a long time. 2.4 SSH SSH is a package that provides secure login and remote commands. It is designed for replacing Rlogin / RSH. SSH and RSA are a secure connection based on the host password encryption. SSH is considered to be more secure, but the problem of its installation and use limits its widespread use. The real SSH faces the problem is whether it is still directly transmitted in a secure connection. Because people like to share keys between hosts, if a hacker broke a host, then install Trojan Trojan on this host, then he can easily capture passwords transferred from other hosts, and try to crack other hosts The password is. SSH is a system that is considered to be a safe. But there is also a problem that is installed and used, causing it not to be used extensively. The problem that is really SSH is that it still passes the password directly from a secure connection to another host. Because there are a lot of people like sharing password, that is, there are many places to use the same password. If there is a SSH server being broken, the invader can install Trojan horse in the server, then track all connections, get the password of all users You can try to crack the other to connect to the host on the SSH server. In order to alleviate this problem, SSH uses the public key key pair, but there is another problem, that is, the user is inconvenient. The key must be moved from one place to another, and the management of the key has also become a problem. In order to avoid so-called public key monitoring, each user is required to have a copy of the public key of the host to which you have to connect under your home directory. But every public key should take up approximately 1K space. If the user attempts to connect a lot of hosts, then all the public keys of all these hosts should take up a part of space while giving management. Although SSH develops to avoid export restrictions outside the United States, it uses RSA technology, and the use of RSA technology is limited by the US government. A US company wants to develop SSH-based products, must face two questions: one is an export restriction to prevent it from publishing SSH-related code; RSA requires a BSAFE license. Therefore, the restriction of the outlet will mainly be the limit on the length of the encrypted key used in SSH.
