Amit ne tegyen

Modul 10: Biztonságban maradni · Olvasási idő: 12 perc

Tanulási cél: A lecke után felismeri azokat a hibákat, amelyek a leggyakrabban vezetnek feltört vagy tönkrement szerverhez, el tudja magyarázni, miért veszélyesek, és tudja, mit tegyen helyettük.

Kulcsfogalmak: root-bejelentkezés jelszóval, gyenge vagy alapértelmezett jelszó, nyitott adatbázis, Docker API a 2375-ös porton, docker.sock egy konténerben, chmod 777, curl | bash, titkok a Gitben, kezelőpanel kétlépcsős azonosítás nélkül, „csak egy percre” kikapcsolt tűzfal, nincsenek frissítések, nincs biztonsági mentés

Miért egy lecke a hibákról?

A legtöbb szervert nem egy zseniális támadó töri fel egy ismeretlen sebezhetőséggel. Olyan botok törik fel őket, amelyek az egész internetet végigpásztázzák ismert hibák után kutatva: kitalálható jelszó, nyitva hagyott adatbázis, egy program, amelyből már hónapok óta hiányzik egy frissítés. Aki elkerüli az ebben a leckében szereplő hibákat, az kiesik ezeknek a botoknak a látóköréből. Ez adja a megszerezhető védelem legnagyobb részét.

Minden hibánál leírjuk, miért veszélyes, és mit tegyen helyette. Szinte mindent megtanult már a korábbi leckékben; ez a lecke összefoglalja őket.

1. Root-bejelentkezés jelszóval

A probléma. Minden szerver egész nap bejelentkezési kísérleteket kap a root címen (5.3. lecke). Ha a root jelszóval bejelentkezhet, akkor csak ez a jelszó áll egy bot és a teljes irányítás között. Az újrahasznosított vagy túl rövid jelszavakat előbb-utóbb kitalálják, vagy már szerepelnek egy kiszivárgott listán.

Tegye ezt. Bejelentkezés csak kulcsokkal: PasswordAuthentication no és KbdInteractiveAuthentication no, a root legfeljebb kulccsal (PermitRootLogin prohibit-password) vagy egyáltalán nem (no), a napi munka pedig egyszerű felhasználóként, sudóval (2.2. és 3.2. lecke). Ellenőrizze kívülről, milyen bejelentkezési módokat kínál a szervere (Z2.2. feladat).

2. Az internet felé nyitott adatbázis, gyorsítótár vagy keresőfürt

A probléma. A MySQL/MariaDB (3306), a PostgreSQL (5432), a Redis (6379), az Elasticsearch vagy az OpenSearch (9200) és a MongoDB (27017) megbízható programok számára készült, megbízható hálózatban. Ha tűzfal nélkül a 0.0.0.0 címen figyelnek, a szkennerek gyorsan megtalálják őket. A Redis saját dokumentációja szerint nem szabad az internet felé kitenni, és aki hozzáfér, az a teljes adatkészletet törölheti; a CONFIG paranccsal a támadó akár fájlokat is írhat a szerverre. A nyitott adatbázisok és keresőfürtök évek óta a nagy adatszivárgások és az adatai helyén megjelenő „váltságdíj”-üzenetek ismert okai.

Tegye ezt. Az ilyen szolgáltatások a 127.0.0.1 címen figyeljenek (5.1. lecke), legyenek a tűzfal mögött (5.2. lecke), Dockerben pedig ne publikálja őket, vagy csak a 127.0.0.1 címen (9.3. lecke). Ha Önnek kell hozzáférnie a laptopjáról: SSH-alagút (2.3. lecke). Ellenőrizze kívülről (Z5.1. feladat).

3. Nyitott Docker API vagy docker.sock egy konténerben

A probléma. Aki a Docker-démont vezérelni tudja, az gyakorlatilag root a szerveren: a Docker dokumentációja szerint csak megbízható felhasználók vezérelhetik a démont, és a démonhoz való hozzáférést a root-hozzáféréssel egyenértékűnek tekinti. Ennek a hibának két változata van:

• A démon TLS nélkül egy TCP-porton figyel (általában a 2375-ösön). Bárki, aki eléri ezt a portot, a szervere lemezét csatolva indíthat konténereket.
• Egy konténer kötetként megkapja a /var/run/docker.sock fájlt („így maga is kezelhet konténereket”). Ha ezt a konténert feltörik, az egész szervernek vége.

A docker csoport is root-egyenértékű (9.2. lecke): csak rendszergazdákat vegyen fel bele.

Tegye ezt. A Docker csak a helyi socketen keresztül működjön. A távoli kezelés SSH-n keresztül történjen (docker context és ssh://), vagy ha valóban TCP-n kell, akkor TLS-sel a 2376-os porton, kliens-tanúsítványokkal. A docker.sock fájlt csak olyan konténerbe csatolja, amelyben teljesen megbízik és amelyre valóban szüksége van, és lehetőleg csak olvasásra, egy korlátozó proxyn keresztül.

4. chmod 777, hogy eltűnjön egy hibaüzenet

A probléma. Feltöltéskor „Permission denied” (hozzáférés megtagadva) jelenik meg, és egy fórum azt tanácsolja: chmod -R 777 /var/www. Ezután a szerveren minden felhasználó és minden folyamat bármit írhat a webhelyébe, egy feltört bővítmény vagy egy másik fiók is. A webszerver által írható kódot egy sebezhetőségen keresztül hátsó ajtóra lehet cserélni.

Tegye ezt. Derítse ki, kinek kell írnia és hova (3.1. lecke): általában csak a webszerver felhasználójának, egyetlen mappába a feltöltések vagy a gyorsítótár számára. A kód tulajdonosa ne a webszerver legyen, jogosultságok 644/755, a feltöltéseké 750/640 vagy hasonló.

5. curl ... | bash és bárhonnan származó szoftver

A probléma. Egy szkript, amelyet átnézés nélkül rootként futtat, bármit megtehet: forrásokat és kulcsokat adhat hozzá, fájlokat írhat felül, megnyithat egy szolgáltatást. Még ha jó is a szándék, utána nem tudja, mi változott, és a következő kiadásfrissítésnél elromlik (4.3. lecke).

Tegye ezt. Töltse le és olvassa el a szkriptet. Inkább a disztribúciója csomagforrásából vagy a készítő hivatalos forrásából telepítsen, saját kulccsal (Signed-By, 4.1. lecke). Jegyezze fel, mit telepít és miért.

6. Nincsenek frissítések, vagy a frissítések „majd később”

A probléma. A sebezhetőségeket kijavítják, majd kihasználják, gyakran napokon belül. Egy szerveren, amely hónapok óta nem kapott frissítést, vagy amely támogatás nélküli kiadáson fut, ismert rések listája található. A konténereket a apt nem frissíti.

Tegye ezt. Kapcsolja be az automatikus biztonsági frissítéseket (4.2. lecke), jelöljön ki egy állandó időpontot az újraindításra, írja be a naptárába a kiadása támogatásának végét (4.3. lecke), és rendszeresen frissítse a konténereket (9.4. lecke).

7. Nincs biztonsági mentés, vagy a mentést soha nem tesztelték

A probléma. Egy ugyanazon a tárolón lévő pillanatkép nem biztonsági mentés (8.1. lecke). A magán a szerveren tárolt mentés egy feltöréssel vagy zsarolóvírussal együtt elvész. Az a mentés pedig, amelyet soha nem állítottak vissza, csak remény, nem bizonyosság.

Tegye ezt. Titkosított biztonsági mentések a szerveren kívül (restic, 8.2. lecke), felügyelet, hogy valóban lefutnak, és legalább negyedévente egy visszaállítási teszt.

8. Mindenki számára nyitott kezelőpanelek kétlépcsős azonosítás nélkül

A probléma. Egy adatbázis kezelőpanelje (például a phpMyAdmin), a Dockeré (például a Portainer), az alkalmazásáé vagy a jelszószéféé vonzó célpont: egyetlen jelszó mindenhez hozzáférést ad. Az olyan alapértelmezett jelszavak, mint a admin/admin, és a nyitva hagyott regisztráció (Vaultwarden, 9.4. lecke) még könnyebbé teszik a dolgot.

Tegye ezt. Ne nyissa meg a kezelőpaneleket az internet felé: SSH-alagúton keresztül vagy csak egy rögzített címről érje el őket. Ha egy panelnek mégis nyilvánosnak kell lennie: https, egy erős, egyedi jelszó a jelszókezelőjéből, kétlépcsős azonosítás, és zárt regisztráció. Az alapértelmezett jelszavakat mindig változtassa meg.

9. Titkok a Gitben vagy a compose-fájlban

A probléma. Egy jelszó, API-kulcs vagy privát kulcs egy olyan fájlban, amely Git-tárolóba kerül, örökre ott marad az előzményekben, még akkor is, ha később eltávolítja. A nyilvános tárolókat botok kutatják át éppen ilyen kulcsok után.

Tegye ezt. A titkokat egy külön, 600-as jogosultságú fájlban tárolja (EnvironmentFile, 6.3. lecke; .env Docker Compose esetén, 9.3. lecke), amely szerepel a .gitignore fájlban. Ha mégis kiszivárgott egy titok: azonnal cserélje le (új jelszó, új kulcs), a Gitben való takarítás önmagában nem elég.

10. „Csak egy percre” kikapcsolt tűzfal, minden rootként, és semmi jegyzet

A probléma. A „csak egy percre kikapcsolom a tűzfalat, hogy teszteljek” feledésbe merül. A „gyorsan megcsinálom rootként” szokássá válik. Egy olyan szervert pedig, amelyről senki sem tudja, mi fut rajta és miért, nem lehet sem kezelni, sem helyreállítani.

Tegye ezt. Teszteljen egy ideiglenes, szűk szabállyal (egy port, egy forráscím), és utána távolítsa el. Dolgozzon egyszerű felhasználóként, sudóval. Vezessen egy rövid szerverdossziét: mi fut, mely portok vannak nyitva, hol vannak a biztonsági mentések, mikor jár le a kiadás támogatása (10.4. lecke).

A gyakorlatban

Mindezeket a hibákat bármely VPS-en el lehet követni, a WebOkénál ugyanúgy, mint más szolgáltatóknál: azt, ami a szerverén belül történik, Ön kezeli. A szolgáltató viszont leválaszthat egy szervert a hálózatról, ha az spamet küld vagy támadásokat hajt végre, mert ez más ügyfeleket is érint. A megelőzés tehát a saját elérhetősége szempontjából is fontos.

Összefoglalás

• A legtöbb feltörés ismert hibákat használ ki, nem ismeretlen sebezhetőségeket.
• Bejelentkezés kulcsokkal, jelszavas bejelentkezés kikapcsolva; adatbázisok, gyorsítótárak és a Docker API soha ne legyenek nyitva az internet felé; ne legyen docker.sock olyan konténerekben, amelyekben nem bízik meg teljesen.
• Nincs chmod 777 és nincs curl | bash: tudja, ki mit tehet meg, és mit telepít.
• Automatikus frissítések, a szerveren kívül tárolt és tesztelt biztonsági mentések, kezelőpanelek alagút mögött vagy kétlépcsős azonosítással.
• Titkok a Giten és a compose-fájlokon kívül; ami kiszivárgott, azt le kell cserélni.

Kvíz

Feladat

Z10.2. feladat: Melyik hibáról van szó? A casussen-z10-2.md mintafájlban nyolc rövid eset található olyan szerverekről, amelyekkel valami nincs rendben. Minden esetnél válassza ki a lecke listájából (A-tól J-ig), melyik hibáról van szó, és mi a legjobb első lépés. A program összeveti a válaszait a rögzített megoldókulccsal, majd esetenként megjeleníti a magyarázatot.

További olvasnivaló

• A VPS biztonságossá tétele: az első öt perc
• Jelszókezelő és passkey-k: így intézheti biztonságosan a bejelentkezéseit
• Docker dokumentáció, Docker security (Docker daemon attack surface): https://docs.docker.com/engine/security/
• Docker dokumentáció, 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/