Annak ellenére, hogy már írtunk róla hogyan kell a WordPress és Joomla oldalakat biztonságossá tenni, egyik szerverünkön ismét nagyjából 100 oldalt törtek fel illetéktelenek. A feltörés a korábbiakhoz hasonló módszerrel történt, a hekker hozzáfért az adatbázis konfigurációs fájlhoz annak rossz biztonsági beállításai miatt és a megszerzett bejelentkezési adatokkal módosította a főoldalt.
Jó tudni!
A támadó azokhoz az oldalakhoz nem fért hozzá, amelyeknek tulajdonosai már elvégezték az oldalak biztonsági megerősítését leírásunk alapján!
Mivel a feltöréssel kapcsolatos beözönlő kérdések igen nagy felesleges munkát jelentenek ügyfélszolgálatunknak, úgy döntöttünk, hogy szigorítjuk szerver beállításainkat. Ennek eredménye képp a FollowSymlinks beállítás nem módosítható az Apache htaccess fájlából.
Jó tudni!
A szigorítás alapvetően nem jelent problémát az oldalak működésében, mert a beállítás ugyan nem módosítható, de bekapcsolt állapotban van.
Problémát jelent viszont olyan oldalaknál, ahol a htaccess fájlban a beállítást megpróbálják módosítani. Sajnos a Joomala CMS rendszer alapértelmezett beállítása is ez, így a Joomla oldal tulajdonosainak ki kell szednie az alábbi sort a .htaccess fájlból, hogy oldaluk megfelelően működjön tovább.
|
1 |
Options FollowSymLinks |
Ezt úgy tudod a legegyszerűbben megtenni, ha egy # karaktert írsz a sor elejére:
|
1 |
# Options FollowSymLinks |
Segít a hibanapló
Ha az oldalad a fentebbi beállítás után sem működik megfelelően és 500-as hibát jelenít meg a szerver, kérlek nézd meg a cPanel felületről elérhető hibanaplót, ahol megtalálod mi a hiba! Lehetséges, hogy a korlátozással más hiba is került a .htaccess fájlodba, amit javítani kell. Ha nem sikerül írj, és megoldjuk!
Update
Este 23 órára minden szerveren lefuttattunk egy szkriptet, ami a htaccess fájlokat megfelelően beállítja, így a Joomla oldalak működőképesek. A szkript csak a fentebbi sor kommentezését végzi el, így gond lehet azoknál az egyedi fejlesztéseknél, ahol a FollowSymLinks beállítás nem egyedül szerpele egy sorban, hanem több Options beállítás is van.
Drupal update
Úgy vettük észre, hogy a Drupal más könyvtárakban is tárol htaccess fájlt, így lehetséges, hogy az oldal megjelenik a fentebbi beállítások után, de a képek és az oldal kinézete viszont nem. A megoldás, hogy a /sites/default/files könyvtárban (vagy máshol a /sites könyvtáron belül) levő htaccess fájlt is módosítani kell így:
|
1 2 3 |
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006 Options None Options +SymLinksIfOwnerMatch |
Erről technikai részleteket is írok a Drupal Fórumon.
Jó tudni!
Ha nem vagy biztos a dolgodban, vagy beállítottál valamit és nem érted miért nem működik, keress minket, segítünk a beállításban! Mindenképp küld el melyik weboldalról és tárhelyről van szó!
6 Hozzászólás
törzsmókus
na igen, csak a softaculousnak nem szól senki, hogy az upgrade-kor erre is figyeljen
törzsmókus
a drupál softaculous upgrade-nél valahogy meg kéne tényleg oldanotok, hogy a FollowSymLinks-et cserélje SymLinksIfOwnerMatch-re, mert minden frissítés után 500-ast dob a decemberi balhé óta.
ha írtok scriptet erre, esetleg azzal a lendülettel a .htaccess fájl 10. sorában lévő megjegyzésbeli aposztrófot (‘) is lecseréltehetnétek ’-re (U+2019), hogy a kódszerkesztő szintaxiskiemelése ne hasaljon el rajta. (gondolom ez egyszerűbb, mint okosítani a szintaxist :P)
meg tudom oldani kézzel mindkettőt, csak „pain in the ass”, ahogy a művelt angol mondja. (és érv a szolgáltatóváltás mellett…)
törzsmókus
az írógép-aposztrófomat (U+0027) az „okos” wordpress átalakította angol nyitó félidézőjellé (‘, U+2018), remélem ettől még érthető
Péter
Értjük a problémát, azonban a megoldás nem olyan egyszerű, hogy ‘írunk egy szkriptet’ ami lecseréli. Közel 8 millió fájl van a szervereken, amit át kell fésülni a htaccess-ért, aztán azokat elemezni. Idő, CPU, memória stb.
Szerintem a megoldás inkább, hogy a drupal közösség ír a fejlesztőknek (vagy módosít a forráskódban), hogy a régi sebezhető beállítás az új Drupal verzióban már ne legyen benne.
Sajnálom ami írtál, hogy az fordul meg a fejedben ‘szolgáltatóváltás’ és nem arra gondolsz, hogy az alapjában sebezhető CMS rendszered biztonságban van.
törzsmókus
a szkriptet nem az aktuális .htaccess fájlok átnyálazására értettem, hanem hogy amikor a softaculous frissíti a drupalt, azután fusson le egy egyszerű csere.
törzsmókus
a drupalnál a fejlesztés folyamatban 🙂
https://drupal.org/node/1269780