If you set up a server, or any information system for that matter, it is important to also secure it according to best practices.
Online Attack Defense
A crucial part of defense against online password attacks is implementing an intrusion prevention system (IPS) which adds protection against different types of brute-force attacks. With an IPS you can apply security on certain ports or services in your server (e.g. apache, ssh, ftp). There are a lot of ways to mitigate a brute-force attack. You can slow them down or to giving false-positive results to the attacker. These are not the best practical solutions though, as the attacker with an average level of expertise will know how to avoid them.
Fail2ban
Fail2ban is an IPS which mitigates brute-force attacks by monitoring log files and creating rules in the iptables configuration. Fail2ban can be installed using the following command: apt install fail2ban.
This will install a service with default settings into your server. The default configuration file for Fail2ban is /etc/fail2ban/jail.conf. As the default settings may be changed by package updates, it is not recommended to edit them nor apply any filtering in the default file. It is better practice to write the settings you want to customize into the /etc/fail2ban/jail.local file.
For example, to enable brute-force defense for Nginx, create a jail.local file and include the settings as shown below:
[nginx]
enabled = true
port = http,https
filter = nginx-http-auth
logpath = /var/log/nginx*/*error.log
maxretry = 6
bantime = 600
Explanation:
[nginx] - name of the jail
enabled = true - enable/disable the jail
port = http,https - ports which will be filtered
filter = nginx-http-auth - filters all nginx-http-auth lines from the error log
logpath = /var/log/nginx/error.log - the log file to be monitored
maxretry = 3 - number of failed attempts before banning
bantime = 60000 - time of ban in seconds, negative value is a permanent ban
To apply the new custom filtering in fail2ban, its service must be restarted: service fail2ban restart.
SSHGuard
Another way to harden the security on your server is using SSHGuard; a tool which protects hosts from brute-force attacks against SSH and a wide range of other services such as Dovecot, Postfix and ftpd. It works by the same principle of monitoring the application log for malicious activity and blocking the suspicious IP addresses for a certain amount of time. SSHGuard also includes a feature called threat-scoring, which means the more frequently someone attacks you, the higher their ‘threat’ score becomes, which extends their ban time.
To install SSHGuard into your server use apt install sshguard.
Inspect your iptables for new filtering rules, which SSHGuard shall add automatically after installation:
root@server:~# iptables -S
-N sshguard
-A INPUT -j sshguard
If you cannot find the filtering rules in your iptables you need to apply them manually and restart the iptables service:
root@server:~# iptables -N sshguard
root@server:~# service iptables restart
Offline Attack Defense
The best method of defending against offline attacks is of course to prevent attackers from gaining access to password storage. However, determined attackers and/or accidental breaches happen all too often so to make things harder for an attacker:
- Do not store passwords in plaintext (this happens far more often than it should)
- Store passwords using a strong, industry-vetted algorithm (e.g. bcrypt) using salt where applicable. Strong algorithms have negligible impact on server performance and dramatically slow down attackers who have obtained hashes
- Prevent users from setting passwords on common attacker lists
- Allow/require the use of Multi-factor Authentication for accounts
Multi-Factor Authentication
Multi-factor Authentication (MFA) is a very effective method of preventing attackers from using passwords recovered from hashes in offline attacks or obtained through social engineering. Rather than simply authenticating a user based on their password, something they know, an MFA solution requires them to additionally prove identity based on something they have (e.g. a smart card) and/or something they are (e.g. a fingerprint). Though more sophisticated attacks exist even against these combinations, they are out of reach for all but the most determined attackers.
Conclusion
The best way to defend against would-be password attackers is to follow best-practices and avoid common system weaknesses that give them easy wins. Coupled with the password generation rules from the previous blog post, these techniques allow you to deter most attackers both as a user and system administrator.
