.jpg)
In the digital age, secure communication is paramount, especially when it comes to sensitive data and remote access to systems. One of the most critical tools that has revolutionized secure communication over the internet is SSH or Secure Shell. SSH has a rich history, and it's not without its share of vulnerabilities and best practices. In this blog, we will dive into the history of SSH, including the story of port 22, why it is recommended not to use this default port, and the notorious Heartbleed vulnerability. We will also touch upon how SecOps allows custom SSH ports for authenticated scanning, highlighting the importance of security in the world of remote access.
To understand the significance of SSH, we must first delve into its origins. SSH was created as a response to the need for secure remote access to Unix-like systems, which were becoming increasingly popular in the early days of the internet. Before SSH, insecure methods like Telnet and rlogin were commonly used for remote access, making it easy for malicious actors to intercept sensitive data.
The story of SSH begins with a Finnish researcher named Tatu Ylönen in 1995. Tatu Ylönen was motivated to create a more secure alternative to Telnet, which was vulnerable to eavesdropping and tampering. Ylönen developed SSH as a solution to these vulnerabilities and initially named it Secure Shell. SSH1 and SSH2 protocols soon followed, each with its own set of improvements.
SSH was designed to take the place of FTP (port 21) and telnet (port 23). The open port was 22. It was neatly located between the telnet and FTP ports. So it was reasoned that possessing that port number might be one of those insignificant details that would lend credibility. However, the main question was how to get that port number. and here's the fascinating part: he knew someone who had the authority to allocate port numbers.
In those early days of the Internet, port numbers were allocated by the esteemed Internet Assigned Numbers Authority (IANA), overseen by prominent figures like Jon Postel and Joyce K. Reynolds. Jon Postel, in particular, had an impressive list of accomplishments, having been the editor of foundational internet RFCs, including IP (RFC 791), ICMP (RFC 792), and TCP (RFC 793). To many, Jon Postel was an intimidating figure due to his contributions to internet standards.
With the vision of SSH in mind and the need for a suitable port, Tatu Ylonen contacted IANA and requested Port 22 for SSH, paving the way for this new, secure communication protocol.
The following mail was written by Tatu Ylonen to IANA for port 22:
.png)
However, using port 22 for SSH services has its disadvantages. It has become a known target for automated scans and brute-force attacks. Malicious actors continuously scan the internet for systems listening on port 22, hoping to find vulnerable SSH servers. This is why it is highly recommended not to use the default port 22 for your SSH services.
To change the default SSH port, you can modify the SSH server configuration file, typically located at /etc/ssh/sshd_config on Unix-like systems. By changing the Port directive to a custom port number (e.g., Port 2222), you can make it more challenging for attackers to find your SSH service.
Using a custom SSH port does not make your system immune to attacks, but it can significantly reduce the number of automated scans and brute-force attempts, enhancing the security of your system.
While SSH has a reputation for security, no system is entirely invulnerable. In 2014, a severe security flaw called the Heartbleed vulnerability sent shockwaves through the tech community. This vulnerability did not affect SSH directly but had a significant impact on another essential security protocol - SSL/TLS.
Heartbleed was a bug in the widely used OpenSSL library, which is responsible for secure data transmission over the internet. This bug allowed attackers to read sensitive data from the memory of a web server. Heartbleed gained notoriety because it could potentially expose private keys used for SSL/TLS encryption.
The SSH protocol itself was not directly affected by Heartbleed. However, it served as a stark reminder of the importance of regularly updating and patching security software and protocols. When such a major vulnerability is discovered, it is crucial to act swiftly to mitigate the risk and prevent potential data breaches.
Following is the Heartlbleed Vulnerability CVE detail calculated from the EPSS calculator:
Heartbleed CVE: CVE-2014-0160
EPSS Score: 97.59%
CPR Score: 87.66%
Severity: High
Severity Score: 7.5
Summary: The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CWE ID: CWE-125
You can use SecOps Solution to find if your servers/VM/endpoints are impacted by Heartbleed it also supports SSH-based authenticated scans to identify vulnerabilities.
SSH has evolved significantly since its inception. SSH1 was the initial version of the protocol, but it had its share of security issues and limitations. This prompted the development of SSH2, which addressed these shortcomings and became the widely adopted standard.
SSH2 introduced numerous security improvements, including stronger encryption algorithms, better key exchange protocols, and enhanced security features. It is important to note that SSH1 is considered less secure and is no longer recommended for use. SSH2 has become the de facto standard for secure remote access and file transfer.
Over the years, SSH has continued to advance, with various implementations and open-source projects contributing to its development. Today, SSH is a critical tool for secure communication, remote administration, and secure file transfers, playing a pivotal role in the cybersecurity landscape.
SSH's significance in the world of secure communication and remote access cannot be overstated. It offers a robust and reliable method for system administrators and developers to manage servers, transfer files, and interact with remote systems securely. Some key benefits of SSH include:
SSH has become a foundational technology for secure access and data transfer in the modern IT landscape, making it a vital tool for businesses, system administrators, and developers alike.
SSH has come a long way from its humble beginnings in the mid-1990s. It has played a pivotal role in securing remote access to systems and facilitating secure communication in the digital age.
The history of SSH is a story of innovation and adaptation in the face of evolving security challenges. As technology advances, so do our approaches to security, and SSH continues to be a cornerstone in this ongoing journey. Whether you're a system administrator, developer, or simply a user looking for secure access to remote systems, SSH remains a powerful and reliable tool for all your secure communication and remote access needs.
SecOps Solution is an award-winning agent-less Full-stack Vulnerability and Patch Management Platform that helps organizations identify, prioritize and remediate security vulnerabilities and misconfigurations in seconds.
To schedule a demo, just pick a slot that is most convenient for you.
