Vaultwarden பாதுகாப்பானதா? முழுமையான பாதுகாப்பு வழிகாட்டி

Vaultwarden பாதுகாப்பானதா? சுருக்கமான பதில்

Vaultwarden மிக முக்கியமான இடத்தில் பாதுகாப்பாக உள்ளது. ஏனெனில், ஒவ்வொரு vault உருப்படியும் server-க்குச் செல்லும் முன்பே உங்கள் சாதனத்திலேயே குறியாக்கப்படுகிறது (encrypted). server-ஆல் படிக்க முடியாத தரவுத் தொகுப்புகளை (blobs) மட்டுமே அது சேமிக்கிறது. முழு database-ஐயும் நகலெடுப்பவர் கூட, அதிலிருந்து பயனுள்ள தகவலைப் பெற master password-ஐ வைத்திருக்க வேண்டும்.

இந்த பதில் பல விஷயங்களை உள்ளடக்கியது. நீங்கள் அமைக்கும் (configure) பகுதிகளில்தான் பாதுகாப்புச் சிக்கல்கள் ஏற்படுகின்றன. ஊகிக்கக்கூடிய token-க்கு பின்னால் இருக்கும் admin panel, இணையம் முழுமைக்கும் திறக்கப்பட்ட container port, plaintext config.json, அதே server-ல் home directory-ல் இருக்கும் backup tarball போன்றவை இதற்கு உதாரணம். இவை எதுவும் குறியாக்கவியல் (cryptography) தொடர்பான சிக்கல்கள் அல்ல. இவை அனைத்தும் self-hosted vaults திருடப்படுவதற்கான காரணங்களாகும்.

கீழே உள்ள அனைத்தும் ஏற்கனவே சரியாக நிறுவப்பட்ட ஒரு அமைப்பை அடிப்படையாகக் கொண்டவை. உங்களிடம் இன்னும் அத்தகைய அமைப்பு இல்லையென்றால், முதலில் VPS-க்கான Vaultwarden நிறுவல் வழிகாட்டி மூலம் அதை நிறுவிவிட்டு, பின்னர் இந்த வரிசைப்படி தொடரவும்.

server உண்மையில் எதைச் சேமிக்கிறது

Vaultwarden, Bitwarden-ன் தரவு மாதிரியை (data model) செயல்படுத்துகிறது. ஒரு vault item-ன் பெயர், username, password, notes மற்றும் URIs ஆகியவை, எந்தவொரு கோரிக்கையும் அனுப்பப்படுவதற்கு முன்பே, client-ல் உங்கள் master password-லிருந்து பெறப்பட்ட ஒரு key மூலம் குறியாக்கம் (encrypt) செய்யப்படுகின்றன. Attachment கோப்புகளின் உள்ளடக்கங்களும் அதே முறையில் குறியாக்கம் செய்யப்படுகின்றன. server, அதனுடன் இணைக்கப்பட்ட ஒரு UUID (universally unique identifier) கொண்ட தெளிவற்ற தரவை (opaque data) மட்டுமே பெறுகிறது.

சில தரவுகள் ciphertext அல்ல, அவை எவை என்பதை நீங்கள் துல்லியமாக அறிந்திருக்க வேண்டும்:

• உங்கள் கணக்கின் மின்னஞ்சல் முகவரி, இது plaintext-ஆக இருக்கும்.
• உங்கள் KDF (key derivation function) அமைப்புகள் மற்றும் salt, ஏனெனில் அடுத்த முறை login செய்யும்போது key-ஐ மீண்டும் உருவாக்க client-க்கு இவை தேவை.
• client அனுப்பும் master password hash-ன் server-side hash, இது login-ஐ அங்கீகரிக்கப் பயன்படுகிறது.
• Metadata: organisation membership, சாதனங்களின் பெயர்கள், கடைசி login நேரங்கள்.
• Vaultwarden login-ஐப் பாதுகாக்கும் two-factor முறைக்கான ரகசியம். இது twofactor அட்டவணையில் குறியாக்கம் செய்யப்படாமல் உள்ளது, ஏனெனில் நீங்கள் உள்ளிடும் குறியீட்டை ஒப்பிட்டுப் பார்க்க, எதிர்பார்க்கப்படும் குறியீட்டை server கணக்கிட வேண்டும். இது ஒரு vault item-க்குள் நீங்கள் சேமிக்கும் TOTP (time-based one-time password) ரகசியத்திலிருந்து வேறுபட்டது; அது மற்ற புலங்களைப் போலவே குறியாக்கம் செய்யப்படுகிறது.

தரவு கோப்புறை (data folder) சிறியது. Docker நிறுவலில், நீங்கள் /data-ல் எதை mount செய்தீர்களோ அதுவே அந்த கோப்புறை.

sudo ls -l /vw-data/

db.sqlite3 அனைத்து நிலைகளையும் (state) கொண்டுள்ளது. attachments/ பதிவேற்றப்பட்ட கோப்புகளை, ஒரு UUID-க்கு ஒன்று என்ற விகிதத்தில் கொண்டுள்ளது; database அட்டவணைகளில் இல்லாத மிக முக்கியமான தரவு வகை இது மட்டுமே. sends/ Send attachments-ஐக் கொண்டுள்ளது, இது தற்காலிகமானது. icon_cache/ நீக்கப்படக்கூடியது. rsa_key.pem மற்றும் அதன் துணை கோப்புகள், login செய்த பயனர்களின் JWT-களை (JSON web tokens) கையொப்பமிடுகின்றன; எனவே, அந்த private key-ன் நகலைப் பயன்படுத்தி ஒரு vault login session-ஐ போலியாக உருவாக்க முடியும். config.json நீங்கள் admin பக்கத்தை செயல்படுத்திய பிறகு மட்டுமே உருவாகும்; இதில் admin token மற்றும் உங்கள் SMTP நற்சான்றிதழ்கள் (credentials) plaintext-ஆக உள்ளன என்பது திட்டத்தின் வெளிப்படையான எச்சரிக்கை.

எனவே, நடைமுறை அச்சுறுத்தல் மாதிரி (threat model) என்பது network cryptography அல்ல, மாறாக filesystem அணுகல் ஆகும். அந்த ஒரு கோப்பகத்திற்கான (directory) வாசிப்பு அணுகல் (read access), ஒவ்வொரு பயனரின் மின்னஞ்சல் முகவரி, அவர்களின் login 2FA ரகசியங்கள், session-களை உருவாக்கும் key மற்றும் ஒவ்வொரு vault-ன் ஆஃப்லைன் நகல் ஆகியவற்றைத் திருட வழிவகுக்கும். கீழே உள்ள ஒவ்வொரு நடவடிக்கையும் அந்த கோப்பகத்திற்குள் மற்றவர்கள் நுழைவதைத் தடுப்பதற்காகவே உருவாக்கப்பட்டுள்ளது.

முதலில் admin token-ஐ சரிசெய்யவும்

/admin என்பது ஒரு முழுமையான கட்டுப்பாட்டுப் பலகம் (control panel): பயனர் பட்டியல், அழைப்புகள் (invitations), நீக்கம் மற்றும் அனைத்து runtime அமைப்புகளையும் இது கொண்டுள்ளது. இது ஒரே ஒரு பகிரப்பட்ட ரகசியத்தால் (shared secret) மட்டுமே பாதுகாக்கப்படுகிறது. இதில் username கிடையாது. ஒவ்வொரு பயனருக்கும் தனித்தனி two-factor authentication வசதியும் இல்லை.

பழைய வழிகாட்டிகள் ADMIN_TOKEN-ஐ openssl rand -base64 48 மூலம் உருவாக்கச் சொல்கின்றன. அது வேலை செய்யும், ஆனால் அது ரகசியத்தை plaintext வடிவில் config.json கோப்பிலும் உங்கள் compose கோப்பிலும் எழுதிவிடும். Vaultwarden, Argon2 PHC (password hashing competition) சரத்தையும் ஏற்கும் என்பதால், சேமிக்கப்படும் மதிப்பு hash வடிவில் இருக்கும். இயங்கிக்கொண்டிருக்கும் container-ல் ஒன்றை உருவாக்க:

docker exec -it vaultwarden /vaultwarden hash

அல்லது இயங்கும் container-ஐத் தொடாமல் உருவாக்க:

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

இது கடவுச்சொல்லை இருமுறை கேட்கும், பின்னர் $argon2id$ என்று தொடங்கும் ஒரு வரியை அச்சிடும். Bare-metal நிறுவலில், ./vaultwarden hash-ஐ இயக்கவும். நீங்கள் argon2 CLI-ஐ நேரடியாகப் பயன்படுத்த விரும்பினால், OWASP-ன் குறைந்தபட்ச அளவுருக்களைப் (minimum parameters) பயன்படுத்தவும்:

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

இப்போது பலரும் சிக்கிக்கொள்ளும் ஒரு பொதுவான தவறு. PHC சரத்தில் நிறைய $ குறியீடுகள் இருக்கும், Docker Compose $-ஐ variable interpolation-ஆகக் கருதும். இதை escape செய்யாமல் environment: தொகுப்பில் ஒட்டினால், container-க்குச் செல்லும் மதிப்பு சிதைந்துவிடும், அதனால் /admin நீங்கள் கொடுக்கும் சரியான token-ஐ நிராகரிக்கும். இரண்டு பாதுகாப்பான வழிகள் உள்ளன. docker-compose.yml-ல், ஒவ்வொரு $-ஐயும் இரண்டு முறை இடவும்:

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

ஒரு .env கோப்பில், escape செய்யத் தேவையில்லை, ஆனால் 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 பதிலளிக்காது. 20 நிமிடங்கள் எந்தச் செயல்பாடும் இல்லையெனில் admin session காலாவதியாகிவிடும்.

இதைவிடச் சிறந்த வழி: அந்தப் பக்கத்தை முடக்குவது. SMTP-ஐ உள்ளமைக்கவும் முதல் பயனர்களை அழைக்கவும் மட்டுமே பெரும்பாலான instances-க்கு இது தேவைப்படும், அதன் பிறகு தேவைப்படாது. இதை முடக்க, ADMIN_TOKEN அல்லது DISABLE_ADMIN_TOKEN எதையும் அமைக்க வேண்டாம், config.json-லிருந்து ஏதேனும் "admin_token" சாவியை நீக்கிவிட்டு, container-ஐ மீண்டும் உருவாக்கவும். கோப்பிலிருந்து சாவியை நீக்குவது முக்கியம், ஏனெனில் admin பக்கம் அமைப்புகளை அங்கேயே எழுதும், மேலும் config.json-ல் உள்ளதே இறுதியானது. variable-ஐ மட்டும் நீக்கினால், அந்தப் பக்கம் தொடர்ந்து திறந்தே இருக்கும்.

யாராவது domain-ஐக் கண்டறிவதற்கு முன்பே registration-ஐ மூடிவிடவும்

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED இயல்பாகவே true என அமைக்கப்பட்டிருக்கும். அதை அப்படியே விட்டால், உங்கள் domain-க்கு வரும் எவரும் கணக்கை உருவாக்க முடியும், மேலும் அவர்களின் தரவு உங்களுடைய அதே db.sqlite3-ல் சேமிக்கப்படும். அதை false என மாற்றி, admin பக்கத்திலிருந்து அழைப்பிதழ்கள் (invitations) மூலம் நபர்களைச் சேர்க்கவும்; இதற்குச் சரியாகச் செயல்படும் SMTP தேவை. INVITATIONS_ALLOWED என்பதும் இயல்பாகவே true என இருக்கும், இது நிறுவன உரிமையாளர்கள் மற்றவர்களை அழைக்க அனுமதிக்கிறது. நீங்கள் பயனர்களை முழுமையாக நம்பினால் இது சரி, ஆனால் ஒரே ஒரு பயனர் மட்டுமே உள்ள instance-ல் இது false என இருக்க வேண்டும். குறிப்பிட்ட domain-கள் மட்டுமே பதிவு செய்ய வேண்டும் என்றால், SIGNUPS_DOMAINS_WHITELIST=example.com என்பது பொதுவான பதிவை விடக் குறைவானது, ஆனால் அழைப்பிதழ் முறையை விடப் பாதுகாப்புக் குறைவானது.

SHOW_PASSWORD_HINT இயல்பாகவே false என இருக்கும், அதை அப்படியே வைத்திருக்க வேண்டும். இது செயல்பாட்டில் இருக்கும்போது, login பக்கத்தில் சரியான மின்னஞ்சல் முகவரியை உள்ளிட்டால், அந்தக் கணக்கின் master password குறிப்பு (hint) காட்டப்படும். இது குறிப்பை வெளிப்படுத்துவதுடன், அந்த மின்னஞ்சல் முகவரி பயன்பாட்டில் இருப்பதையும் உறுதிப்படுத்திவிடும்.

உங்கள் instance-ல் சிறிது காலம் பதிவு செய்யும் வசதி (signups) திறந்திருந்திருந்தால், நீங்கள் மட்டுமே பயனர் என்று கருதுவதற்கு முன், admin பக்கத்தைத் திறந்து பயனர் பட்டியலைச் சரிபார்க்கவும்.

நீங்கள் வெளியிட விரும்பாத port

Docker image, container-க்குள் port 80-ல் இயங்குகிறது. Bare-metal நிறுவல் இயல்பாக ROCKET_PORT=8000-ஐப் பயன்படுத்தும். ஆவணப்படுத்தப்பட்ட run கட்டளை அதை இவ்வாறு வெளியிடுகிறது:

--publish 127.0.0.1:8000:80

127.0.0.1: முன்னொட்டுதான் இதன் முக்கிய நோக்கமே. அதற்குப் பதிலாக -p 8000:80 என்று எழுதினால், Docker 0.0.0.0-ல் பிணைக்கப்படும் (bind). இது nat அட்டவணையில் DNAT (destination network address translation) விதிகளை எழுதுவதன் மூலம் நடக்கிறது. இந்த விதிகள் ufw நிர்வகிக்கும் filter சங்கிலிகளுக்கு முன்பே மதிப்பீடு செய்யப்படுகின்றன. எனவே, port இணையத்திற்குத் தடையின்றி பதிலளிக்கும்போதே, ufw status அந்த port மறுக்கப்பட்டதாகக் காட்டும். இதன் முழுமையான செயல்பாட்டை Docker ports ufw-ஐத் தவிர்க்கும் முறை குறித்த வழிகாட்டி-யில் வாசிப்பது பயனுள்ளது.

எது உண்மையில் listening நிலையில் உள்ளது என்பதைச் சரிபார்க்கவும்:

sudo ss -tlnp | grep 8000

சரியான முடிவு என்பது 127.0.0.1:8000-ல் பிணைக்கப்பட்ட ஒற்றை வரியாகும். 0.0.0.0:8000-ல் பிணைக்கப்பட்ட வரி இருந்தால், vault நேரடியாக வெளி உலகிற்குத் திறந்துவிடப்பட்டுள்ளது என்று பொருள். Mapping-ஐச் சரிசெய்துவிட்டு, container-ஐ மீண்டும் உருவாக்கவும். ஏனெனில், container உருவாக்கப்படும்போதே port binding நிர்ணயிக்கப்பட்டுவிடும், docker compose restart அதை மாற்றாது:

docker compose up -d --force-recreate

பழைய வழிகாட்டிகளில் இன்னும் ஒரு port உள்ளது: 3012, இது தனிப்பட்ட WebSocket port ஆகும். Vaultwarden 1.31.0 பதிப்பில் இதற்கான ஆதரவு நீக்கப்பட்டுவிட்டது, ஏனெனில் notification traffic பிரதான HTTP port-க்கு மாற்றப்பட்டது. WEBSOCKET_ENABLED மற்றும் WEBSOCKET_PORT ஆகியவை 1.29.0 பதிப்பிலிருந்து புறக்கணிக்கப்படுகின்றன. தற்போதைய switch ENABLE_WEBSOCKET ஆகும், இது இயல்பாக true-ஐக் கொண்டிருக்கும். உங்கள் firewall அல்லது compose கோப்பில் இன்னும் 3012 திறந்திருந்தால், அதை மூடிவிடவும்.

Rocket-ல் அல்லாமல், reverse proxy-ல் TLS-ஐ முடிவுக்குக் கொண்டுவருதல்

Vaultwarden தனது web framework-ஆன Rocket மூலம் TLS (transport layer security)-ஐ நேரடியாக வழங்க முடியும். ஆனால், production சூழலில் அவ்வாறு செய்ய வேண்டாம் என்று இந்தத் திட்டம் அறிவுறுத்துகிறது. Rocket-ன் உள்ளமைக்கப்பட்ட TLS-ல் முறையான SNI (server name indication) ஆதரவு இல்லை. இதனால்தான், உங்கள் instance-ஐ எப்போதும் hostname மூலமாகவே அணுக வேண்டும், IP முகவரி மூலம் அணுகக்கூடாது என்று பாதுகாப்பு ஆலோசனைகள் வழங்கப்படுகின்றன. பொது IP முகவரிகள் தொடர்ந்து ஸ்கேன் செய்யப்படுகின்றன; IP முகவரியில் பதிலளிக்கும் ஒரு 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 1 MB ஆக உள்ளது. எனவே, அந்த வரி இல்லையென்றால், attachment upload தோல்வியடையும் மற்றும் nginx error log-ல் 413 Request Entity Too Large என்று காட்டும், ஆனால் Vaultwarden logs-ல் எந்தத் தகவலும் இருக்காது. Upgrade மற்றும் Connection headers-கள் WebSocket handshake-ஐ /notifications/hub-க்குக் கொண்டு செல்கின்றன. இவற்றை நீக்கினால், vault வேலை செய்யும், ஆனால் நீங்கள் பக்கத்தை கைமுறையாக reload செய்யும் வரை மற்ற சாதனங்களில் மாற்றங்கள் தெரியாது.

Caddy சுருக்கமானது மற்றும் அதுவே 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 என உள்ளது. எனவே, proxy அந்த header-ஐ சரியாக அமைப்பதை உறுதி செய்வது உங்கள் வேலை. இல்லையென்றால், ஒவ்வொரு log வரியும் மற்றும் login rate limit-ம் proxy-ன் முகவரியான 127.0.0.1-ஐயே காட்டும். இதனால், ஒரு தாக்குதல் நடத்துபவரின் தோல்விகள் அந்த instance-ல் உள்ள அனைத்து பயனர்களின் கணக்கிலும் சேர்க்கப்படும். DOMAIN-ஐ உண்மையான https URL-க்கு அமைக்கவும், ஏனெனில் Vaultwarden அழைப்பிதழ் மற்றும் கடவுச்சொல் மாற்றும் இணைப்புகளை இதிலிருந்தே உருவாக்குகிறது, மேலும் WebAuthn security keys அந்த origin-உடன் பிணைக்கப்பட்டுள்ளன.

மக்கள் கவனிக்கத் தவறும் ஒரு விவரம்: WebSocket இணைப்பு session token-ஐ /notifications/hub?access_token=[JWT] என்ற query string-ஆக அனுப்புகிறது. இது உங்கள் proxy access log-ல் தெளிவாகத் தெரியும். log format-ல் access_token parameter-ஐ மறைக்கவும் (redact), அல்லது அந்த logs உங்கள் கட்டுப்பாட்டில் இல்லாத இடங்களுக்கு அனுப்பப்படாமல் இருப்பதை உறுதி செய்யவும்.

Login endpoint-ல் brute force தாக்குதலைத் தடுத்தல்

Rate limits இயல்பாகவே செயல்பாட்டில் உள்ளன (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). இவை தாக்குதல் நடத்துபவரின் வேகத்தைக் குறைக்கும். ஆனால், அவை தாக்குதலை முழுமையாகத் தடுப்பதில்லை. fail2ban இதற்கு உதவும், ஆனால் Vaultwarden முதலில் ஒரு log file-ஐ எழுத வேண்டும். இது இயல்பாகவே அமைக்கப்பட்டிருக்காது:

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

ஒருமுறை login தோல்வியடைந்தால், சரியாக ஒரு வரி பதிவாகும். உங்கள் 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 login தோல்விகள் வேறு ஒரு செய்தியாகப் பதிவாகும், அதை login filter கண்டறியாது. பின்னர் உங்கள் பணியைச் சரிபார்க்கவும்:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

சரியாகச் செயல்படும் jail, உங்கள் log file-ஐ File list-ன் கீழ் பட்டியலிடும் மற்றும் Currently failed: 0-ஐத் தெரிவிக்கும். வேறொரு network-லிருந்து தவறான password-ஐ மூன்று முறை உள்ளிடவும். அப்போது counter உயரும், பின்னர் அந்த IP முகவரி Banned IP list-ன் கீழ் தோன்றும். counter உயரவில்லை என்றால், அதற்கு வழக்கமான காரணம் logpath ஆகும்: இது container-க்குள் இருக்கும் /data/... path ஆக இருக்கக்கூடாது, host-ல் உள்ள file-ன் path ஆக இருக்க வேண்டும். இரண்டாவது பொதுவான காரணம் X-Real-IP விடுபட்டிருப்பது; இது அனைத்து ban-களையும் உங்கள் proxy-யையே குறிவைக்கச் செய்யும். நீங்கள் ஏற்கனவே இயக்கி வரும் SSH jail உட்பட, மீதமுள்ள அமைப்புகள் Ubuntu 24.04-க்கான fail2ban வழிகாட்டியில் உள்ளன.

Master password-தான் முழு அமைப்பின் பாதுகாப்பு

Client-side encryption என்பதால், master password-தான் முதன்மையான திறவுகோலாகச் செயல்படுகிறது. ஒரு attacker database-ஐ நகலெடுத்துவிட்டால், குறுகிய நீளம் கொண்ட master password-ஆல் எந்தப் பாதுகாப்பும் கிடைக்காது. ஏனெனில், attacker தனது சொந்த வன்பொருளைப் பயன்படுத்தி, அந்த நகலை offline-ல் மிக வேகமாகத் தாக்க முடியும். Server-ல் செய்யப்படும் எந்த மாற்றமும் attacker-ன் கணினியைப் பாதிக்காது.

PASSWORD_ITERATIONS=600000 என்பது புதிய கணக்குகளை உருவாக்கும்போது client-களுக்கு வழங்கப்படும் KDF iteration count ஆகும். ஏற்கனவே உள்ள கணக்குகள் அவை உருவாக்கப்பட்டபோது இருந்த மதிப்பையே வைத்திருக்கும். எனவே, இந்த மதிப்பை அதிகரிப்பதால் கடந்த ஆண்டு கணக்கு தொடங்கிய பயனர்களுக்கு எந்த மாற்றமும் ஏற்படாது. அவர்கள் தங்கள் web vault security settings-க்குச் சென்று, தாங்களாகவே இதை மாற்ற வேண்டும்; அப்போதுதான் அவர்களின் திறவுகோல் மீண்டும் encrypt செய்யப்படும். இடைமுகத்தில் (interface) இதற்கான அறிவிப்பு வராது என்பதால், பயனர்களுக்கு இதைத் தெரிவிக்க வேண்டும்.

அடுத்து, ஒவ்வொரு கணக்கிற்கும் two-factor authentication-ஐ இயக்கவும். இது ciphertext-ஐப் பாதுகாக்காது, ஏனெனில் vault key என்பது master password-ஐ மட்டுமே சார்ந்தது. இருப்பினும், திருடப்பட்ட password-ஐ மட்டும் வைத்துக்கொண்டு ஒரு பயனர் உள்நுழைவதையும், தரவுகளை sync செய்வதையும் இது தடுக்கும். REQUIRE_DEVICE_EMAIL=true, ஒரு கணக்கு அங்கீகரிக்கப்படாத சாதனத்திலிருந்து முதல்முறை உள்நுழையும்போது, மின்னஞ்சல் உறுதிப்படுத்தல் (email confirmation) படியைச் சேர்க்கிறது.

Backups-ல் தான் self-hosted vaults தவறுதலாக கையாளப்படுகின்றன

ஒரே VPS-ல் உள்ள home directory-ல் விடப்படும் data folder-ன் ஒரு tar czf, மேலே சொன்ன அனைத்து பாதுகாப்பு நடவடிக்கைகளையும் பயனற்றதாக்கிவிடும். அந்த archive-ல் ஒவ்வொரு பயனரின் ciphertext-உம் உள்ள db.sqlite3, login sessions-ஐ உருவாக்க உதவும் rsa_key.pem, மற்றும் admin token, SMTP password ஆகியவற்றை plaintext-ல் கொண்ட config.json ஆகியவை இருக்கும். அந்த ஒரு கோப்பை அணுக முடிந்தால், vault-ஐயும் முழுமையாக அணுக முடியும்.

இதற்கு இரண்டு விதிகள் உள்ளன. Archive-ஐ அந்த server-லிருந்து வெளியேற்றவும். வெளியேற்றும் முன்பே அதை encrypt செய்யவும்.

இதில் துல்லியம் சார்ந்த ஒரு சிக்கலும் உள்ளது. Service இயங்கிக்கொண்டிருக்கும்போது cp மூலம் db.sqlite3-ஐ நகலெடுப்பது, முழுமையற்ற கோப்பை உருவாக்கலாம்; அது திறக்கப்படாது. இதை restore செய்ய முயலும்போதுதான் நீங்கள் அறிவீர்கள். அதற்கு பதிலாக SQLite-ன் சொந்த snapshot வசதியைப் பயன்படுத்தவும்:

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

Restore செய்யும் முறை, அதாவது யாரும் சோதித்துப் பார்க்காத அந்த பாதியை, Vaultwarden backup and restore guide-ல் காணலாம்.

Hosted Bitwarden-க்கு மாற்றாக நீங்கள் எவற்றை இழக்கிறீர்கள்

நேர்மையான கணக்கீடு. Bitwarden-ன் hosted service-ஐ, அதை முழுநேரப் பணியாகக் கொண்ட நிபுணர்கள் இயக்குகிறார்கள். இதற்கு அங்கீகரிக்கப்பட்ட மூன்றாம் தரப்பு தணிக்கைகள் (audits) உள்ளன, மேலும் அதிகாலை 3 மணிக்கும் ஏதேனும் சிக்கல் ஏற்பட்டால் கவனிக்க ஆட்கள் உள்ளனர். Self-hosting முறையில், இந்த பொறுப்பு உங்கள் வசம் வருகிறது; நீங்களே patch-களை உடனுக்குடன் நிறுவ வேண்டும்.

Vaultwarden பாதுகாப்புத் திருத்தங்களை சாதாரண releases-ஆக வெளியிடுகிறது. 24 July 2026 அன்று வெளியான Version 1.37.0, August 2026 நிலவரப்படி தற்போதைய பதிப்பாகும். இதைப் பதிவிறக்கியவுடன் உடனடியாக update செய்யுமாறு அதன் குறிப்புகள் பயனர்களைக் கேட்டுக்கொள்கின்றன. ஒரு வருடம் முன்பு நீங்கள் அமைத்துவிட்டு மறந்துபோன ஒரு instance, ஒரு வருடம் பழமையான code-ஐயே இயக்கும். latest tag மட்டும் இதற்கு உதவாது: நீங்கள் docker compose pull கட்டளையை இயக்கி container-ஐ மீண்டும் உருவாக்கும் வரை, இயங்கிக்கொண்டிருக்கும் container அது தொடங்கப்பட்ட அதே image-ஐயே வைத்திருக்கும். Host packages-க்காக Ubuntu-வில் unattended upgrades வசதியைச் செயல்படுத்தவும், container update-ஐ நீங்கள் தவறாமல் பார்க்கும் ஒரு calendar reminder-ல் குறித்து வைக்கவும்.

ஒரு நேர்மையான வாசகர் இதிலிருந்து புரிந்துகொள்ள வேண்டியது: இங்குள்ள cryptography என்பது Bitwarden-ன் வடிவமைப்பு, அது பாதுகாப்பானது; ஆனால் செயல்பாட்டு அபாயங்கள் (operational risk) முழுமையாக உங்கள் வசம் வருகின்றன. நீங்கள் அதைத் தொடர்ந்து patch செய்து, வேறொரு இடத்தில் backup எடுத்தால், உங்கள் கட்டுப்பாட்டில் உள்ள VPS-ல் Vaultwarden instance-ஐ வைத்திருப்பது கடவுச்சொற்களைப் பாதுகாக்க ஒரு நியாயமான வழியாகும். இந்த இரண்டு பழக்கங்களும் உங்களால் சாத்தியமில்லை என்றால், hosted service-க்கு பணம் செலுத்திவிட்டு, உங்கள் கவனத்தை மற்ற பணிகளில் செலுத்தலாம். அம்சங்களின் ஒப்பீடு Vaultwarden மற்றும் self-hosted Bitwarden ஒப்பீடு பகுதியில் உள்ளது.

Container-க்கு அடியில் உள்ள host-ஐ பலப்படுத்துதல்

Vaultwarden என்பது Linux machine-ல் இயங்கும் ஒரு process ஆகும். application எவ்வாறு கட்டமைக்கப்பட்டிருந்தாலும், அந்த machine-ன் root பயனர் /vw-data-ஐ வாசிக்க முடியும். எனவே, உங்கள் compose file-ல் user: "1000:1000"-ஐப் பயன்படுத்தி, container-ஐ privileged அல்லாத பயனராக இயக்கவும். இதற்கேற்ப data folder-ன் உரிமையாளரை மாற்றவும். மேலும், container எதையும் எழுதாத கோப்புகளை :ro மூலம் read-only முறையில் mount செய்யவும். இறுதியாக, பிரதான நுழைவாயிலை மூடவும்: VPS-ல் SSH-ஐ பலப்படுத்துதல் என்ற பகுதி, key-only login மற்றும் password authentication-ஐ முடக்குவது பற்றி விளக்குகிறது. மேலே குறிப்பிட்ட அனைத்து பாதுகாப்பு நடவடிக்கைகளையும் மீறி வரும் சாதாரண தாக்குதல்களைத் தடுக்க இதுவே சிறந்த வழியாகும்.

FAQ

Vaultwarden database திருடப்பட்டால், எனது கடவுச்சொற்களை யாராவது படிக்க முடியுமா?

நேரடியாக முடியாது. ஒவ்வொரு vault உருப்படியும் master password-லிருந்து பெறப்பட்ட ஒரு key மூலம் client-லேயே குறியாக்கம் (encrypt) செய்யப்படுகிறது, எனவே db.sqlite3-ல் ciphertext மட்டுமே இருக்கும். அவர்கள் உடனடியாகப் பெறுவது ஒவ்வொரு கணக்கின் மின்னஞ்சல் முகவரி, KDF அமைப்புகள், login மற்றும் device metadata, மற்றும் twofactor அட்டவணையில் உள்ள two-factor secrets மட்டுமே. இவை குறியாக்கம் செய்யப்படாமல் சேமிக்கப்படுகின்றன, ஏனெனில் server சரியான குறியீட்டை (code) கணக்கிட வேண்டியது அவசியம். அவர்கள் vault ciphertext-ஐ ஆஃப்லைனில் எவ்வளவு காலம் வேண்டுமானாலும் தாக்க முயற்சி செய்யலாம், இதனால்தான் master password-ன் நீளம் பாதுகாப்பைத் தீர்மானிக்கும் முக்கிய காரணியாகிறது.

நான் ADMIN_TOKEN-ஐப் பயன்படுத்த வேண்டுமா அல்லது admin பக்கத்தை முழுமையாக முடக்க வேண்டுமா?

முடிந்தால் அதை முடக்கிவிடுங்கள், ஏனெனில் பெரும்பாலான instances-க்கு SMTP-ஐ உள்ளமைக்கவும் பயனர்களை அழைக்கவும் ஒருமுறை மட்டுமே இது தேவைப்படும். இதை முடக்க, ADMIN_TOKEN அல்லது DISABLE_ADMIN_TOKEN ஆகியவற்றை அமைக்க வேண்டாம், config.json-லிருந்து ஏதேனும் "admin_token" key இருந்தால் அதை நீக்கிவிட்டு, container-ஐ மீண்டும் உருவாக்கவும். environment variable-ஐ மட்டும் நீக்குவது போதாது, ஏனெனில் admin பக்கத்தால் எழுதப்பட்ட அமைப்புகள் config.json-ல் இருக்கும் மற்றும் அவை முன்னுரிமை பெறும். நீங்கள் அந்தப் பக்கத்தை வைத்திருந்தால், token-ஐ plain text-ஆக வைக்காமல் vaultwarden hash மூலம் உருவாக்கப்பட்ட Argon2 hash-ஆகச் சேமிக்கவும், மேலும் ADMIN_RATELIMIT_MAX_BURST=3-ஐ அமைக்கவும்.

எனது ADMIN_TOKEN சரியாக உள்ளது, ஆனால் /admin அதை நிராகரிக்கிறது. என்ன தவறு?

இது பெரும்பாலும் $ interpolation காரணமாகவே நிகழ்கிறது. ஒரு Argon2 PHC string பல $ எழுத்துக்களைக் கொண்டிருக்கும், Docker Compose அவற்றை docker-compose.yml environment: தொகுதிக்குள் variables-ஆக விரிவுபடுத்தும். இதனால் உங்கள் கோப்பு சரியாகத் தெரிந்தாலும், container சிதைந்த மதிப்பையே பெறும். compose கோப்பில் உள்ள ஒவ்வொரு $-ஐயும் $$ என இரட்டிப்பாக்கவும், அல்லது அந்த மதிப்பை ஒற்றை மேற்கோள்களுக்குள் (single quotes) ஒரு .env கோப்பில் வைக்கவும், அங்கு escape செய்ய வேண்டிய அவசியம் இருக்காது. container-ஐ மீண்டும் உருவாக்கவும், ஏனெனில் restart செய்வதன் மூலம் environment மாற்றங்கள் நடைமுறைக்கு வராது.

அறிவிப்புகளுக்கு (notifications) நான் இன்னும் port 3012-ஐத் திறக்க வேண்டுமா?

இல்லை. Vaultwarden 1.31.0 பதிப்பில் port 3012-ல் WebSocket traffic-க்கான ஆதரவு நீக்கப்பட்டுவிட்டது, ஏனெனில் அறிவிப்புகள் பிரதான HTTP port-க்கு மாற்றப்பட்டுவிட்டன. WEBSOCKET_ENABLED மற்றும் WEBSOCKET_PORT ஆகியவை 1.29.0 பதிப்பிலிருந்து புறக்கணிக்கப்படுகின்றன. தற்போதைய அமைப்பு ENABLE_WEBSOCKET ஆகும், இது இயல்பாகவே true என இருக்கும். firewall-ல் 3012-ஐ மூடிவிட்டு, உங்கள் compose கோப்பிலிருந்து அதை நீக்கவும். உங்கள் reverse proxy Upgrade மற்றும் Connection headers-ஐ forward செய்வதை உறுதிப்படுத்தவும், ஏனெனில் நிகழ்நேர ஒத்திசைவு (real-time sync) இப்போது இதையே சார்ந்துள்ளது.