SSD Nodes Learn 🎉 VPS $5.50/నెల నుండి
మార్గదర్శకాలు Matt Connorద్వారా Matt Connor · అప్‌డేట్ చేయబడింది 2026-08-13

Vaultwarden సురక్షితమేనా? Hardening చెక్‌లిస్ట్

Vaultwarden vault అంశాలను client లోనే encrypt చేస్తుంది; server కు plaintext కనిపించదు. నిజమైన ప్రమాదాలు admin token మరియు backup file, వాటిని ఎలా harden చేయాలో తెలుసుకోండి.

Vaultwarden సురక్షితమేనా? సంక్షిప్త సమాధానం

అత్యంత ముఖ్యమైన స్థాయిలో Vaultwarden సురక్షితంగా ఉంటుంది. ప్రతి vault అంశం server కు చేరకముందే మీ device లోనే encrypt అవుతుంది. Server చదవలేని blobs ను మాత్రమే నిల్వ చేస్తుంది. ఎవరో మొత్తం database ను కాపీ చేసినా, దానిలోని ఉపయోగకరమైన సమాచారాన్ని పొందడానికి వారికి master password అవసరం.

ఈ సమాధానంలో అనేక అంశాలు ఉన్నాయి. వాటిలో సమస్యలు ఏర్పడేది మీరు configure చేసే భాగాల్లోనే. ఊహించగలిగే token తో రక్షించిన admin panel. మొత్తం internet కు publish చేసిన container port. Plaintext config.json. అదే box లోని home directory లో ఉంచిన backup tarball. ఇవేవీ cryptography సమస్యలు కావు. Self-hosted vaults ఖాళీ కావడానికి ఇవన్నీ కారణాలు.

క్రిందివన్నీ పనిచేస్తున్న install ఉందని భావిస్తాయి. మీ వద్ద ఇంకా install లేకపోతే, ముందుగా VPS కోసం Vaultwarden install guide ఉపయోగించి దాన్ని setup చేయండి. తరువాత ఈ జాబితాను క్రమంలో అనుసరించండి.

సర్వర్ వాస్తవంగా ఏమి నిల్వ చేస్తుంది

Vaultwarden, Bitwarden యొక్క డేటా మోడల్‌ను అమలు చేస్తుంది. Vault item పేరు, username, password, notes మరియు URIs ను మీ master password నుంచి ఉత్పన్నమైన key తో, ఏదైనా request పంపకముందే client లో encrypt చేస్తుంది. Attachment file contents కూడా ఇదే విధంగా encrypt అవుతాయి. Server కు UUID (universally unique identifier) జతచేయబడిన అర్థరహిత డేటా మాత్రమే అందుతుంది.

కొన్ని అంశాలు ciphertext కావు. అవి ఏవో ఖచ్చితంగా తెలుసుకోవాలి:

  • మీ account email address, plaintext రూపంలో.
  • మీ KDF (key derivation function) settings మరియు salt. తదుపరి login సమయంలో key ను మళ్లీ నిర్మించడానికి client కు అవి అవసరం.
  • Client పంపే master password hash యొక్క server-side hash. Login ను authenticate చేయడానికి ఇది ఉపయోగించబడుతుంది.
  • Metadata: organisation membership, device names, last login times.
  • Vaultwarden login ను రక్షించే two-factor method యొక్క secret. ఇది twofactor table లో unencrypted గా ఉంటుంది, ఎందుకంటే మీ code తో పోల్చడానికి server ఊహించిన code ను లెక్కించాలి. ఇది vault item లో మీరు నిల్వ చేసే TOTP (time-based one-time password) secret కు సమానం కాదు. ఆ secret ఇతర field లాగే encrypted గా ఉంటుంది.

Data folder చిన్నదిగా ఉంటుంది. Docker install లో, మీరు /data వద్ద mount చేసినదే ఆ folder.

sudo ls -l /vw-data/

db.sqlite3 లో దాదాపు మొత్తం state ఉంటుంది. attachments/ లో UUID కు ఒక్క file చొప్పున uploaded files ఉంటాయి. Database tables లో నిల్వ కాని ముఖ్యమైన data తరగతి ఇదొక్కటే. sends/ లో Send attachments ఉంటాయి. అవి తాత్కాలికంగా ఉండేలా ఉద్దేశించబడ్డాయి. icon_cache/ తాత్కాలిక data మాత్రమే. Login చేసిన users యొక్క JWTs (JSON web tokens) కు rsa_key.pem మరియు దానికి సంబంధించిన files signing చేస్తాయి. అందువల్ల ఆ private key యొక్క copy తో vault login session ను నకిలీగా సృష్టించవచ్చు. Admin page ను enable చేసిన తర్వాత మాత్రమే config.json ఏర్పడుతుంది. ఈ విషయం గురించి project స్పష్టంగా చెబుతుంది: ఇందులో admin token మరియు మీ SMTP credentials plaintext రూపంలో ఉంటాయి.

అందువల్ల ప్రాయోగిక threat model network cryptography కాదు; filesystem access. ఆ ఒక్క directory కు read access లభిస్తే, ప్రతి user యొక్క email address, వారి login 2FA secrets, sessions ను నకిలీగా సృష్టించగల key, అలాగే సమయం తీసుకుని దాడి చేయడానికి ప్రతి vault యొక్క offline copy దొరుకుతాయి. దిగువన ఉన్న ప్రతి చర్య, ఆ directory లోకి ఇతరులు ప్రవేశించకుండా నిరోధించడానికే ఉంది.

ముందుగా admin token ను సరిచేయండి

/admin అనేది పూర్తి control panel: user list, invitations, deletion, ప్రతి runtime setting ఇందులో ఉంటాయి. ఇది ఒకే shared secret ద్వారా మాత్రమే రక్షించబడుతుంది. Username లేదు. ప్రతి user కు వేర్వేరు two-factor లేదు.

పాత guides లో openssl rand -base64 48 తో ADMIN_TOKEN ను generate చేయమని చెబుతారు. అది పనిచేస్తుంది. అయితే secret ను plaintext రూపంలో config.json లో, అలాగే మీ compose file లో కూడా రాస్తుంది. Vaultwarden Argon2 PHC (password hashing competition) string ను కూడా అంగీకరిస్తుంది. అందువల్ల నిల్వ చేసే విలువకు బదులుగా hash ఉంటుంది. నడుస్తున్న container కు వ్యతిరేకంగా ఒకదాన్ని generate చేయండి:

docker exec -it vaultwarden /vaultwarden hash

లేదా నడుస్తున్న container ను అసలు తాకకుండానే:

docker run --rm -it vaultwarden/server /vaultwarden hash

ఇది password ను రెండుసార్లు అడుగుతుంది. తరువాత $argon2id$ తో ప్రారంభమయ్యే ఒక line ను చూపిస్తుంది. Bare-metal install లో ./vaultwarden hash ను అమలు చేయండి. argon2 CLI ను నేరుగా ఉపయోగించాలనుకుంటే, project OWASP కనిష్ఠ parameters ను ఇలా document చేస్తుంది:

echo -n 'MySecretPassword' | argon2 "$(openssl rand -base64 32)" -e -id -k 19456 -t 2 -p 1

ఇప్పుడు ఒక గంట సమయం వృథా చేసే సమస్యను చూడండి. PHC string లో అనేక $ characters ఉంటాయి. Docker Compose $ ను variable interpolation గా పరిగణిస్తుంది. దాన్ని escape చేయకుండా environment: block లో paste చేస్తే, container కు చేరే విలువ మారిపోతుంది. అందువల్ల సరైనదని మీకు తెలిసిన token ను కూడా /admin తిరస్కరిస్తుంది. సురక్షితమైన రెండు విధానాలు ఉన్నాయి. docker-compose.yml లో ప్రతి $ ను రెండుసార్లు రాయండి:

environment:
  ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$UUZxK1FZMkZoRHFQRlVrTXZvS0E3bHpNQW55c2dBN2NORzdsa0Nxd1JhND0$$cUoId+JBUsJutlG4rfDZayExfjq4TCt48aBc9qsc3UI

.env file లో escaping అవసరం లేదు. అయితే single quotes ఉపయోగించండి:

ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$MmeKRnGK5RW5mJS7h3TOL89GrpLPXJPAtTK8FTqj9HM$DqsstvoSAETl9YhnsXbf43WeaUwJC6JhViIvuPoig78'

తరువాత panel కు rate limit అమలు చేసి, దాని session వ్యవధిని తగ్గించండి:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

ఐదు నిమిషాల్లో మూడు తప్పు ప్రయత్నాలు జరిగితే, ఆ client కు panel స్పందించడం ఆపేస్తుంది. ఎలాంటి activity లేకపోతే admin session 20 minutes తరువాత ముగుస్తుంది.

ఇవన్నింటికన్నా మెరుగైనది: ఆ page ను పూర్తిగా ఆపివేయండి. చాలా instances లో SMTP ను configure చేసి, మొదటి users ను invite చేయడానికి మాత్రమే అది ఒక్కసారి అవసరం. ఆ తరువాత మళ్లీ అవసరం ఉండదు. దాన్ని disable చేయడానికి ADMIN_TOKEN లేదా DISABLE_ADMIN_TOKEN ఏదీ set చేయకండి. config.json నుండి ఏదైనా "admin_token" key ను తొలగించండి. తరువాత container ను మళ్లీ create చేయండి. File నుండి key ను తొలగించడం ముఖ్యమైనది. కారణం, admin page settings ను అక్కడ రాస్తుంది. config.json లో ఉన్న విలువ environment పై ప్రాధాన్యత కలిగి ఉంటుంది. Variable ను మాత్రమే తొలగిస్తే page తెరిచే ఉంటుంది.

ఎవరైనా ఆ domain ను కనుగొనేలోపు registration ను మూసివేయండి

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED డిఫాల్ట్‌గా true గా ఉంటుంది. దాన్ని అలాగే ఉంచితే, మీ domain ను చేరుకోగల ఎవరైనా account సృష్టించగలరు. వారి data కూడా మీ data ఉన్న అదే db.sqlite3 లో నిల్వ అవుతుంది. దీన్ని false గా సెట్ చేసి, admin page లోని invitations ద్వారా వ్యక్తులను చేర్చండి. దీనికి పనిచేసే SMTP అవసరం. INVITATIONS_ALLOWED కూడా డిఫాల్ట్‌గా true గా ఉంటుంది. ఇది organisation owners ఇతరులను ఆహ్వానించడానికి అనుమతిస్తుంది. మీరు మీ users ను విశ్వసించినప్పుడు ఇది సరైనదే. అయితే single-user instance లో ఇది false గా ఉండాలి. కొన్ని domains మాత్రమే ఎప్పుడైనా registration చేయగలగాలని కోరుకుంటే, SIGNUPS_DOMAINS_WHITELIST=example.com open signup కంటే పరిమితమైనది. అయితే invitations కంటే ఇది చాలా బలహీనమైన నియంత్రణ.

SHOW_PASSWORD_HINT డిఫాల్ట్‌గా false గా ఉంటుంది. దీన్ని అలాగే ఉంచాలి. ఇది enable అయి ఉంటే, login form లో చెల్లుబాటు అయ్యే email address ను నమోదు చేసినప్పుడు ఆ account కు సంబంధించిన master password hint తిరిగి వస్తుంది. దీని వల్ల hint బయటపడటమే కాకుండా, ఆ address ఉనికిలో ఉందని కూడా నిర్ధారించవచ్చు.

మీ instance కొంతకాలమైనా open signups తో నడిచినట్లయితే, మీరు మాత్రమే account కలిగి ఉన్నారని అనుకోకముందు admin page ను తెరిచి user list ను పరిశీలించండి.

మీరు publish చేయాలని ఉద్దేశించని port

Docker image container లో port 80 పై listen చేస్తుంది. Bare-metal install డిఫాల్ట్‌గా ROCKET_PORT=8000 ను ఉపయోగిస్తుంది. Documentation లోని run command దాన్ని ఇలా publish చేస్తుంది:

--publish 127.0.0.1:8000:80

127.0.0.1: prefix నే మొత్తం ఉద్దేశ్యం. దాని బదులుగా -p 8000:80 అని రాస్తే, Docker 0.0.0.0 ను bind చేస్తుంది. ఇందుకోసం అది nat table లో DNAT (destination network address translation) rules రాస్తుంది. ఈ rules ను ufw నిర్వహించే filter chains కంటే ముందుగా evaluate చేస్తారు. అందువల్ల ufw status ఆ port ను denied గా చూపించినా, ఆ port internet నుంచి వచ్చే అభ్యర్థనలకు స్పందిస్తూనే ఉంటుంది. ఈ పూర్తి విధానం గురించి ufw ను దాటిపోయే Docker ports పై guide లో చదవవచ్చు.

వాస్తవంగా ఏది listening చేస్తుందో పరిశీలించండి:

sudo ss -tlnp | grep 8000

సరైన ఫలితంలో 127.0.0.1:8000 కు bound అయిన ఒకే line ఉంటుంది. 0.0.0.0:8000 కు bound అయిన line ఉంటే vault నేరుగా బయటకు expose అయిందని అర్థం. Mapping ను సరిచేసి container ను మళ్లీ create చేయండి. ఎందుకంటే port binding container create చేసినప్పుడు స్థిరపడుతుంది; docker compose restart దాన్ని మార్చదు:

docker compose up -d --force-recreate

పాత guides లో ఇంకా కనిపించే మరో port ఉంది: 3012, ఇది ప్రత్యేక WebSocket port. Vaultwarden 1.31.0 లో దీనికి support తొలగించారు, ఎందుకంటే notification traffic ప్రధాన HTTP port పైకి మార్చబడింది. WEBSOCKET_ENABLED మరియు WEBSOCKET_PORT ను 1.29.0 నుంచి పరిగణనలోకి తీసుకోవడం లేదు. ప్రస్తుత switch ENABLE_WEBSOCKET; దీని default విలువ true. మీ firewall లేదా compose file ఇంకా 3012 ను open చేస్తుంటే, దాన్ని close చేయండి.

Reverse proxy వద్ద TLS ను terminate చేయండి, Rocket లో కాదు

Vaultwarden తన web framework అయిన Rocket ద్వారా స్వయంగా TLS (transport layer security) అందించగలదు. అయితే production లో అలా చేయవద్దని project సూచిస్తుంది. Rocket లోని built-in TLS కు strict SNI (server name indication) మద్దతు లేదు. అందుకే hardening సూచనల్లో instance ను hostname ద్వారా మాత్రమే చేరుకోవాలని, bare IP address ద్వారా ఎప్పుడూ చేరుకోకూడదని చెబుతారు. Public IP ranges ను నిరంతరం scan చేస్తుంటారు. IP address పై స్పందించే vault గుర్తించబడుతుంది.

nginx server block లో ముఖ్యమైన భాగాలు:

client_max_body_size 525M;

location / {
  proxy_pass http://127.0.0.1:8000;
  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;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
}

nginx లో client_max_body_size default విలువ 1 MB. కాబట్టి ఆ line లేకపోతే attachment upload విఫలమవుతుంది. nginx error log లో 413 Request Entity Too Large కనిపిస్తుంది. Vaultwarden log లో మాత్రం ఏమీ కనిపించదు. Upgrade మరియు Connection headers WebSocket handshake ను /notifications/hub కు పంపిస్తాయి. వాటిని తొలగించినా vault పనిచేస్తుంది. అయితే మీరు page ను చేతితో reload చేసే వరకు ఇతర devices లో మార్పులు కనిపించవు.

Caddy configuration చిన్నదిగా ఉంటుంది. Certificate ను అది స్వయంగా పొందుతుంది:

vw.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

తర్వాత Vaultwarden కు దాని గురించి తెలియజేయండి:

DOMAIN=https://vw.example.com
IP_HEADER=X-Real-IP

IP_HEADER కు ఇప్పటికే X-Real-IP default గా ఉంటుంది. కాబట్టి proxy ఆ header ను నిజంగా set చేస్తుందో లేదో నిర్ధారించాలి. అది set చేయకపోతే, ప్రతి log line మరియు ప్రతి login rate limit కు 127.0.0.1, అంటే proxy స్వయంగా client గా కనిపిస్తుంది. దాంతో ఒక attacker చేసిన failures instance లోని ప్రతి user పై లెక్కించబడతాయి. DOMAIN ను నిజమైన https URL కు కూడా set చేయండి. Vaultwarden invitation మరియు password reset links ను దాని ఆధారంగా నిర్మిస్తుంది. WebAuthn security keys కూడా ఆ origin కు bind అవుతాయి.

చాలామంది గమనించని ఒక విషయం ఉంది. WebSocket connection session token ను query string లో /notifications/hub?access_token=[JWT] రూపంలో పంపుతుంది. అది మీ proxy access log లో స్పష్టమైన రూపంలో నమోదవుతుంది. Log format లో access_token parameter ను redact చేయండి. లేదా ఆ logs మీ నియంత్రణలో లేని ఏ ప్రదేశానికీ పంపబడకుండా చూసుకోండి.

లాగిన్ endpoint పై brute-force దాడులను నిరోధించండి

Rate limits డిఫాల్ట్‌గా enabled గా ఉంటాయి (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). అవి దాడి చేసేవారి వేగాన్ని తగ్గిస్తాయి. కానీ ఒక్క దాడి చేసేవారిని పూర్తిగా ఆపవు. fail2ban అలా చేస్తుంది. అయితే ముందుగా Vaultwarden ఒక log file లోకి రాయాలి. ఇది out of the box గా జరగదు:

LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=info
EXTENDED_LOGGING=true

విఫలమైన login తర్వాత ఖచ్చితంగా ఒక line వస్తుంది. మీ filter సరిపోల్చాల్సిన string ఇదే:

[2026-08-07 09:14:22][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 203.0.113.10. Username: user@example.com.

ఈ filter ను /etc/fail2ban/filter.d/vaultwarden.local లో రాయండి:

[INCLUDES]
before = common.conf

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

jail ను /etc/fail2ban/jail.d/vaultwarden.local లో రాయండి:

[vaultwarden]
enabled = true
port = 80,443
filter = vaultwarden
banaction = %(banaction_allports)s
logpath = /vw-data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400

మీరు admin page ను ఉంచితే, failregex విలువ ^.*Invalid admin token\. IP: <ADDR>.*$ గా ఉండే రెండవ jail ను జోడించండి. Admin వైఫల్యాలు వేరే message తో log అవుతాయి. అందువల్ల login filter వాటిని ఎప్పటికీ గుర్తించదు. తరువాత మీ పని సరిగా ఉందో పరిశీలించండి:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

సరిగా పనిచేస్తున్న jail తన log file ను File list కింద చూపిస్తుంది. అలాగే Currently failed: 0 ను report చేస్తుంది. వేరే network నుంచి మూడు సార్లు తప్పు password ఇవ్వండి. అప్పుడు ఆ counter పెరుగుతుంది. తరువాత ఆ address Banned IP list కింద కనిపిస్తుంది. Counter ఎప్పటికీ పెరగకపోతే సాధారణ కారణం logpath. ఇందులో container లోని /data/... path కాకుండా host పై ఉన్న file path ఉండాలి. రెండవ సాధారణ కారణం X-Real-IP లేకపోవడం. దాంతో ప్రతి ban మీ స్వంత proxy ను target చేస్తుంది. మీరు ఇప్పటికే నడుపుతూ ఉండాల్సిన SSH jail తో సహా మిగతా setup మొత్తం Ubuntu 24.04 కోసం fail2ban guide లో ఉంది.

మాస్టర్ పాస్‌వర్డ్ ఇప్పటికీ మొత్తం వ్యవస్థకు కీలకం

Client-side encryption లో master password నే key గా ఉపయోగిస్తారు. దాని database ను attacker కాపీ చేసిన instance లో చిన్న master password ఉంటే, ఈ పోస్ట్‌లోని ఏ అంశమూ దానికి రక్షణ ఇవ్వదు. Attacker తన hardware అనుమతించే వేగంతో ఆ కాపీపై offline దాడి చేయగలడు. Attacker స్వంత machine పై ఏ server setting కూడా ప్రభావం చూపదు.

కొత్త account సృష్టించే సమయంలో clients కు అందించే KDF iteration count PASSWORD_ITERATIONS=600000. Existing accounts సృష్టించినప్పుడు ఉన్న విలువనే కొనసాగిస్తాయి. అందువల్ల గత సంవత్సరం signup చేసిన users కోసం దాన్ని పెంచడం వల్ల ఎలాంటి మార్పు ఉండదు. వారు web vault security settings లో స్వయంగా దాన్ని మార్చాలి. అలా చేస్తే వారి key మళ్లీ encrypt అవుతుంది. ఈ విషయం వారికి తప్పనిసరిగా చెప్పాలి, ఎందుకంటే interface లో ఎక్కడా దీనికి సూచన ఉండదు.

తరువాత ప్రతి account కు two-factor authentication enable చేయండి. ఇది ciphertext ను రక్షించదు, ఎందుకంటే vault key పూర్తిగా master password నుంచే వస్తుంది. అయితే దొంగిలించిన password తో login చేసి ఒక కాపీని sync చేయడం ఒక్కటే సరిపోకుండా ఇది నిరోధిస్తుంది. గుర్తించని device నుంచి account మొదటిసారి login అయినప్పుడు REQUIRE_DEVICE_EMAIL=true email confirmation దశను జోడిస్తుంది.

స్వయంగా హోస్ట్ చేసిన vaultలు బ్యాకప్‌ల విషయంలో విఫలమయ్యే అవకాశం ఉంది

అదే VPSలోని home directoryలో ఉంచిన data folder యొక్క tar czf, పై చేసిన ప్రతి చర్యను వృథా చేస్తుంది. ఆ archiveలో ప్రతి వినియోగదారుడి ciphertext ఉన్న db.sqlite3, login sessionsను నకిలీగా సృష్టించగల rsa_key.pem, అలాగే admin token మరియు SMTP passwordలను plaintextలో కలిగి ఉన్న config.json ఉంటాయి. ఆ ఒక్క fileకు read access ఉంటే vaultకు కూడా read access ఉన్నట్టే.

రెండు నియమాలు దీనిని నియంత్రిస్తాయి. Archiveను ఆ server వెలుపల ఉంచండి. అది serverను విడిచే ముందు encrypt చేయండి.

సరైనతకు సంబంధించిన మరో సమస్య కూడా ఉంది. సేవ నడుస్తున్నప్పుడు cpతో db.sqlite3ను copy చేస్తే, మధ్యలో write జరుగుతున్న file ఏర్పడవచ్చు. అది open కాకపోవచ్చు. Restore చేసే వరకు ఈ విషయం మీకు తెలియకపోవచ్చు. బదులుగా SQLite స్వంత snapshotను ఉపయోగించండి:

sqlite3 /vw-data/db.sqlite3 ".backup '/tmp/vw-db-backup.sqlite3'"

ఎవరూ పరీక్షించని భాగమైన restore విధానం Vaultwarden backup మరియు restore guideలో వివరించబడింది.

హోస్ట్ చేసిన Bitwarden తో పోలిస్తే మీరు వదులుకునేది

నిజాయితీగా పరిశీలిస్తే, Bitwarden హోస్ట్ చేసిన సేవను దాన్ని నిర్వహించడమే పూర్తి-కాల పని అయిన సిబ్బంది నిర్వహిస్తారు. ప్రచురితమైన మూడవ పక్ష ఆడిట్‌లు ఉంటాయి. తెల్లవారుజామున 3 గంటలకు కూడా స్పందించడానికి ఒకరు on-call లో ఉంటారు. Self-hosting లో ఈ సౌకర్యాల స్థానంలో మీ స్వంత patch cadence వస్తుంది.

Vaultwarden భద్రతా పరిష్కారాలను సాధారణ releases రూపంలో విడుదల చేస్తుంది. 24 July 2026న విడుదలైన Version 1.37.0, August 2026 నాటికి ప్రస్తుత వెర్షన్. దాని release notes వినియోగదారులు వీలైనంత త్వరగా update చేయాలని సూచిస్తున్నాయి. మీరు ఒక సంవత్సరం క్రితం setup చేసి మర్చిపోయిన instance, ఒక సంవత్సరం పాత code ను నడుపుతూ ఉంటుంది. latest tag ఒక్కటే దీనికి పరిష్కారం కాదు: మీరు docker compose pull అమలు చేసి container ను recreate చేసే వరకు, నడుస్తున్న container ప్రారంభమైనప్పుడు ఉపయోగించిన image నే కొనసాగిస్తుంది. Host packages కోసం Ubuntuలో unattended upgrades అమలు చేయండి. Container update కోసం మీరు నిజంగా చూసే calendar reminder ను ఏర్పాటు చేయండి.

నిజాయితీగా పరిశీలించే పాఠకుడు తీసుకోవాల్సిన నిర్ణయం ఇదే: ఇక్కడి cryptography Bitwarden రూపకల్పనపై ఆధారపడి ఉంటుంది, అది సమర్థంగా ఉంది. అయితే operational risk మొత్తం మీపైనే ఉంటుంది. మీరు దీనికి patches అమలు చేసి, వేరే చోట backup ఉంచితే, మీరు నియంత్రించే VPSలోని Vaultwarden instance మీ passwords ఉంచడానికి సమంజసమైన ప్రదేశం. ఈ రెండు అలవాట్లు అమలు చేయలేకపోతే, hosted service కోసం చెల్లించి, మీ సమయాన్ని వేరే పనికి కేటాయించండి. Feature-by-feature పోలికను self-hosted Bitwardenతో Vaultwarden పోలిక లో చూడండి.

కంటైనర్ కింద ఉన్న host ను భద్రపరచండి

Vaultwarden అనేది Linux బాక్స్‌పై నడిచే ఒక process. ఆ బాక్స్‌లోని root, అప్లికేషన్‌లో ఏ configuration ఉన్నా /vw-data ను చదవగలదు. మీ compose file లో user: "1000:1000" ఉపయోగించి కంటైనర్‌ను unprivileged user గా నడపండి. Data folder ownership ను కూడా దానికి సరిపోయేలా సెట్ చేయండి. కంటైనర్ రాయాల్సిన అవసరం లేని ప్రతి దానిని :ro తో read-only గా mount చేయండి. తరువాత ప్రధాన ప్రవేశ మార్గాన్ని భద్రపరచండి: VPS పై SSH భద్రతను బలోపేతం చేయడంలో key-only login ను అమలు చేయడం, password authentication ను నిలిపివేయడం గురించి వివరించబడింది. ఇవే పై రక్షణలను దాటి జరిగే సాధారణ దాడులను అడ్డుకుంటాయి.

FAQ

నా passwords ను ఎవరైనా Vaultwarden database దొంగిలించి చదవగలరా?

నేరుగా చదవలేరు. ప్రతి vault item client లో master password నుంచి రూపొందించిన key తో encrypt చేయబడుతుంది. అందువల్ల db.sqlite3 లో ciphertext మాత్రమే ఉంటుంది. వెంటనే వారికి ప్రతి account యొక్క email address, KDF settings, login మరియు device metadata, అలాగే twofactor table లోని two-factor secrets లభిస్తాయి. Server expected code ను లెక్కించాల్సి ఉండటంతో ఇవి unencrypted గా నిల్వ చేయబడతాయి. వారు vault ciphertext పై offline attack ను తమకు కావలసినంతకాలం కొనసాగించగలరు. అందుకే ఫలితాన్ని నిర్ణయించేది master password length.

ADMIN_TOKEN ఉపయోగించాలా, లేక admin page ను పూర్తిగా disable చేయాలా?

సాధ్యమైతే దాన్ని disable చేయండి. చాలా instances కు SMTP configure చేయడానికి మరియు users ను invite చేయడానికి అది ఒకసారి మాత్రమే అవసరం అవుతుంది. ఆ తర్వాత సాధారణంగా అవసరం ఉండదు. దాన్ని disable చేయడానికి ADMIN_TOKEN లేదా DISABLE_ADMIN_TOKEN ఏదీ set చేయవద్దు. config.json నుంచి ఏదైనా "admin_token" key ను తొలగించండి. తరువాత container ను recreate చేయండి. Environment variable ను మాత్రమే తొలగించడం సరిపోదు. Admin page ద్వారా రాసిన settings config.json లో ఉంటాయి మరియు వాటికే ప్రాధాన్యం ఉంటుంది. Page ను కొనసాగిస్తే token ను plaintext random string గా కాకుండా vaultwarden hash ద్వారా రూపొందించిన Argon2 hash గా నిల్వ చేయండి. అలాగే ADMIN_RATELIMIT_MAX_BURST=3 ను set చేయండి.

నా ADMIN_TOKEN సరైనదే, కానీ /admin దాన్ని తిరస్కరిస్తోంది. సమస్య ఏమిటి?

దాదాపు ఎల్లప్పుడూ కారణం $ interpolation. Argon2 PHC string లో అనేక $ characters ఉంటాయి. Docker Compose వాటిని docker-compose.yml environment: block లో variables గా expand చేస్తుంది. అందువల్ల మీ file సరైనదిగా కనిపించినా container కు మారిన value అందుతుంది. Compose file లో ప్రతి $ ను $$ గా double చేయండి. లేదా value ను single quotes తో చుట్టిన .env file లోకి మార్చండి. అక్కడ escaping అవసరం ఉండదు. ఆ తర్వాత container ను recreate చేయండి. Restart చేసినప్పుడు environment changes వర్తించవు.

Notifications కోసం ఇంకా port 3012 తెరవాలా?

వద్దు. Vaultwarden 1.31.0 లో port 3012 పై WebSocket traffic కు support తొలగించబడింది. Notifications ఇప్పుడు ప్రధాన HTTP port పైకి మార్చబడ్డాయి. అలాగే WEBSOCKET_ENABLED మరియు WEBSOCKET_PORT ను 1.29.0 నుంచి పట్టించుకోవడం లేదు. ప్రస్తుత setting ENABLE_WEBSOCKET. దీని default విలువ true. Firewall లో 3012 ను close చేయండి. మీ compose file నుంచి కూడా దాన్ని తొలగించండి. తరువాత reverse proxy, Upgrade మరియు Connection headers ను forward చేసేలా నిర్ధారించండి. ప్రస్తుతం real-time sync దానిపైనే ఆధారపడి ఉంటుంది.

#vaultwarden#security#self-hosting#passwords#hardening