These guidelines assume a fresh install of Ubuntu 14.04.
Secure SSH Access
The most important step is probably to change the default port for SSH.
Change the default SSH port.
Many brute force hacking attempts target the username “root” on port 22.
Simply changing the port can reduce the number of malicious login attempts drastically.
Change the SSH port number to something between 1025 and 65536. The Server’s SSH connections will then look to the new port number.
In Ubuntu the SSH port is set in:
Before going any further, backup the config file!
cp /etc/ssh/sshd_config /etc/ssh/sshd_config_backup
Open the config file and amend the port number (first uncommented line in the file):
sudo nano /etc/ssh/sshd_config
Restart SSH to enable the changes:
service ssh restart or
TEST THE NEW CONFIGURATION
Keep your terminal open, and try to log in with a new terminal. In this way, if you can’t login you still have server access.
Remember to specify the correct port number (see below).
SSH Login - Non Standard Port
Assuming the SSH port is 1234.
ssh -p 1234 firstname.lastname@example.org
scp -P 1234 email@example.com:/path/file.txt
Note: uppercase P is necessary - lowercase p is an scp switch.
rsync --progress -a -v -rz --checksum --delete -e "ssh -p 1234" _site/ firstname.lastname@example.org:/var/www/path/directory
Once the SSH port has been reset, prevent root login with password. Root will still be able to gain access by means of public SSH keys - which can be set up on your local machine.
Amend the following block in
Alternatively, prevent root access altogether:
Make sure you’ve created a new user with sudo privileges before doing this.
After making changes to SSH configuration, restart SSH:
Set up a Firewall
sudo iptables -L, will return an empty ruleset:
Make a file for firewall rules:
sudo nano /etc/iptables.firewall.rules
…and add some rules:
sudo iptables-restore < /etc/iptables.firewall.rules
/etc/iptables.firewall.rules as necessary.
Check you Still Have SSH Access
The firewall rules set the port number for SSH access - this should correspond to the value set in
While still logged in on one terminal, open a new terminal and check SSH connection is still functional.
Apply Firewall Rules When System Reboots
sudo nano /etc/network/if-pre-up.d/firewall
Save, make executable:
sudo chmod +x /etc/network/if-pre-up.d/firewall
sudo apt-get install fail2ban
View Fail2Ban configuration settings - read only:
This file can be modified by package upgrades - thereby losing customisations - so to make changes, create a jail.local file.
First copy the jail.conf:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Make all amendments to jail.local.
Default setting ignores traffic from the local machine:
ignoreip = 127.0.0.1/8. Additional IP addresses could be added here, by appending to the existing parameter, separating IP addresses with a space.
You could add the local office IP address for example, to prevent accidental lockout.
Check it’s running:
sudo fail2ban-client status
sudo iptables -S
The –dport number on line 11 corresponds to the number set in firewall rules - SSH connections are accepted on that port.
This means fail2ban port should change. Amend
Once this change is made, reload fail2ban configuration:
sudo fail2ban-client reload
Because Fail2Ban sets the port as “ssh” bu default, it searches in the
/etc/services file and maps ssh to the named port.
The port is set to 22 in this file by default. Adjusting this value would be another way of pointing Fail2Ban to the right port.
See this Server Fault question.
Handy Fail2Ban commands
sudo fail2ban-client start- starts the server and the jails
sudo fail2ban-client reload- reloads the configuration
sudo fail2ban-client reload <JAIL>- reloads the jail
sudo fail2ban-client stop- stops all jails and terminate the server
sudo fail2ban-client status- gets the current status of the server
sudo fail2ban-client ping- tests if the server is alive
sudo fail2ban-client help- return this output
More Fail2Ban commands.
comments powered by Disqus