This is part three of four in a series of articles about security.
- Text Processing Tools in UNIX
- Parsing SSH Logs
- Configuring fail2ban
- Configuring mail (and Slack) for SSH Notifications
In the first two parts of this series, I wrote aboit how much port scanning and login attempts happen on a server, I am not comfortable leaving a server openly accessible anymore.
Restricting Access Methods
If I do not want a server openly accessible, how van I access it?? How can one restrict access to a server that is one the Internet? Whitelist IP addresses and power on & off the server as needed.
Whitelist IP Addresses
This option only allows specified IP addresses to access a server. To configure which addresses are allowed, there are security settings to specify which addresses to which port. AWS allows this to be configured through its Security Group settings. Another is on the server itself, through the firewall settings.
Power on & off the server
A server off makes the system inaccessible and only powering on when you need it, just a computer that you have physical access. Even though the server is hosted in the cloud, powering on & off as needed is possible with AWS instances.
If whitelisting IP addresses and powering the server on & off is too much work, the next best thing is to secure the login. Some ways to secure:
SSH public key authentication
This will protect from brute force username & password attempts as the ‘password’ is a VERY hard to guess. This will require private keys to be on every SSH client that accesses the server.
SSH Two-factor authentication
Configure SSH to use two factor authentication, so a password and a randomly generated token is required for login. This is great working on systems which you want to access temporarily (i.e. a friend’s computer) but do not want to copy the SSH key onto.
These two methods step up system security by essentially defeating brute force login attempts. System is still accessible and make login very difficult without private keys or authentication tokens.
Even with secure SSH login, I want to step up my security, especially after exploring the SSH log of my server. There is definitely activity on a server that is accessible, even if the login method is secured.
fail2ban is a daemon (a UNIX system service) that automatically parses logs for malicious behavior and bans offenders through reconfiguration of the system firewall, iptables on Linux, that bans the offender from connecting in general. After a specified period, the ban is lifted.
fail2ban is a great way to add another level of security that deters repeat offenders while permitting authorized access.
The following is a quick one-line script to just continuously attempt logging into a specified server every second:
This will be the ‘test’ for system reaction to multiple login attempts with and without fail2ban configured.
For purposes of this article, a server has been setup with address: feta.ddns.net that is accessible by ssh.
Test system without fail2ban:
On a fresh Linux install, running the test script against the server produces:
Note: feta.ddns.net will have fail2ban configured.
This is the result of a system that does not have fail2ban running.
Permission denied (publickey). message will repeat
continuously. The default configuration for SSH will not do very much
against brute force attacks, even though it is noted in its log.
This is how to install fail2ban on a Debian based distribution such as Ubuntu:
For other UNIX systems, the fail2ban.org download page has more information.
At this point, fail2ban is installed and the service is already started. Running:
Will display its current status.
Will start, stop, or restart it. Required after any configuration changes to fail2ban.
Test with fail2ban results
Test multiple login attempts on the same server with the script and the results are:
After exactly six login attempts, the
Permission denied message
ssh: connect to host feta.ddns.net port 22: Connection
This is fail2ban in action. The current client cannot even get an SSH prompt because its IP address has been blocked completely.
Working with iptables
Some tips on working with the iptables firewall in Linux.
List Banned Offenders
To see the current list of SSH bans by fail2ban:
Remove a Banned Offender
To remove a ban set by fail2ban-ssh the command is:
so, to remove the ban on: linux.example.com from the previous output:
Additional fail2ban Configurations
At this point, fail2ban is running and already protecting the system against more than six consecutive failed SSH login attempts within ten minutes.
Additional configuration to fail2ban can improve peace of mind and deter repeat offenders.
Additional Configuration File
fail2ban is configured through a file
all of its global settings. Changing configuration in the
file work, but a
jail.local file is in the same directory provides
I like to configure fail2ban with the
jail.local, which provides a
kind of backup for the global one. If something doesn’t work in the
jail.local I configured, I can easily reset using the original.
To make a local config file, Copy the
A copy of my
jail.local with the following changes can be found
# is the comment delimiter on the
never put a comment on the same line as a setting. (i.e.
3600 # 60 * 60) This messes up fail2ban parsing.
Always Allow an IP address: ignoreip
Any IP addresses set with
ignoreip are always allowed to access,
especially after too many failed login attempts.
I put my most commonly used IP addresses but do not change frequently, like my home IP address.
Note: space is the separator between addresses.
Ban Offenders Longer: bantime
bantime is the duration to ban offenders before allowing access
again. This value is in seconds and the default is 600, which is
equivalent to 10 minutes.
From my experience, 10 minutes (600) was too short, even one hour (3600) was not long enough to deter repeat offenders.
I recommend 24 hours (86400) as a good value for bantime. Make sure ignoreip is configured to an IP that is accessible to you within the bantime, just in case. ;-D
Email fail2ban Activity
fail2ban can also send emails when a ban occurs and when service has been restarted. To have fail2ban email activity, install sendmail and configure fail2ban to mail.
No need to configure sendmail further. fail2ban can use sendmail with its default options.
Note: email clients may flag them as spam since the emails are coming directly from the server, not through a known SMTP host.
Email offenders: destemail
As a way to gauge effectiveness, I like having emails of every time fail2ban bans someone. So, configuring an email address:
+ markers in the address can be used, so
[email protected] can be used as is.
Email logs: action
destemail is configured to send email to a real address, having
additional information in the email is very nice.
To have fail2ban email when a ban occurs,
action needs to be set to
a value of either
%(action_mwl)s. Both emails
will include WHOIS data. The latter option will also include relevant
This is what a sample email report will look like:
How to install fail2ban, test whether the service is running or not, work with Linux’s iptables firewall to see and remove bans, provide additional options for fail2ban for greater peace of mind.
Next time: setting up SSH to send an email on successful login.