mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-02-05 00:29:40 +03:00
Wiki description Fail2Ban #282
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jonathanmmm on GitHub (Apr 20, 2019).
Hi,
I believe in the Fail2Ban Wiki is some misunderstanding possible about docker.
First maybe
sudo apt-get install fail2ban should be included in the wiki settings (is not much)
and the notes about docker made me change the settings as I would use docker.
But I use docker for bitwarden_rs and not for fail2ban in a docker container.
The setting is only needed, when you use fail2ban as a container right? Or is it needed when there is no proxy (like nginx) so I would have to put the ports in that I expose docker to which I then reverse proxy for example?
Suppose:
bitwarden_rs docker is 81:80 (in docker run) and nginx reverse proxy uses http://127.0.0.1:81 and listens on port 80 and 443.
I would have to block port 80 and 443 without the CHAIN setting and if I want to block docker I would have to use it but block port 81 right?
Got it to work, but needed some time.
@M2Shawning commented on GitHub (Apr 27, 2019):
To add to this, in my experience I found that
EXTENDED_LOGGING=falseprevented the logs from being written to a file. Disabling extended logging was mentioned briefly in the "Logging" Wiki page but the "Fail2Ban" page never mentioned this circumstance.@dani-garcia commented on GitHub (Apr 27, 2019):
@jonathanmmm About the Fail2Ban documentation, yes adding instructions for the installation is probably a good idea. I don't know a lot about fail2ban, but my intuition is you only need the chain setting when using docker, not when running directly or through a proxy.
In that example you gave, yes you'd configure fail2ban on the ports 80 and 443, and you'd also need to make sure that port 81 is not accessible from the outside. I would recommend testing to check if it's actually banning properly just in case anyway.
@M2Shawning The log_file functionality requires the extended logging to be enabled yes, I documented it in the .env template which is probably the most up-to-date documentation about the available config options other than the code itself.
The wiki is mostly maintained by other users, and I would really appreciate if you both could update the respective wiki entries to fix any mistakes and add any extra information as you see fit.
@jonathanmmm commented on GitHub (May 1, 2019):
Can do end next week probably. Also the wiki for updating the server would be nice if it includes a guide to updating bitwarden as a service:
Would probably be Something like (havent tested yet)
Sudo systemctl stop bitwarden.service
Sudo docker rm bitwarden.service
Sudo docker pull mprasil/bitwarden:latest
Sudo systemctl restart bitwarden.service
(Restart or start, should be the same)
@jonathanmmm commented on GitHub (May 1, 2019):
Logging worked and fail2ban blocked also something but I believe it blocked port 80 and 443 for the container Traffic or something like that.
Without the chain setting it blocks the port 80 and 443 (in my case nginx reverse proxy) for the specific ip
@jonathanmmm commented on GitHub (May 3, 2019):
Added both, the update and the fail2ban instructions.
Extended logging is enabled by default, so should work.
Can somebody look at the changes and check them?
@dani-garcia commented on GitHub (May 3, 2019):
Looks good to me. Thanks, @jonathanmmm! I think this can be considered solved now.