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:


Najprostszy sposób: wpisz adres swojej strony głównej i po załadowaniu się podmienionej zobacz, jaki url widnieje w pasku adresu: jeśli z głównego adresu strony przekierowało Cię do jakiegoś katalogu w Twojej domenie – zainteresuj się też tym katalogiem, bo w nim właśnie jest ta okropna strona z czaszką czy jakimś innym potworem.

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.

Subskrybcja
Powiadom o
guest
8 komentarzy
Wbudowane komentarze zwrotne
Pokaż wszystkie komentarze
Anonimowo

kolejny bardzo dobry edukacyjny artykuł o Joomli ale mimo to nie zycze nikomu aby musial stosowac sie do wskazowek dotyczacych “reanimacji”. A tak swoja droga bardzo ciekawa analogia w tytułe ;-]

pen.R

we wczesniejszym komentarzu zapomniałem podpisac się ;-]

Arek

Gdyby wszyscy podchodzili odpowiedzialnie do swoich witryn to niepotrzebne by były tego typu artykuły. Ale tak nie jest i trzeba tłumaczyć czasami nawet jak dziecku. Widzę, Szuman, że spodobał Ci się pomysł na artykuł, który podsunąłem w komentarzu do artykułu o włamaniach. W imieniu tych wszystkich ignorantów dzięki za tekst. I tak jak Pen.R. napisał “nie zycze nikomu aby musial stosowac sie do wskazowek dotyczacych “reanimacji”. Pozdrawiam i czekam na kolejne ciekawe teksty o Joomla!

szuman

pomysł był dobry, więc skorzystałem ;) Masz rację, gdyby ludzie byli odpowiedzialni, to takie artykuły byłyby zbędne. Z resztą podobnie jest z kierowcami, pieszymi, internautami…

regdos

Tak mi się nasunęło czytając:
“Jak wiadomo, index.html ma pierwszeństwo przed index.php (innymi słowy serwer w pierwszej kolejności szuka pliku z rozszerzeniem .html”

Nie jest to prawdą, ponieważ to zależy od tego co admin wpisał do konfiguracji apache, a dokładnie ważna jest kolejność plików w dyrektywie DirectoryIndex pliku konfiguracyjnego w tym wypadku serwera apache.

szuman

w sumie rację masz, ale osobiście nie zetknąłem się jeszcze z serwerem skonfigurowanym tak, jak piszesz. Przeważnie jednak jest tak, że na pierwszy ogień idzie .html.

Peter

Bardzo ciekawy i pomocny artykuł. Ja mam ustawione domyślnie index.php. Mi ostatnio zhakowali stronę. Najpierw podmienili pliki a katalogu administratora, że nie mogłem się zalogować, a na drugi dzień (w nocy) podmienili index.php. Ale boję się, że mi coś tam wrzucili “nie mojego” i jestem zmuszony wgrać kopie ftp.
Oczywiście byli z Turcji. Pomimo, że miałem wszystkie zaktualizowane komponenty i joomle.

szuman

@Peter, sama aktualizacja bazowego systemu i rozszerzeń nie wystarcza: przede wszystkim ustawienia serwer muszą być dostosowane, a dokładnie register_globals, bo własnie ta funkcja odpowiada za te “tureckie włamania” :) Przeczytaj tekst “Sezon włamań na Joomla rozpoczęty” – tam jest właśnie o tych atakach (jeśli jeszcze nie czytałeś)