Co nedělat
Modul 10: Zůstaňte v bezpečí · Doba čtení: 12 min.
Cíl lekce: Po této lekci rozpoznáte chyby, které nejčastěji vedou k napadenému nebo nefunkčnímu serveru, dokážete vysvětlit, proč jsou nebezpečné, a víte, co dělat místo nich.
Klíčové pojmy: přihlášení roota heslem, slabé nebo výchozí heslo, otevřená databáze, Docker API na portu 2375, docker.sock v kontejneru, chmod 777, curl | bash, tajné údaje v Gitu, administrační panel bez dvoufázového ověření, firewall „na chvíli vypnutý“, žádné aktualizace, žádná záloha
Proč lekce o chybách?
Většinu serverů nenapadne geniální útočník s neznámou zranitelností. Napadnou je boti, kteří procházejí celý internet a hledají známé chyby: heslo, které se dá uhodnout, databázi, která je otevřená, program, kterému už měsíce chybí aktualizace. Kdo se vyhne chybám z této lekce, pro tyto boty přestane být zajímavý. To je největší část ochrany, jakou můžete získat.
U každé chyby najdete, proč je nebezpečná a co dělat místo ní. Téměř vše jste se naučili v předchozích lekcích; tato lekce to shrnuje přehledně na jednom místě.
1. Přihlášení roota heslem
Problém. Každý server dostává celý den pokusy o přihlášení na root (lekce 5.3). Může-li se root přihlásit heslem, je toto heslo jediné, co stojí mezi botem a úplnou kontrolou. Opakovaně používaná nebo příliš krátká hesla budou dříve či později uhodnuta, nebo už jsou v nějakém uniklém seznamu.
Udělejte toto. Přihlašujte se pouze klíči: PasswordAuthentication no a KbdInteractiveAuthentication no, root nanejvýš s klíčem (PermitRootLogin prohibit-password) nebo vůbec (no), každodenní práci dělejte jako běžný uživatel se sudo (lekce 2.2 a 3.2). Zvenku zkontrolujte, jaké metody přihlášení Váš server nabízí (úkol Z2.2).
2. Databáze, cache nebo vyhledávací cluster otevřené do internetu
Problém. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch nebo OpenSearch (9200) a MongoDB (27017) jsou určeny pro důvěryhodné programy v důvěryhodné síti. Pokud naslouchají na 0.0.0.0 bez firewallu, skenery je rychle najdou. Redis ve své vlastní dokumentaci uvádí, že by neměl být vystaven do internetu a že kdokoli s přístupem může smazat celou datovou sadu; pomocí příkazu CONFIG může útočník dokonce zapisovat soubory na server. Otevřené databáze a vyhledávací clustery jsou už léta známou příčinou velkých úniků dat a zpráv s požadavkem na „výkupné“ místo Vašich dat.
Udělejte toto. Nechte takové služby naslouchat na 127.0.0.1 (lekce 5.1), držte je za firewallem (lekce 5.2) a v Dockeru je nepublikujte, nebo jen na 127.0.0.1 (lekce 9.3). Sami se k nim ze svého notebooku dostanete přes SSH tunel (lekce 2.3). Zkontrolujte to zvenku (úkol Z5.1).
3. Otevřené Docker API nebo docker.sock v kontejneru
Problém. Kdo může ovládat démona Dockeru, je fakticky rootem na serveru: dokumentace Dockeru uvádí, že démona smějí ovládat pouze důvěryhodní uživatelé, a přístup k démonovi označuje za rovnocenný přístupu roota. Tato chyba má dvě varianty:
- Démon naslouchá na TCP portu bez TLS (obvykle 2375). Kdokoli, kdo se k tomuto portu dostane, může spouštět kontejnery s připojeným diskem Vašeho serveru.
- Kontejner dostane
/var/run/docker.sockjako volume („pak může sám spravovat kontejnery“). Pokud je tento kontejner napaden, je po celém serveru.
Také skupina docker je rovnocenná rootovi (lekce 9.2): zařaďte do ní jen správce.
Udělejte toto. Nechte Docker pracovat pouze přes lokální socket. Vzdálená správa probíhá přes SSH (docker context s ssh://), nebo pokud to opravdu musí být přes TCP, s TLS na portu 2376 a klientskými certifikáty. docker.sock připojujte jen do kontejneru, kterému plně důvěřujete a který ho opravdu potřebuje, a raději pouze pro čtení přes omezující proxy.
4. chmod 777, aby zmizela chybová hláška
Problém. Při nahrávání se objeví „Permission denied“ (přístup odepřen) a nějaké fórum radí: chmod -R 777 /var/www. Poté může každý uživatel a každý proces na serveru zapisovat cokoli do Vašeho webu, včetně napadeného pluginu nebo jiného účtu. Kód, do kterého může webový server zapisovat, lze přes zranitelnost nahradit zadními vrátky (backdoor).
Udělejte toto. Zjistěte, kdo potřebuje zapisovat a kam (lekce 3.1): obvykle jen uživatel webového serveru v jedné složce pro nahrané soubory nebo cache. Kód by měl mít jiného vlastníka než webový server, oprávnění 644/755, nahrané soubory 750/640 nebo podobně.
5. curl ... | bash a software odkudkoli
Problém. Skript, který bez kontroly spustíte jako root, může cokoli: přidat zdroje a klíče, přepsat soubory, otevřít službu. I když je úmysl dobrý, nevíte potom, co se změnilo, a při příštím upgradu vydání se to rozbije (lekce 4.3).
Udělejte toto. Skript si stáhněte a přečtěte. Instalujte raději z repozitáře své distribuce nebo z oficiálního zdroje autora s vlastním klíčem (Signed-By, lekce 4.1). Zapište si, co instalujete a proč.
6. Žádné aktualizace, nebo aktualizace „později“
Problém. Zranitelnosti se opravují a poté zneužívají, často během několika dnů. Server, který měsíce nedostal aktualizace nebo běží na vydání bez podpory, má seznam známých děr. Kontejnery se pomocí apt neaktualizují.
Udělejte toto. Zapněte automatické bezpečnostní aktualizace (lekce 4.2), stanovte pevný čas pro restarty, zapište si datum konce podpory svého vydání do kalendáře (lekce 4.3) a pravidelně aktualizujte kontejnery (lekce 9.4).
7. Žádná záloha, nebo záloha, která nikdy nebyla otestována
Problém. Snapshot na stejném úložišti není záloha (lekce 8.1). Záloha uložená přímo na serveru zmizí spolu s ním při napadení nebo útoku ransomwaru. A záloha, která nikdy nebyla obnovena, je naděje, nikoli jistota.
Udělejte toto. Šifrované zálohy mimo server (restic, lekce 8.2), monitoring, který hlídá, že probíhají, a alespoň jednou za čtvrtletí test obnovy.
8. Administrační panely otevřené všem, bez dvoufázového ověření
Problém. Administrační panel databáze (například phpMyAdmin), Dockeru (například Portainer), Vaší aplikace nebo Vašeho trezoru hesel je lákavý cíl: jedno heslo dává přístup ke všemu. Výchozí hesla jako admin/admin a registrace, která zůstane otevřená (Vaultwarden, lekce 9.4), to ještě usnadňují.
Udělejte toto. Nezpřístupňujte administrační panely do internetu: připojujte se k nim přes SSH tunel nebo jen z pevné adresy. Pokud musí být panel přesto veřejný: https, silné jedinečné heslo z Vašeho správce hesel, dvoufázové ověření a uzavřená registrace. Výchozí hesla vždy změňte.
9. Tajné údaje v Gitu nebo v souboru compose
Problém. Heslo, API klíč nebo privátní klíč v souboru, který se dostane do Git repozitáře, zůstává navždy v historii, i když ho později odstraníte. Veřejné repozitáře prohledávají boti právě kvůli takovým klíčům.
Udělejte toto. Tajné údaje patří do samostatného souboru s oprávněním 600 (EnvironmentFile, lekce 6.3; .env u Docker Compose, lekce 9.3), který je uveden v .gitignore. Pokud přesto nějaký tajný údaj unikl: okamžitě ho nahraďte (nové heslo, nový klíč), samotné vyčištění Gitu nestačí.
10. Firewall „na chvíli“ vypnutý, všechno jako root a žádné poznámky
Problém. „Na chvíli vypnu firewall, abych to otestoval“ se zapomene. „Udělám to rychle jako root“ se stane zvykem. A server, o kterém nikdo neví, co na něm běží a proč, nelze spravovat ani obnovit.
Udělejte toto. Testujte s dočasným, úzkým pravidlem (jeden port, jedna zdrojová adresa) a poté ho odstraňte. Pracujte jako běžný uživatel se sudo. Veďte si krátkou dokumentaci serveru: co na něm běží, které porty jsou otevřené, kde jsou zálohy, kdy končí podpora vydání (lekce 10.4).
V praxi
Všech těchto chyb se lze dopustit na jakémkoli VPS, u WebOké stejně jako u jiných poskytovatelů: co se děje uvnitř Vašeho serveru, spravujete sami. Poskytovatel však může server odpojit od sítě, pokud rozesílá spam nebo provádí útoky, protože to postihuje ostatní zákazníky. Prevence je tedy důležitá i pro dostupnost Vašich vlastních služeb.
Shrnutí
- Většina útoků využívá známé chyby, nikoli neznámé zranitelnosti.
- Přihlašování klíči, přihlášení heslem vypnuté; databáze, cache a Docker API nikdy otevřené do internetu; žádný
docker.sockv kontejnerech, kterým plně nedůvěřujete. - Žádné
chmod 777a žádnécurl | bash: vězte, kdo smí co a co instalujete. - Automatické aktualizace, zálohy mimo server a otestované, administrační panely za tunelem nebo s dvoufázovým ověřením.
- Tajné údaje mimo Git a mimo soubory compose; co uniklo, je třeba nahradit.
Kvíz
Úkol
Úkol Z10.2: O jakou chybu jde? V ukázkovém souboru casussen-z10-2.md je osm krátkých případů serverů, se kterými je něco v nepořádku. U každého případu vyberte, o kterou chybu ze seznamu v této lekci jde (A až J), a jaký je nejlepší první krok. Program odpovědi porovná s pevným klíčem a poté u každého případu zobrazí vysvětlení.
Doporučujeme k přečtení
- Zabezpečení VPS: prvních pět minut
- Správce hesel a přístupové klíče (passkeys): jak si bezpečně zajistit přihlašování
- Dokumentace Dockeru, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
- Dokumentace Dockeru, Protect the Docker daemon socket: https://docs.docker.com/engine/security/protect-access/
- Redis, Security: https://redis.io/docs/latest/operate/oss_and_stack/management/security/