Checkout SlayerLabs.com!
Networks Engineered to Exploit.
- Windows/UNIX - Domains/Subnets - Initial/Post/Lateral - Low Cost VPN Ranges -

Securing SSH

This guide is geared towards securing SSH - specifically for users who are fairly new to administering their own servers. The focus will be public facing Linux webservers.

AllowUsers

In the /etc/ssh/sshd_config file you can allow only certain users to have access to ssh. Not ever user may NEED access to the server via ssh right? Least Privileges best practices..? It also may prevent possible malicious logins with exploited users or services (backup, exim etc).

AllowUsers zerocool acidburn lordnikon  

Using Keys

If you’ve setup a webserver in the past with ssh passwords allowed, you’ve probably noticed all the bots brute forcing your server. A quick way to counter this is to allow only public/private keys.

First, create the key pair on your local/client machine. If you’d like to add a passphrase to your keys (more secure & recommended), go ahead and add it during the generation process - if not just hit enter enter, etc.

root@kali:~# ssh-keygen -t rsa

Once generated, the public and private keys will be in the /root/.ssh directory.

• id_rsa.pub = Public key

• id_rsa = Private key

Change permissions on your client..

root@kali:~# chmod 700 .ssh
root@kali:~# chmod 600 .ssh/id_rsa 

Next, you’ll need to copy the public key from your local machine to the webserver, installing the key in the ~/.ssh/authorized_keys file.

Change permissions on the server..

root@centos:~# chmod 700 .ssh
root@centos:~# chmod 600 .ssh/authorized_keys 

Once all set, you can disable passwords by finding the PasswordAuthentication and in your servers /etc/sshd_config file, then set it to PasswordAuthentication no

You may also have to uncomment the AuthorizedKeysFile path in sshd config, and set accordingly.

Make sure to test the key authenticaion before you close all your current ssh sessions ;(

Fail2ban

A whole seciton to setup fail2ban here: http://liberty-shell.com/sec/2018/01/04/fban/

Change SSH to non-default port

Changing the default SSH port will reduce the amount bots and other automated attacks against your server. It’s a quick and easy security measure to implement.

It’s best to choose a port from 49152 through 65535 since these are not register ports or well-known ports. You’ll just need to change one line in yor servers /etc/ssh/sshd_config file

# What ports, IPs and protocols we listen for
Port 55222

Save, and restart ssh..

root@centos:~# service ssh restart

On your client machine you can try to ssh into the new port, or run nmap on the server to verfiy…

root@centos:~# nmap -sV 127.0.0.1 -p55222
root@kali:~# ssh root@192.168.72.136 -p 55222

Updating your firewall may be needed..

root@centos:~# iptables -A INPUT -p tcp -m tcp --dport 55222 -m comment
 --comment "SSH" -j ACCEPT

Port Knocking

Crafty and unique, this mischevious little technique can hide our precious ssh service unless a certain sequence of packets are sent to certain ports.

So let’s say you setup your port knocking daemon to accept the sequence of ports: 11, 65 and 99. As the client you scan the server and SSH is showing closed. Then you run an hping (or similar tool) script that sends a packet to port 11, then port 65, then port 99. Once you rescan the address, you should see port 22 open.

What if the daemon crashes for whatever reason, or the server reboots without the port knocker daemon running? Unless you have easy physical access to the server, or other remote means (vSphere, VNC, etc), this stinker may be a bit risky to run.