Joomla – profilaktyka i reanimacja

Ciąg dalszy wywodów na temat niefrasobliwości niektórych administratorów Joomla!. Z własnego doświadczenia wiem, że za powodzenie chyba wszystkich (na pewno 99,99999%) ataków na serwisy postawione na Joomla odpowiada włączona funkcja register_globals (pisałem o tym – link). Jeśli ktoś zna inne przypadki włamań, niech opisze, wszak winniśmy dzielić się wiedzą i doświadczeniem :)
Poprzednio naciskałem na dostosowanie konfiguracji serwera pod Joomla. Jeśli ktoś czytał tekst “Sezon włamań na Joomla rozpoczęty” i wziął sobie jego treść do serca, to jest mi z tego powodu niezmiernie miło. Teraz coś dla tych, którzy mają zamiar gościć na swoim serwerze przybyszów z Turcji :)Szczerze powiedziawszy, to w głowie mi się to nie mieści: jak można nie robić kopii zapasowych swojego serwisu?! No jak?! Niektórzy jednak tak właśnie robią (tzn. nie robią backupów). Czy aż do tego stopnia nie szanują swojej pracy? Czy może brakuje im wyobraźni?

Większość firm hostingowych (mówię o serwerach płatnych, nie darmowych) z automatu robi backup danych nawet kilka razy w tygodniu. Z tych kopii każdy klient może w razie potrzeby skorzystać, ale to dłuższą chwilę trwa: trzeba skontaktować się z administratorem serwera, a ten nie zawsze jest na miejscu (siku, papierosek, piwko, kobietka ;) ), no i nie wszyscy admini dyżurują 24h na dobę.

Teraz posłużę się przykładami:

1) administrator niczym fryzjer:
Sobota, godzina 23, hakier składa uszanowanie i podmienia stronę główną. Panika: co robić, co robić? Aha, mail do admina serwera, on pomoże. I zonk, bo admin przyjmuje jak fryzjer, tj. pon-pt 9-18, sobota 8-15 :) A żeby było jeszcze ciekawiej, to automatyczny backup wykonywany jest w nocy z soboty na niedzielę. I co teraz? Leżysz!!! Ty nie masz kopii zapasowej, a admin będzie dysponował plikami już zhackowanej strony.

2) administrator jest do dyspozycji przez cały czas:
Nie posiadasz kopii, włamali Ci się na stronę, więc prosisz admina o pomoc. Ten po bliżej niekreślonym czasie odpowiada, że spoko, zaraz przywróci zawartość Twojego konta z ostatniego backupu. Ty się niecierpliwisz, bo takie odtwarzanie kopii chwilę trwa: pliki są archiwizowane, usunięcie starych, rozpakowanie i skopiowanie nowych plików sporo czasu zajmuje. A w tym samym czasie gości Twojej strony wita uśmiechnięty szkieletor :) Pół biedy, jeśli hakier nie będzie tak „miły” i nie zainfekuje podmienionej strony jakimś trojanem. Tak czy siak tracisz w oczach internautów prestiż i zaufanie (pomijając już Twój stres).

A gdybyś tak miał pod ręką kopię plików swojego serwisu…

Wariant trzeci:
posiadasz na swoim dysku kopię zapasową serwisu:
Odpalasz klienta FTP i szybko stawiasz stronę na nogi. Włamania nieznacznie różnią się skutkami, ale z grubsza wyglądają podobnie. Zatem: jak się pozbierać?

Kiedy w katalogu głównym znajduje się plik index.html…
Jak wiadomo, index.html ma pierwszeństwo przed index.php (innymi słowy serwer w pierwszej kolejności szuka pliku z rozszerzeniem .html). Jeśli jest, to przed usunięciem go upewnij się, czy nie ma w nim przekierowania w stylu:

Kiedy w głównym katalogu nie ma pliku index.html…
wgraj właściwy index.php i configuration.php, bo przeważnie im się dostaje

Powinno pomóc, choć może się zdarzyć, że do wymiany będzie też któryś z plików znajdujący się w katalogu /includes (swego czasu spotkałem się z podmienionym plikiem joomla.php, który gdzieś tam przekierowywał). Podobnie może się dziać, kiedy zmianie ulegnie któryś z plików komponentu robiącego za stronę główną (w tym domyślny com_frontpage)

Zabiegi opisane powyżej powinny tchnąć życie w Twoją stronę, ale najgorsze dopiero przed Tobą. Zrób sobie mocną kawę, bo nie pośpisz w nocy. Dlaczego masz to robić w nocy?
a) ludzie śpią i ruch na stronie będzie najmniejszy.
b) serwery i łącza są mniej obciążone i przywrócenie setek drobniutkich plików pójdzie sprawniej.

Wrzuć na serwer do katalogu głównego pusty plik index.html. No, niekoniecznie pusty, bo możesz napisać w nim np. “przerwa techniczna”. Chodzi po prostu o to, aby przypadkowy internauta nie widział zawartości Twojego serwera, podczas gdy Ty będziesz najpierw usuwał, a później wgrywał z kopii całą jego zawartość.

Tak, musisz wszystko usunąć i wgrać na nowo pliki, których jesteś pewien. Rzadko atak kończy się jedynie podmianą strony głównej. Często uszkodzeniom lub nadpisaniu ulegają pliki komponentów i modułów, a bywa też tak, że hakier wgra sobie w jakieś dyskretne miejsce (np. do katalogu z dużą ilością plików) własny plik, dzięki któremu będzie miał pełny dostęp do zawartości Twojego serwera, oczywiście z maksymalnymi prawami dostępu (mi też tak zrobili). Dlatego nadpisywanie plików nie wchodzi w grę!!! Usuń wszystko i wgraj na nowo, bo jeśli pójdziesz na skróty i nadpiszesz, to zaktualizujesz własne, a cudze pliki zostaną nietknięte.

Po wgraniu kopii nie zapomnij o nadaniu odpowiednim katalogom i plikom właściwych CHMOD-ów.

Podsumowanie:
1) jeśli w katalogu głównym znajdziesz index.html – delete go
2) z backupu wgraj index.php i configuration.php (oczywiście do głównego katalogu)
3) Nocą (najlepiej) usuń całą zawartość swojego serwera i wgraj ze swojej kopii, której jesteś pewien

Poza tym: zmień hasła serwisu oraz bazy danych i na wszelki wypadek możesz sprawdzić, czy nie przybyło Ci administratorów :)

Wiem, wiem, lenistwo płynie razem z krwią, ale robienie backupów to nie taka straszna rzecz, oczywiście pod warunkiem, że odpowiednio się to zorganizuje. Najlepiej zrobić (choćby zaraz) pełen zrzut zawartości serwera na własny dysk. Później wystarczy aktualizować:
– katalogi, w których zawartość się zmieniła: obrazki, pliki w downloadzie, katalogi dodatków jeśli coś nowego instalowałeś
– configuration.php, jeśli zmieniałeś jakieś ustawienia.