The most popular account used in the attempted logins was the username root. In general, users attempted to gain knowledge about the server-such as the processes running on the system and the version of the operating system-and to download files that could allow them to increase their system privileges or run software such as an IRC network bouncer. Although the users' attempted actions may be interesting, this paper will focus only on the access attempts. After a user was logged in, he or she entered an emulated environment that allowed observation of the attempted logins and any actions that the user attempted after the successful login. Login attempts for less common usernames were recorded even if they were unable to successfully authenticate to the system. The SSH honeypot was configured to allow logins from any location using common username and password combinations. If the authentication succeeds, the user is granted remote access to the system. If this authentication fails, the connection is closed. After the encrypted channel is established, the remote user can attempt authentication. After the three-way handshake completes setting up the TCP connection between the client and server, both client and server exchange SSH version information and cryptographic encryption keys. Typically, SSH servers listen for connection attempts on TCP port 22. This paper will focus on the attempts to gain remote access to a system using data collected from an SSH honeypot on the Internet during a period of approximately 6 months. SSH provides similar functionality while offering encrypted communications, password-less logins via public key authentication, and host-based verification.īecause SSH provides mechanisms for remote access or remote file transfer, attacks against SSH typically either attempt to gain remote access to a system or to cause a denial of service condition. RFC 4251 describes SSH as "a protocol for secure remote login and other secure network services over an insecure network." Most administrators use SSH as a secure replacement for Telnet and the older BSD r commands such as rsh and rcp. This white paper provides an overview of Secure Shell (SSH) login activity that administrators and engineers may use to reduce the exposure and risk of compromise via SSH. Should You Run the SSH Server on a Different Port? Is the Server Exposed to Untrusted Hosts? Is It Necessary? Have Administrators Considered Public Key Logins?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |