Brute-force attack and protection Apache using Fail2ban Defense SSH Server

How to use Fail2ban Defense SSH Server brute force hack attack

A common attack on SSH services is brute force attack--a remote attacker who attempts to log on indefinitely with a different password. Of course, SSH can set up the use of non-password authentication authentication methods to counter this attack, such as public key authentication or double authentication. Put the pros and cons of different validation methods aside, what if we have to use a password verification method? How do you protect your SSH server from brute force cracking attacks?

In this tutorial, I'll show you how to install and configure Fail2ban to protect your SSH server from brute force attacks from remote IP addresses.

install Fail2ban on Linux

To install Fail2ban on CentOS or Rhel, first set up the Epel warehouse, and then run the following command.

$ sudo yum install Fail2ban

Install Fail2ban on Fedora and simply run the following command:

$ sudo yum install Fail2ban

Install Fail2ban on Ubuntu,debian or Linux mint:

$ sudo apt-get install Fail2ban

configuring Fail2ban for the SSH server

Now you are ready to strengthen your SSH server by configuring Fail2ban. You need to edit the configuration file/etc/fail2ban/jail.conf. In the "[Default]" section of the configuration file, you can define the default parameters for all monitored services here, and in the configuration section of a particular service, you can set specific configurations for each service (such as Ssh,apache, etc.) to override the default parameter configuration.

In the service-oriented prison area (behind the [DEFAULT] area), you need to define a [ssh-iptables] area that defines the SSH-related prison configuration. The real ban on IP addresses is done through iptables.

The following is a sample file containing the/etc/fail2ban/jail.conf of the "Ssh-iptables" prison configuration. Of course, depending on your needs, you can also designate other application prisons.

$ sudo vi/etc/fail2ban/jail.local

[DEFAULT]
# A space-delimited list that can be an IP address, CIDR prefix, or DNS host name
# used to specify which addresses can ignore Fail2ban defenses
Ignoreip = 127.0.0.1 172.31.0.0/24 10.10.0.0/24 192.168.0.0/24

# Client Host Blocked duration (sec)
Bantime = 86400

# Number of failures allowed before client host is blocked
Maxretry = 5

# Duration (seconds) to find the number of failures
Findtime = 600

MTA = SendMail

[Ssh-iptables]
Enabled = True
Filter = sshd
Action = Iptables[name=ssh, Port=ssh, Protocol=tcp]
Sendmail-whois[name=ssh, dest=your@email.com, sender=fail2ban@email.com]
# The release of the Debian department
LogPath =/var/log/auth.log
# Red Hat System release
LogPath =/var/log/secure
# Maximum number of attempts to SSH service
Maxretry = 3

Depending on the configuration described above, Fail2ban automatically disables any IP addresses that have failed access attempts for more than 3 times in the last 10 minutes. Once banned, this IP address will be blocked from accessing SSH services for 24 hours. This event will also send mail notifications via SendEmail.

Once the configuration file is ready, restart the Fail2ban service in the following manner.

In Debian, Ubuntu or Centos/rhel 6:

$ sudo service Fail2ban restart

In Fedora or Centos/rhel 7:

$ sudo systemctl restart Fail2ban

To verify that Fail2ban is running successfully, use the parameter ' ping ' to run the fail2ban-client command. If the Fail2ban service is running properly, you can see "pong" in response.

$ sudo fail2ban-client ping
Server Replied:pong

Test Fail2ban protect ssh from brute force cracking attack

To test whether Fail2ban is working properly, try using the wrong password to connect to the server using SSH to simulate a brute force attack. At the same time, monitor/var/log/fail2ban.log, which records any sensitive events that occur in Fail2ban.

$ sudo tail-f/var/log/fail2ban.log

According to the above log file, Fail2ban has banned an IP address 192.168.1.8 by detecting multiple failed logon attempts for IP addresses.

Check the Fail2ban status and unlock the locked IP address

Because Fail2ban's "ssh-iptables" prison uses iptables to block the IP address of the problem, you can detect the current iptables to verify the blocking rule in the following ways.

$ sudo iptables--list-n

Chain INPUT (Policy ACCEPT)
Target Prot opt source destination
Fail2ban-ssh TCP--0.0.0.0/0 0.0.0.0/0 TCP dpt:22

Chain FORWARD (Policy ACCEPT)
Target Prot opt source destination

Chain OUTPUT (Policy ACCEPT)
Target Prot opt source destination

Chain Fail2ban-ssh (1 references)
Target Prot opt source destination
DROP All--192.168.1.8 0.0.0.0/0
Return all--0.0.0.0/0 0.0.0.0/0

If you want to unlock an IP address from the Fail2ban, you can use the iptables command:

$ sudo iptables-d fail2ban-ssh-s 192.168.1.8-j DROP

Of course, you can use the above iptables command to manually verify and manage the Fail2ban IP blocking list, but in fact there is an appropriate way to use the Fail2ban-client command line tool. This command not only allows you to manage "ssh-iptables" prisons, but is also a standard command-line interface to manage other types of Fail2ban prisons.

To verify the Fail2ban status (the list of currently active prisons is displayed):

$ sudo fail2ban-client status

In order to test the status of a particular prison (e.g. Ssh-iptables):

$ sudo fail2ban-client status ssh-iptables

The above command displays a list of banned IP addresses.

To understand the lock-specific IP address:

$ sudo fail2ban-client set ssh-iptables unbanip 192.168.1.8

Note that if you stop the Fail2ban service, all IP addresses will be unlocked. When you restart Fail2ban, it will find an unusual list of IP addresses from/etc/log/secure (or/var/log/auth.log), and if the occurrence of these unusual addresses is still in the forbidden time, then Fail2ban will again prohibit the IP addresses.

Set Fail2ban to start automatically

Once you have successfully tested the Fail2ban, the final step is to have it start automatically on your server when it is powered on. In a Debian-based distribution, the Fail2ban has been made automatically active by default. In the Red-hat release, the following is the way to make the autostart effective.

In Centos/rhel 6:

$ sudo chkconfig fail2ban on

In Fedora or Centos/rhel 7:

$ sudo systemctl enable Fail2ban

Summary

In this tutorial, I demonstrated how to install and configure Fail2ban to protect an SSH server. Of course Fail2ban can mitigate violent password attacks, but note that this does not protect the SSH server from complex distributed brute-force cracking organizations that bypass Fail2ban defenses by using thousands of machine-controlled IP addresses.



How to configure Fail2ban to protect the Apache server

The Apache servers in the production environment may be subject to different attacks. An attacker might attempt to gain unauthorized or inaccessible directories by brute force attack or by executing a malicious script. Some malicious reptiles may scan your site for various vulnerabilities or send spam by collecting email addresses and Web forms.

The Apache server has a comprehensive logging capability to capture the exception events that are reflected by various attacks. However, it does not systematically parse the specific Apache logs and react quickly to potential attacks (for example, prohibiting/unlocking IP addresses). At this time Fail2ban can save all this and liberate the work of the system administrator.

Fail2ban is an intrusion prevention tool that detects different tools based on system logs and can automatically take protection such as prohibiting IP through iptables, blocking connections via/etc/hosts.deny, or sending notifications via mail. Fail2ban has a series of predefined "prisons" that use specific program log filters to detect common attacks. You can also write custom rules to detect attacks from any program.

In this tutorial, I'll show you how to configure Fail2ban to protect your Apache server. I assume you have Apache and Fail2ban installed. For installation, refer to another tutorial.

What is Fail2ban prison?

Let's get a deeper understanding of Fail2ban prison. The prison defines a specific application policy that triggers a protection for the specified program. Fail2ban in/etc/fail2ban/jail.conf for some popular programs such as Apache, Dovecot, LIGHTTPD, MySQL, Postfix, SSH and other predefined prison. Each prison detects the usual attack through a specific program log filter (under/ETC/FAIL2BAN/FILETER.D). Let me see an example of prisons: SSH prison.

[SSH]
Enabled = True
Port = SSH
Filter = sshd
LogPath =/var/log/auth.log
Maxretry = 6
Banaction = Iptables-multiport

The configuration of the SSH prison defines these parameters:

[SSH]: The name of the prison is in square brackets.
Enabled: whether to enable prisons
Port: Port number (or the corresponding service name)
Filter: Log resolution rules for detecting attacks
LogPath: Detected log files
Maxretry: Maximum number of failures
Banaction: Prohibited operation

Any parameters defined in the prison configuration will overwrite the corresponding default configuration parameters in Fail2ban-wide. Conversely, any missing parameters use the default values defined in the [Default] field.

Predefined log filters are placed in/ETC/FAIL2BAN/FILTER.D, while the prohibited actions that can be taken are placed in/ETC/FAIL2BAN/ACTION.D.

If you want to overwrite Fail2ban default actions or define any custom prisons, you can create/etc/fail2ban/jail.local* files. In this tutorial, I'll use/etc/fail2ban/jail.local.

enable the predefined Apache prisons

The default installation of Fail2ban provides some predefined prisons and filters for the Apache service. I'm going to activate these built-in Apache prisons. Because the Debian and Redhat configurations are slightly different, I will provide their profiles separately.

enabling Apache prisons in Debian or Ubuntu

To enable predefined Apache prisons on Debian based systems, create/etc/fail2ban/jail.local as follows.

$ sudo vi/etc/fail2ban/jail.local

# Detection Password Authentication failed
[Apache]
Enabled = True
Port = Http,https
Filter = Apache-auth
LogPath =/var/log/apache*/*error.log
Maxretry = 6
# Detection vulnerabilities and PHP vulnerability scans
[Apache-noscript]
Enabled = True
Port = Http,https
Filter = Apache-noscript
LogPath =/var/log/apache*/*error.log
Maxretry = 6
# Detect Apache Overflow attacks
[Apache-overflows]
Enabled = True
Port = Http,https
Filter = Apache-overflows
LogPath =/var/log/apache*/*error.log
Maxretry = 2
# detects attempts to find a home directory on the server
[Apache-nohome]
Enabled = True
Port = Http,https
Filter = Apache-nohome
LogPath =/var/log/apache*/*error.log
Maxretry = 2

These prisons will trigger the default measures as there are no designated measures in the prisons above. To see the default action, find "Banaction" under [Default] in/etc/fail2ban/jail.conf.

Banaction = Iptables-multiport

In this case, the default action is Iptables-multiport (defined in/etc/fail2ban/action.d/iptables-multiport.conf). This measure uses a iptable multiport module to prohibit an IP address.

After the opening of the prison, you must restart Fail2ban to load the prison.

$ sudo service Fail2ban restart

To enable Apache prisons in Centos/rhel or fedora.

To enable predefined prisons in a red hat based system, create/etc/fail2ban/jail.local as follows.

$ sudo vi/etc/fail2ban/jail.local

# Detection Password Authentication failed
[Apache]
Enabled = True
Port = Http,https
Filter = Apache-auth
LogPath =/var/log/httpd/*error_log
Maxretry = 6
# crawler that detects crawling mail addresses
[Apache-badbots]
Enabled = True
Port = Http,https
Filter = Apache-badbots
LogPath =/var/log/httpd/*access_log
Bantime = 172800
Maxretry = 1
# Detection vulnerabilities and PHP vulnerability scans
[Apache-noscript]
Enabled = True
Port = Http,https
Filter = Apache-noscript
LogPath =/var/log/httpd/*error_log
Maxretry = 6
# Detect Apache Overflow attacks
[Apache-overflows]
Enabled = True
Port = Http,https
Filter = Apache-overflows
LogPath =/var/log/httpd/*error_log
Maxretry = 2
# detects attempts to find a home directory on the server
[Apache-nohome]
Enabled = True
Port = Http,https
Filter = Apache-nohome
LogPath =/var/log/httpd/*error_log
Maxretry = 2
# detects attempts to execute scripts that do not exist
# These are popular Web service programs
# such as: Webmail, phpmyadmin,wordpress
Port = Http,https
Filter = Apache-botsearch
LogPath =/var/log/httpd/*error_log
Maxretry = 2

Note These prison files the default action is Iptables-multiport (defined in "Banaction" under/etc/fail2ban/jail.conf [Default] field). This measure uses a iptable multiport module to prohibit an IP address.

After the prison is opened, you must restart Fail2ban to load the prison.

In Fedora or Centos/rhel 7:

$ sudo systemctl restart Fail2ban

In Centos/rhel 6:

$ sudo service Fail2ban restart

Check and manage Fail2ban forbidden status

Once the prison is activated, you can use the Fail2ban Client command-line tool to monitor the current prohibited state.

View the list of active prisons:

$ sudo fail2ban-client status

View the status of a specific prison (containing a banned IP list):

$ sudo fail2ban-client status [prison name]

You can also manually prohibit or ban the IP address:

to be used to make prisons prohibit IP:

    $ sudo fail2ban-client set [Name-of-jail] Banip [IP -address]

to ban the IP of the specified prison shield:

    $ sudo fail2ban-client set [Name-of-jail] Unbanip [ip-addres S]

Summary

This tutorial explains how Fail2ban prisons work and how to use the built-in prisons to protect Apache servers. Depending on your environment and the type of Web server you want to protect, you may want to adjust the existing prisons or write custom prisons and log filters.