Czego nie należy robić

Moduł 10: Bezpieczeństwo na co dzień · Czas czytania: 12 min

Cel lekcji: Po tej lekcji rozpoznają Państwo błędy, które najczęściej prowadzą do włamania na serwer lub jego awarii, potrafią wyjaśnić, dlaczego są niebezpieczne, i wiedzą, co robić zamiast nich.

Kluczowe pojęcia: logowanie roota hasłem, słabe lub domyślne hasło, otwarta baza danych, API Dockera na porcie 2375, docker.sock w kontenerze, chmod 777, curl | bash, sekrety w Git, panel administracyjny bez weryfikacji dwuetapowej, zapora "na chwilę wyłączona", brak aktualizacji, brak kopii zapasowej

Dlaczego lekcja o błędach?

Większość serwerów nie pada ofiarą genialnego napastnika, który zna nieujawnioną lukę. Włamują się na nie boty, które przeszukują cały internet w poszukiwaniu znanych błędów: hasła, które da się odgadnąć, otwartej bazy danych, programu, który od miesięcy czeka na aktualizację. Kto unika błędów opisanych w tej lekcji, przestaje być celem dla tych botów. To największa część ochrony, jaką można uzyskać.

Przy każdym błędzie wyjaśniamy, dlaczego jest niebezpieczny i co zrobić zamiast tego. Prawie wszystko poznali Państwo we wcześniejszych lekcjach; ta lekcja zbiera to w jednym miejscu.

1. Logowanie roota hasłem

Problem. Każdy serwer przez cały dzień otrzymuje próby logowania na root (lekcja 5.3). Jeśli root może zalogować się hasłem, to hasło jest jedyną przeszkodą między botem a pełną kontrolą. Hasła używane wielokrotnie lub zbyt krótkie prędzej czy później zostaną odgadnięte albo już znajdują się na liście z wycieku.

Co robić. Logowanie wyłącznie kluczami: PasswordAuthentication no i KbdInteractiveAuthentication no, root co najwyżej z kluczem (PermitRootLogin prohibit-password) lub wcale (no), codzienna praca jako zwykły użytkownik z sudo (lekcja 2.2 i 3.2). Prosimy sprawdzić z zewnątrz, jakie metody logowania oferuje Państwa serwer (zadanie Z2.2).

2. Baza danych, cache lub klaster wyszukiwania otwarte na internet

Problem. MySQL/MariaDB (3306), PostgreSQL (5432), Redis (6379), Elasticsearch lub OpenSearch (9200) i MongoDB (27017) są przeznaczone dla zaufanych programów w zaufanej sieci. Jeśli nasłuchują na 0.0.0.0 bez zapory, skanery szybko je znajdą. Redis w swojej dokumentacji podaje, że nie powinien być wystawiony na internet i że osoba z dostępem może skasować cały zbiór danych; za pomocą polecenia CONFIG napastnik może nawet zapisywać pliki na serwerze. Otwarte bazy danych i klastry wyszukiwania od lat są znaną przyczyną dużych wycieków danych oraz komunikatów z żądaniem "okupu" w miejscu Państwa danych.

Co robić. Prosimy ustawić takie usługi na nasłuch na 127.0.0.1 (lekcja 5.1), trzymać je za zaporą (lekcja 5.2), a w Dockerze nie publikować ich wcale lub tylko na 127.0.0.1 (lekcja 9.3). Własny dostęp z laptopa: tunel SSH (lekcja 2.3). Prosimy sprawdzić z zewnątrz (zadanie Z5.1).

3. Otwarte API Dockera lub docker.sock w kontenerze

Problem. Kto może sterować demonem Dockera, ten w praktyce jest rootem na serwerze: dokumentacja Dockera podaje, że demonem powinni sterować tylko zaufani użytkownicy, i stawia dostęp do demona na równi z dostępem roota. Ten błąd występuje w dwóch wariantach:

• Demon nasłuchuje na porcie TCP bez TLS (zwykle jest to 2375). Każdy, kto dotrze do tego portu, może uruchamiać kontenery z podłączonym dyskiem Państwa serwera.
• Kontener otrzymuje /var/run/docker.sock jako wolumen ("wtedy sam może zarządzać kontenerami"). Jeśli ktoś włamie się do tego kontenera, przejmuje cały serwer.

Również grupa docker jest równoważna rootowi (lekcja 9.2): prosimy dodawać do niej wyłącznie administratorów.

Co robić. Docker powinien działać wyłącznie przez lokalne gniazdo. Zdalne zarządzanie odbywa się przez SSH (docker context z ssh://), a jeśli naprawdę musi to być TCP, to z TLS na porcie 2376 i certyfikatami klienta. Prosimy montować docker.sock tylko w kontenerze, któremu w pełni Państwo ufają i który naprawdę tego potrzebuje, a najlepiej tylko do odczytu przez ograniczające proxy.

4. chmod 777, żeby pozbyć się komunikatu o błędzie

Problem. Przy wysyłaniu pliku pojawia się "Permission denied" (brak uprawnień), a na forum ktoś radzi: chmod -R 777 /var/www. Od tej chwili każdy użytkownik i każdy proces na serwerze może zapisywać wszystko w Państwa stronie, także zainfekowana wtyczka lub inne konto. Kod, do którego serwer WWW może zapisywać, można przez lukę podmienić na backdoor.

Co robić. Prosimy ustalić, kto musi zapisywać i gdzie (lekcja 3.1): zwykle tylko użytkownik serwera WWW w jednym katalogu na przesłane pliki lub cache. Kod powinien mieć innego właściciela niż serwer WWW, uprawnienia 644/755, przesłane pliki 750/640 lub podobne.

5. curl ... | bash i oprogramowanie z dowolnych źródeł

Problem. Skrypt uruchomiony jako root bez przejrzenia może wszystko: dodać źródła i klucze, nadpisać pliki, otworzyć usługę. Nawet jeśli intencje są dobre, potem nie wiedzą Państwo, co zostało zmienione, a przy następnej aktualizacji wydania coś przestaje działać (lekcja 4.3).

Co robić. Prosimy pobrać skrypt i go przeczytać. Lepiej instalować z repozytorium pakietów dystrybucji lub z oficjalnego źródła twórcy, z osobnym kluczem (Signed-By, lekcja 4.1). Prosimy zapisywać, co i dlaczego Państwo instalują.

6. Brak aktualizacji lub aktualizacje "później"

Problem. Luki są łatane, a potem wykorzystywane, często w ciągu kilku dni. Serwer, który od miesięcy nie dostaje aktualizacji lub działa na wydaniu bez wsparcia, ma całą listę znanych furtek. Kontenery nie są aktualizowane przez apt.

Co robić. Automatyczne aktualizacje bezpieczeństwa włączone (lekcja 4.2), stały termin ponownych uruchomień, data końca wsparcia wydania w kalendarzu (lekcja 4.3) i regularne aktualizowanie kontenerów (lekcja 9.4).

7. Brak kopii zapasowej lub kopia, której nigdy nie przetestowano

Problem. Snapshot na tym samym magazynie danych nie jest kopią zapasową (lekcja 8.1). Kopia przechowywana na samym serwerze znika razem z nim przy włamaniu lub ataku ransomware. A kopia, której nigdy nie przywrócono, to nadzieja, a nie pewność.

Co robić. Szyfrowane kopie zapasowe poza serwerem (restic, lekcja 8.2), monitorowanie, czy się wykonują, i co najmniej raz na kwartał test przywracania.

8. Panele administracyjne otwarte dla wszystkich, bez weryfikacji dwuetapowej

Problem. Panel administracyjny bazy danych (np. phpMyAdmin), Dockera (np. Portainer), Państwa aplikacji lub sejfu na hasła to atrakcyjny cel: jedno hasło daje dostęp do wszystkiego. Domyślne hasła, takie jak admin/admin, i pozostawiona otwarta rejestracja (Vaultwarden, lekcja 9.4) jeszcze to ułatwiają.

Co robić. Prosimy nie wystawiać paneli administracyjnych na internet: dostęp przez tunel SSH lub tylko ze stałego adresu. Jeśli panel musi być publiczny: https, silne, unikalne hasło z menedżera haseł, weryfikacja dwuetapowa i zamknięta rejestracja. Domyślne hasła należy zawsze zmieniać.

9. Sekrety w Git lub w pliku compose

Problem. Hasło, klucz API lub klucz prywatny w pliku, który trafi do repozytorium Git, zostaje w historii na zawsze, nawet jeśli później go Państwo usuną. Publiczne repozytoria są przeszukiwane przez boty właśnie pod kątem takich kluczy.

Co robić. Sekrety w osobnym pliku z uprawnieniami 600 (EnvironmentFile, lekcja 6.3; .env w Docker Compose, lekcja 9.3), wpisanym do .gitignore. Jeśli sekret mimo to wyciekł: prosimy natychmiast go wymienić (nowe hasło, nowy klucz), samo wyczyszczenie Git nie wystarczy.

10. Zapora "na chwilę" wyłączona, wszystko jako root i brak notatek

Problem. "Wyłączę na chwilę zaporę, żeby przetestować" zostaje zapomniane. "Zrobię to szybko jako root" staje się nawykiem. A serwerem, o którym nikt nie wie, co na nim działa i dlaczego, nie da się zarządzać ani go odtworzyć.

Co robić. Prosimy testować z tymczasową, wąską regułą (jeden port, jeden adres źródłowy) i potem ją usunąć. Prosimy pracować jako zwykły użytkownik z sudo. Prosimy prowadzić krótką dokumentację serwera: co działa, które porty są otwarte, gdzie są kopie zapasowe, kiedy kończy się wsparcie wydania (lekcja 10.4).

W praktyce

Wszystkie te błędy można popełnić na każdym VPS, w WebOké tak samo jak u innych dostawców: tym, co dzieje się wewnątrz serwera, zarządzają Państwo sami. Dostawca może jednak odłączyć serwer od sieci, jeśli wysyła spam lub przeprowadza ataki, ponieważ dotyka to innych klientów. Zapobieganie jest więc ważne także dla dostępności Państwa własnych usług.

Podsumowanie

• Większość włamań wykorzystuje znane błędy, a nie nieznane luki.
• Logowanie kluczami, logowanie hasłem wyłączone; bazy danych, cache i API Dockera nigdy otwarte na internet; żadnego docker.sock w kontenerach, którym nie ufają Państwo w pełni.
• Żadnego chmod 777 i żadnego curl | bash: trzeba wiedzieć, kto ma jakie uprawnienia i co się instaluje.
• Aktualizacje automatyczne, kopie zapasowe poza serwerem i przetestowane, panele administracyjne za tunelem lub z weryfikacją dwuetapową.
• Sekrety poza Git i poza plikami compose; sekret, który wyciekł, należy wymienić.

Quiz

Zadanie

Zadanie Z10.2: Jaki to błąd? W przykładowym pliku casussen-z10-2.md znajduje się osiem krótkich przypadków serwerów, z którymi coś jest nie tak. Dla każdego przypadku prosimy wybrać, o który błąd z listy w tej lekcji chodzi (od A do J) i jaki jest najlepszy pierwszy krok. Program porówna odpowiedzi ze stałym kluczem i następnie wyświetli wyjaśnienie dla każdego przypadku.

Przeczytaj więcej

• Zabezpieczanie VPS: pierwsze pięć minut
• Menedżer haseł i klucze dostępu (passkeys): jak bezpiecznie zorganizować swoje logowanie
• Dokumentacja Dockera, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
• Dokumentacja Dockera, 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/