Sziasztok!
Az alábbi kérdésben szeretném a segítségeteket / véleményeteket / ötleteteket / RTFM stb. kérni:
Adott egy fizetős tárhelyszolgáltatónál egy nonprofit alapítványi weboldal drupal alapokon. Az oldalt többször érték spam támadások, azonban a mai napon a szolgáltató biztosnági okokra hivatkozva törölte...
-
Előre is elnézést kérek, ha hosszúra sikerülne...
- (jelenleg) Drupal 6.6 -os motor és az alábbi modulok:
- backup_migrate
- bbcode
- dhtml_menu
- google_analytics
- i18n
- image
- img_assist
- lightbox2
- Az oldalt 6.1-es drupal-al hoztam először létre, majd folyamatosan (max 2-3 hét késéssel) frissítem mindig az aktuális bugfix drupal kiadásra (modulokat is).
- Sehol nem nyúltam a drupal és a modulok forrásába, minden "gyári"; egyedül a téma css-ét és template-jét szerkesztettem szükségszerűen (lightfantastic)
- Az egyetlen egy változtatás, amit forrás szinten eszközölni kellett az oldal működő képessé tételéhez a hosting szolgáltatónál az a .htaccess fileban történt (pastebin.com). A változtatás lényege, hogy ki kellett commentelnem a FilesMatch, -Indexes, +FollowSymliks, Error Document, Directory Index és php_value* sorokat, mert ha egyetlen egyet is bent hagytam az oldal semmilyen formában nem jelent meg.
A probléma:
Körül belül 3 hónapja kezdődtek a gondjaink (kb drupal 6.3 körül), amikor is a statikus HTML-oldalak végére valamilyen furmányos módon spam (kínai viagra stb.) került. gyk hozzáfűztek a .html fájlokhoz jó néhány sort (a weboldalról be voltak linkelve). Ekkor Frissítettem minden komponenst, lecseréltem minden jelszót újra, ellenőriztem a fáj permissionokat (mindent 644 és 755-re állítottam). Ez kb 5 napig volt elég, a spam visszatért.
December környékén már az index.php végére is sikeresen spam-et raktak, ekkor kikapcsoltam minden extra modult, a hiba mégis fennállt. Végrehajtottam egy teljesen tiszta újratelepítést - minden file-t töröltem, jelszavakat megváltoztattam (az eredeti forrástól eltérő file-t nem találtam). Átneveztem az xmlrpc.php-t és a cron.php-t. Ekkor már már úgy tűnt megvan a hiba forrása, azonban 3 héttel ezelőtt újra felfedeztem a spam-et a statikus html-oldalak végén.
A google semilyen kulcsszó kombinációra nem dobott értékelhető ereményt. A drupal.org-ot kb 1 hétig nyálaztam, még csak hasonló bureportra sem akadtam...
Ma reggel pedig az oldal 404-el tért vissza, a szolgáltató pedig az alábbi e-mailel válaszolt:
Tisztelt X Y!
Az Önök tulajdonában lévő
xxxxxx.huweboldalon keresztül, a héten sajnos másodjára is behatoltak szerverünkre maradandó károkat okozva több ügyfelünk adataiban.
Az ingyenes cms rendszerek hátránya, hogy adott hibát feltárva folyamatosan mindenhol kihasználva ezt szervereket tesznek tönkre.
Az Önök tevékenysége nagyon fontos és elismert világszerte és egyes csoportok akár csak szórakozásból is úgy próbálnak hírnévre szert tenni , hogy feltörik , károsítják, törlik.Ennek következtében sajnos weboldalukat le kellett tiltanunk néhány órával ezelőtt.
[...]
hosszútávú megoldás egy nem cms rendszer, hanem egy egyedi programozású weboldal, ott ilyen problémák nem merülhetnek fel.
Sajnost a rendszergazda által javasolt "egyedi programozású" weboldalra sem időnk és sem energiánk/pénzünk nincs, szivesebben fordítjuk szűkös erőforrásainkat az alapítvány tényleges működésére.
Az oldal egyetlen célja az információ közzététel esztétikus formában. Azért választottam a drupal CMS-t mert egyszerű letisztult és igen elterjedt, több nagyforgalmú weboldal is zökkenőmentesen használja -- ezért nem is értem igazán a rendszergazda által javasoltakat.
A kérésem tehát az lenne, hogy segítsetek elindulni, hogy milyen irányban keressem a hiba forrását, mit kérjek a tárhely szolgáltatómtól, hogy az oldal biztosnágosan üzemeljen?
Köszönettel:
Dr. Bujdosó Sándor
hol is
Drupalban nincsenek statikus HTML oldalak, tehat jo lenne tudni, hogy az a spam hol is volt. Az adatbazisba kerult bele vagy a smink fajlokba?
ha a spam az adatbazisban volt, akkor alap kerdesek:
1. PHP filter modul be van e kapcsolva?
2. lehet e regisztralni az oldalra? ha igen, akkor milyen jogosultsagai vannak a bejelentkezett felhasznalonak.
ha a spam nem az adatbazisban volt, akkor valoszinuleg a fajl jogosultsagok voltak rosszak, vagy a tamado mas modon (nem a Drupalon keresztul) jutott fel a szerverre..
köszönöm a választ.
Köszi a választ!
0. az oldal tartalmához hozzátartozik néhány statikus (nem a drupalhoz tartozó) html file is. a spam ezek végén valamin a drupal index.php és cron.php végére került.
1. a php filter modul be van kapcsolva
2. az oldalra nem lehet regisztrálni; az anonymous felhasználóknak csak olvasási joga van a megjelent node-okra.
a fájl jogosultságok 644/755 volt mindenhol.
Mivel az adatbázis az makulátlanul tiszta ezért én is így gondolom, hogy a támadó nem a drupalon keresztül jutott be az oldalra, azonban mégsem vagyok/voltam teljesen biztos ebben.
Igazából nemtudom,h mivel érveljek a szolgáltatónál :(
ervelni
Ha statikus HTML fajljaid vannak amiket spam-meltek akkor nem ertem miert okolja valaki a Drupalt, amikor annak semmi koze azokhoz a fajlokhoz..
meg azt tudom elkepzelni, hogy a fajlok tulajdonosa volt rosszul megadva. De akkor sem ertem hogyan lehetne mas weboldalak fajljait modositani..
a szolgaltato mivel tud ervelni? miert a Drupal oldal a bunbak es a tobbi oldal az aldozat, miert nem forditva?
a szolgaltato valtason el kellene gondolkozni, mert a .htaccess beallitasok lehetosege eleg egyertelmu hiannyossagokra utal..
Találkoztam már hasonlóval
Sajnos a vannak szolgáltatók, akik a saját hanyagságukat, tudatlanságukat másra fogják. Igyekeznek az ügyfél előtt a fent idézett "szakzsargonnal" palástolni hozzá nem értésüket.
hozzáférés
Ez teszi igazán érdekessé a helyzetet, hiszen ez független az adatbázis-hozzáféréstől, és talán a PHP-tól is. A kérdés: Milyen módon férhettek hozzá a térhelyedhez?
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
A tárhelyhez egyetlen egy
A tárhelyhez egyetlen egy "hivatalos" hozzáférés létezik: ftp. Több alkalommal változtattunk jelszót, azonban 100% biztonsággal nem tudom kizárni a mi (felhasználó) oldalán történt esetleges hanyagságot (keylogger? azonban eddigi "ön"vizsgálódásaink nem találtak semmit).
Egyelőre a FTP és a webszerver logokra várunk (gondolom hétfőn) azokból hátha le tudunk valamilyen következtetést vonni.
Köszönöm a válaszokat, amit lesznek fejlemények igyekszem azokról beszámolni.