A rosszindulatú Joomla kód eltávolítása. Joomla logbook rosszindulatú kód

Együtt kell csinálni. Ha megszünteti a feltörés eredeti okát (például a CMS-bővítmény biztonsági rését), de nem távolítja el az összes rosszindulatú fájlt, a támadó ismét hozzáférhet a webhelyhez valamelyik szkriptje segítségével. Ha eltávolítja az összes letöltött rosszindulatú szkriptet, de nem szünteti meg a feltörés okát, a támadó újra feltörheti a webhelyet, és újra letöltheti a szkripteket.

A megfelelő tudással és tapasztalattal rendelkező szakembernek el kell végeznie a rosszindulatú szkriptek eltávolítását és a hackelés okainak elemzését:

A rosszindulatú szkriptek eltávolításához a PHP programozási nyelv ismerete, valamint a népszerű CMS-ek (Joomla, WordPress stb.) és a hozzájuk tartozó bővítmények „belsejének” ismerete szükséges. Ez a tudás szükséges ahhoz, hogy a parancsfájlokat közvetlenül a CMS-től és a kiterjesztéseit megkülönböztessük az idegen fájloktól, és egyértelműen meg tudjuk határozni, milyen műveleteket hajtanak végre, ha kétes szkriptekkel találkozunk.
A hackelés okainak elemzéséhez szerveradminisztrációs tapasztalat szükséges. Erre azért van szükség, hogy elemezzük a fiókban lévő fájlok állapotát, módosításuk idejét, valamint ezen adatoknak a szervernaplókkal való összehasonlításához annak megállapításához, hogy a támadó mely műveletei vezettek webhelyek feltöréséhez.

Ezért, ha webhelyét feltörték, az ismételt feltörések elkerülése érdekében javasolt, hogy ne saját kezűleg végezze el a munkát, hanem forduljon szakemberhez, aki elvégzi a szükséges diagnosztikát, és javasolja vagy megteszi a szükséges lépéseket a probléma megoldásához, és ki tudja garantálni a kapott eredmény minőségét.

Vannak azonban olyan intézkedések, amelyek bizonyos esetekben segítik a helyreállítást biztonságos munkavégzés oldal speciális ismeretek nélkül. Az alábbi módszer korlátja, hogy ahhoz, hogy az oldal újra működjön, szükséges a jelenléte biztonsági másolat, amelyet a feltörés előtti időben hoztak létre. Ha a jogsértés dátuma ismeretlen, akkor a rendelkezésre álló legrégebbi biztonsági másolat használatával próbálkozhat ezzel a módszerrel. A második korlátozás az elsőből következően az, hogy a webhely visszaállítása után a biztonsági mentés visszaállítása után hozzáadott adatok (például új cikkek, képek vagy dokumentumok) jönnek létre. Ha az új adatok megőrzése mellett vissza kell állítania a webhelyet, forduljon szakemberhez.

Ezek az intézkedések nem teszik lehetővé, hogy meghatározzuk a webhely feltörésének okát, de mindegyikük célja a behatolás egyik lehetséges okának megszüntetése. Mivel a feltörés pontos oka ismeretlen, mindegyiket végre kell hajtani. A műveletek olyan sorrendben vannak elrendezve, hogy először teljesen kiküszöböljék annak lehetőségét, hogy a támadó jelenleg továbbra is működjön az oldalon vagy a tárhelyfiókon, majd megakadályozza, hogy a támadó a jövőben behatoljon az oldalra.

Az alábbi lépések feltételezik, hogy csak egy webhely van a tárhelyfiókjában. Ha több webhely is van a fiókban, akkor azokat is feltörhetik, és az oldalt rajtuk keresztül is feltörhetik. Vagy át kell vinni azt a helyet, amelyen a helyreállítási munkálatok zajlanak, egy külön fiókba, vagy egyidejűleg a fiókban tárolt összes webhely helyreállítását kell elvégezni.

A műveletek sorrendje fontos, ezért azokat pontosan abban a sorrendben kell végrehajtani, amelyben lent találhatók.

Közvetlenül azután, hogy felfedezték, hogy egy webhelyet feltörtek, teljesen le kell tiltani a látogatók hozzáférését. Ez egyrészt megakadályozza, hogy a támadó rosszindulatú tevékenységeket hajtson végre a webhelyen, másrészt pedig nem akadályozza meg a helyreállítási munkálatokat. Ez a lépés nagyon fontos, mivel a rosszindulatú szkriptek eltávolítása és a feltörés okának megszüntetése nem megy egyik napról a másikra - általában több órát vesz igénybe. Ha a webhely kívülről elérhető marad, a támadó újra fel tudja tölteni a szkripteket a webhely már törölt részébe. Ebben az esetben a támadó különböző IP-címeket használhat a csatlakozáshoz, így a hozzáférés megtagadása csak az IP-címek listájához nem működik. Annak érdekében, hogy a webhely megtisztuljon az észlelt rosszindulatú szkriptektől, teljesen meg kell akadályozni, hogy egy támadó hozzáférjen a webhelyhez, ami csak a teljes blokkolás webhely minden látogató számára. A letiltásához lépjen kapcsolatba a webhelyét üzemeltető tárhely technikai támogatási szolgálatával.

A webhely blokkolása után frissített vírusadatbázisokkal rendelkező modern víruskeresővel kell ellenőriznie azokat a számítógépeket, amelyekről az oldallal dolgozott. Ha a webhelyet úgy törték fel, hogy vírussal ellopták a fiók jelszavait, akkor erről meg kell győződnie további munka egy feltört webhelyet olyan számítógépről hajtanak végre, amelyen nincsenek vírusok, különben a hozzáférési jelszavak megváltoztatása után újra ellophatják őket.

A webhely blokkolása és a vírusok ellenőrzése után meg kell változtatnia fiókja összes hozzáférési jelszavát: FTP-n keresztül, SSH-n keresztül, valamint a tárhely vezérlőpultjához való hozzáférést. Ha egy támadó a fenti módszerek valamelyikével hozzáfért a fiókfájlokhoz, a jelszavak megváltoztatása után ezt már nem tudja megtenni.

A jelszavak megváltoztatása után meg kell semmisítenie az összes, a webhelyet fenntartó fiók alatt futó szerverfolyamatot. Egy támadó indította be háttér A folyamatok anélkül, hogy megsemmisülnének, a helyreállítási munkálatok után újra elhelyezhetik a rosszindulatú szkripteket a webhelyen. Ennek elkerülése érdekében minden, a webhely blokkolása előtt futó folyamatot meg kell semmisíteni. A webhelyet ebben a pillanatban már le kell tiltani, hogy a támadó ne tudjon új folyamatokat indítani a webhelyen található egyik szkriptjének elérésével. A fiókjában futó folyamatok megsemmisítéséhez lépjen kapcsolatba a webhelyét üzemeltető tárhely technikai támogatási szolgálatával.

Most már lehetetlen kívülről behatolni a webhelyre, és megkezdheti a helyreállítását.

Előtt további akciók törölje az összes meglévő webhelyfájlt, hogy megbizonyosodjon arról, hogy nincsenek rosszindulatú szkriptek vagy CMS-szkriptek, amelyekbe a támadó rosszindulatú kódot illesztett be. Ez a lépés azért is fontos, mert amikor egy webhelyet biztonsági másolatból állít vissza, a visszaállítás előtt létező fájlok nem mindig törlődnek. Ha a biztonsági másolatból történő visszaállítás után régi rosszindulatú szkriptek maradnak a webhelyen, a támadó újra be tud lépni a webhelyre. Ezt elkerülheti, ha a helyreállítás végrehajtása előtt törli az összes webhelyfájlt.

Az összes webhelyfájl törlése után állítsa vissza a webhelyet a feltörés előtt készített biztonsági másolatból. Gyakran elegendő csak a webhely fájljait visszaállítani, de ha azok visszaállítása után hibákat észlelnek a webhely működésében, akkor a webhelyet teljesen vissza kell állítani: mind a fájlokat, mind az adatbázist.

A biztonsági másolatból történő visszaállítás után frissítse a tartalomkezelő rendszert (CMS) és a bővítményeket a legújabb verziókra. Erre azért van szükség, hogy kizárjuk a webhely ismert sebezhetőségeinek jelenlétét, amelyeken keresztül feltörhető. A frissítés általában a CMS adminisztrációs szakaszán keresztül végezhető el. Megszerzéséért teljes utasításokat A CMS frissítéséhez fel kell lépnie a rendszerfejlesztő webhelyére. Fontos, hogy ne csak magát a CMS-t frissítse, hanem annak összes bővítményét is, mivel a feltörések gyakran valamelyik CMS-bővítményben található sebezhetőségen keresztül történnek (például bővítmények, témák, widgetek stb.). Jelenleg még mindig lehetetlen feloldani a webhely blokkolását a látogatók számára, mivel az továbbra is sebezhető lehet. A frissítésekért az oldal eléréséhez vegye fel a kapcsolatot technikai támogatás az Ön webhelyét üzemeltető tárhelyszolgáltatót, és csak az Ön számítógépének IP-címéről kérheti a webhelyhez való hozzáférést. Megtudhatja IP-címét például az inet.yandex.ru webhelyen.

A webhelykezelő rendszer és bővítményeinek frissítése után lépjen a webhely adminisztrációs szakaszába, és módosítsa a rendszergazdai hozzáférési jelszót. Győződjön meg arról, hogy a webhely felhasználói között nincs más rendszergazdai jogosultságokkal rendelkező felhasználó (akár támadó is hozzáadhatta őket), és ha talál ilyet, törölje őket.

Most, hogy a webhelyet biztonsági másolatból visszaállították, és nem tartalmaz rosszindulatú szkripteket, a CMS és a kiterjesztései a következőre lettek frissítve. legújabb verziói, amelyben nincsenek sebezhetőségek, valamint megváltoztak az oldal hozzáférési jelszavai és a tárhelyfiók, újra megnyithatja az oldalt a látogatók előtt.

Valamennyi fenti műveletet a megadott sorrendben, kihagyások és változtatások nélkül kell végrehajtani. Ha a műveleteket pontatlanul hajtják végre, akkor rosszindulatú szkriptek vagy sebezhetőségek maradhatnak az oldalon, aminek következtében egy támadó rövid időn belül újra feltörheti. Ha valamilyen oknál fogva nem lehet végrehajtani a fenti lépéseket a feltüntetett formában, forduljon szakemberhez a webhely feltörése utáni helyreállításához.

Ahhoz, hogy webhelyét a jövőben megóvja az ismételt feltörésektől, tartsa be a következő ajánlásokat:

Kövesse nyomon a CMS frissítéseit és a hozzá tartozó bővítményeket a fejlesztők webhelyein, és azonnal frissítse azokat a legújabb verziókra. Ha egy frissítési megjegyzés azt állítja, hogy a frissítés egy biztonsági rést javít, akkor a lehető leghamarabb telepítse a frissítést.

Csak olyan számítógépekről dolgozzon a webhellyel és a tárhelyfiókkal, amelyeket folyamatosan frissített vírusadatbázisokkal rendelkező modern antivírusok védenek a vírusoktól.

Használjon összetett jelszavakat, hogy ne lehessen őket kitalálni szótári kereséssel.

Ne mentse az FTP- és SSH-jelszavakat a webhelyhez való csatlakozásra szolgáló programokba, és ne mentse el a hozzáférési jelszót a webhely adminisztrációs területére és a böngésző tárhely-vezérlőpultjára.

Időnként (például háromhavonta) módosítsa a webhelyhez és a tárhelyfiókhoz való hozzáférés jelszavait.

Ha vírusokat észleltek azon a számítógépen, amelyről az oldallal dolgozott, a lehető leggyorsabban módosítsa a webhely és a tárhelyfiók hozzáférési jelszavait. Meg kell változtatni az összes jelszót: hozzáférési jelszavakat FTP-n, SSH-n keresztül, jelszót a webhely adminisztrációs paneljéről, valamint a jelszót a hosting vezérlőpultról.

Ne biztosítson hozzáférést az oldalhoz harmadik feleknek, hacsak nem biztos abban, hogy ők is betartják ezeket az irányelveket.

Ha SSH-n keresztül fér hozzá a webhelyhez, a következő parancsok futtatásával találhatja meg a beadott kódot tartalmazó fájlokat:

#grep -lr --include=*.php "eval(base64_decode" /pathWebroot #grep -lr --include=*.php "strrev(" /pathWebroot)

Ha nincs hozzáférés, megkérheti a tárhely-támogatási szolgálatot, hogy végezze el ezt Ön helyett, és küldjön jelentést.

Íme egy példa a listára: ./components/com_wrapper/wrapper.php ./components/com_wrapper/controller.php ./components/com_wrapper/router.php ./components/com_wrapper/views/wrapper/view.html.php ./ összetevő html. php ./components/com_finder/helpers/route.php ./components/com_finder/helpers/html/filter.php ./components/com_finder/helpers/html/query.php ./components/com_finder/controllers/suggestions. json. php ./components/com_jshopping/tables/productfiles.php ./components/com_jshopping/tables/statictext.php ./components/com_jshopping/tables/country.php ./components/com_jshopping/tables/productlabel.php . /com_jshopping /tables/shippingext.php .... ./administrator/components/com_jshopping/controllers/orderstatus.php ./administrator/components/com_jshopping/controllers/shippingsprices.php ./administrator/components/com_jshopping/controllers/ php . /administrator/components/com_jshopping/controllers/productlabels.php ./administrator/components/com_jshopping/controllers/categories.php ./administrator/components/com_cache/cache.php ./administrator/components/com_cachemo.del php . /administrator/components/com_cache/controller.php ./administrator/components/com_cache/views/purge/view.html.php ./administrator/components/com_cache/views/cache/view.html.php ./administrator/ Components/com_cache/helpers/cache.php ./administrator/components/com_content/tables/featured.php

Összesen 1606 alkalommal. Gyakorlatilag ennyi PHP fájl s. A beinjektált kód manuális eltávolítása haszontalan. Ez túl sok időt vesz igénybe. Felfedezte és új fájl images/post.php bármely kód futtatásához.

A rosszindulatú kód eltávolítása a fertőzött fájlokból

Először készítsen teljes biztonsági másolatot webhelyéről arra az esetre, ha valami baj lenne.

Ha webhelyének azonnali funkcionalitása nagyon fontos Önnek, egyszerű parancsok futtatásával eltávolíthatja a beszúrt kódot.

#grep -lr --include=*.php "eval(base64_decode" /pathWebroot | xargs sed -i.bak "s/eval(base64_decode[^;]*;//" #grep -lr --include=*. php "strrev(" /pathWebroot | xargs sed -i._bak "s/$_ = strrev([^;]*; @$_([^;]*;//")

A parancsok eltávolítják az ilyen rosszindulatú kódok minden előfordulását a fájlokból, és biztonsági másolatot készítenek róluk a .bak kiterjesztéssel. Ezzel csak időt nyerhet a webhely teljes helyreállításához, de nem menti meg a későbbi támadásoktól. Meg kell érteni, hogy nagy a valószínűsége annak, hogy a fent leírt fájlok, például az images/post.php, bármilyen kód végrehajtásához és régi lyukak telepítéséhez a telepített kiterjesztésekben találhatók.

Harmadik féltől származó bővítmények

Ha nem fosztották meg a webhely adminisztrációs paneljét, megtekintheti a telepített összetevőket, modulokat, bővítményeket és sablonokat. Ha nincs hozzáférés, akkor FTP-n vagy SSH-n keresztül csatlakozva meg kell tekintenie az oldal tartalmát.

Tekintse meg a modulok listáját #ls ./modules index.html mod_banners mod_login mod_users_latest mod_articles_archive mod_breadcrumbs mod_menu mod_weblinks mod_articles_categories mod_custom mod_random_image mod_whosonline mod_related mod_articles_fems_category der mod_search mod_articles_new s mod_footer mod_stats mod_articles_popular mod_languages mod_syndicate #ls ./administrator/modules index. html mod_latest mod_menu mod_quickicon mod_title mod_custom mod_logged mod_multilangstatus mod_status mod_toolbar mod_feed mod_login mod_popular mod_submenu mod_version

Csak szabványos Joomla modulokat használnak

Tekintse meg az összetevők listáját #ls ./components com_banners com_finder com_media com_search com_wrapper com_contact com_jshopping com_newsfeeds com_users index.html com_content com_mailto com_phocapdf com_weblinks _installer com_weblinks _installer_com_adfcom/s. _media com_phoca pdf com_users com_banners com_contact com_joomlaupdate com_menus com_plugins com_weblinks com_cache com_content com_jshopping com_messages com_redirect index. html com_categories com_cpanel com_languages com_modules com_search com_checkin com_finder com_login com_newsfeeds com_templates

A szabványos komponensek mellett a com_jshopping és a com_phocapdf is használatos.

Tekintse meg a bővítmények listáját #ls ./plugins hitelesítés tartalomszerkesztők-xtd kereső phocapdf kereső felhasználó captcha szerkesztők kiterjesztése index.html gyorsikon rendszer

Ezenkívül meg kell tekintenie ezen mappák tartalmát. Ezek beépülő modulok csoportjai.

#ls ./plugins/authentication gmail index.html joomla ldap #ls ./plugins/captcha index.html recaptcha #ls ./plugins/content emailcloak geshi joomla pagebreak rokbox kereső index.html loadmodule oldalnavigáció szavazás #ls/editorsplu codemirror index.html none tinymce #ls ./plugins/editors-xtd cikk kép index.html oldaltörés tovább #ls ./plugins/extension index.html joomla #ls ./plugins/finder kategóriák kapcsolattartók tartalom index.html hírfolyamok weblinkek #ls ./plugins/quickicon extensionupdate index.html joomlaupdate #ls ./plugins/search kategóriák névjegyek tartalom index.html hírfolyamok webhivatkozások #ls ./plugins/rendszer gyorsítótár kiemelés nyelvkód napló p3p emlékszem sef debug index.html nyelvszűrő kijelentkezés átirányítás rokbox #ls . /plugins/user contactcreator index.html joomla profil

A szabványos beépülő modulok mellett a phocapdf bővítmény is használatos.

Tekintse meg a sablonok listáját #ls ./templates atomic beez_20 beez5 index.html rendszersablon1

A szabványos sablonok mellett a templ1 is használatos.

Fertőzött webhely helyreállítása

Töltse le a legújabb kiadás terjesztési készletét, csomagolja ki az archívumot a jövőbeli webhely könyvtárába, és törölje a telepítési könyvtárat onnan.
Nevezze át a htaccess.txt fájlt .htaccess névre. Ha olyan utasításokat használt, amelyeket Ön írt le, vigye át azokat a fertőzött példányból.
A konfiguráció.php fájlt kimásoljuk a fertőzött másolatról, miután előzőleg ellenőriztük, hogy nincs-e benne beinjektált kód.

Harmadik féltől származó bővítmények

Megtaláljuk a használt harmadik féltől származó Phoca PDF, JoomShopping összetevőket, a "Phoca PDF Content Plugin" bővítményt, letöltés.
Kicsomagoljuk és átmásoljuk a fájlokat, miután korábban létrehoztunk egy, a fertőzött példányhoz hasonló könyvtárstruktúrát. Ne feledkezzünk meg a lokalizációs fájlokról.

A sablon helyzete kicsit bonyolultabb. A sablont speciális szoftver hozta létre, és nem található. Ki kell majd "kiszednünk belőle mindent, ami felesleges".

Szerencsére 21 PHP fájl van a sablonban, és az összes beszúrt kódot eltávolítottuk a #grep -lr --include=*.php "strrev(" /pathWebroot | xargs sed -i._bak "s/$_ = strrev([^ ;]*; @$_([^;]*;//"

Saját fájlok

Hozzon létre könyvtárakat, ahol képeket, dokumentumokat és egyéb fájlokat tárol, és másolja őket.

A webhelynek azonnal működnie kell, amint lecseréli a régi tartalmat az újra.

Lépjen a webhely adminisztrációs paneljére, módosítsa a CMS-hez való hozzáféréshez használt felhasználónevet és jelszót, és ellenőrizze, hogy a SuperUsers e-mail-címe le lett-e cserélve (a támadó a funkció segítségével visszaállíthatja az elfelejtett jelszót). Soha ne használja a szokásos admin felhasználónevet. Gondosan ellenőrizze az összes felhasználó jogait. Nem zárható ki annak lehetősége, hogy egy támadó másik rendszergazdát telepítsen.

Cserélje ki a felhasználónevet és az adatbázis jelszavát MySQL adatok, ha a szabványos jos_ adatbázistábla előtagot használjuk, akkor azt le kell cserélni egy másikra, ez megakadályozza az SQL injekciós támadás lehetőségét.

A helyreállítási munka végeztével telepítse a BotsGo404 bővítményt.

Ha hasznosnak találta ezt a cikket, szavazzon rá. Ez segít másoknak, hogy gyorsabban megtalálják ezt a cikket sok más, kevésbé hasznos cikk közül.(17 szavazat)

A Joomla nem csak az egyik legnépszerűbb CMS az interneten. Sajnos ez a tartalomkezelő rendszer a leginkább érzékeny a hackertámadásokra. Ma arról fogunk beszélni, hogy mit tegyünk, ha Joomla webhelyét feltörték, valamint megvizsgáljuk a megelőző intézkedéseket és a behatolók elleni küzdelmet.

Az olvasókkal folytatott kommunikáció kénytelen volt beilleszteni egy bekezdést. Nem adunk ingyenes vagy fizetős tanácsadást az Ön oldalának feltörésével kapcsolatban, de készek vagyunk fizetős szolgáltatást nyújtani az oldal hackertámadás utáni kezelésére és helyreállítására.

Miért törnek fel a hackerek egy webhelyet?

Nem veszek figyelembe olyan egzotikus eseteket, amikor egy webhely elleni támadást szándékosan, információszerzés céljából hajtanak végre. Mert amikor bizalmas adatokat helyezünk el az interneten, a Joomla kivételével bármit felhasználnak. A modern hackerek motivációja meglehetősen világos, és három fő részre osztható.

Támadó webhelyének reklámozása.

Olyan szkriptek kerülnek bevezetésre, amelyek a támadó webhelyére mutató hivatkozásokkal töltik meg az oldalakat. Átirányítási lehetőség lehetséges, amikor a látogatót azonnal elküldik a hacker által kívánt irányba.

Gyakran előfordul, hogy egy támadó hozzáfér az adatbázishoz és az adminisztrációs panelhez, és Ön mások cikkeit és híreit találja az anyagok listájában.

Hackelés a hacker önbecsülésének növelésére

A Joomla fájlok teljesen törölhetők, vagy támadó szkriptekkel helyettesíthetők. Nagy a valószínűsége annak, hogy a látogató valami piros és sötét színben fog látni valamit, ahol az lesz írva, hogy a hackelést egy csodálatos törökországi srác hajtotta végre.

Spam küldése webhelye nevében.

2015-ben a legtöbb feltörés emiatt történt.

Mi az algoritmus a rosszindulatú szkriptek és támadók működéséhez?

A webhely elleni támadást a Joomla CMS vagy összetevő egy biztonsági rése hajtja végre. Vannak esetek, amikor rosszindulatú kód kezdetben jelen van egy telepített bővítményben.

Ez azokra az összetevőkre, bővítményekre és modulokra vonatkozik, amelyeket illegálisan töltöttek le.

Az oldalra való behatolás eredményeként számos script fájl jelenik meg a különböző Joomla könyvtárakban.

A fájlok neve és könyvtárakban való elhelyezése olyan, hogy első pillantásra nem könnyű megkülönböztetni a rosszindulatú szkripteket a „natív” Joomla-fájloktól. Emiatt a webhely „kezelése” gyakran hiányos, és néhány nap vagy hét elteltével újabb köteg spam távozik a domain nevében.

A technikai támogatás szinte azonnal fenyegető levelet küld Önnek, amelyben felajánlja a biztonsági probléma megoldását. A tétlenség a fiók letiltásával és a webhely leállításával fenyeget.

Mi a teendő, ha egy Joomla webhelyet feltörtek?

A rosszindulatú szkriptek elleni háború kezdete a tárhelyszolgáltatójával kezdődik. Valószínűleg az ő levele adja az utat a katonai akcióhoz

Sikerük nagyban függ attól, hogy a hosting cég milyen eszközöket bocsát az Ön rendelkezésére. Felsorolom a főbbeket:

A tárhelybe beépített víruskereső panel. Általában nem végez fertőtlenítést, de segít megtalálni a rosszindulatú szkriptek jelentős részét

Hozzáférés SSH-n keresztül. Enélkül lehetetlen a vírusok elleni teljes küzdelemről beszélni.

Gyors és szakképzett műszaki támogatás

Napi biztonsági mentés. Az ideális lehetőség az egy hónappal ezelőtti másolat visszaállítása vagy letöltése

Ha a tárhelyszolgáltató nem biztosít víruskeresőt szoftver(beépíthető a tárhelypanelbe, vagy kérésére a tárhelyszolgáltató önállóan is elindíthatja) - fogd meg a fertőzött oldaladat és változtasd meg a tárhely szolgáltatást nyújtó céget. A piac egyszerűen tele van ilyen ajánlatokkal.

A legtöbb webhely a következő helyen található virtuális tárhely, és mind a négy felsorolt ponton egy masszív ötöst adnék a cégnek, amelynek linkje lent található:

Teljesen más a történet, ha a teljes szervert béreljük. Az első, a harmadik és a negyedik pont teljes mértékben az Ön lelkiismeretén lesz. És a második pont magától értetődik.

Hackelési eljárás

1. lépés: Tisztítsa meg a webhelyet rosszindulatú fájlok

Általános szabály, hogy nem telik el sok idő a feltöréstől a technikai támogatástól kapott levélig. Ritka esetekben maga a webhely tulajdonosa fedez fel egy feltörést.

A legegyszerűbb módja a webhely visszaállítása nem fertőzött biztonsági másolatból. Ez azonban csak akkor alkalmas, ha hosszú ideig nem történt változtatás az oldalon.

A rendszeresen frissített oldalon a keresést manuálisan kell végrehajtani. És ezt SSH-n keresztül. A feladat rendkívül egyszerű lesz. Meg kell találnia, hogy mely fájlok változtak a közelmúltban. Például egy hét múlva. Mert operációs rendszer A Debian parancs így nézne ki:

keresse meg a /könyvtárat, ahol a keresést végrehajtják/ -type f -mtime -7

Ennek a parancsnak megfelelően a rendszer megjeleníti azokat a fájlokat, amelyek az elmúlt 7 nap során megváltoztak. Figyelünk a PHP kiterjesztésű fájlokra.

Ők azok, akik veszélyt jelentenek. Ugyanakkor meg kell értenie, hogy a megjelenített fájlok némelyike nem fertőzött, és magához a Joomlához tartozik. Ezért kéznél kell lennie a működő verzió eredeti terjesztésének Ebben a pillanatban.

A képernyőképen két fájlt látunk. Az első valószínűleg vírus. A második az rendszerfájl Joomla.

Honnan vannak ilyen következtetések?

A helyzet az, hogy a /components/com_weblinks/views/category/ könyvtárban elvileg nem szabad start.php fájlnak lennie.

A /logs/ könyvtárban található error.php fájl pedig a CMS része. Ha azonban kifejezetten törli, semmi kritikus nem történik, mivel a Joomla naplók tárolására szolgál.

2. lépés: Védje meg a webhelyet a feltöréstől

Tegyük fel, hogy sikeresen eltávolította az összes rosszindulatú szkriptet. A tárhely technikai támogatása és víruskereső jelentése: "igen, minden tiszta." Mit kell tenni, hogy ez ne forduljon elő?

A Joomla és a bővítmények frissítése a legújabb verzióra

Ha webhelye a Joomla 3.X-ig terjedő verzióján fut, van még egy ok, hogy fontolja meg a frissítést. Az utóbbi időben sok tárhelyszolgáltató ragaszkodik ehhez.

Ezzel nem oldódik meg 100 százalékosan a biztonsági probléma, de a jövőben lehetőség nyílik a rendszer gyors frissítésére és egy gombnyomással telepíthető biztonsági javítások, amelyek az utóbbi időben szinte hetente megjelentek.

Különös figyelmet szeretnék fordítani telepített bővítmények a webhelyén. Minden összetevőt, beépülő modult, modult is frissíteni kell a legújabb verzióra. Végezzen ellenőrzést webhelye adminisztrációs paneljén.

Minden kiterjesztést használnak?

Az alacsony képzettség miatt a modern webmesterek minden problémát megoldanak egy plugin vagy modul telepítésével, bár elegendő néhány sort hozzáadni a webhely sablon kódjához. Vagy módosítsa a CSS-t.

Minél kevesebb további bővítmény található a webhelyen, annál kisebb a valószínűsége annak, hogy feltörik!

RSFirewall komponens

A tartalomtól függetlenül a Joomla CMS-t futtató webhely minden nap ki van téve a támadásoknak. Riasztó rendszerességgel fordulnak elő a hackerek, akik kitalálják az adminisztrációs panel jelszavát, és megpróbálnak rosszindulatú kódot bevinni. Lehetetlen egyedül ellenállni a támadásoknak és a behatolásoknak.

Egy olyan komponensre szeretném felhívni a figyelmet, amely rengeteg, a weboldal biztonságával kapcsolatos problémát megold. A neve „RSFirewall”.

Tekintsük röviden az RSFirewall által megoldott főbb képességeket, funkciókat és feladatokat:

A rendszer ellenőrzése a sebezhetőségek szempontjából. A rendszer elemzi az adatbázist, a fájlokat és a környezetet, amelyben a webhely működik

A rendszeren lévő fájlok összehasonlítása az eredeti Joomla disztribúcióval. Ez nagyban leegyszerűsíti a fertőzött fájlok keresését.

Könyvtárak és fájlok jogainak elemzése.

Keressen rosszindulatú kódot tartalmazó fájlokat. A lista megjelenítése után manuálisan kell elemeznie az egyes fájlokat, mivel néhányuk teljesen normális működő kódnak bizonyulhat a Joomla kiterjesztések számára

A bejelentkezési kísérletek naplózása a Joomla adminisztrációs paneljére, valamint azon felhasználók blokkolásának lehetősége, akik bizonyos számú alkalommal rossz bejelentkezési nevet és jelszót adtak meg

Minden webhelylátogatás naplózása és azon IP-címek blokkolásának lehetősége, amelyekről feltörési kísérlet történt

Az oldalhoz való hozzáférés tilalma meghatározott országokból.

A komponens fizetős. A jelenlegi verzió kizárólag a Joomla 3.X verzióihoz érhető el

A cikk írásakor három változatban terjesztik. Az alábbiakban egy táblázat mutatja a költségeket, az előfizetési feltételeket és egy linket arra az oldalra, ahol ezt az előfizetést vásárolt.

Az RSFirewallt az „alapértelmezett” lokalizáció segítségével fogjuk felfedezni. Vagyis a kezelőfelület nyelve az angol marad.

Az alkatrész telepítése szabványos, a bővítménykezelőn keresztül történik. Az összetevő telepítése után lépjen az „Összetevők – RSFirewall – Rendszerellenőrzés” részre.

Megnyílik egy oldal, ahol meg kell vizsgálnunk a Joomla és a szerver konfigurációját, hogy ellenáll-e a hackeléssel szemben. A következőket is keresni fogják:

Joomla fájlok, amelyek módosítottak, és különböznek az eredeti disztribúciótól

rosszindulatú fájlok

a könyvtárakhoz és fájlokhoz való jogok ellenőrzésre kerülnek

Az ellenőrzés megkezdéséhez kattintson a „Rendszerellenőrzés végrehajtása” gombra.

Tekintsük az elemzés eredményét.

Felül láthatja, hogy a komponens a webhely ellenőrzése után hány pontot vagy százalékot rendel hozzá. A „100” érték a legmagasabb pontszám. Jelenleg a tesztelt oldal csak 84 ponttal rendelkezik. Találjuk ki, miért.

Nézzük meg részletesen a listát, ne hagyjuk ki a zölddel kiemelt szöveget.

Joomla konfigurációs rész

Ellenőrizd, hogy a legújabb Joomla! Verzió – Ellenőrizze: ez telepített verzió A Joomla a legújabb. Amint látja, ezzel minden rendben van. A cikk írásakor a Joomla verziója 3.4.8 volt

Ellenőrizze, hogy a legújabb RSFirewall-e van-e! Verzió – Ellenőrizze: az RSFirewall összetevő telepített verziója a legújabb. Ez fontos jellemzője a rendszer biztonságát, mivel az összetevő nem csak a rosszindulatú szkriptek adatbázisát szerzi be, hanem folyamatosan változtatja a funkcionalitást a Joomlában felfedezett biztonsági réseknek megfelelően.

Gyenge adatbázis-jelszó ellenőrzése – Ebben az esetben az összetevő ellenőrzi az adatbázisjelszó feltörési ellenállását.

Annak ellenőrzése, hogy az alapértelmezett "admin" felhasználó aktív-e. - Biztonsági okokból a kiemelt webhely adminisztrátorának bejelentkezési nevének különböznie kell a széles körben használt „admin”-től. Ha a komponens ilyen bejelentkezési névvel rendelkező felhasználót talál az adatbázisban, figyelmeztetés jelenik meg.

Ellenőrzés, hogy beállítottad-e az FTP-jelszót - A Joomla telepítésének vagy beállításainak szerkesztésének szakaszában megengedett fatális hiba. Hozzáférés: FTP protokoll-ban jelzett konfigurációs fájl Joomla. Van egy ugyanilyen tragikus lehetőség is. A Joomla általános beállításainak mentésekor az adminisztrációs panel bejelentkezési neve és jelszava rögzítésre kerül az FTP hozzáférési mezőben. Ezért ügyelünk arra, hogy a konfiguráció.php fájl megfelelő paraméterei üresek legyenek.

Annak ellenőrzése, hogy engedélyezve vannak-e a keresőbarát URL-ek – Ellenőrzés: benne van-e Általános beállítások Joomla SEF URL támogatás.

A configuration.php sértetlenségének ellenőrzése — A configuration.php fájl helyességének és integritásának ellenőrzése.

Annak ellenőrzése, hogy valamelyik adminisztrátori felhasználónak nincs-e gyenge jelszava – A webhely kiemelt rendszergazdáinak összes jelszavának ellenőrzése repedésállóság szempontjából

A munkamenet élettartamának ellenőrzése - A munkamenet élettartamának ellenőrzése, amely a Joomla általános beállításaiban van beállítva. Ha ez meghaladja a 15 percet, figyelmeztetés jelenik meg.

Annak ellenőrzése, hogy vannak-e fájlok a Joomla! ideiglenes mappa – Ebben az esetben ellenőrizni kell, hogy a fájlok a Joomla ideiglenes könyvtárában találhatók-e. Alapértelmezés szerint ez a könyvtár a „tmp” mappa. Ezt a könyvtárat tisztán kell tartani, mert a bővítmények telepítése vagy a Joomla frissítése után szükségtelen archívumok és szkriptek lehetnek ott.

.htaccess keresése – A .htaccess fájl meglétének ellenőrzése. A Joomla telepítése után a htaccess.txt fájl alapértelmezés szerint a webhely gyökerében jön létre. Az Ön feladata, hogy nevezze át .htaccess névre. Pontosan úgy, ahogy meg van írva, ponttal az elején és .txt nélkül a végén

Ellenőrizzük, hogy a Joomla! az ideiglenes mappa nyilvánosan elérhető – Ellenőrzi, hogy az ideiglenes Joomla fájlok könyvtára elérhető-e a számára nyílt hozzáférésű. Mit kell ez alatt érteni? Egyszerűen fogalmazva, beírható-e olyan hivatkozás a böngésző címsorába, mint a www.yoursite.com/tmp?

Nem mindenki tudja, hogy el lehet helyezni egy ideiglenes könyvtárat úgy, hogy csak a Joomla szkriptek férhessenek hozzá. Elegendő egy tetszőleges nevű mappát létrehozni, magasabb szinten, mint a webhely található, és beírni a mappa elérési útját a configuration.php fájlba.

A munkamenetkezelő ellenőrzése – A munkamenetkezelő típusának ellenőrzése. Javasoljuk, hogy az értéket „Nem”-re állítsa. Ezt a Joomla általános beállításaiban lehet megtenni

Szerverkonfiguráció szakasz

Térjünk át a következő szakaszra, ahol a szerver konfigurációját elemeztük.

Látjuk, hogy a konfiguráció PHP direktívák az összetevő szempontjából nincs megfelelően konfigurálva.

Nem kell megérteni, hogy melyik irányelv miért felelős. Először azonban meg kell oldania a problémát a Joomla ideiglenes könyvtárával, amelyről fentebb írtam.

Másolja ide HDD számítógépét, és törölje a webhely gyökérkönyvtárából, mert csak tájékoztató jellegű, és megmondja a PHP direktívák jelentését, amelyeket be kell illesztenie a php.ini fájlba.

Hogy hogyan találja meg a szerveren, és hogy engedélyezett-e a hozzáférés, azt a tárhelyszolgáltatójánál kell egyeztetni. A PHP direktívák gyakran a tárhelypanel beállításainak módosításával módosulnak. Ezért itt nincs univerzális recept.

Szkennelési eredmény szakasz

Itt vannak a rendszer vizsgálatának eredményei. Eredményeik tanulmányozását javaslom.

A Joomla! (CMS) fájlok – be ez a szekció a CMS Joomla fájlok vizsgálatának eredménye megjelenik, és összehasonlítja az eredeti disztribúcióval a sértetlenség és a fájlok lehetséges módosításai szempontjából. Nem csak a szkriptek kerülnek összehasonlításra, hanem a kép- és CSS-fájlok is. Nos, ez minden.

A mappák ellenőrzése – FTP-n keresztül keresse fel mindegyiket, és győződjön meg arról, hogy mentes a rosszindulatú szkriptektől

Fájlok vizsgálata – ebben az esetben fájljogokról beszélünk. A műveleteknek ugyanazoknak kell lenniük, mint a könyvtárak esetében

Fájlok ellenőrzése gyakori rosszindulatú programok után – rosszindulatú kód keresése. Mint látható, az RSFirewall talált egy fájlt, és amikor elemezte azt szöveg szerkesztő, valóban rosszindulatúnak találták, és én eltávolítottam a szerverről.

Foglaljuk össze

Sajnos nem lehet egy anyagban lefedni az RSFirewall komponens összes képességét és beállítását. A következő cikkben megvizsgáljuk az összetevők konfigurációját.

Ha nem áll készen arra, hogy önállóan megoldja a webhely feltörésének problémáját, írjon a „Kapcsolatok” szakaszba, vagy a képernyő jobb alsó sarkában található chatbe.

A helyszíni kezelés térítés ellenében történik.

A munka aktuális költsége a következő oldalon látható: „Webhelyek (CMS Joomla) kezelése vírusoktól”

Üdvözlettel, Vladimir Egorov

Ezt a bejegyzést több webhelytulajdonos kérdése indította arra vonatkozóan, hogyan távolítsák el a rosszindulatú kódokat webhelyükről. Az alábbiakban megpróbálom leírni a sorrendet egyszerű lépéseket, amely nem igényel különleges ismereteket, és elsősorban kezdőknek lesz hasznos az internetes források kezelésében.

Honnan tudhatja, hogy egy webhely olyan támadás áldozatává vált, amely során rosszindulatú kódot találtak el? Az első és legegyszerűbb dolog az, hogy a webhely leállt, vagy nem úgy néz ki, mint egy „egészséges” erőforrásnak. Ez megnyilvánulhat nemkívánatos tartalom megjelenésében vagy a tartalom eltűnésében, az oldalak nem töltődnek be, vagy hibásan töltődnek be. Ezen túlmenően, ha webhelyét felveszi a Yandex vagy a Google webmester oldalára, akkor valószínűleg értesítést kap ezektől a rendszerektől a rosszindulatú kódokról. Bizonyos esetekben a sérülékenységről a böngészőből tájékozódhat (képernyőkép a Google Chrome-ból).

Ilyen esetekben nagyon nem kívánatos az oldal további megnyitása.

Rosszindulatú kódot keresünk az oldalon

Nem fogjuk megérteni annak a személynek az indítékait, aki rosszindulatú kódot telepített az Ön webhelyére, és még kevésbé fogjuk megkeresni azt. Fő célunk a "rossz" kód megtalálása és eltávolítása. Először is át kell vizsgálnia az erőforrást az összes „fertőzött” oldal észleléséhez. Ez lehetővé teszi a keresés szűkítését. Például rosszindulatú kódot lehet elhelyezni Javascript-szkript formájában egyes esetekben külön oldal, mondjuk, egy bejegyzés vagy az ahhoz fűzött megjegyzés tartalmába. Ebben az esetben a probléma az oldal adminján keresztül megoldható úgy, hogy eltávolítja az ilyen kódot a tartalomból/kommentből. Ellenkező esetben meg kell keresnie az erőforrás forráskódjában.

A sebezhetőségek kereséséhez használja a https://sitecheck.sucuri.net webhelyet. Ennek eredményeként a következőket láthatja:

Amint a képernyőképen is látható, a „rossz” szkript az oldal több oldalán is megtalálható, ezért a forráskódban kell keresni.

Szerezzen hozzáférést a forráskód webhely többféle módon:

A legegyszerűbb módja a webhely adminisztrációs paneljének használata. A Wordpress-ben például " Kinézet" -> "Szerkesztő". Ez a módszer nem teljesen kényelmes a fájlok tartalmának keresésének hiánya miatt, ezért nagyon alaposan át kell nézni mindegyiket külön-külön, és meg kell keresni a „rossz” szkriptet.

Sok blog, vállalati erőforrás és online áruház olyan szervereken található, amelyek a hosting vezérlőpulton keresztül érhetők el. Ez a panel gyakran cPanel. A hozzáféréshez ismernie kell bejelentkezési nevét és jelszavát. Általában a tárhely vásárlásakor küldik el a tranzakciót végző személynek. A vezérlőpultra való bejelentkezés után a „Fájlkezelőn” keresztül megtekintheti az összes forrásfájlt, és megpróbálhatja megtalálni azokat, amelyek tartalmazzák az észlelt rosszindulatú szkriptet.

A legkényelmesebb módja egy FTP kliens. Ha FTP-kliens segítségével „kommunikál” az erőforrásával, könnyen futtathat keresést a forrásfájlok tartalmában.

Ne próbáljon rosszindulatú kódot találni benne forrás fájlok Az Ön webhelye, teljesen helyettesítve azt a keresésben. Válassza ki annak egyedi részét, például esetünkben a googleleadservices.cn-t, és ismételje meg a keresést többször.

Rosszindulatú kód eltávolítása

A rosszindulatú kód észlelése után egyszerűen el kell távolítani. Esetünkben az oldalon a Joomla futott, és a „rossz” szkript bekerült a gyökérkönyvtár index.php fájljába. Ez az oka annak, hogy a sérülékenységet egyszerre több oldalon fedezték fel, mivel ezt az index.php-t használják az erőforrás összes oldalának felépítéséhez.

Közvetlenül a rosszindulatú kód eltávolítása után azt javaslom, hogy változtassa meg az összes felhasználó jelszavát a webhely vezérlőpultján, és próbálja meg tájékozódni más rendszergazdák tapasztalatairól, akik találkoztak ezzel a problémával. Szükség lehet további intézkedések megtételére.

Megelőzés

A megelőzés mindig jobb, mint a gyógyítás, ezért javaslom:

Használjon „jó” jelszót a webhely összes felhasználója számára (hosszú, számokkal, nagy- és kisbetűkkel).

Vegye komolyan, és szűrje le azokat a tartalmakat, amelyeket nem Ön generál az oldalon (vendég bejegyzések, hozzászólások).

Ne várja meg az értesítéseket, hanem rendszeresen ellenőrizze a webhelyet a sebezhetőségekért.

Időben frissítse a tartalomkezelő rendszert (Wordpress, Joomla, Drupal, ...).

Kérjük, hagyjon fel bármilyen kérdést vagy megjegyzést a megjegyzésekben.