Ha baj történik

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

Tanulási cél: A lecke után Ön felismeri a feltört szerver jeleit, megteszi az első lépéseket anélkül, hogy bizonyítékot vagy biztonsági mentést tenne tönkre, dönt a megtisztítás és az újratelepítés között, és tudja, mikor kell bejelentenie egy adatvédelmi incidenst.

Kulcsfogalmak: incidens, jelek, elszigetelés, pillanatkép mint bizonyíték, incidensnapló, újratelepítés, kulcsok és jelszavak cseréje, tiszta biztonsági mentés, adatvédelmi incidensek bejelentési kötelezettsége (72 óra), Nemzeti Adatvédelmi és Információszabadság Hatóság, vészhelyzeti terv

Egy incidens felismerése

Egy betörés ritkán jelenti be magát. Többnyire csak azt veszi észre, hogy valami "furcsa". Komolyan veendő jelek:

• Indokolatlanul magas terhelés: a processzor folyamatosan 100%-on fut, például egy kriptobányász miatt. A top vagy a htop segítségével nézze meg, melyik folyamatról van szó, és melyik felhasználó alatt fut.
• Ismeretlen folyamatok vagy szolgáltatások: egy furcsa nevű program, gyakran a /tmp, /dev/shm vagy /var/tmp mappában, vagy egy systemd-szolgáltatás vagy időzítő, amelyet nem Ön hozott létre.
• Gyanús kimenő forgalom: a szolgáltatója jelzi, hogy a szervere spamet küld vagy más szervereket támad, vagy a panel hálózati grafikonjain kiugrások látszanak.
• Új felhasználók vagy kulcsok: egy ismeretlen sor a ~/.ssh/authorized_keys fájlban, egy 0-s UID-jű felhasználó a /etc/passwd fájlban, egy új sor a /etc/sudoers.d/ fájlban.
• Módosított fájlok: ismeretlen PHP-fájlok a webhelyén, egy megváltozott crontab.
• Eltűnt vagy üres naplók: a támadók szívesen eltüntetik a nyomaikat.

Néhány parancs a gyors körülnézéshez:

anna@web1:~$ top -o %CPU
anna@web1:~$ sudo ss -tunap | grep ESTAB
anna@web1:~$ sudo last -n 20
anna@web1:~$ awk -F: '$3 == 0 {print $1}' /etc/passwd
anna@web1:~$ sudo find /etc/systemd/system /etc/cron* -newer /etc/hostname -type f
anna@web1:~$ for u in /root /home/*; do sudo cat $u/.ssh/authorized_keys 2>/dev/null; done

A last megmutatja, ki mikor jelentkezett be, a awk sor kilistázza az összes 0-s UID-jű fiókot (ennek csak a root fióknak kellene lennie), a find sor pedig azokat a unitokat és cron-fájlokat keresi, amelyek újabbak egy, a telepítéskor létrehozott fájlnál.

Figyelem: egy valóban feltört szerveren ezek a parancsok is meg lehetnek hamisítva. Abban segítenek, hogy valamit gyanítson, nem abban, hogy bebizonyítsa: minden tiszta.

Az első lépések: nyugalom, elszigetelés, rögzítés

Az első percekben a legfontosabb, hogy ne kezdjen pánikban dolgokat törölni. Ebben a sorrendben haladjon.

1. Kezdjen naplót vezetni. Írja fel papírra vagy a laptopjára (nem a szerverre), mit lát, mikor, és mit tesz. Erre később szüksége lesz az ok felderítéséhez, egy bejelentéshez, feljelentéshez vagy a biztosítójához. A holland NCSC is ezt javasolja.

2. Szigetelje el a szervert. Akadályozza meg, hogy további kárt okozzon (spam, támadások, adatok kiküldése), anélkül hogy kikapcsolná:

• a szolgáltatója tűzfalában (ha van ilyen) zárjon le mindent, kivéve az SSH-t a saját címéről; vagy
• tegye ugyanezt magán a szerveren, a konzolon keresztül;
• ha nincs más lehetőség: kapcsolja ki a szervert a panelen. Ilyenkor azonban elvész a memória tartalma.

3. Készítsen pillanatképet. A panelen készített pillanatkép rögzíti a jelenlegi állapotot. Ez a bizonyítéka és a forrása ahhoz, hogy később kiderítse, hogyan jutott be a támadó, akkor is, ha utána újratelepíti a szervert.

4. Biztosítsa a biztonsági mentéseit. Ellenőrizze, hogy a szerveren kívül tárolt mentései sértetlenek-e, és gondoskodjon róla, hogy a feltört szerver többé ne férjen hozzájuk (például vonja vissza a szerver hozzáférési kulcsát a mentési tárhelyhez). A támadók a mentéseket is megpróbálják törölni vagy titkosítani.

Megtisztítás vagy újratelepítés?

A csábító válasz: törölni a gyanús fájlt, leállítani a kriptobányászt, és kész. Csakhogy nem tudja, mi mindent tett még a támadó: egy második hátsó ajtó, egy módosított program, egy plusz kulcs, egy időzítő, amely mindent visszaállít. Egy olyan szerverben, ahol valaki root jogosultsággal rendelkezett, többé nem bízhat meg.

A rendszergazdák és a holland NCSC tanácsa ezért: telepítse újra az érintett rendszereket, és az adatait olyan biztonsági mentésből állítsa vissza, amely maga nem fertőzött. A gyakorlatban:

1. Egy új telepítés (újratelepítés a panelen, vagy egy új szerver).
2. Azonnal a tanfolyam alapjai: frissítések, egy sudo jogosultságú egyszerű felhasználó, SSH új kulcsokkal, tűzfal (a 2-től az 5. modulig).
3. Az alkalmazások újratelepítése hivatalos forrásokból, lehetőleg a compose-fájljai vagy jegyzetei alapján (10.4. lecke).
4. Az adatok (adatbázis, feltöltések) visszaállítása egy, az incidens előtti mentésből. Kódot vagy konfigurációt ne állítson vissza vakon: ezek tartalmazhatják a hátsó ajtót. A visszaállított adatokat is kritikusan nézze át; lehet, hogy a támadó már régebb óta bent volt, mint gondolná.
5. A rés bezárása, amelyen keresztül a támadó bejutott. Különben újra megtörténik. A 3. lépésben készített pillanatkép segít a felderítésben.

Mindent cseréljen le, ami kiszivároghatott

Induljon ki abból, hogy minden, ami a szerveren volt, a támadó kezébe került:

• SSH-kulcsok: a szerveren tárolt nyilvános kulcsokat mindenhonnan távolítsa el, és készítsen új kulcspárokat, ha privát kulcsok is voltak a szerveren.
• Jelszavak: az adatbázisoké, a kezelőpaneleké és az alkalmazása felhasználóié.
• API-kulcsok és tokenek (levelezés, fizetés, felhőtárhely, mentési tárhely) a .env fájlokból és a konfigurációból: vonja vissza őket a szolgáltatásnál, és cserélje le.
• Tanúsítványok: a tanúsítvány privát kulcsa a szerveren volt. Vonassa vissza a tanúsítványt, és igényeljen újat (a Let's Encrypt segítségével ez gyorsan megy, 7.3. lecke).

Bejelentés: a GDPR és mások

Ha személyes adatok (ügyféladatok, fiókok, e-mail-címek) voltak a szerveren, akkor lehet, hogy adatvédelmi incidens történt. A GDPR (33. cikk) szerint az adatkezelő az adatvédelmi incidenst indokolatlan késedelem nélkül, és ha lehetséges, legkésőbb 72 órával azután, hogy tudomást szerzett róla, bejelenti a felügyeleti hatóságnak. Magyarországon ez a Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH); a bejelentés elektronikus űrlapon történik. Néhány fontos szempont:

• nem kell bejelenteni, ha az incidens valószínűleg nem jár kockázattal az érintettekre nézve; ha kétsége van, jelentse be;
• ha még nincs meg minden információja, akkor is jelentse be 72 órán belül, és később egészítse ki;
• azokat, akiknek az adatai kiszivárogtak, tájékoztatnia kell, ha rájuk nézve magas a kockázat;
• minden adatvédelmi incidenst rögzítsen egy saját nyilvántartásban, akkor is, ha nem kell bejelentenie.

Ha egy ügyfél számára kezeli a szervert, akkor általában Ön az adatfeldolgozó: ilyenkor indokolatlan késedelem nélkül tájékoztatnia kell az ügyfelet (az adatkezelőt), hogy ő bejelenthesse. Ez a lecke nem jogi tanácsadás; kétség esetén nézze meg a NAIH honlapját.

Továbbá: a szerveréről elkövetett visszaéléseket jelentse a szolgáltatójának (aki gyakran már észre is vette), súlyos támadás esetén pedig tegyen feljelentést a rendőrségen. Ha a szervezete a Magyarország kiberbiztonságáról szóló 2024. évi LXIX. törvény (a NIS2 átültetése) hatálya alá tartozik, akkor külön, rövidebb bejelentési határidők vonatkoznak Önre.

Felkészülés: a vészhelyzeti terv

Egy incidens mindig rosszkor jön. Amit előre elintézett, az órákat takarít meg:

• Tudja, hogyan éri el a szolgáltatója konzolját és pillanatkép gombját, és tartsa a panel belépési adatait (kétlépcsős azonosítással) valahol a szerveren kívül.
• Tudja, hol vannak a biztonsági mentései, hogyan állítja vissza őket, és hogy működnek (8.2. lecke).
• Vezessen listát a szerveren tárolt összes titokról, hogy tudja, mit kell lecserélnie.
• Tartson egy telefonlistát: a szolgáltatója, ki más kell, hogy tudjon a szerverről (ügyfél, kolléga), és az adatvédelmi incidens bejelentéséhez szükséges elérhetőségek.

A gyakorlatban

A WebOké VPS-felületén megtalálja a konzolt, a pillanatképeket, a biztonsági mentéseket és az újratelepítés gombját; más szolgáltatóknál ezek nagyjából ugyanígy hívják (console vagy VNC, snapshot, rescue, reinstall). Ez a tanfolyam önsegítő: senki sem figyeli a szerverét, és senki sem takarít fel Ön helyett egy incidens után. Éppen ezért olyan fontos egy vészhelyzeti terv, amelyet saját maga is végre tud hajtani.

Összefoglalás

• Jelek: megmagyarázhatatlan terhelés, ismeretlen folyamatok, szolgáltatások vagy kulcsok, furcsa kimenő forgalom, módosított vagy eltűnt fájlok és naplók.
• Első lépések: napló vezetése, a szerver elszigetelése, pillanatkép készítése bizonyítékként, a mentések biztosítása.
• Egy szervert, ahol valaki root jogosultsággal rendelkezett, nem megtisztít, hanem újratelepít; az adatokat tiszta mentésből állítja vissza, és bezárja a rést.
• Cseréljen le minden kulcsot, jelszót, tokent és tanúsítványt, amely a szerveren volt.
• Személyes adatok is érintettek? Az adatvédelmi incidenst lehetőleg 72 órán belül jelentse be a NAIH-nak, és minden incidenst rögzítsen.

Kvíz

Feladat

Feladat O10.3: Az Ön vészhelyzeti terve egy oldalon. Írjon a saját szerveréhez egy legfeljebb egy A4-es oldalnyi vészhelyzeti tervet: hogyan jut be a panelbe, a konzolba és a pillanatképekhez; hol vannak a biztonsági mentései, és hogyan állítja vissza őket; milyen titkok vannak a szerveren; kit kell tájékoztatnia (és kell-e bejelentenie egy adatvédelmi incidenst); és melyik öt első lépést teszi meg, ha betörést gyanít. A tervet a szerveren kívül tárolja.

További olvasnivaló

• Nem fér hozzá a VPS-éhez: mi a teendő?
• A VPS snapshotjai és biztonsági mentései
• Saját ISO csatolása vagy a VPS újratelepítése
• A holland NCSC, Feltörték, mi a teendő? (holland nyelvű forrás): https://www.ncsc.nl/incidenten-en-herstellen/gehackt-wat-nu
• Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH), adatvédelmi incidensek bejelentése: https://naih.hu/