Bitwarden RS or Full

riff-raff · 5. Juli 2020

Keeping all my passowords in mind bothers me quite a while, so in the process of merging OMV4->OMV5 and all native services into docker I discovered the quite charming tool bitwarden.

After a short research if figured out that many users use the bitwardenrs/server container. On the other hand there are the official containers, which separate each service part.

I use letsencrypt with reverse proxy and nextcloud (subdomain-configuration) and I might need to integrate bitwarden in the existing setup. As far as I know, the installer script of bitwarden installs a separate letsencrypt-container which I already have. So I guess I need to configurate my letsencrypt to match both services, bitwaren and nextcloud with nextcloud.domain.com and bitwarden.domain.com and therefore I can't use the installer script.

I lack the documentation (environment, ports, volumes, etc) of each of the required bitwarden containers and their connection.

Can someone show me a direction or where to start?

Is the usage of official containers the best way for me or should I stick to the RS?

macom · 6. Juli 2020

The bitwardenrs container has over 10M (or even over 50M) pulls. Can't be that bad.

Zitat

perfect for self-hosted deployment where running the official resource-heavy service might not be ideal.

riff-raff · 6. Juli 2020

The bitwardenrs is my alternative. I got the official setup running in a VM right now and have a look on reverse proxy configuration, environments, volumes etc.

My goal would be to set it up with official and create a little HowTo.

davidh2k · 9. Juli 2020

The bitwardenrs image is a single container for everything. Bitwarden itself needs like 5 containers to run. Go with the rs container, if you want to go the easier route. If you want to switch, keep in mind that the data volumes are incompatible and you need to export and import again in the new one.

Quoting the github page for bitwardenrs:

Zitat

This is a Bitwarden server API implementation written in Rust compatible with upstream Bitwarden clients*, perfect for self-hosted deployment where running the official resource-heavy service might not be ideal.

Reverse proxy (traefik2.0):

Code

      - traefik.http.routers.bwrsweb.entrypoints=websecure
      - traefik.http.routers.bwrsweb.rule=Host(`subdomain.domain.tld`)
      - traefik.http.routers.bwrsweb.tls=true
      - traefik.http.routers.bwrsweb.tls.certresolver=le
      - traefik.http.routers.bwrsweb.service=bwrsweb

      - traefik.http.services.bwrsweb.loadbalancer.server.port=80

      - traefik.http.routers.bwrshub.entrypoints=websecure
      - traefik.http.routers.bwrshub.rule=(Host(`subdomain.domain.tld`) && Path(`/notifications/hub`))
      - traefik.http.routers.bwrshub.tls=true
      - traefik.http.routers.bwrshub.tls.certresolver=le
      - traefik.http.routers.bwrshub.service=bwrshub

      - traefik.http.services.bwrshub.loadbalancer.server.port=3012

Alles anzeigen

You gotta take care of your "certresolver" name, if you were to use that config.

Reverse proxy (traefik1.7):

Code

#      - traefik.web.frontend.rule=Host:subdomain.domain.tld
#      - traefik.web.port=80
#      - traefik.hub.frontend.rule=Host:subdomain.domain.tld;Path:/notifications/hub
#      - traefik.hub.port=3012

Greetings

David

sabamimi · 11. Juli 2020

BitwardenRS is also my choice.

(I use HAPROXY for SSL and proxy front end for all my apps reachable from outside)

If you go for BitwardenRS, you may also consider:

"bruceforce/bw_backup:latest"

It will do backups (you can configure frequency and number of revisions) of the BitwardenRS database

Cheers

Morlan · 11. Juli 2020

I also use bitwardenrs with the letsencrypt container. Works very well and has very good documentation

riff-raff · 11. Juli 2020

Does the BitwardenRS-Server work with the payed features, like multiple user? As far as I cound figure out, even with self -hosting, a Bitwarden-Account is still needed and with more than one user, a little allowance to be due.

Morlan · 12. Juli 2020

It seems to me that bitwardenrs offers the payed features for free

riff-raff · 12. Juli 2020

But how do you login with your clients? Setting server address is obvious, but login email and master password is still required.

sabamimi · 12. Juli 2020

Zitat von riff-raff

Does the BitwardenRS-Server work with the payed features, like multiple user? As far as I cound figure out, even with self -hosting, a Bitwarden-Account is still needed and with more than one user, a little allowance to be due.

BitwardenRS "offers" shared entries
(very useful to me )

sabamimi · 12. Juli 2020

Zitat von riff-raff

But how do you login with your clients? Setting server address is obvious, but login email and master password is still required.

If I understand correctly your question, the answer is that user's emails / passwords definitions are done on your server using a BitwardenRS admin menu

riff-raff · 12. Juli 2020

Ah, awesome! Thanks. Makes sense.

Morlan: How does your reverse proxy configuration with letsencrypt look like? Did you stick to the sample provided with the letsencrypt-container?

Code

# make sure that your dns has a cname set for bitwarden and that your bitwarden container is not using a base url
# make sure your bitwarden container is named "bitwarden"

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name bitwarden.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 128M;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    # enable for Authelia
    #include /config/nginx/authelia-server.conf;

    location / {
        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /ldaplogin;

        # enable for Authelia
        #include /config/nginx/authelia-location.conf;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app bitwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

    location /notifications/hub {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app bitwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
    }

    location /notifications/hub/negotiate {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app bitwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

}

Alles anzeigen

EDIT: WORKS!

Code

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name bitwarden.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    location / {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app bitwardenrs;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_max_temp_file_size 128m;
    }
}

Alles anzeigen

Morlan · 12. Juli 2020

If I remember correctly I edited some details according to the samples of the GitHub wiki. My bitwarden.subdomain.conf looks like this.

Code

# make sure that your dns has a cname set for bitwarden and that your bitwarden container is not using a base url
# make sure your bitwarden container is named "bitwarden"

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name bitwarden.*;

    include /config/nginx/ssl.conf;
    client_max_body_size 128M;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /login;

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app bitwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

    }

    location /notifications/hub {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app bitwarden;
        set $upstream_port 3012;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
    }

    location /notifications/hub/negotiate {
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app bitwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
    location /admin {
        # See: https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/
        #auth_basic "Private";
        #auth_basic_user_file /path/to/htpasswd_file;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app bitwarden;
        set $upstream_port 80;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}

Alles anzeigen

riff-raff · 18. Juli 2020

Do you have fail2ban of your letsenctypt container (I assume its the one from LS.IO?) configured?

Morlan · 18. Juli 2020

Zitat von riff-raff

(I assume its the one from LS.IO?)

Yes, I did not change it above the default values.

riff-raff · 18. Juli 2020

My bitwarden works like a charm, I enabled admin page and cancled registration, but exposing it gives me some worries due to possible brute force attempts. Having fail2ban would be a nice security pillow. Might be a good thing to set up on a rainy Sunday

Morlan · 18. Juli 2020

I was intrigued by your comment and set up fail2ban with bitwarden. Will post the steps later

Morlan · 18. Juli 2020

Fail2Ban is integrated in the Linuxserver.io letsencrypt docker. Therefore the log file of Bitwarden needs to be accessible by the letsencrypt docker.

First of all enable logging of the Bitwarden container by adding these lines in docker-compose:

Code

    environment:
      LOG_FILE: 'log/bitwarden.log'
      LOG_LEVEL: 'warn'
      EXTENDED_LOGGING: 'true'
      TZ: 'Europe/Berlin'

Then bind mount the bitwarden log folder to the letsencrypt log folder:

Code

    volumes:
      - /srv/dev-disk-by-label-data/appdata/letsencrypt/log/bitwarden:/log

I was not sure if Bitwarden would create the log file so created it manually touch /srv/dev-disk-by-label-data/appdata/letsencrypt/log/bitwarden/bitwarden.log

Then I recreated the Bitwarden container with docker-compose up -d. I checked that logging worked by entering a wrong password on my Bitwarden Login Page.

Code: bitwarden.log

[2020-07-18 22:26:39][error][ERROR] Username or password is incorrect. Try again. IP: ********. Username: ******.

Now setting up Fail2Ban. Again the wiki of the Bitwarden_rs project was very helpful https://github.com/dani-garcia…en_rs/wiki/Fail2Ban-Setup .

I created the two files bitwarden.local and bitwarden-admin.local in /srv/dev-disk-by-label-data/appdata/letsencrypt/fail2ban/filter.d with following contents:

Bash: bitwarden.local

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Code: bitwarden-admin.local

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*Invalid admin token\. IP: <ADDR>.*$
ignoreregex =

and then added the following lines in /srv/dev-disk-by-label-data/appdata/letsencrypt/fail2ban/jail.local

Code: jail.local

[bitwarden]

enabled = true
port = http,https
filter = bitwarden
logpath = /config/log/bitwarden/bitwarden.log

[bitwarden-admin]

enabled = true
port = http,https
filter = bitwarden-admin
logpath = /config/log/bitwarden/bitwarden.log

Alles anzeigen

After that docker restart letsencrypt. Then I simulated another failed login attempt and checked /srv/dev-disk-by-label-data/appdata/letsencrypt/log/fail2ban/fail2ban.log:

Code

2020-07-18 22:26:39,101 fail2ban.filter         [371]: INFO    [bitwarden] Found ******** - 2020-07-18 22:26:39

I also simulated 5 failed login attempts and the resulting ban worked, too. To unban my IP: docker exec -it letsencrypt fail2ban-client set bitwarden unbanip <IP>

perfect for self-hosted deployment where running the official resource-heavy service might not be ideal.

This is a Bitwarden server API implementation written in Rust compatible with upstream Bitwarden clients*, perfect for self-hosted deployment where running the official resource-heavy service might not be ideal.

Jetzt mitmachen!