Drupal - feltörtek vagy én rontom el?

Web, mail, IRC, IM, hálózatok

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, hosszúra sikerült...

  • (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, adatbázist nem töröltem). Á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 semmilyen kulcsszó kombinációra nem dobott értékelhető eredmé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.hu weboldalon 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.

Sajnos a rendszergazda által javasolt "egyedi programozású" weboldalra sem időnk és sem energiánk/pénzünk nincs, szívesebben 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 (hup.hu:) 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 biztonságosan üzemeljen?

Nagyon nem szeretnénk a statikus HTML oldalakhoz visszatérni :|

Köszönettel:
Dr. Bujdosó Sándor

  • 2529 megtekintés

( Yorirou | 2009. 02. 14., szo – 14:20 )

Elsőre:
1.) jelenleg 6.9-es Drupal van, nem 6.6-os
2.) az a 2-3 hét sok, jó lenne 2-3 órára vagy max egy napra redukálni (fel kell íratkozni az RSS-re, és ha jön az update, akkor frissíteni amilyen gyorsan csak lehet)
3.) érdemes a contrib modulokra is figyelni, és azokat is frissen tartani
4.) én még körülnéznék a jogosultságok környékén, nincs-e véletlen több jog adva az anonymous usereknek, mint kellene

A saját fejlesztésű oldalnál is merülnek fel security problémák, túlnyomó részükben olyan alapvető programozási hibák vannak, hogy fél perc alatt teljesen ki lehet nyírni az oldalt...

"PHP's coding style pulls common elements from C++, Java, PERL, Python, BASIC, Assembly, Dragonspeak, and Microsoft Office Excel."

( zeller | 2009. 02. 14., szo – 14:32 )

"hosszútávú megoldás egy nem cms rendszer, hanem egy egyedi programozású weboldal, ott ilyen problémák nem merülhetnek fel"

LOL. Gondolom ők jó pénzért meg is csinálnák az egyedi programozású weboldalatokat... Az álításukkal meg finoman szólva is vitába szállnék, de ezzel gondolom nem vagyok egyedül...

Ha az oldalról nem, vagy csak minimális inputot kell fogadnotok, akkor érdemes olyan CMS-t választani, ami képes statikus exportra, és azt tolni a publikus site-ra, a szerkesztés meg egy másik szerveren csinálni. Egy deface után elég a szerkesztői rendszerből kipublikálni a teljes anyagot, és kész.

Nem csak rajtad keresztül. A szerkesztőségi rendszeren (ez egy védett helyen lévő gép/CMS) szerkesztenek, aztán a szerkesztési folyamat végén vagy egy html-oldalon tol oda a rendszer eléjük egy gombot hogy "Publikál...", vagy a wendózon kapnak egy ikont, ami mögött egy script szépen megcsinálja a statikus exportot, majd felrámolja a szolgáltató szerverére, illetve az esetleg ott tárolt dinamikus adatokat meg lehozza.

( eax | 2009. 02. 14., szo – 14:34 )

Ha csak a static html-ekbe nyultak bele, akkor en inkabb arra gyanakodnek, hogy megszereztek az egyik FTP account-otokat. Kinek van FTP elerese az oldalhoz?

Milyen logjaitok vannak? FTP belepes? Apache access log? Mod_security logok?

A szolgaltato rg-jere meg ne hallgassatok, az egyedi fejlesztesu oldalakban sokkal gyakoribbak a sokkal sulyosabb sechole-ok, mint a drupal core modulokban.

(Egyebkent nem akarom a szolgaltatot minositeni, de a "Az Önök tulajdonában lévő xxxxxx.hu weboldalon keresztül, a héten sajnos másodjára is behatoltak szerverünkre maradandó károkat okozva több ügyfelünk adataiban." c. resz arra enged kovetkeztetni, hogy bizony ok sem tettek meg minden toluk telhetot biztonsag tekinteteben).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

  • Igen, csak a static html-oldalakat vagy az index.php, cron.php végére "append"-eltek spamet. sehova máshova. Az ominózus ma reggeli "betörésről" semmit nem tudok (még).
  • Az oldalhoz FTP hozzáférésünk van (SFTP / TLS stb nincs) annak jelszavát több alkalommal (egy webes https felületen) lecseréltük nem szótáron alapuló jelszóra.
  • Általunk olvasható log nincs (én nem tudok róla) se admin felületen se ftp-vel belépve. A drupal "beépített" logja semmilyen gyanúra okot adható dolgot nem mutatott (google robot, random látogatók; de ez nem jelent semmit...)
  • Azt pedig, hogy egy virtuális hoszt szolgáltatás esetén hogyan fértek az ő rendszerükhöz hozzá nemtudom, minősíteni nem akarom, sajnos egyelőre még nem akarunk váltani ($$$).

"Az oldalhoz FTP hozzáférésünk van (SFTP / TLS stb nincs) annak jelszavát több alkalommal (egy webes https felületen) lecseréltük nem szótáron alapuló jelszóra."

Az keves az udvosseghez, ha a kliensre betelepult malware-el el tudjak kapni a jelszot (amit eleg gyakran tesznek ujabban). Szerintem probaljatok elkerni az ftp login log ratok vonatkozo reszet (ha az access logot is sikerul, megjobb), es nezzetek ossze az ominozus file-ok mtime-javal.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Egyetertek az elozoekkel, nagy valoszinuseggel FTP jelszot loptak, nalunk ugyfeleink kozul is volt mar erre pelda
A ftp logbol egyertelmuen kiderul majd, mer valszeg pl. ukran vagy brazil cimekrol lesznek ftp belepesek :))

a hosting ceg meg eleg vicces vagy feluletes, hogy ennyit nem vesz eszre.

Hasonló esettel találkoztam én is. Ott (szerintem) a Total Commander volt a ludas, illetve az, hogy fixen volt tárolva a user/pass páros, hogy ne kelljen mindig begépelni, meg még valami trutyi a gépen :). Jelszó és szokás :) csere óta nincs ilyen gond, ha maradtak is még szemetek azon a gépen, azok meg nem ftp pass lopással foglalkoznak :)

Nem lehet elkérni a szolgáltatótól a site-ra vonatkozó logbejegyzéseket? Ha vannak használható logok, akkor mindenképp abból kéne kiindulni. Persze nem lesznek használható logok valószínűleg, mert a nyavajást POST-okat nem logolják, csak a GET-ek látszanak (ami nem is annyira nagy hülyeség, most, hogy így belegondolok csak ilyenkor megnehezíti a dolgokat).
A problémát ott látom, hogy a szolgáltató a helyett, hogy bármiféle segítséget próbálna nyújtani, védi a saját rendszerét, amit minden bizonnyal rosszul tákoltak össze.
Lehet ezt biztonságosan csinálni, úgy, hogy más ügyfelek dolgaiban ne keletkezzen kár, csak érteni kéne hozzá (persze azt meg is kéne fizetni).

( wwrreecckk | 2009. 02. 14., szo – 19:54 )

Sztm nem ftp bibi.
Ha lenne FTP hozzáférésem, akkor én nem csak appendálnék...

Inkább a php, vagy vmi db matató, webes levelező nincs frissítve, és egy script(-kiddie) ezt használja ki.

Kérj a módosítás környékéről http access logot, ott lesz a megoldás, sztm.
(mivel bizonyították, hogy rajtatok keresztül hekkelik a rendszert?)
(A többieket hogy hekkelik?
Mert az "vicces", ha őket is ugyanígy... )

( janoszen v | 2009. 02. 14., szo – 19:59 )

Nekem is volt ilyen problémám a volt szolgáltatómnál. Egyszerűen annyi volt a probléma, hogy egy tök más felhasználó rendszerében találtak egy lukat és a rosszul bekonfigolt PHP-nak köszönhetően szépen végig is dolgozták a szervert, mindenhova beappendelve a szemetet.

Megoldás: tanítsuk meg a szolgáltatót a szakmájára vagy váltsunk szolgáltatót. (Ez utóbbi preferált, hiszen ha tényleg ez a probléma, akkor nagyon nem érthet valamihez.)

Dettó hasonló esettel szívtam én is, ott is az volt a gond,
hogy egy másik felhasználó által használt "saját fejlesztésű" kiválóan megírt cms-t törték rommá, aztán végigmentek a szerveren, ahogy janoszen is írta.

Javaslat: válts szolgáltatót, mást nem tudsz csinálni.

( tomsolo | 2009. 02. 14., szo – 21:43 )

#1 admin/user/rules sem ártana jól beállítani
#2 én htaccess be is beleszoktam nyúlni még
#3 ftp -t szintén fentiek szerint

nem említette senki de használtatok IMCE-t vagy vmi hasonló stuffot ami enged uploadolni és belepiszkálni az oldal fájljaiba?

de sztem kb 90% hogy a hoszting cég a gáz.

No rainbow, no sugar

( asci v | 2009. 02. 14., szo – 21:54 )

Kíváncsi lennék a hoszting cég nevére.

( hrgy84 | 2009. 02. 14., szo – 23:28 )

Velemenyem szerint amikor le kellett uriteni a .htacces-t akkor kellett volna otthagyni oket a francba. Vagy szolni nekik, hogy lesznek szivesek beloni ezt.

Lehetoseg szerint probalj meg a legtobb logot beszerezni toluk, ez a legkevesebb, amit tehetnek. Amugy mindenkepp tarhelyszolg cseret javaslok (ha erdekel, privatba ajanlatot is adok), ezek igy nagyjabol arrol sem igen hallottak, hogy biztonsag. Ott, ahol egy weboldal le tud rohasztani egy komplett webszervert, ott en nem hosztolnam az oldalamat, hanem tepnek elfele ezerrel.

En nem tudom, mi drupal oldalakat hostolunk tobbet is, es meg nem tortek fel minket, pedig a cimek eleg publikusak. Nem hinnem, hogy drupal oldalon kell keresni a hibat.

Az elso tipp szinte biztos, hogy ftp, de lehet akar valamilyen webszerver exploit is. Akkor meg orulhettek, hogy csak ez van.
Mindegy, egy a lenyeg: kerjetek ki a logokat, es ha a legkisebb gyanu is felmerul, hogy nem egyedul ti vagytok a vetkesek, azonnal tavozni, nem hezitalni.

Ja, es megeccer: nem hiszem, hogy a drupal problemaja volt ez. Ha rendszeresen volt frissitve, ha mindig oda volt ra figyelve, ilyen gondot nem okozhatott csak es kizarolagosan a drupal. Ne valtsatok egyedi weboldalra, azzal csak szivni lehet nagyokat.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( bujdi | 2009. 02. 15., v – 04:08 )

Köszönöm szépen az eddigi válaszokat, igyekszem / igyekszünk megemészteni. Egyelőre olybá tűnik, hogy kitört a hétvége kicsit lelassítva az ügyünk alakulását.

Holnap (ma) dolgozom, így csak hétfőn fogok tudni érdemben foglalkozni ismét az üggyel, igyekszem majd tájékoztatást adni, hogy mi lett a végkifejlet.

Meg lehetne tudni, mi lett a vegkifejlet?
Amugy vicces ez az ftp-ugy: a T. cegek minket cseszegetnek, hoyg valtsdunk jelszot, en kozlom, hogy szivesen, de eloszor az, akinek ftp hozzaferese van a szerverhez, legyen szives egy virus/trojai keresot futtatni, mert addig orankent valthatunk jelszot, sok ertelme nem lesz.