Fortifying SSH: Essential Hardening Techniques to Prevent Cyber Attacks

Introduction

In a penetration testing environment, it’s essential to understand how attackers exploit common vulnerabilities. By configuring basic security measures, we can block fundamental attacks on critical systems. In this post, I’ll demonstrate how an attacker can attempt to compromise SSH services on a Debian system and how implementing simple security settings can thwart these efforts​

Scenario

An attacker scans the network to find services running on port 22 (the default SSH port). Once found, they launch a brute-force attack to compromise credentials. This type of attack can severely impact system security and performance, especially on systems with default configurations.

Referenced from: https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html

After listing out the services on port 22, the attacker is then able to craft their weapon of choice. In this case a brute force.

This type of attack is very aggressive and has a very high impact on overall services along with the threat of stealth of credentials. It is highly effective to systems that have default configurations.

Defending & Mitigating SSH Brute-Force Attacks on Debian

To mitigate SSH brute-force attacks, we’ll harden the SSH configuration file to:

  • Change the SSH port.
  • Disable password authentication.
  • Enable key-based authentication.
  • Implement security policies to block repeated failed attempts.

Such attacks can be simply avoided with the use of proper configuration and management. Let us do so with our SSH services.

systemctl stop ssh

Initial Configuration

Step 1: Backup and Review SSH Configuration

First, create a backup of the existing SSH configuration for best practices

sudo cp sshd_config sshd_config-backup

Now that we have created a backup for the prmary configuration, we will configure the file from a default state to a hardened state. Pick your editor of choice.

gedit /etc/ssh/sshd_config
  • Port 2468: Specifies a custom port for SSH Connections, reducing exposure to automated attacks that typically target the default port (22).
  • LogLevel VERBOSE increases the logging level to VERBOSE for better tracking of authentication attempts and system events, which can help monitoring and troubleshooting.
  • LoginGraceTime sets a shorter grace period for users to log in, reducing the window for potential unauthorized access.
  • Strict Modes yes: Disables direct root login. This helps prevent unauthorized access and limits potential damage from compromised accounts.
  • AuthorizedKeyFile: Ensues that only .ssh/authorized_keys is used for public keys, making it clearer and more secure.
  • PasswordAuthentication: Setting this to “no” disables password based authentication, enforcing the use of SSH Keys for access, which is considered to be more secure.
  • PermitEmptyPasswords: Setting this to “no” prevents users from logging in with empty passwords enhancing security.
  • ClientAliveInterval/ClientAliveCountMax: The above configuration sets the server to send keep-alive messages every 300 seconds. If two messages are missed, the server disconnects the client. This helps manage idle sessions and free up resources.

Now lets save and restart SSH services

systemctl restart ssh

Closing Existing Connections

A key point to notice is that these configurations were being made during the time when an unauthorized user had already established a connection to our SSH Server.

The connection indicates that there is an active SSH session using the default SSH port 22 and not to the new port (2468) that we configured. Let us list services on port 22 and stop the service from running.

sudo kill 6454 6474
sudo lsof -i:22
sudo netstat -anpt | grep ssh

The unauthorized user will no longer have access to this connection.

Testing the Defense

Let us now verify security enhancements of our newly configured SSH service.

As per our brute force attack earlier. Let us see how the attack performs now.

The attack was unsuccessful because we have configured our ssh in another port. However, let us also see what the attack would do if we specify our authenticated port.

As per the result, we have managed to prevent this attack as the method of the attack requires a password based authentication mechanism.

Conclusion

In today’s threat landscape, securing SSH access is a critical step in protecting your Debian systems from cyber attacks. By implementing key SSH hardening techniques—such as disabling password-based logins, changing the default SSH port, and enforcing session timeouts—you significantly reduce the risk of brute-force attacks, service disruptions, and unauthorized access.

These simple yet effective measures fortify your system against common vulnerabilities, ensuring that it remains secure, reliable, and compliant with industry standards. Regularly reviewing and updating your SSH settings is essential for maintaining strong security as new threats emerge.

Detection & Mitigations

  • Detection: Brute-Force SSH Attempts
    • Monitor SSH logs (/var/log/auth.log) for repeated failed login attempts or large numbers of authentication failures. Use tools like Logwatch to regularly review authentication logs.
  • Mitigation:
    • Disable password-based authentication (PasswordAuthentication no) to prevent brute-force attacks from succeeding.
    • Limit the number of authentication attempts (MaxAuthTries 3) to reduce the impact of such attacks.
    • Change the default SSH port (Port 2468) to avoid automated brute-force scans on port 22.
  • Detection: Unauthorized Root Access Attempts
    • Check SSH logs for attempts to log in as the root user, especially if the root account has not been disabled.
  • Mitigation:
    • Disable root login via SSH (PermitRootLogin no) to prevent attackers from escalating privileges through root access.
    • Enforce the use of SSH keys for login authentication to further secure access.
  • Detection: Idle or Suspicious SSH Sessions
    • Use monitoring tools or review open sessions to detect idle or suspiciously long-lived SSH connections that may have been hijacked.
  • Mitigation:
    • Set session timeouts (ClientAliveInterval 300, ClientAliveCountMax 0) to automatically close idle SSH connections, reducing the risk of session hijacking.
    • Regularly audit active SSH sessions to detect any unauthorized access attempts.
  • Detection: Information Disclosure through SSH Banners
    • Review SSH banners (e.g., MOTD or login messages) to ensure that no sensitive information is being disclosed to potential attackers.
  • Mitigation:
    • Disable SSH banners and MOTD (PrintMotd no, PrintLastLog no) to prevent attackers from gathering information about the system environment.

Credits & References

Share the Post:

Table of Contents

Subscribe To Our Blog

Light