Skip to main content

Set Bruteforce Protection

Brute force protection is a critical aspect of securing blockchain nodes and servers. As these systems often manage valuable assets and sensitive information, they are prime targets for attackers seeking unauthorized access. Brute force attacks involve systematically attempting various combinations of ports, usernames, and passwords to gain access to a target system. Implementing robust security measures on blockchain nodes and servers is essential, so brute force attacks can not target them.

While we will later protect our system with key authentication, limiting login attempts and connection is smart. One widely used security tool is called Fail2Ban. It is a security tool that helps protect your system against brute-force attacks and other unauthorized access attempts. It monitors log files for patterns that indicate malicious activities, such as repeated failed login attempts.

When such activities are detected, Fail2Ban automatically updates the firewall rules to block the offending IP addresses for a specified duration.

3.7.1 Install Fail2Ban

First, we need to get the service installed using APT:

sudo apt install fail2ban

After the installation has been successful, we can continue its configuration.

3.7.2 Configure Protection Rules

Fail2Ban has its own preset of configurations saved within the /etc/fail2ban/jail.conf file. However, if you want to apply custom rules, you can use a separate file: /etc/fail2ban/jail.local. The configuration allows you to specify settings for individual services, determine how many failed login attempts should trigger a ban, set the duration of the ban, and define other security measures.

Using a separate file for custom configurations is super convenient because it ensures that your changes are preserved when Fail2Ban is updated, as the original will never be modified.

Setting properties for the SSH daemon process for the blockchain node is recommended, as it is the only way to access our node. We can do so by defining the [sshd] tag and setting enabled=true. These are the recommended setting properties:

  • port: This specifies the port number on which the SSH daemon is listening. Set the opened port number you've configured for SSH on the node.
  • filter: This option sets the filter for parsing log files and detecting failed login attempts. In our case, the filter should be selected to sshd, a predefined filter for the SSH daemon.
  • logpath: This sets the path to the log file for monitoring failed login attempts. The file typically contains information about authentication events, including failed SSH login attempts. I will set its path to /var/log/auth.log as it is the standard location for log files on Unix-based systems. It is designed to store log files generated by various system processes, services, and applications. Placing it in the /var/log/ directory follows the standard convention. It allows system administrators to quickly locate and manage log files related to different system components in a centralized location.
  • maxretry: This option sets the maximum number of failed login attempts allowed within the specified period before an IP address gets banned. I prefer 3 tries, a typical number for bankcard payments.
  • findtime: This option sets the time window in seconds, during which the maximum of failed login attempts can occur before an IP address gets banned. In my case, I set it to 300 seconds, e.g., 5 minutes, but you could also reduce the number.
  • bantime: This option sets the duration in seconds for which an IP address will be banned after exceeding the allowed number of failed login attempts within the findtime period. In my case, it's set to 28,800 seconds, e.g., 8 hours before the IP address can try again.
  • backend: This option sets the backend to monitor the specified log file. The service will automatically select the most appropriate backend based on your system's configuration when set to auto.
  • ignoreip: This option allows you to specify a list of IP addresses or address ranges that should not be banned, even if they exceed the maximum number of allowed failed login attempts. You can add the local IP range 127.0.0.1/8 to prevent accidentally denying your local connections. The ignore rule will also work if you want to set single addresses.

You can also add custom IP addresses to the ignoreip property, e.g., allow connections from your VPN service's address range. But remember that people with the same VPN service could still bypass the restrictions.

Open the configuration file:

sudo nano /etc/fail2ban/jail.local

Input the properties into the configuration snippet:

[sshd]
enabled=true
port=<desired-port-number>
filter=sshd
logpath=/var/log/auth.log
maxretry=3
findtime=300
bantime=28800
backend=auto
ignoreip=127.0.0.1/8

Please exchange <desired-port-number> with the port number you opened for SSH. You may want to change specific settings to personalize your setup.

Be cautious: When creating new rules or modifying existing ones, it's essential to follow the correct syntax and structure to ensure that Fail2Ban functions appropriately and provides the desired level of security. Please verify that you do not use spaces between properties and their values.

3.7.3 Start the Fail2Ban Service

First, we need to reload the system manager configuration. It is used when making changes to service configuration files or creating new service files, ensuring that the system daemon service is aware of the changes like before.

sudo systemctl daemon-reload

Afterward, we can start the Fail2Ban service using the system control command.

sudo systemctl start fail2ban

To enable the Fail2Ban service to start automatically when the system boots, we can use the system control to create a symbolic link as we did before.

sudo systemctl enable fail2ban

We can fetch the current status from the system control to check if the Fail2Ban service is running and configured correctly. It will display whether it is active, enabled, or disabled and show any recent log entries.

sudo systemctl status fail2ban

The output should look like this:

● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: active (running) since [DATE]; [TIME] ago
Docs: man:fail2ban(1)
Main PID: 5875 (fail2ban-server)
Tasks: 5 (limit: 38043)
Memory: [USED_MEMORY]
CPU: [EXECUTION_TIME]
CGroup: /system.slice/fail2ban.service
└─5875 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

[DATE] [USER] systemd[PID]: Started Fail2Ban Service.
[DATE] [USER] fail2ban-server[PID]: Server ready

If everything is alright, we can start configuring the node's network and router settings.