Szigorítottunk szerver beállításainkon

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.

Options FollowSymLinks

Ezt úgy tudod a legegyszerűbben megtenni, ha egy # karaktert írsz a sor elejére:

# 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:

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
    Posted 2013. február 22. 15:57 0Likes

    na igen, csak a softaculousnak nem szól senki, hogy az upgrade-kor erre is figyeljen

  • törzsmókus
    Posted 2013. március 8. 08:31 0Likes

    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
      Posted 2013. március 8. 08:48 0Likes

      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
      Posted 2013. március 8. 09:56 0Likes

      É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
    Posted 2013. április 5. 10:22 0Likes

    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
    Posted 2013. december 3. 10:48 0Likes

    a drupalnál a fejlesztés folyamatban 🙂
    https://drupal.org/node/1269780

Hozzászólás küldése

Kövess minket!