Feltörve: felismerés, helyreállítás és megelőzés

Modul 7: Biztonság · Olvasási idő: 10 perc

Cél: E lecke után felismeri egy feltörés jeleit, helyes sorrendben állítja helyre a weboldalát, és megakadályozza, hogy ez újra megtörténjen.

Kulcsfogalmak: feltörés jelei, dokumentálás, elszigetelés, minden jelszó és salt lecserélése, a behatolási pont megtalálása, naplók, tiszta biztonsági mentés, tiszta újratelepítés, ellenőrző összegek, ismeretlen adminisztrátorok, PHP az uploads mappában, mu-plugins, Search Console, adatvédelmi incidens bejelentése

Mi számít feltörésnek

Egy weboldal feltört, ha valaki engedély nélkül megszerezte az irányítást (a weboldal egy része) felett: fájlokat vagy az adatbázist tudja módosítani, vagy kódot tud futtatni. Gyakran egy hátsó kapun (backdoor) keresztül marad bent: egy elrejtett fájl vagy kódrészlet, amellyel később is vissza tud térni, akkor is, ha az eredeti biztonsági rést bezárja.

Ez utóbbi a lecke lényege: önmagában nem elég eltávolítani a látható kárt. Amíg a hátsó kapu megvan, vagy a rés, amelyen keresztül bejutott, nyitva marad, a feltörés megismétlődik. Gyakran néhány napon belül.

Felismerés

Jelek (némelyiket Ön látja, másokat keresnie kell):

• A Google azt jelzi a weboldalánál, hogy "Ez a webhely feltörésre kerülhetett", vagy a Search Console biztonsági problémát jelez.
• A keresési találatok között (site:example.com) olyan oldalak jelennek meg, amelyeket nem ismer, gyakran más nyelven vagy gyógyszerekről, szerencsejátékról vagy hamis webáruházakról.
• A látogatókat átirányítják, gyakran csak akkor, ha keresőmotoron keresztül érkeznek vagy telefonon böngésznek. Ön ezt nem látja, mert be van jelentkezve, vagy könyvjelzőn keresztül érkezik. Tesztelje privát ablakban, egy keresési találaton keresztül.
• A Felhasználók között olyan adminisztrátor szerepel, akit nem ismer.
• PHP-fájlok vannak a wp-content/uploads mappában, vagy furcsa nevű fájlok a gyökérmappában vagy a wp-content/mu-plugins mappában.
• A tárhelyszolgáltatója vagy egy rosszindulatú kód szkenner fertőzött fájlokat jelez; a levelei elutasításra kerülnek, vagy a csomagja spamet küld.
• A weboldal hirtelen lassú lett, vagy a tárhelye megtelt.

A teendők sorrendje

1. Nyugalom és dokumentálás

Ne dobjon ki azonnal mindent. Jegyezze fel, mit lát és mióta, készítsen képernyőképeket, és készítsen másolatot a jelenlegi állapotról (fájlok és adatbázis, vagy egy extra biztonsági mentés a tárhelyszolgáltatóján keresztül). Erre a másolatra szüksége lesz a behatolási pont megtalálásához, és bizonyítékként is. Ne a webmappába mentse.

2. A látogatókat érintő kár megállítása

Kapcsolja ki ideiglenesen a weboldalt, vagy helyezzen el egy karbantartási oldalt, különösen ha a látogatókat rosszindulatú szoftverre vagy adathalász oldalra irányítják át. A DirectAdmin esetén felfüggesztheti a domaint; máshol segíthet egy jelszó az egész weboldalra, vagy egy ideiglenes index.html fájl egy üzenettel.

3. Minden jelszó és kulcs lecserélése

Induljon ki abból, hogy a behatoló ismer minden jelszót, amely a weboldalon vagy azon keresztül megtalálható volt. Cserélje le, lehetőleg egy másik (tiszta) számítógépről:

• a tárhelykezelő fiók jelszavát és minden FTP- és SFTP-fiók jelszavát (törölje a nem használt fiókokat);
• az adatbázis-felhasználó jelszavát, és állítsa be a wp-config.php fájlban is;
• minden WordPress-adminisztrátor jelszavát, és törölje az Ön számára ismeretlen fiókokat;
• a kulcsokat és salt-okat a wp-config.php fájlban (1.3. lecke). Ezzel minden bejelentkezési süti érvényét veszti, beleértve a behatolóét is;
• alkalmazásjelszavakat (3.3. lecke) és az összekapcsolt szolgáltatások API-kulcsait;
• e-mail jelszavakat, ha spam ment ki egy postafiókon keresztül.

Ezután kapcsolja be a kétlépcsős azonosítást mindenhol (7.3. lecke).

4. A behatolási pont megtalálása

A behatolási pont ismerete nélkül nem lehet biztos abban, hogy a rés be van zárva. A leggyakoribb okok (7.1. lecke), és hol keresse őket:

• Elavult bővítmény vagy sablon: mely elemek maradtak le a frissítésekkel? Keresse meg a neveket egy sebezhetőség-adatbázisban (5.3. lecke).
• Kiszivárgott jelszó: nézze meg a tárhelykezelő fiók és az FTP bejelentkezési előzményeit.
• A webszerver naplói: keressen a legelső furcsa fájlok megjelenésének időpontja körül olyan POST-kéréseket, amelyek ismeretlen fájlokra vagy bővítményfájlokra érkeztek, gyakran ugyanarról az IP-címről.
• Fájlok dátum szerint: rendezze a Fájlkezelőben vagy SFTP-n keresztül módosítási dátum szerint. Azok a fájlok, amelyek egyszerre módosultak, különösen frissítésen kívül, különös figyelmet érdemelnek.

5. Tisztítás

Két megoldás, és gyakran ezek kombinációja:

A. Tiszta biztonsági mentés visszaállítása a feltörés előtti időpontból (8.2. lecke). Válasszon olyan biztonsági mentést, amely biztosan a legelső jelek előtti, mert a behatolók néha heteket várnak. Állítsa vissza teljesen, hogy a hozzáadott fájlok is eltűnjenek. Ezután azonnal frissítsen mindent (különben a rés ismét ott lesz). Hátrány: minden, ami a biztonsági mentés óta történt (bejegyzések, rendelések), elveszik.

B. Tiszta újraépítés a meglévő tartalommal:

1. Cserélje le magát a WordPress-t egy friss másolatra a wordpress.org oldalról (wp-admin, wp-includes és a külön fájlok; nem a wp-content és a wp-config.php). A WP-CLI segítségével előbb megnézheti, mi változott:

wp core verify-checksums
wp plugin verify-checksums --all

Ezek a fájlokat összehasonlítják a hivatalos verziókkal, és jelzik az összes módosított vagy hozzáadott fájlt (a második csak a wordpress.org bővítménytárában lévő bővítményekre vonatkozik).

2. Törölje az összes bővítményt és sablont, és telepítse őket újra a forrásból, a legújabb verzióban. Amire nincs szüksége, az nem tér vissza.
3. Ellenőrizze a wp-content/uploads mappát PHP-fájlok és egyéb nem médiafájlok szempontjából, valamint a wp-content/mu-plugins mappát.
4. Ellenőrizze a .htaccess fájlt furcsa átirányítási szabályok szempontjából, és a wp-config.php fájlt ismeretlen sorok szempontjából.
5. Ellenőrizze az adatbázist: ismeretlen adminisztrátorok, a siteurl, home és active_plugins beállítások a wp_options táblában, és keressen a bejegyzésekben beillesztett szkripteket (<script furcsa címekkel).
6. Nézze meg az ütemezett feladatokat: cronjobokat a tárhelykezelő fiókjában és a WP-Cron esetében (egy bővítménnyel vagy a wp cron event list paranccsal).

Egy rosszindulatú kód szkenner (a tárhelyszolgáltatójától vagy egy bővítmény) segít a keresésben, de ne bízzon vakon benne: amit nem talál meg, az még ott lehet.

6. Lezárás és ellenőrzés

• Frissítsen mindent, erősítse meg a védelmet (7.4. lecke), és kapcsolja vissza a weboldalt.
• Nem biztonságosként jelöli a Google a weboldalát? Kérjen a Search Console-ban a Biztonsági problémák résznél új felülvizsgálatot, de csak miután minden tiszta.
• Figyelje az azt követő heteket: új fájlok, új adminisztrátorok, a szkenner jelzései. Ha a probléma visszatér, a behatolási pont vagy egy hátsó kapu még nem lett megtalálva.

Személyes adatok: adatvédelmi incidens bejelentése

Ha a behatolók hozzáférhettek személyes adatokhoz (egy webáruház ügyféladataihoz, űrlapbeküldésekhez, tagsági listákhoz, a weboldal felhasználóihoz), akkor a GDPR értelmében adatvédelmi incidensről van szó. Ezt a felfedezéstől számított 72 órán belül be kell jelentenie a felügyeleti hatóságnak (Magyarországon: Nemzeti Adatvédelmi és Információszabadság Hatóság, NAIH), kivéve ha nem valószínű, hogy kockázatot jelent az érintettek számára (GDPR 33. cikk). Ha a kockázat magas, az érintetteket is tájékoztatnia kell (34. cikk). Mindenképpen dokumentálja, mi történt és mit tett, akkor is, ha nem jelenti be. Ha bizonytalan, nézze meg az Ön országának adatvédelmi hatósága (Magyarországon a NAIH) honlapját (9.3. lecke).

Segítség kérése

Egy feltörés megtisztítása időt és tapasztalatot igényel. Ha nem biztos abban, hogy mindent megtett, kérjen segítséget: a weboldalkészítőjétől, egy erre szakosodott cégtől, vagy a tárhelyszolgáltatójától (egyes tárhelyszolgáltatók, köztük a WebOké is, kínálnak ilyen szolgáltatást, általában díj ellenében). Adja át nekik az 1. lépésben készített másolatot, azt, hogy mit és mikor látott, valamint amit már megtett.

Összefoglalás

• Egy feltörés gyakran hátsó kaput hagy maga után; önmagában nem elég eltávolítani a látható kárt.
• Sorrend: dokumentálás, a látogatók védelme, minden jelszó és salt lecserélése, a behatolási pont megtalálása, tisztítás, lezárás és ellenőrzés.
• A tisztítás történhet egy jóval a feltörés előtti tiszta biztonsági mentéssel, vagy a WordPress, a bővítmények és a sablonok friss telepítésével, valamint az uploads, mu-plugins, .htaccess és az adatbázis átvizsgálásával.
• A wp core verify-checksums megmutatja, mely WordPress-fájlok változtak meg.
• Ha személyes adatokról van szó, jelentse be az adatvédelmi incidenst 72 órán belül a felügyeleti hatóságnak (Magyarországon a NAIH-nak), kivéve ha a kockázat nem valószínű.

Kvíz

Feladat

D7.5. feladat: Vészterve egy feltörés esetére. Töltse ki a vésztervet a saját weboldalára, hogy ne kelljen kitalálnia, amikor sor kerül rá: hol találhatók a biztonsági mentései, és mennyire régiek a legrégebbiek, ki rendelkezik milyen jelszavakkal, és hogyan cseréli le mindet (lista), hol találja a tárhelyszolgáltatása naplóit, kit hív segítségért, és milyen személyes adatok vannak a weboldalán (a kérdés eldöntéséhez, hogy kell-e adatvédelmi incidenst bejelentenie). Ezután végezze el a gyakorlatot: melyik öt lépést teszi meg az első órában, ha megkapja a "Ez a webhely feltörésre kerülhetett" üzenetet, milyen sorrendben, és miért ebben a sorrendben?

További olvasnivaló

Ezek a cikkek a WebOké vezérlőpultjaiban leírt lépéseket mutatják be; más vezérlőpultokon hasonlóan működnek.

• DirectAdmin útmutató 18.2: A weboldalamat feltörték: lépésről lépésre útmutató
• Segítség! Feltörték a weboldalamat. Hogyan háríthatom el, és hogyan előzhetem meg?
• DirectAdmin útmutató 15.11: Imunify360: a weboldal vizsgálata kártevők szempontjából
• DirectAdmin útmutató 17.2: Oldal áttekintés és naplók: a hibanapló és a hozzáférési napló
• DirectAdmin útmutató 3.4: Bejelentkezési előzmények: ki és mikor jelentkezett be?
• Adatvédelmi incidensek (holland adatvédelmi hatóság, Autoriteit Persoonsgegevens): https://www.autoriteitpersoonsgegevens.nl/themas/beveiliging/datalekken
• GYIK: feltörték a weboldalamat (wordpress.org, angol nyelven): https://wordpress.org/documentation/article/faq-my-site-was-hacked/