První hodina na novém VDS: kontrolní seznam nastavení

Čerstvé VDS je stroj s přístupem root, veřejnou adresou a bez jakýchkoli názorů. Během pár minut po jeho spuštění na port 22 začnou automatické skenery zkoušet hesla a všechno, co s ním uděláš dál, počítá se základem, který je záplatovaný, má uživatele, který není root, a odpovídá jen na portech, které sis vybral. Ten základ zabere asi dvacet minut. Hodina v titulku je tam proto, že máš číst, co píšeš, a protože uspěchání téhle části je způsob, jak lidé za čtrnáct dní stroj znovu stavějí.

Pořadí níže je důležité. Aktualizace jdou před konfiguraci, protože balíčky, které se chystáš konfigurovat, jsou právě ty, které se nahrazují. Uživatel jde před uzamčení SSH, protože zamknout roota dřív, než máš jiný vstup, je klasický způsob, jak o server přijít hned první den. Firewall přichází po SSH, protože pravidlo výchozího zákazu bez výjimky pro port 22 ukončí relaci i celý rozhovor.

Příkazy jsou pro Debian a Ubuntu, což je většina obrazů VDS. V systémech rodiny RHEL nahraď apt příkazem dnf, sudo skupinou wheel a ufw službou firewalld; princip se nemění.

První přihlášení a co zkontrolovat#

Dostal jsi adresu a buď heslo roota, nebo klíč. Přihlas se a přečti si otisk v dotazu, nepiš yes reflexivně - je to jediná šance potvrdit, že mluvíš se svým strojem. Porovnej ho s otiskem v konzoli svého poskytovatele, pokud ho zveřejňuje.

$ ssh root@203.0.113.10The authenticity of host '203.0.113.10' can't be established.ED25519 key fingerprint is SHA256:5xM8n...Are you sure you want to continue connecting (yes/no/[fingerprint])?

Pak stráv dvě minuty zjišťováním, co vlastně máš. Vyplatí se to dřív, než cokoli nainstaluješ, protože je to jediná chvíle, kdy je stroj ve známém stavu:

$ cat /etc/os-release          # distribution and version$ uname -r                     # kernel$ lscpu | head -20             # cores, model, virtualisation flags$ free -h                      # memory, and whether swap exists$ df -h /                      # disk, and how much the image used$ ip -brief address            # addresses, v4 and v6$ ss -ltnp                     # what is already listening$ systemd-detect-virt          # kvm, lxc, none

Nejzajímavější je ss -ltnp. Čistý obraz obvykle ukazuje jen sshd a někdy klienta DHCP nebo mail transfer agenta poslouchajícího na localhostu. Cokoli dalšího, co poslouchá na 0.0.0.0, jsi nechtěl a měl bys to prověřit. systemd-detect-virt říká, jestli jsi na plné virtualizaci, nebo sdílíš jádro, což rozhoduje, zda jsou některé pozdější kroky vůbec možné - VPS, VDS, nebo dedikovaný server vysvětluje, proč na tom rozdílu záleží víc než na marketingu.

Pokud heslo roota přišlo e-mailem, ber ho jako už veřejné a během následujících dvaceti minut počítej s úplným vypnutím přihlašování heslem. To je čtvrtý krok.

Aktualizuj všechno a restartuj#

Obraz je snímek z doby, kdy vznikl, což může být před několika měsíci. Před čímkoli jiným:

$ apt update$ apt full-upgrade -y$ apt autoremove --purge -y

full-upgrade místo upgrade, protože upgrade odmítá odebírat balíčky, a proto tiše přeskakuje aktualizace, které vyžadují změnu závislostí. Na čerstvém obrazu je tím rozdílem obvykle jádro.

Potom zkontroluj, zda je potřeba restart, a udělej ho hned, ne v nevhodnou chvíli později:

$ [ -f /var/run/reboot-required ] && cat /var/run/reboot-required$ reboot

Aktualizace jádra nic nedělá, dokud se stroj nerestartuje do nového. Zbrusu nové VDS, na kterém nic neběží, je nejlevnější restart, jaký kdy podstoupíš, tak ho udělej. Přihlas se znovu a pomocí uname -r potvrď, že se verze změnila.

Uživatel, který není root#

Celodenní práce jako root znamená, že každý překlep se provede s plnou mocí a každý proces, který spustíš, ji zdědí. Vytvoř běžný účet, který může eskalovat vědomě:

$ adduser deploy$ usermod -aG sudo deploy

adduser je interaktivní obálka Debianu: vytvoří domovský adresář, nastaví shell a zeptá se na heslo. Dej mu skutečné heslo, i když se chceš přihlašovat klíči, protože sudo si o ně řekne.

Teď tomuto uživateli dej svůj klíč SSH. Nejjednodušší spolehlivý způsob, pokud už má root nainstalovaný tvůj klíč, je zkopírovat celý adresář a opravit vlastnictví jedním krokem:

$ rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy/$ chmod 700 /home/deploy/.ssh$ chmod 600 /home/deploy/.ssh/authorized_keys

Ta oprávnění nejsou dekorace. sshd odmítne použít soubor authorized_keys, do kterého může zapisovat kdokoli kromě vlastníka, a z pohledu klienta to udělá tiše, což vyvolá záhadu „pořád se ptá na heslo“.

Otevři druhý terminál a otestuj to, než změníš cokoli dalšího:

$ ssh deploy@203.0.113.10$ sudo -v

Nech tu druhou relaci otevřenou po zbytek tohoto článku. Pokud změna konfigurace rozbije přihlašování, zachrání tě relace, kterou už máš.

Klíče SSH a zavření hlavních dveří#

Pokud ještě nemáš pár klíčů, vytvoř ho na svém vlastním stroji, ne na serveru:

$ ssh-keygen -t ed25519 -C "deploy@laptop"$ ssh-copy-id deploy@203.0.113.10

Použij ed25519. Je menší a rychlejší než RSA a podporuje ho každá implementace SSH z poslední dekády. Soukromý klíč zabezpeč passphrase a nech svého agenta, ať ho po pracovní den drží odemčený.

Pak vypni dvě věci, kvůli kterým se dá server uhodnout. V moderním Debianu a Ubuntu začíná /etc/ssh/sshd_config řádkem Include /etc/ssh/sshd_config.d/*.conf a tenhle detail chytí skoro každého: sshd použije první hodnotu, kterou pro klíčové slovo získá, takže cokoli v tom adresáři má přednost před hlavním souborem pod ním. Cloudové obrazy tam často dodávají soubor, který přihlašování heslem znovu zapíná.

$ ls -la /etc/ssh/sshd_config.d/$ grep -r PasswordAuthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

Napiš vlastní soubor pojmenovaný tak, aby se řadil před cokoli, co tam už je:

PermitRootLogin noPasswordAuthentication noKbdInteractiveAuthentication noPubkeyAuthentication yesAuthenticationMethods publickeyMaxAuthTries 3LoginGraceTime 20AllowUsers deploy

Před restartem zkontroluj syntaxi, protože vadný konfigurační soubor znamená, že se sshd nevrátí:

$ sshd -t && systemctl restart ssh

Teď z třetího terminálu dokaž, že nové přihlášení stále funguje a že přihlášení heslem je odmítnuto. Teprve potom zavři relaci roota.

Klíče SSH a zabezpečení pokrývá zbytek pořádně: agenty, jump hosty, omezení pro jednotlivé klíče a co dělat, když se přece jen vyzamkneš.

Firewall: výchozí zákaz#

Příchozí provoz ve výchozím stavu zakázat, odchozí povolit, potom otevřít přesně to, co potřebuješ. V Ubuntu je to ufw a na pořadí příkazů nesmírně záleží:

$ ufw default deny incoming$ ufw default allow outgoing$ ufw allow OpenSSH$ ufw enable$ ufw status numbered

ufw allow OpenSSH před ufw enable, pokaždé. Zapnutí politiky výchozího zákazu bez pravidla pro SSH tě okamžitě odpojí a jediná cesta zpět vede přes konzoli poskytovatele. ufw tě varuje a na varování se snadno proklikne.

Potom služby, které skutečně budeš provozovat:

$ ufw allow 80/tcp$ ufw allow 443/tcp$ ufw allow 27015:27020/udp      # a range for game servers$ ufw allow from 10.0.0.0/24 to any port 5432 proto tcp

Ta poslední forma je ta, kterou se vyplatí naučit. Databáze, endpoint metrik nebo administrační panel by měly být dosažitelné z pojmenovaných adres, ne odevšud. Pravidla firewallu, na kterých záleží obsahují úvahy za tím a průvodce ufw syntaxi v plné šíři.

Jedna past: Docker publikuje porty zápisem vlastních pravidel iptables a ta pravidla ufw úplně obcházejí. Kontejner spuštěný s -p 5432:5432 je otevřený do internetu i při úhledně vypadajícím ufw status. Buď naváž publikování na localhost pomocí -p 127.0.0.1:5432:5432, nebo přidej svá pravidla do řetězce DOCKER-USER. Docker na VDS to popisuje v souvislostech.

Čas, název stroje a drobná nastavení#

Špatné hodiny dávají špatné logy, neúspěšné TLS handshaky a prošlé tokeny a jsou neviditelné, dokud nejsou.

$ timedatectl set-timezone Etc/UTC$ timedatectl set-ntp true$ timedatectl

Na serverech používej UTC. Jednou budeš korelovat log z tohoto stroje s logem z jiného a ta verze úlohy, kde je už všechno v UTC, je ta příjemná.

Dej stroji jméno, které něco znamená, zvlášť pokud bude existovat druhý:

$ hostnamectl set-hostname web-01

Přidej to jméno do /etc/hosts vedle 127.0.1.1, jinak sudo při každém příkazu na vteřinu zaváhá, zatímco se pokouší přeložit název hostitele a selhává.

Ještě dvě drobnosti, které stojí za to udělat, když už tu jsi. Nastav locale (update-locale LANG=en_GB.UTF-8), aby skriptované nástroje přestaly vypisovat varování o locale, a omez žurnál, aby logy nemohly zaplnit disk:

[Journal]SystemMaxUse=500MSystemMaxFileSize=50M

Plný kořenový souborový systém položí server stejně účinně jako cokoli, co by mohl udělat útočník, a neomezený žurnál u upovídané služby je nejčastější příčinou. Logy, které stojí za uchování popisuje, co ponechat.

Automatické bezpečnostní aktualizace#

Server, který nikdo neaktualizuje, je server, do kterého se dřív nebo později někdo vloupá. Automatické bezpečnostní aktualizace jsou nejhodnotnějších dvacet vteřin na tomto seznamu.

$ apt install unattended-upgrades$ dpkg-reconfigure --priority=low unattended-upgrades

Tím se zapíše /etc/apt/apt.conf.d/20auto-upgrades. Potom otevři /etc/apt/apt.conf.d/50unattended-upgrades a rozhodni dvě věci: zda se stroj smí sám restartovat a kdy.

Unattended-Upgrade::Automatic-Reboot "true";Unattended-Upgrade::Automatic-Reboot-WithUsers "false";Unattended-Upgrade::Automatic-Reboot-Time "04:00";Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

Automatické restarty jsou správné pro webový server a špatné pro herní server, na kterém jsou ve čtyři ráno lidé. Pokud je vypneš, převzal jsi úkol restartovat po aktualizacích jádra sám a ke kontrole slouží /var/run/reboot-required. Ověř, že celé to funguje, místo abys to předpokládal:

$ unattended-upgrade --dry-run --debug$ cat /var/log/unattended-upgrades/unattended-upgrades.log

Ve výchozím stavu se používají jen bezpečnostní aktualizace, což je správný rozsah. Rozšíření na všechny aktualizace na produkčním stroji vymění malé riziko zneužití za větší riziko, že se balíček změní, zatímco spíš.

Swap a strop paměti#

Většina malých obrazů VDS se dodává úplně bez swapu. Bez něj se špička paměti nezpomalí, ale něco zabije: OOM killer v jádře vybere největší proces, což je obvykle přesně to, kvůli čemu server provozuješ.

Skromný swapový soubor je pojistka, ne dodatečná paměť. Dva gigabajty jsou na stroji s 8 GB víc než dost.

$ fallocate -l 2G /swapfile || dd if=/dev/zero of=/swapfile bs=1M count=2048$ chmod 600 /swapfile$ mkswap /swapfile$ swapon /swapfile$ swapon --show

Aby přežil restart, přidej jeden řádek do /etc/fstab:

/swapfile none swap sw 0 0

Pak sniž ochotu jádra ho používat, aby zůstal záchrannou sítí a nestal se běžným stavem:

$ echo 'vm.swappiness=10' > /etc/sysctl.d/99-swap.conf$ sysctl --system

fallocate na některých souborových systémech selhává, proto je tam záložní dd. A pokud server za běžného provozu skutečně swapuje, swap není řešení - stroj je příliš malý, nebo něco uniká. Swap v Linuxu a OOM killer popisuje čtení důkazů a CPU, nebo RAM pro herní servery čeho se ti ve skutečnosti nedostává.

Co může počkat do druhé hodiny#

Máš hotovou část, která se musí stát dřív, než stroj začne dělat jakoukoli práci. Další vrstva, v pořadí, v jakém ji většina lidí potřebuje:

fail2ban, služby systemd pro tvé aplikace a nginx jako reverzní proxy se každý pořádně věnuje jedné z těch věcí. Pokud je plán několik herních serverů na jednom stroji, více herních serverů na jednom VDS pokrývá porty, uživatele a dohled nad procesy, než se s nimi zamotáš.

Co nedělat v první hodině: instalovat řídicí panel, o kterém ses nerozhodl, otevírat porty pro služby, které ještě neexistují, nebo se řídit průvodcem zabezpečením, který mění čtyřicet hodnot sysctl, jež neumíš vysvětlit. Každá změna, kterou neumíš vysvětlit, je změna, kterou tě nenapadne vrátit, když se něco rozbije.

VDS je stroj, který vlastníš celý, včetně údržby. Pokud ten seznam vypadá jako práce, kterou bys nechtěl dělat každý měsíc, upřímné srovnání je v VDS, nebo herní panel a odpověď je pro různé lidi skutečně různá.

FAQ#

Kterou distribuci mám zvolit?

Tu verzi s dlouhodobou podporou, kterou už znáš. Ubuntu LTS i Debian stable dostávají bezpečnostní aktualizace roky, mají nejvíc přesné dokumentace a předpokládá je většina instalačních návodů. Novější, kratší vydání ti přinese verze balíčků, které pravděpodobně nepotřebuješ, výměnou za upgrade každých devět měsíců.

Opravdu potřebuji uživatele bez roota, když stroj používám jen já?

Ano a důvodem nejsou jiní lidé. Provoz jako root dělá každou chybu maximální, každý napadený proces rootovým a každý příkaz zkopírovaný z internetu rootovým příkazem. Vědomé napsání sudo je půlvteřinová pauza před těmi destruktivními.

Vyplatí se změnit port SSH?

Odstraní většinu šumu z logů ověřování, takže skutečné události jsou lépe vidět. Nepřidává zabezpečení proti nikomu, kdo míří přímo na tebe, protože skenování portů najde nový port za vteřiny. Udělej to pro tiché logy, jestli chceš, ale nikdy místo klíčů a firewallu.

Mám fail2ban nainstalovat hned?

Je užitečný a je až druhořadý. Se zakázaným přihlašováním heslem nemůže útok hrubou silou na SSH uspět bez ohledu na počet pokusů, takže tam fail2ban hlavně šetří objem logů. Své místo si získá před webovými přihlášeními, poštou a čímkoli dalším, co heslo ještě přijímá.

Kolik swapu přidat?

Dost na pohlcení špičky, ne dost na zakrytí problému. Jeden až dva gigabajty na stroji s 8 GB nebo víc a nízká hodnota vm.swappiness. Pravidlo, že server potřebuje swap úměrný paměti, pochází z éry mnohem menších strojů a hibernace.

Který krok lidé přeskakují a litují toho?

Testování druhého přihlášení před zavřením první relace. Každý příběh o vyzamčení začíná tím, že někdo restartuje sshd po změně konfigurace, zavře terminál a zjistí, že v AllowUsers byl překlep. Nech fungující relaci otevřenou, dokud nová neuspěje.