Pokud pouzivate FTP, kontroloval bych jeste pristupy tam + zmenil heslo. Ac je to metoda stara jak jeruzalem, tak unikle prihlasovaci udaje z FTP jsou stale castou pricinou.

Jinak projit seznam modulu, vyhledat cokoli co by mohlo umoznovat uzivatelum upload a zkontrolovat nastaveni. V neposledni rade nastavit webserver tak aby jediny spustitelny soubor byl index.php. Na 99% nic jineho z venku neni treba hitnout a spustit. Pokud je vse nastavene spravne, tak by ani kod skryty ve files adresari nemel vadit protoze defaultne nicemu z files neduvereujeme stejne jako kazdemu jinemu uzivatelkemu vstupu. Kazdopadne zbavit se toho je lepsi nez doufat ze je vse nastaveno spravne.

Ahoj tehdy jsem nebyl přihlášen, ale původní dotaz byl ode mě.... jen pro info... a teď jak jsme to vyřešili...má to několik kroků:

1) odstranili jsme všechny readme.txt

2) odstranili jsme všechny changelog.txt

3) a všechny ostatní *.txt soubory, které nejsou potřeba

4) z adresáře libraries odstranit vše nepotřebné (dodatečné knihovny většinou mají spoustu balastu a můžou tam být potenciální zadní vrátka např. v různých demo ukázkách)

a proč to všechno? někdo by mohl zkoušet podle nich určovat verze modulů, zranitelnost js souborech atd...

4) Zásadní věc úprava práv:

uživatel www-data může zapisovat pouze do adresáře files (vytvářet a mazat adresáře + soubory) práva u souborů jsou nastavena na 740 a adresáře na 750 vše rekurzivně (máme to i jako masku pro nové):

find . -type f -exec chmod 740 {} \;

find . -type f -exec chmod 750 {} \;

Vlastnictví souborů a adresářů ve /files je nastaveno na www-data:www-data

určitě nedoporučuji jak je psané v souboru install.txt nastavit /files na 777!!!!!!!!

ostatní soubory a adresáře drupalu nejsou ve vlastnictví www-data, ale jiného uživatele, který má oprávnění pouze číst

pak jsme odstranili soubory které nejsou nezbytně nutné:

1) xmlrpc.php

2) install.php

3) update.php

4) zkontrolovat integritu databáze respektive dat... v našem případě se útočníkovi podařilo dopsat javascript do těla nodu resp. článku to vedlo k opakovaným útokům. Takže po analýze kodu jsme napsali script, který projel databázi a kompletně ji vyčistil.

5) u útoku také docházelo k dopisování php kodu většinou do souborů témat vzhledu (většinou se to týkalo souborů typu page.tpl.php a jeho odvozených potomků ... nevím jak bych to jinak nazval :-) a také souboru *.html.php, další soubor, který byl napaden byl i index.php.

6) Samozřejmě změna hesel a přístupových jmen nebo i uživatelů jako takových např. pod kterým běží web, databáze atd...

Takže doporučuji také zkontrolovat aktuálnost tématu!

Všechny tyto soubory jsme vyčistili opět pomocí scriptu, který vše prošel...

Tohle byla jedna část...

Druhá část se týká nastavení samotného systému (OS) ... v našem případě linux:

1) logovat veškeré aktivity

2) nastavení iptables

3) zakázat přístup ze zemí jako rusko, čína, ukrajina... ze kterých šlo nejvíce utoků...

nicméně vždy se najde pc, na kterém běží nějaký malware ... takže být na pozoru!!!

Do teď děláme analýzy aktivit a podle toho operativně přizpůsobujeme bezpečnost

Musím říct, že druhá část je hlavně doménou mého kolegy... jež se mnoho let věnuje bezpečnosti především na unix/linux systémech

4) uzavřít všechny porty, které nejsou potřeba

5) používat jen zabezpečené připojení ssh apod...

7) pouze autorizované ip mají přístup k serveru pro jeho správu

Kolega postupně analyzoval kam se malware vzdáleně připojuje a provedl emulaci, tak aby tento program měl pocit, že je neustále online...i když se vlastně již nikam nemohl dostat :-) v podstatě "Man in the middle" (pro zjednodušení)

V současný době skenujeme i soubory takže něco jako *.ico by se tam již němělo vyskytovat krom povolené v tématu vzhledu (scan je prováděn i co do obsahu).

Další věc nebo spíš kapitola sama pro sebe je a to jsme také řešili vkládání škodlivého kodu do obrázků resp. fotek... tento útok se naštěstí nepotvrdil.

Zásadní věc, která nám zachránila krk byla záloha, kterou provádíme pravidelně v daných intervalech... a to databáze i kodu... díky této záloze jsme mohli operativně vylepšovat zabezpečení resp. reagovat na to jak se útok (resp útoky) vyvíjeli v čase. Jde např. i o vytváření a porovnání kontrolních součtů apod. díky tomu jsme mohli také zjišťovat změny...

Abych to shrnul trvalo nám to několik dní než jsme vše vyladili tak, tak aby vše normálně fungovalo. Rozhodně to není nic jednoduchého v podstatě by se o tom dala napsat celkem slušná příručka :-)

Snad tyhle informace někomu můžou pomoc... každý útok je specifický a jeho vývoj může být různý... především když to je kombinace botnetu nebo nějakého automatizovaného útoku + když do toho zasahuje i intruder, aby operativně reagoval na naše opatření.

Myslím, že by nebylo od věci vytvořit nějaké vlákno věnované čistě bezpečnosti vedle vlákna "Jak na to"...

PS. ten odkaz http://rankinstudio.com/Drupal_ico_index_hack určitě doporučuji!!!! Více méně řeší to co jsme řešili také :-)