MirrorHub/bitwarden_rs
0
0
Fork 0
mirror of https://github.com/dani-garcia/vaultwarden synced 2024-09-27 21:08:55 +02:00
Code Issues Releases Wiki Activity

Better indentation and fixed code blocks

JuanM04 2021-01-02 14:55:45 -03:00
parent cd54372ca0
commit 4a81706952
1 changed files with 134 additions and 129 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

263
Fail2Ban-Setup.md

@ -16,24 +16,24 @@ Setup Fail2ban will prevent attackers to brute force your vault logins. This is
- [SELinux Problems](#selinux-problems) - [SELinux Problems](#selinux-problems)
## Pre-requisite ## Pre-requisite
- Commands below are using `vi`. The basics can be found [there](https://pc.net/resources/commands/vi). However, you can use whatever text editor you want. - Filenames are at the top of each code block.
- From Release 1.5.0, Bitwarden_rs supports logging to file. Please set this up : [[Logging|logging]] - From Release 1.5.0, Bitwarden_rs supports logging to file. Please set this up : [[Logging|logging]]
- Try to log to web vault with a false account and check the log files for following format - Try to log to web vault with a false account and check the log files for following format
```` ```
[YYYY-MM-DD hh:mm:ss][bitwarden_rs::api::identity][ERROR] Username or password is incorrect. Try again. IP: XXX.XXX.XXX.XXX. Username: email@domain.com. [YYYY-MM-DD hh:mm:ss][bitwarden_rs::api::identity][ERROR] Username or password is incorrect. Try again. IP: XXX.XXX.XXX.XXX. Username: email@domain.com.
```` ```
## Installation ## Installation
### Debian / Ubuntu / Raspberry Pi OS ### Debian / Ubuntu / Raspberry Pi OS
``` ```bash
sudo apt-get install fail2ban -y sudo apt-get install fail2ban -y
``` ```
### Fedora / Centos ### Fedora / Centos
EPEL repository is necessary (CentOS 7) EPEL repository is necessary (CentOS 7)
``` ```bash
sudo yum install epel-release sudo yum install epel-release
sudo yum install fail2ban -y sudo yum install fail2ban -y
``` ```
### Synology DSM ### Synology DSM
@ -47,181 +47,186 @@ With Synology, a bit more work is needed for various reasons. The full solution
Therefore, we will use Fail2ban in a Docker container. [Crazy-max/docker-fail2ban](https://github.com/crazy-max/docker-fail2ban) provides a good solution and the Synology's Docker GUI will be ignored. From command line through SSH, here the steps. As a convention `volumeX` is to be adapted to your Synology's config. Therefore, we will use Fail2ban in a Docker container. [Crazy-max/docker-fail2ban](https://github.com/crazy-max/docker-fail2ban) provides a good solution and the Synology's Docker GUI will be ignored. From command line through SSH, here the steps. As a convention `volumeX` is to be adapted to your Synology's config.
0. Get root 0. Get root
```` ```bash
sudo -i sudo -i
```` ```
1. Creating persistent folders 1. Creating persistent folders
```bash
```` mkdir -p /volumeX/docker/fail2ban/action.d/
mkdir -p /volumeX/docker/fail2ban/action.d/ mkdir -p /volumeX/docker/fail2ban/jail.d/
mkdir -p /volumeX/docker/fail2ban/jail.d/ mkdir -p /volumeX/docker/fail2ban/filter.d/
mkdir -p /volumeX/docker/fail2ban/filter.d/ ```
````
2. Replace `REJECT` by `DROP` blocktype 2. Replace `REJECT` by `DROP` blocktype
```` ```INI
vi /volumeX/docker/fail2ban/action.d/iptables-common.local # /volumeX/docker/fail2ban/action.d/iptables-common.local
````
Copy and paste the following content
````
[Init]
blocktype = DROP
[Init?family=inet6]
blocktype = DROP
````
3. Create docker-compose file
````
vi /volumeX/docker/fail2ban/docker-compose.yml
````
Copy and paste the following content
````
version: '3'
services:
fail2ban:
container_name: fail2ban
restart: always
image: crazymax/fail2ban:latest
environment:
- TZ=Europe/Paris
- F2B_DB_PURGE_AGE=30d
- F2B_LOG_TARGET=/data/fail2ban.log
- F2B_LOG_LEVEL=INFO
- F2B_IPTABLES_CHAIN=INPUT
volumes: [Init]
- /volumeX/docker/fail2ban:/data blocktype = DROP
- /volumeX/docker/bw-data:/bitwarden:ro [Init?family=inet6]
blocktype = DROP
```
network_mode: "host" 3. Create `docker-compose` file
```yml
# /volumeX/docker/fail2ban/docker-compose.yml
version: '3'
services:
fail2ban:
container_name: fail2ban
restart: always
image: crazymax/fail2ban:latest
environment:
- TZ=Europe/Paris
- F2B_DB_PURGE_AGE=30d
- F2B_LOG_TARGET=/data/fail2ban.log
- F2B_LOG_LEVEL=INFO
- F2B_IPTABLES_CHAIN=INPUT
volumes:
- /volumeX/docker/fail2ban:/data
- /volumeX/docker/bw-data:/bitwarden:ro
network_mode: "host"
privileged: true
cap_add:
- NET_ADMIN
- NET_RAW
```
privileged: true
cap_add:
- NET_ADMIN
- NET_RAW
````
4. Start the container using command line 4. Start the container using command line
```` ```bash
cd /volumeX/docker/fail2ban cd /volumeX/docker/fail2ban
docker-compose up -d docker-compose up -d
```` ```
You should see the container running in Synology's Docker GUI. You will have to reload after configuring the filters and jails You should see the container running in Synology's Docker GUI. You will have to reload after configuring the filters and jails
## Setup for web vault ## Setup for web vault
As a convention, `path_f2b` means the path needed for Fail2ban to work. This depends on your system. E.g. on Synology, we are talking about `/volumeX/docker/fail2ban/` where on some other systems we are talking about `/etc/fail2ban/` As a convention, `path_f2b` means the path needed for Fail2ban to work. This depends on your system. E.g. on Synology, we are talking about `/volumeX/docker/fail2ban/` where on some other systems we are talking about `/etc/fail2ban/`
### Filter ### Filter
Create and fill the following file
````
vi path_f2b/filter.d/bitwarden_rs.local
````
Copy and paste the following content
````
[INCLUDES]
before = common.conf
[Definition] Create and fill the following file
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex = ```INI
```` # path_f2b/filter.d/bitwarden_rs.local
[INCLUDES]
before = common.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =
```
**Tip:** If you get the following error message in `fail2ban.log` (CentOS 7, Fail2Ban v0.9.7) **Tip:** If you get the following error message in `fail2ban.log` (CentOS 7, Fail2Ban v0.9.7)
`fail2ban.filter [5291]: ERROR No 'host' group in '^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$'` `fail2ban.filter [5291]: ERROR No 'host' group in '^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$'`
Please Use `<HOST>` instead of `<ADDR>` in `bitwarden_rs.local` Please Use `<HOST>` instead of `<ADDR>` in `bitwarden_rs.local`
**Tip:** If you see 127.0.0.1 as the IP address of failed logins in bitwarden.log, then you're probably using a reverse proxy and fail2ban won't work correctly: **Tip:** If you see 127.0.0.1 as the IP address of failed logins in bitwarden.log, then you're probably using a reverse proxy and fail2ban won't work correctly:
```` ```
[YYYY-MM-DD hh:mm:ss][bitwarden_rs::api::identity][ERROR] Username or password is incorrect. Try again. IP: 127.0.0.1. Username: email@example.com. [YYYY-MM-DD hh:mm:ss][bitwarden_rs::api::identity][ERROR] Username or password is incorrect. Try again. IP: 127.0.0.1. Username: email@example.com.
```` ```
To remedy this, forward the true remote address to bitwarden_rs via the X-Real-IP header. How to do this varies depending on the proxy you use. For example, in Caddy 2.x, when you define the reverse-proxy, define `header_up X-Real-IP {remote_host}`. See [Proxy examples](https://github.com/dani-garcia/bitwarden_rs/wiki/Proxy-examples) for more info. To remedy this, forward the true remote address to bitwarden_rs via the X-Real-IP header. How to do this varies depending on the proxy you use. For example, in Caddy 2.x, when you define the reverse-proxy, define `header_up X-Real-IP {remote_host}`. See [Proxy examples](https://github.com/dani-garcia/bitwarden_rs/wiki/Proxy-examples) for more info.
### Jail ### Jail
Create and fill the following file Create and fill the following file
```` ```INI
vi path_f2b/jail.d/bitwarden_rs.local # path_f2b/jail.d/bitwarden_rs.local
````
Copy and paste the following content [bitwarden_rs]
```` enabled = true
[bitwarden_rs] port = 80,443,8081
enabled = true filter = bitwarden_rs
port = 80,443,8081 banaction = %(banaction_allports)s
filter = bitwarden_rs logpath = /path/to/bitwarden.log
banaction = %(banaction_allports)s maxretry = 3
logpath = /path/to/bitwarden.log bantime = 14400
maxretry = 3 findtime = 14400
bantime = 14400 ```
findtime = 14400
````
Note: Docker uses the FORWARD chain instead of the default INPUT chain. Therefore replace the `banaction` line with the following `action` when using Docker: Note: Docker uses the FORWARD chain instead of the default INPUT chain. Therefore replace the `banaction` line with the following `action` when using Docker:
```INI
action = iptables-allports[name=bitwarden_rs, chain=FORWARD]
``` ```
action = iptables-allports[name=bitwarden_rs, chain=FORWARD]
```
**NOTE**: **NOTE**:
Do not use this if you use a reverse proxy before Docker container. If proxy, like apache2 or nginx is used, use the ports of the proxy and do not use chain=FORWARD, only when using Docker **without** proxy! Do not use this if you use a reverse proxy before Docker container. If proxy, like apache2 or nginx is used, use the ports of the proxy and do not use `chain=FORWARD`, only when using Docker **without** proxy!
**NOTE on the NOTE above**: **NOTE on the NOTE above**:
That's at least not true for running on Docker (CentOS 7) with caddy as reverse proxy. chain=FORWARD is absolutely fine and working with caddy as reverse proxy. That's at least not true for running on Docker (CentOS 7) with caddy as reverse proxy. `chain=FORWARD` is absolutely fine and working with caddy as reverse proxy.
Reload fail2ban for changes to take effect: Reload fail2ban for changes to take effect:
`sudo systemctl reload fail2ban` ```bash
sudo systemctl reload fail2ban
```
Feel free to change the options as you see fit. Feel free to change the options as you see fit.
## Setup for admin page ## Setup for admin page
If you've enabled the admin console by setting the `ADMIN_TOKEN` environment variable, you can prevent an attacker brute-forcing the admin token using Fail2Ban. The process is the same as for the web vault. If you've enabled the admin console by setting the `ADMIN_TOKEN` environment variable, you can prevent an attacker from brute-forcing the admin token using Fail2Ban. The process is the same as for the web vault.
### Filter ### Filter
Create and fill the following file
````
vi path_f2b/filter.d/bitwarden-admin.local
````
Copy and paste the following content
````
[INCLUDES]
before = common.conf
[Definition] Create and fill the following file
failregex = ^.*Invalid admin token\. IP: <ADDR>.*$ ```INI
ignoreregex = # path_f2b/filter.d/bitwarden-admin.local
````
[INCLUDES]
before = common.conf
[Definition]
failregex = ^.*Invalid admin token\. IP: <ADDR>.*$
ignoreregex =
```
### Jail ### Jail
Create and fill the following file Create and fill the following file
```` ```INI
vi path_f2b/jail.d/bitwarden_rs-admin.local # path_f2b/jail.d/bitwarden_rs-admin.local
````
Copy and paste the following content [bitwarden_rs-admin]
```` enabled = true
[bitwarden_rs-admin] port = 80,443
enabled = true filter = bitwarden_rs-admin
port = 80,443 banaction = %(banaction_allports)s
filter = bitwarden_rs-admin logpath = /path/to/bitwarden.log
banaction = %(banaction_allports)s maxretry = 3
logpath = /path/to/bitwarden.log bantime = 14400
maxretry = 3 findtime = 14400
bantime = 14400 ```
findtime = 14400
````
Note: Docker uses the FORWARD chain instead of the default INPUT chain. Therefore replace the `banaction` line with the following `action` when using Docker: Note: Docker uses the FORWARD chain instead of the default INPUT chain. Therefore replace the `banaction` line with the following `action` when using Docker:
```INI
action = iptables-allports[name=bitwarden_rs, chain=FORWARD]
``` ```
action = iptables-allports[name=bitwarden_rs, chain=FORWARD]
```
Reload fail2ban for changes to take effect: Reload fail2ban for changes to take effect:
`sudo systemctl reload fail2ban` ```bash
sudo systemctl reload fail2ban
```
## Testing Fail2Ban ## Testing Fail2Ban
Now just try to login to bitwarden using any email (it doesn't have to be a valid email, just an email format) Now just try to login to bitwarden using any email (it doesn't have to be a valid email, just an email format)
If it works correctly and your IP is banned, you can unban the IP by running: If it works correctly and your IP is banned, you can unban the IP by running:
Without Docker: Without Docker:
`sudo fail2ban-client set bitwarden_rs unbanip XX.XX.XX.XX` ```bash
# With Docker
sudo docker exec -t fail2ban fail2ban-client set bitwarden_rs unbanip XX.XX.XX.XX
# Without Docker
sudo fail2ban-client set bitwarden_rs unbanip XX.XX.XX.XX
```
With Docker: If Fail2Ban does not appear to be functioning, verify that the path to the Bitwarden log file is correct. For Docker: If the specified log file is not being generated and/or updated, make sure the `EXTENDED_LOGGING` env variable is set to true (which is default) and that the path to the log file is the path inside the Docker (when you use `/bw-data/:/data/` the log file should be in `/data/...` to be outside the container).
`sudo docker exec -t fail2ban fail2ban-client set bitwarden_rs unbanip XX.XX.XX.XX`
If Fail2Ban does not appear to be functioning, verify that the path to the Bitwarden log file is correct. For Docker: If the specified log file is not being generated and/or updated, make sure the `EXTENDED_LOGGING` env variable is set to true (which is default) and that the path to the log file is the path inside the Docker (when you use /bw-data/:/data/ the log file should be in /data/... to be outside the container).
Also verify that the timezone of the Docker container matches the timezone of the host. Check this by comparing the time shown in the logfile with the host OS time. If they differ, there are various ways to fix this. One option is to start Docker with the option `-e "TZ=<timezone>"`. A list of valid timezones is [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) (eg. `-e "TZ=Australia/Melbourne"`) Also verify that the timezone of the Docker container matches the timezone of the host. Check this by comparing the time shown in the logfile with the host OS time. If they differ, there are various ways to fix this. One option is to start Docker with the option `-e "TZ=<timezone>"`. A list of valid timezones is [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) (eg. `-e "TZ=Australia/Melbourne"`)