Hardening Linux Security by Changing the Default SSH Port

Secure Shell (SSH) enables secure remote administration by encrypting all traffic between client and server connections. This prevents sensitive data like passwords from being intercepted and stolen. However, SSH‘s ubiquitous default TCP port 22 is a prime target for attackers – changing this can reduce intrusion vectors.

SSH Usage and Encryption Fundamentals

SSH usage has grown to an estimated 5-10 billion authentications per day according to Tatu Ylönen, CEO of SSH Communications Security. As cloud infrastructure expands, SSH is the go-to for secure administrative connections to Linux and UNIX-based systems:

IPv4 space SSH scans per month	1.5 trillion
Estimated SSH brute force attacks daily	150 million
Secure coding policies mandating SSH	77%

The security and ubiquity of SSH rests within its encrypted connections that prevent man-in-the-middle attacks:

• Symmetric encryption creates a shared secret between client and server using algorithms like AES, Blowfish etc.
• Asymmetric encryption allows key exchange over public channels without revealing sensitive key data.
• Hash functions like SHA-1 authenticate packet integrity by detecting tampering.

Common implementations like OpenSSH provide strong encryption paired with a range of authentication options. However, client-server connections are still vulnerable at the TCP port level if unused defaults remain.

Dangers of the Default Port 22

Hackers have been exploiting weaknesses in SSH implementations for decades by targeting builds, protocols and the default port itself:

Year	SSH Vulnerability Example	Severity
2001	RSAREF overflow	High 7.5 (CVSS v2)
2005	CRC-32 compensation attack detector	High 7.8 (CVSS v2)
2016	User enumeration timing attack	Low 5.3 (CVSS v3)

Regardless of build or implementation, using the default port 22 introduces unnecessary risk. Various studies have shown port 22 as one of the most targeted across internet-facing systems:

+-----------+-------------------+--------------+----------+
| Protocol  | Port              | Frequency    | Traffic  |
+-----------+-------------------+--------------+----------+
| TCP       | 443 (HTTPS)       | 22.99%       |  35.60%  | 
| TCP       | 53 (DNS)          | 14.32%       |   1.76%  |
| TCP       | 22 (SSH)          |  6.85%       |   3.80%  |
+-----------+-------------------+--------------+----------+

Most scanned ports on internet devices – Source: Code42 Research 2021

This lines up with evidence of port 22 being responsible for over 6% of data breaches within Linux environments. The port has also remained highly exploited by both general intrusion tools like Metasploit and SSH-targeted malware like Mirai.

To lower exposure, changing the default SSH port closes off this obvious attack vector to automated exploits and brute forcers. Let‘s examine how to properly configure an alternate port securely.

Step-by-Step Guide to Changing the SSH Port

Changing the port SSH listens on within Linux is quite straight forward by binding SSHD to an updated value:

Check Current SSHD Configuration

First check the existing configuration and active listening ports with these commands:

# Grep for SSH port value
$ sudo grep Port /etc/ssh/sshd_config
# Port 22

# Review listening SSH connections  
$ sudo ss -tulpn | grep sshd

Modify SSH Configuration File

Next, edit the main SSH server daemon configuration file to change the listening port:

$ sudo nano /etc/ssh/sshd_config

# Change or append Port to alternate  
Port 2222  

Additional hardening like disabling root login, banner customization etc. can be done here as well.

Reload SSH with New Configuration

After saving changes & validating syntax, restart the daemon to load the latest config:

$ sudo systemctl restart sshd

Validate Proper Binding on New Port

SSH shouldn‘t bind successfully on the old port but will show your new listening port:

$ sudo ss -tulpn | grep sshd
tcp   LISTEN     0      128    [::]:2222     [::]:*  

You can also check logs for errors if troubleshooting issues after a config change.

Using SSH Port Changes as Part of Defense in Depth

While changing the default SSH port enhances security posture, it should be paired with other controls like:

• Network-level firewall rules restricting source IP ranges
• Fail2ban integration to ban brute force attacks
• Removing root login and requiring key-based public authentication
• Mandating SSH client protocols like SFTP that support encryption by default

Firewall Rule Examples

Pair port changes using iptables rules by IP address masks:

# Only allow SSH from office IP range  
$ sudo iptables -A INPUT -p tcp --dport 2222 -s 199.201.28.0/22 -j ACCEPT

# Reject all other traffic trying to hit SSHD
$ sudo iptables -A INPUT -p tcp --dport 2222 -j REJECT

Cloud platforms like AWS provide network ACLs filtering port access.

Brute Force Monitoring with Fail2Ban

Local intrusion detection integration has symbiosis with obscuring SSH ports. Fail2Ban can leverage custom filters to pick up authentication failures on new ports:

# Ban hosts trying SSH more than 3 times on port 5000
[sshd-alt-port]
enabled = true 
port = 5000
filter = sshd
logpath = /var/log/auth.log
maxretry = 3 

This shows robust configurations require multiple controls, not just changing defaults. Let‘s explore additional methods for authorization hardening.

Managing SSH Securely

Beyond fundamental port and encryption tactics, several other steps can be taken to operate SSH securely:

Authentication Best Practices

Leverage public key pairs for login instead of password mechanisms alone to enhance identity assurance. Keys should use at least 2048 bit RSA or Ed25519 algorithms.

Multi-factor should be mandated for privileged user access to critical systems with technologies like WebAuthn hardware keys.

Activity Monitoring & Logging

Syslog agent forwarding coupled with centralized aggregation solutions like Splunk or Elastic provide rich SSH user behavior analysis:

• Session activity monitoring
• Geolocation analysis
• Log enrichment and correlation

Session recording solutions capture entire user terminal activity as well which aids intrusion investigation.

Vulnerability and Patch Management

Both announced and zero-day vulnerabilities against SSH implementations remain highly exploited in the wild. Maintaining robust patch cycles for both clients and daemon builds is crucial.

OpenSSH releases average 5-10 times per year – usually consisting of critical security fixes.

The Importance of Changing Defaults

Implementing SSH securely remains highly nuanced – spanning encryption, port or network adjacent protections, patching and account access considerations. However, altering simple defaults provides tremendous defensive posturing improvements.

Changing the SSH server port closing direct attack vectors based on outdated assumptions of port 22 availability. This forces adversaries to expend additional effort determining where SSH has moved to using slow banner grabbing, packet sniffing or TCP port scans.

Each small speed bump and variation introduced chips away at attack scalability. Paired with fail2ban, firewall rules and other controls this can have exponential effects on brute forcing viability.

While moving SSH port locations cannot prevent all intrusions, it eliminates the lowest hanging fruit risks. Implemented among other security in depth measures it is highly effective toward denying unauthorized access and hardening Linux environments.