vaultwarden
/
vaultwarden-alternativa-bitwarden
mirror of https://github.com/dani-garcia/vaultwarden.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Do not conflict with Bitwarden jail added upstream https://github.com/fail2ban/fail2ban/pull/2567/files

Daniel M. Capella 2020-11-12 04:00:43 +00:00
parent 2d753865ad
commit 25c62ca2ad
1 changed files with 20 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
Fail2Ban-Setup.md

@ -114,7 +114,7 @@ As a convention, `path_f2b` means the path needed for Fail2ban to work. This dep
### Filter ### Filter
Create and fill the following file Create and fill the following file
```` ````
vi path_f2b/filter.d/bitwarden.local vi path_f2b/filter.d/bitwarden_rs.local
```` ````
Copy and paste the following content Copy and paste the following content
```` ````
@ -128,7 +128,7 @@ Create and fill the following file
**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.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:
```` ````
@ -139,15 +139,15 @@ To remedy this, forward the true remote address to bitwarden_rs via the X-Real-I
### Jail ### Jail
Create and fill the following file Create and fill the following file
```` ````
vi path_f2b/jail.d/bitwarden.local vi path_f2b/jail.d/bitwarden_rs.local
```` ````
Copy and paste the following content Copy and paste the following content
```` ````
[bitwarden] [bitwarden_rs]
enabled = true enabled = true
port = 80,443,8081 port = 80,443,8081
filter = bitwarden filter = bitwarden_rs
action = iptables-allports[name=bitwarden] action = iptables-allports[name=bitwarden_rs]
logpath = /path/to/bitwarden.log logpath = /path/to/bitwarden.log
maxretry = 3 maxretry = 3
bantime = 14400 bantime = 14400
@ -155,7 +155,7 @@ Create and fill the following file
```` ````
Note: Docker uses the FORWARD chain instead of the default INPUT chain. Therefore use the following action when using Docker: Note: Docker uses the FORWARD chain instead of the default INPUT chain. Therefore use the following action when using Docker:
``` ```
action = iptables-allports[name=bitwarden, 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!
@ -163,9 +163,9 @@ Do not use this if you use a reverse proxy before docker container. If proxy, li
**NOTE on the NOTE above**: **NOTE on the NOTE above**:
Thats 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. Thats 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.
You need to restart fail2ban for changes to take effect: Reload fail2ban for changes to take effect:
`sudo systemctl restart fail2ban` `sudo systemctl reload fail2ban`
Feel free to change the options as you see fit. Feel free to change the options as you see fit.
@ -190,15 +190,15 @@ Create and fill the following file
### Jail ### Jail
Create and fill the following file Create and fill the following file
```` ````
vi path_f2b/jail.d/bitwarden-admin.local vi path_f2b/jail.d/bitwarden_rs-admin.local
```` ````
Copy and paste the following content Copy and paste the following content
```` ````
[bitwarden-admin] [bitwarden_rs-admin]
enabled = true enabled = true
port = 80,443 port = 80,443
filter = bitwarden-admin filter = bitwarden_rs-admin
action = iptables-allports[name=bitwarden] action = iptables-allports[name=bitwarden_rs]
logpath = /path/to/bitwarden.log logpath = /path/to/bitwarden.log
maxretry = 3 maxretry = 3
bantime = 14400 bantime = 14400
@ -206,22 +206,22 @@ Create and fill the following file
```` ````
Note: Docker uses the FORWARD chain instead of the default INPUT chain. Therefore use the following action when using Docker: Note: Docker uses the FORWARD chain instead of the default INPUT chain. Therefore use the following action when using Docker:
``` ```
action = iptables-allports[name=bitwarden, chain=FORWARD] action = iptables-allports[name=bitwarden_rs, chain=FORWARD]
``` ```
You need to restart fail2ban for changes to take effect: Reload fail2ban for changes to take effect:
`sudo systemctl restart fail2ban` `sudo systemctl reload fail2ban`
## Testing Fail2Ban ## Testing Fail2Ban
Now just try to login to bitwarden using any email (it doesnt 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 unbanip XX.XX.XX.XX` `sudo fail2ban-client set bitwarden_rs unbanip XX.XX.XX.XX`
With docker : With docker :
`sudo docker exec -t fail2ban fail2ban-client set bitwarden unbanip XX.XX.XX.XX` `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). 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).
@ -236,5 +236,4 @@ When you are using SELinux it is possible that SELinux hinders fail2ban to read
``` ```
type=AVC msg=audit(1571777936.719:2193): avc: denied { search } for pid=5853 comm="fail2ban-server" name="containers" dev="dm-0" ino=1144588 scontext=system_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1571777936.719:2193): avc: denied { search } for pid=5853 comm="fail2ban-server" name="containers" dev="dm-0" ino=1144588 scontext=system_u:system_r:fail2ban_t:s0 tcontext=unconfined_u:object_r:container_var_lib_t:s0 tclass=dir permissive=0
``` ```
To actually find out the reason you can use `grep 'type=AVC msg=audit(1571777936.719:2193)' /var/log/audit/audit.log | audit2why`. `audit2allow -a` will give you specific instructions on how to create a module and allow fail2ban to access these logs. Follow these steps and you're done! fail2ban should now work correctly. To actually find out the reason you can use `grep 'type=AVC msg=audit(1571777936.719:2193)' /var/log/audit/audit.log | audit2why`. `audit2allow -a` will give you specific instructions on how to create a module and allow fail2ban to access these logs. Follow these steps and you're done! fail2ban should now work correctly.