I noticed a bot had decided to target our Gitea service, so thought of putting it into fail2ban to lock it down. Turned out this wasn’t as straight forward as I’d hoped.
Adding to the fail2ban was not a simple task, as Gitea is in a docker container. First thing required is to change the docker json/console output the log to syslog instead.
docker-compose.yml
Add a logging stanza to the gitea service in docker-compose.yml
logging:
driver: syslog
options:
syslog-address: udp://127.0.0.1:514
tag: "gitea"
Notice I tagged it with gitea
. You could make this a bit more automated using something like:
tag: "{{.NAME}}/{{.ID}}"
This is used by rsyslog as a filter to separate gitea traffic to gitea.log
as below.
rsyslog
/etc/rsyslog.conf
Edit the rsyslog.conf
file to enable listening on udp by uncommenting the lines:
# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")
rsyslog.d/30-gitea
Edit/create the file to filter the received log
#Log gitea docker log messages to file
:syslogtag,contains,"gitea" /var/log/gitea.log
Now we can monitor the /var/log/gitea.log
file to start banning users.
fail2ban
fail2ban/filter.d/gitea.conf
[Definition]
failregex = Invalid user.* <HOST>
fail2ban/jail.d/gitea.conf
[gitea-docker]
enabled = true
filter = gitea
logpath = /var/log/gitea*.log
maxretry = 5
bantime = 365d
port = 22
action = iptables-allports[chain="FORWARD"]
The magic that makes this work is action = iptables-allports[chain="FORWARD"]
. The reason for this is that iptables gets NAT’et traffic from the gateway firewall and cannot block the NAT address unless it is in the FORWARD
chain..