Configure fail2ban for a Gitea docker container

Gitea is a self-hosted open-source git management platform. I have found it to be much snappier than Gitlab. The memory footprint of a Gitea docker instance was also found to be significantly lower than that of a Gitlab instance in my short experimentation with both.

The instructions to configure fail2ban for Gitea, specifically for a dockerized instance, are available on Gitea's official website. But since it did not apply directly in my case, I had to struggle for an hour to figure out how to exactly configure my instance. I thought I should note it down before I forget.

The Gitea instance in this case runs on a docker host on Linode and is proxied via the Nginx proxy manager (NPM). The NPM instance runs as another docker container.

Though I originally set up the Gitea instance with a docker volume for /data, later I decided to map the logs to a local directory.

I used portainer to bind  /data/gitea/log to a local directory under the user git's home. Let's assume its name is gitea_log

First go to NPM and add proxy_set_header X-Real-IP $remote_addr; in the advanced section so that the client's actual IP is passed to the container rather than the docker IP.

You should also set something like

REVERSE_PROXY_LIMIT = 1
REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.1/8,172.17.0.0/8

in Gitea's configuration file app.ini

I edited the Gitea container's files by opening the files via the containers's shell by accessing it from Portainer's webui. In this case for example I just open the shell and do

apk add emacs
emacs /data/gitea/conf/app.ini

to edit the configuration file (The package manager is apk in alpine Linux on which my container is based. Note that the package installation may not be persistent).

The actual IPs would vary depending on your network configuration.

You should also configure Gitea to write the logs to a file (the default configuration writes only to stdout for whatever reason.

For this, changes that I made in app.ini are

[logs]
MODE = console,file
ENABLE_ACCESS_LOG = true 

Leave the other values in the [logs] section as it is. The ENABLE_ACCESS_LOGS may not be relevant but I decided to have it anyway.

Configuring fail2ban

This part is somewhat straight forward.

You should install fail2ban on the host if you haven't already

Now, configure two jails gitea and gitea-docker

#/etc/fail2ban/jail.d/gitea.conf
[gitea]enabled = true
filter = gitealog
path = /home/git/gitea_log/gitea.log
maxretry = 5
findtime = 600
bantime = 1800action = iptables-allports

#/etc/fail2ban/jail.d/gitea-docker.conf
[gitea-docker]
enabled = true
filter = gitea
logpath = /home/git/gitea_log/gitea.log
maxretry = 5
findtime = 600
bantime = 1800

The above example is for banning an IP that performs an activity that matches the configured regular expression 5 times in a duration of 600 seconds. The ban will last for 1800 seconds.

Now, decide what are the activities that you want the block to be triggered by and set up a filter /etc/fail2ban/filter.d/gitea.conf file to something like this

# gitea.conf
[Definition]
failregex =  .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from <HOST>
ignoreregex =

Restart fail2ban and you will find that the ban is active

You can run fail2ban-client status as root and you will see that your new jails are in operation.

Make sure that you have access through some means (If you are on a cloud VPS provider like Linode you probably have direct access to a console via their webui) before you experiment to get self-banned.

Try logging in with a wrong username/password 5 times. You should be kicked out from the system by fail2ban now.

You can view the banned IPs by running

fail2ban-client status <jailname>

To remove yourself from a jail, go to the console and run

fail2ban-client set <jailname> unbanip <IP>

You should be unbanned and be able to login now.