2018-05-18 05:16:30 -04:00
---
date: "2018-05-11T11:00:00+02:00"
2023-04-06 05:06:32 -04:00
title: "Fail2ban Setup "
2018-05-18 05:16:30 -04:00
slug: "fail2ban-setup"
2023-07-26 00:53:13 -04:00
sidebar_position: 16
2020-12-09 01:47:06 -05:00
toc: false
2018-05-18 05:16:30 -04:00
draft: false
Refactor docs (#23752)
This was intended to be a small followup for
https://github.com/go-gitea/gitea/pull/23712, but...here we are.
1. Our docs currently use `slug` as the entire URL, which makes
refactoring tricky (see https://github.com/go-gitea/gitea/pull/23712).
Instead, this PR attempts to make future refactoring easier by using
slugs as an extension of the section. (Hugo terminology)
- What the above boils down to is this PR attempts to use directory
organization as URL management. e.g. `usage/comparison.en-us.md` ->
`en-us/usage/comparison/`, `usage/packages/overview.en-us.md` ->
`en-us/usage/packages/overview/`
- Technically we could even remove `slug`, as Hugo defaults to using
filename, however at least with this PR it means `slug` only needs to be
the name for the **current file** rather than an entire URL
2. This PR adds appropriate aliases (redirects) for pages, so anything
on the internet that links to our docs should hopefully not break.
3. A minor nit I've had for a while, renaming `seek-help` to `support`.
It's a minor thing, but `seek-help` has a strange connotation to it.
4. The commits are split such that you can review the first which is the
"actual" change, and the second is added redirects so that the first
doesn't break links elsewhere.
---------
Signed-off-by: jolheiser <john.olheiser@gmail.com>
2023-04-27 23:33:41 -04:00
aliases:
- /en-us/fail2ban-setup
2018-05-18 05:16:30 -04:00
menu:
sidebar:
2023-03-23 11:18:24 -04:00
parent: "administration"
2018-05-18 05:16:30 -04:00
name: "Fail2ban setup"
2023-07-26 00:53:13 -04:00
sidebar_position: 16
2018-05-18 05:16:30 -04:00
identifier: "fail2ban-setup"
---
2019-11-10 20:33:28 -05:00
# Fail2ban setup to block users after failed login attempts
2018-05-18 05:16:30 -04:00
2020-11-27 20:08:23 -05:00
**Remember that fail2ban is powerful and can cause lots of issues if you do it incorrectly, so make
2018-05-18 05:16:30 -04:00
sure to test this before relying on it so you don't lock yourself out.**
2020-11-27 20:08:23 -05:00
Gitea returns an HTTP 200 for bad logins in the web logs, but if you have logging options on in
`app.ini` , then you should be able to go off of `log/gitea.log` , which gives you something like this
2020-12-08 12:54:33 -05:00
on a bad authentication from the web or CLI using SSH or HTTP respectively:
2018-05-18 05:16:30 -04:00
```log
2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx
```
2020-12-15 03:45:13 -05:00
```log
2020/10/15 16:05:09 modules/ssh/ssh.go:143:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
```
2022-07-27 21:22:47 -04:00
2021-06-28 19:26:40 -04:00
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
2020-12-15 03:45:13 -05:00
```log
2020/10/15 16:05:09 modules/ssh/ssh.go:155:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
```
2022-07-27 21:22:47 -04:00
2021-06-28 19:26:40 -04:00
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
2020-12-15 03:45:13 -05:00
2020-12-08 12:54:33 -05:00
```log
2020-12-15 03:45:13 -05:00
2020/10/15 16:05:09 modules/ssh/ssh.go:198:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
2020-12-08 12:54:33 -05:00
```
2022-07-27 21:22:47 -04:00
2021-06-28 19:26:40 -04:00
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
2020-12-15 03:45:13 -05:00
```log
2020/10/15 16:05:09 modules/ssh/ssh.go:213:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
```
2022-07-27 21:22:47 -04:00
2021-06-28 19:26:40 -04:00
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
2020-12-15 03:45:13 -05:00
```log
2020/10/15 16:05:09 modules/ssh/ssh.go:227:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
```
2022-07-27 21:22:47 -04:00
2021-06-28 19:26:40 -04:00
(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
```log
2020/10/15 16:05:09 modules/ssh/ssh.go:249:sshConnectionFailed() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
```
2022-07-27 21:22:47 -04:00
2021-06-28 19:26:40 -04:00
(From 1.15 this new message will available and doesn't have any of the false positive results that above messages from publicKeyHandler do. This will only be logged if the user has completely failed authentication.)
2020-12-15 03:45:13 -05:00
2020-12-08 12:54:33 -05:00
```log
2020/10/15 16:08:44 ...s/context/context.go:204:HandleText() [E] invalid credentials from xxx.xxx.xxx.xxx
```
2018-05-18 05:16:30 -04:00
2019-10-23 10:07:32 -04:00
Add our filter in `/etc/fail2ban/filter.d/gitea.conf` :
2018-05-18 05:16:30 -04:00
```ini
# gitea.conf
[Definition]
2020-12-08 12:54:33 -05:00
failregex = .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from < HOST >
2018-05-18 05:16:30 -04:00
ignoreregex =
```
2019-10-23 10:07:32 -04:00
Add our jail in `/etc/fail2ban/jail.d/gitea.conf` :
2018-05-18 05:16:30 -04:00
```ini
[gitea]
enabled = true
filter = gitea
2020-11-27 20:08:23 -05:00
logpath = /var/lib/gitea/log/gitea.log
2018-05-18 05:16:30 -04:00
maxretry = 10
findtime = 3600
bantime = 900
action = iptables-allports
```
2020-11-27 20:08:23 -05:00
If you're using Docker, you'll also need to add an additional jail to handle the **FORWARD**
2019-10-23 10:07:32 -04:00
chain in **iptables** . Configure it in `/etc/fail2ban/jail.d/gitea-docker.conf` :
```ini
[gitea-docker]
enabled = true
filter = gitea
2022-03-16 12:39:13 -04:00
logpath = /var/lib/gitea/log/gitea.log
2019-10-23 10:07:32 -04:00
maxretry = 10
findtime = 3600
bantime = 900
action = iptables-allports[chain="FORWARD"]
```
2020-11-27 20:08:23 -05:00
Then simply run `service fail2ban restart` to apply your changes. You can check to see if
2019-10-23 10:07:32 -04:00
fail2ban has accepted your configuration using `service fail2ban status` .
2020-11-27 20:08:23 -05:00
Make sure and read up on fail2ban and configure it to your needs, this bans someone
2018-05-18 05:16:30 -04:00
for **15 minutes** (from all ports) when they fail authentication 10 times in an hour.
2019-03-09 16:15:45 -05:00
If you run Gitea behind a reverse proxy with Nginx (for example with Docker), you need to add
2020-11-27 20:08:23 -05:00
this to your Nginx configuration so that IPs don't show up as 127.0.0.1:
2018-05-18 05:16:30 -04:00
```
proxy_set_header X-Real-IP $remote_addr;
```
2021-07-16 05:04:52 -04:00
The security options in `app.ini` need to be adjusted to allow the interpretation of the headers
as well as the list of IP addresses and networks that describe trusted proxy servers
2023-08-27 07:59:12 -04:00
(See the [configuration cheat sheet ](administration/config-cheat-sheet.md#security-security ) for more information).
2021-07-16 05:04:52 -04:00
```
REVERSE_PROXY_LIMIT = 1
REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.1/8 ; 172.17.0.0/16 for the docker default network
```