A Devops blog visszaállítja a szervert a hackelés után

A kiszolgáló visszaállítása a hackelés után

Tehát nézzünk egy példát egy olyan kiszolgálóra, amelyet feltörtek egy kizsákmányolás letöltésével a php parancsfájl hibáján keresztül, elindítva rajta keresztül, és hozzáféréssel a shellhez a webszerver jogaival. Ezt ékesszólóan mindenki számára írható könyvtárak "nyomai" jelzik: / tmp, / var / tmp, / dev / shm.

[hirdetés ad-5]

A hackelés elkerülhető ebben a szakaszban az ideiglenes fájlok partícióinak telepítése nélkül a futtatás jogával, a veszélyes php-funkciók letiltásával és csak egy alaposabb kóddal a PHP-ben. Azonban semmi sem történt.
A hacker nem vesztegette az idejét. Feltöltötte a különböző kihasználásokat, összeállította őket, és az indítás után gyökérkezelést kapott, az egyik sebezhetőséggel.
És ezen a ponton megakadályozhatja, hogy letiltja a wget-et és a fordítóprogramokat a hátrányos helyzetű felhasználók számára, és olyan javítást tesz, amely megakadályozza a kódfuttatást a veremben vagy a libsafe-ben. De sajnos, és nem történt meg.
A helyzet vegyes volt. Egyrészt - nagyon fontos adatok, amelyek elvesztése kritikus, másrészt - a backdor probléma, amikor egy hacker egy felhasználóhoz jöhet, vagy egy bizonyos csomagkészletet küld a démonhoz, amely a portot hallgatja. Úgy döntöttek, hogy helyreállítják a kiszolgálót, és gondosan figyelemmel kísérik.
Miután megszüntettek olyan folyamatokat, amelyeknek nyilvánvalóan valami idegen volt a rendszerben, az első dolog lett telepítve, frissítve és elindították a rkhunter-et, egy trójai vadászatra.
A rkhunter következtetése csalódást okozott - legalább két rootkit, sok megváltozott bináris.
Ebben a helyzetben csak egy dolog fog segíteni - a rootkit-t fertőzött gyökércsíkot tiszta eszközzel helyettesíteni. Azonban tudnia kell, hogy melyik binárisokat kell kicserélni. De itt egy kicsit szerencsés. A hacker az attribútumokat a módosított fájlokra helyezi, amelyek tiltják a fájl megváltoztatását, törlését vagy kicserélését. A csak a chmod számára ismerõs neofiták esetében ez a rendszer által a hacker által fertõzött binárisok ellenõrzését okozza, de nem írják felül, bár az íráshoz való jog.
Miután létrehozta a fertőzött binárisok listáját, az összes attribútumot parancsokkal visszaállította

chattr -iacsuASDd / bin / *
chattr -iacsuASDd / sin / *
chattr -iacsuASDd / sbin / *
chattr -iacsuASDd / usr / sbin / *
chattr -iacsuASDd / usr / bin / *
chattr -iacsuASDd / usr / local / bin / *
chattr -iacsuASDd / usr / local / sbin / *

Azonban számos olyan bináris, amely nem védett a változástól, még mindig fertőzött. Ezt rkhunter mutatta. Így világossá vált, hogy ez egy rendkívüli cracker, aki kifejezetten elhagyta a feltört fájlokat annak helyreállítása érdekében. Ennek megfelelõen a rendszer háttértárolója van telepítve.
Emellett számos csapat nem működött, bár rkhunter nem mutatta meg. Például a felső nem mutatott több folyamatot a rendszerben. Nyilvánvaló, hogy a fertőzés a kernel modul szintjén volt, amely a fertőzött binárisok titkos védelmét biztosította.
Azonban a hacker nem számolt arra, hogy az RPM-alapú Linux disztribúciókban lehetőség van arra, hogy megtudja, módosította-e a fájlt rpm-enként.
Az eljárás meglehetősen egyszerű - először megtudjuk, hol található a gyanús bináris, például:

Ez a parancs visszaadja a teljes elérési utat a / usr / bin / top segédprogramhoz. Most az rpm-sel kapcsolatban megtudjuk, melyik csomagba tartozik ez a fájl:

rpm -qf / usr / bin / top

Ez a parancs megmondja, hogy a legfelső segédprogram szerepel a procps csomagban. Telepítse újra az apt parancs használatával:

apt-get -reinstall install procps

A telepítés során volt egy üzenet, hogy az előző tete a /lib/libext-2.so.7 könyvtárhoz kapcsolódott. Talán ez a lopakodó mechanizmus része. Információ kérése a könyvtárról rpm-ről

rpm -qf /lib/libext-2.so.7

hogy a fájl nem része a rendszernek. Természetesen törölték:

chattr -iacsuASDd / lib / *
rm /lib/libext-2.so.7

Ezután több rejtett folyamatot fedeztek fel, amelyeket a killall segédprogram segítségével megöltek.
Természetesen nem csak a procpset kellett újratelepíteni, hanem számos egyéb csomagot is fel kellett volna hackelni: util-linux, psmisc, net-tools, kernel, dev, initscripts és még sokan mások.
A rendszermag cseréje után a kiszolgáló újraindult, és az összes fájl ellenőrzése a parancs segítségével történt

rpm -Va

A rendszerben közvetett jelzések adódtak. Egy kis kutatást követően a hátsó ajtót fedezték fel. Azt is felfedezték, hogy minden rendszerhasználó megváltoztatta a shell-et / bin / sh-re. Ily módon lehetővé tette a hívás visszahívását bármely felhasználó nevében. Az ilyen helyzet elkerülése érdekében számos nem kívánt szolgáltatást különítettek el, és új felhasználót hoztak létre, amely az ssh-n keresztül keresztülhaladhat a hálózaton keresztül a shell-be. Mindenki le volt tiltva.
Jelenleg nem észleltek jogosulatlan hozzáférési kísérleteket, ami azt mutatja, hogy a betörő nagyon magas szintű és nem hajlandó megvilágítani.

Ezt a történetet a feltört szerver tulajdonosa beleegyezésével írja le. Elmondása szerint mindössze annyi támogatást nyújtott a php apache-hoz. Nem is tudta ennek következményeit.

Légy éber! A nyári szünetben sok a hackelés. Védje a dedikált szervert, mielőtt feltörte. A különböző szinteken történő hackelés megakadályozása. És ami a legfontosabb - rendszeres időközönként ellenőrizze az ideiglenes fájlok könyvtárainak tartalmát. Lehetséges, hogy már van valami.

Különösen vigyázz a fájlokból kiinduló, vagy csak szóközökből álló fájlokról - ez a közvetlen bizonyíték a sikeres hackelésre.