WHY:
There were numerous unauthorized login attempts on the SSH server for Gitea, causing potential security risks. To mitigate this I setup Fail2Ban. Since writing, I have disabled SSH.
Install Fail2Ban
This was as easy as sudo apt install fail2ban. The configuration is more in depth.
Configure Fail2Ban for Gitea:
Custom configuration files were created to set up Fail2Ban specifically for monitoring the Gitea log file located at /var/log/remotelogs/gitea.log.
Jail Configuration (/etc/fail2ban/jail.d/gitea.conf):
[gitea]
enabled = true
filter = gitea
logpath = /var/log/remotelogs/gitea.log
maxretry = 2
findtime = 86400
bantime = 900
action = gitea[name=gitea, bantime=600]
Action Configuration (/etc/fail2ban/action.d/gitea.conf):
[Definition]
actionstart = touch /var/run/fail2ban/fail2ban.gitea
actionstop =
actioncheck =
actionban = /opt/fail2ban/ban.sh <name> <bantime> <ip>
actionunban = /opt/fail2ban/unban.sh <ip>
bantime = 0
port = "0:65535"
[Init]
init = Gitea Notifications
Ban Script
This was the script I used to ban hosts (Essentially just record the ip, then manually review them and add them into the firewall later):
#!/bin/bash
echo $1 $2 $3 >> /opt/fail2ban/banned.txt
Filter Configuration (/etc/fail2ban/filter.d/gitea.conf):
# gitea.conf
[Definition]
failregex = .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user|Invalid user incoming|Invalid user).* from <HOST>
ignoreregex =
Disable Default SSH Monitoring:
The default SSH jail was disabled by commenting out the SSHD block in /etc/fail2ban/jail.conf:
# [sshd]
# enabled = true
This customization ensures that Fail2Ban focuses only on Gitea-related incidents.
Connecting Fail2Ban to AWS Firewall:
After configuring Fail2Ban to detect and manage failed login attempts for Gitea, the next step is to link it with AWS Firewall to dynamically update firewall rules based on detected intrusions.
Monitoring and Verifying Fail2Ban Status:
Run the following command to check the status of Fail2Ban and its jails:
sudo fail2ban-client status
Output example:
Status
|- Number of jail: 1
`- Jail list: gitea
Check Specific Jail Status:
sudo fail2ban-client status gitea
Output example:
Status for the jail: gitea
|- Filter
| |- Currently failed: 3
| |- Total failed: 9
| `- File list: /var/log/remotelogs/gitea.log
`- Actions
|- Currently banned: 0
|- Total banned: 1
`- Banned IP list:
Find Banned IPs:
sudo zgrep 'Ban' /var/log/fail2ban.log*
By setting up Fail2Ban, unauthorized attempts are efficiently blocked, securing the Gitea environment against brute-force attacks and potential breaches.
Links:
- Syslog-NG 3.16 Administration Guide: Match
- Syslog-NG 3.24 Administration Guide: Filter Match
- Using Fail2Ban to Secure Your Server - Linode
- How Fail2Ban Works - GitHub Wiki
- Proper Fail2Ban Configuration - GitHub Wiki
- How to Show All Banned IPs with Fail2Ban - ServerFault
- Iptables - Arch Linux Wiki
- Fail2Ban Tutorial - The Art of Web
- Custom Fail2Ban Action - WebCP
- Fail2Ban Setup for Gitea - Gitea Documentation
- Reprocess Log Files with Fail2Ban - SuperUser
- Protect SSH with Fail2Ban on Ubuntu 20.04 - DigitalOcean
- Fail2Ban Setup Guide for Gitea - Gitea Docs
- How Does Fail2Ban Detect the Time of an Intrusion Attempt - Unix StackExchange
- Answer on How Fail2Ban Detects Intrusion - Unix StackExchange
- Another Answer on Fail2Ban Intrusion Detection - Unix StackExchange