Hostingová firma, u níž hostuji náš školní Moodle měla problémy s hackerským útokem. Po provedených opravách sice systém bez potíží funguje, ale přestala být funkční čaát administrátorské sekce. Například se mi nezobrazí seznam registrovaných uživatelů. Tipuju problém s přesunem systému na jiný fyzický server s novou adresací. Nevíte někdo, kde by se daly mnou popsané problémy řešit? Není někde v administrátorských souborech cesta k umístění serveru? Předem díky za možné tipy.
Při některých útocích byl napaden přímo Moodle. Prohlédněte vzorek skriptů moodle. byla to nějaká zranitelnost v Zend skriptu pro vyhledávání.
Bohužel, nejsem takový odborník na programování, takže vůbec netuším ani o čem píšete (Zend skripty), ani jak ten problém opravit. Snad reinstalací? To by byla opravdu noční můra ...
Podívejte se do skriptů. Pokud je v nich něco neobvyklého, zeptejte se někoho znalejšího. Pokud je to skutečně ten virus, asi nejlepší je zazálohovat config.php, vyčistit od nákazy, vymazat všechny skripty moodle a nahrát znovu skripty příslušné verze moodle na server a vrátit na místo vyčištěný config. Pozor, buďte opatrný - je podstatné, kde máte adresář moodledata, abyste jej nevymazal taky. Správně by měl být umístěn mimo instalaci moodle, v adresářovém stromu na stejné pozici jako wwwroot, pak do něj apache nemůže a nikdo vám odtud nemůže nic stahovat. Reinstalace není nutná, v moodledata i v databázích může vše zůstat. Zkontrolujte uživatele, zda nejsou přidáni nějací blabla viagra
Cesta od IP nikde není, provider namapuje vaši doménu na příslušné IP serveru, takže pokud to funguje, funguje to. Pokud výše uvedené nezvládáte, musíte požádat někoho o pomoc.
Cesta od IP nikde není, provider namapuje vaši doménu na příslušné IP serveru, takže pokud to funguje, funguje to. Pokud výše uvedené nezvládáte, musíte požádat někoho o pomoc.
Dobrý den,
zažil jsem něco podobného. Systém se zpomalil a přestalo fungovat zálohování. Jednalo se o hosting na banan.cz. Zjistil jsem z PHP.INFO, že došlo k snížení paměťových limitů a dalších hodnot. Doporučuji zkontrolvat PHP.INFO - hlavně memory_limit (min 64M) a safe_mode (OFF). Napadené soubory najdete nejsnadněji podle změny datumu. Většina souborů na hostingu má stejné datum vytvoření. Napadené soubory mají většinou čerstvé datum. Vložený skrip hledejte až na konci souboro. Před ním může být vloženo několik stovek prázdných řádků.
Snad Vám to pomůže. JoNy
Nene, bacha, asi jsme se setkali s jiným napadením. Tj. změna data je relevantní kritérium, souhlas. Mé napadení bylo naopak na začátku. Asi ale můžeme doporučit: hledej na začátku nebo na konci. Moodle je vhodné v takovém případě smazat - ono to tam přidalo několik souborů pro inkluzi a čertví, co kde všechno.... A jak jsem psal nahradit Moodle stejné verze z archivu. Bacha na ztrátu config.php - to by se muselo instalovat znovu 
> Bacha na ztrátu config.php - to by se muselo
> instalovat znovu
Nemuselo. Jen by se musela udělat kopie config-dist.php na config.php a doplnit stejné údaje, jaké měl ten původní. Klíčová je zejména sůl hesel, ale i s její ztrátou se dá přežít - všichni si jen musejí projít procedurou zapomenutého hesla.
Souhlasím nicméně s tím, že je chytré udržovat si záložní kopii config.php.
--mudrd8mz
> instalovat znovu
Nemuselo. Jen by se musela udělat kopie config-dist.php na config.php a doplnit stejné údaje, jaké měl ten původní. Klíčová je zejména sůl hesel, ale i s její ztrátou se dá přežít - všichni si jen musejí projít procedurou zapomenutého hesla.
Souhlasím nicméně s tím, že je chytré udržovat si záložní kopii config.php.
--mudrd8mz
No.. jasněže.. ale s tím napsáním config do čistého.. to by mohl být pro kolegu problém
Kupodivu se jedná v mém případě také o banan.cz. Začal jsem kontrolovat datumy všech souborů, ale je úžasná dřina. Protože se jedná o problémy administrační sekce, prošel jsem poctivě všechny soubory a složky v adresáři admin. Všechny datumy jsou datumy instalace moodlu. Protože vůbec nerozumím programování scriptů, pomohlo by překopírování adresářové struktury z lokáního počítače při zachování config.php? Pokud tomu aspoň trochu rozumím, tak moodledata jsou mimo root moodlu a v pořádku, databáze je také O.K. - tak by mohla pomoci zkopírování instalačních adresářů?
Když se jednalo o to napadení, byly změněny všechny skripty v den útoku. Na banán už tu někdo nadával, že sundali memory limit a ještě snad něco. Některé stránky v administraci s nedostatečným ML nejedou a celý Moodle je pak jako vrhcáby. Ano, překopírování z lokálního počítače se stejnou verzí by pomohlo - ale asi to není case. Zapněte zobrazování chyb, pokud to nejde z adminu, nedávno tu David psal, jak to zapnout z config-u.
Jasně, pokud tam nemáte nic jiného vlastního, klidně všechno až na config.php smažte a nahrejte znovu. Dokonce nemusíte ani zálohovanou verzi - prostě stáhněte z Download Moodle poslední stabilní verzi stejné řady, jakou máte nainstalovanou (předpokládám 1.9.x) a tu tam šoupněte. To je úplně korektní procedura, protože se tak postupuje např. v případě upgrade.
Na nějaké ruční procházení datumů se vykašlete (s prominutím). Pokud nejste znalý PHP a web security, tak tam to napadení ani nemusíte spatřit.
--mudrd8mz
Na nějaké ruční procházení datumů se vykašlete (s prominutím). Pokud nejste znalý PHP a web security, tak tam to napadení ani nemusíte spatřit.
--mudrd8mz
Ja len asi na zaver dodam, ze prvym krokom by malo byt poziadat hosting o obnovu dat z ich zalohy. V pripade ked neuspejete, zmenit hosting, pretoze zalohovanie aspon niekolko dni dozadu by malo byt predsa len akymsi standardom.
Suhlasim s tym, ze najlepsim riesenim je vsetko zmazat (okrem config.php). Treba si dat este pozor na to, ze ak mate nejaku vlastnu (alebo upravenu) sablonu, tak tu treba obnovit z vasej lokalnej zalohy. V zavislosti od pliagy, ktora tam bola moze byt vlozena prave aj do tychto suborov a nebylo by rozumne stiahnut si sablonu zo servera, vsetko zmazat a nahrat sablonu naspat. Ono moodle moze fungovat ale budete distribuovat nejaky virus.
Potom vam zostava uz len dufat, ze provider problem vyriesil a ze sa to nebude znova opakovat. A my ostatni sa vsetci tesime na php6, kde by sa uz toto stat nemalo - len to sa este nacakame.
p.
Suhlasim s tym, ze najlepsim riesenim je vsetko zmazat (okrem config.php). Treba si dat este pozor na to, ze ak mate nejaku vlastnu (alebo upravenu) sablonu, tak tu treba obnovit z vasej lokalnej zalohy. V zavislosti od pliagy, ktora tam bola moze byt vlozena prave aj do tychto suborov a nebylo by rozumne stiahnut si sablonu zo servera, vsetko zmazat a nahrat sablonu naspat. Ono moodle moze fungovat ale budete distribuovat nejaky virus.
Potom vam zostava uz len dufat, ze provider problem vyriesil a ze sa to nebude znova opakovat. A my ostatni sa vsetci tesime na php6, kde by sa uz toto stat nemalo - len to sa este nacakame.
p.
Každopádně dobrou a dosti účinnou prevencí by mělo být nastavení práv ke všem adresářům moodle vyjma moodledata jen na čtení. Každodenní zálohování databází by mělo být samozřejmostí a zálohování www by mělo mít alespoň nějakou rozumnou periodu.
To nastavení read-only je tradovaným doporučením, ale nespoléhejte se na to. Už jsou známy i útoky přes moodledata, např. přes injekci kódu do jazykových balíčků. Jedinou rozumnou ochranou je pravidelná aktualizace Moodlu, nejlépe každý týden po středečním vydání weekly buildu. Všechny známé útoky na Moodle využívaly chyb, které již byly ve stabilní větvi opraveny. Většina hackerů nehledá slabiny v kódu, ale sleduje anonci jejich oprav. Pak jen napíší nástroj, který chybu využívá (což vzhledem k tomu, že mají k dispozici přesný popis problému, není zase taková potíž). No a protože správci své servery neaktualizují často ani přes výslovná doporučení od vývojářů Moodle (schválně kolik z nás tady má 1.9.7+), mají pak hotové žně.
Máte-li k dispozici vlastní server, přejděte na CVS. Aktualizaci vašeho Moodlu pak stihnete dřív, než si ráno vypijete kafe
Pokud musíte uploadovat přes FTP, kupte si ke kafi koláč.
--mudrd8mz
Máte-li k dispozici vlastní server, přejděte na CVS. Aktualizaci vašeho Moodlu pak stihnete dřív, než si ráno vypijete kafe
--mudrd8mz
Jasně, plný souhlas. Nicméně ta moodledata by měla být na úrovni wwwroot-u, takže by z webu neměla být dostupná.