Jak sprawdzić, czy Joomla 5 ma wirusa? Objawy i diagnostyka
Infekcja Joomla 5 nie zawsze powoduje natychmiastowe wyłączenie strony. Złośliwy kod może działać w tle, przekierowywać tylko część użytkowników, tworzyć spamerskie podstrony dla Google, wysyłać wiadomości albo utrzymywać ukryty dostęp do serwera.
Strona może więc wyglądać prawidłowo dla administratora, a jednocześnie stanowić zagrożenie dla odwiedzających i innych witryn znajdujących się na tym samym koncie hostingowym.
Rozpoznanie infekcji powinno obejmować nie tylko automatyczny skan plików, lecz także kontrolę bazy danych, kont użytkowników, rozszerzeń, zadań cyklicznych, konfiguracji PHP i logów serwera.
Najczęstsze objawy infekcji Joomla 5
1. Strona przekierowuje na inną domenę
Jednym z najbardziej charakterystycznych objawów jest przekierowanie użytkownika do serwisu reklamowego, fałszywego konkursu, strony hazardowej, sklepu z lekami lub suplementami, komunikatu o rzekomym wirusie albo witryny podszywającej się pod bank lub operatora płatności.
Przekierowanie może być uruchamiane wyłącznie na urządzeniach mobilnych, przy pierwszej wizycie, po wejściu z Google, dla użytkowników niezalogowanych, z określonych adresów IP lub po kliknięciu konkretnego elementu.
Dlatego administrator, który jest zalogowany i wielokrotnie odwiedza stronę z tego samego komputera, może nie widzieć problemu.
2. W Google pojawiły się obce podstrony
W wynikach wyszukiwania mogą pojawić się adresy dotyczące kasyn, leków, pożyczek, kryptowalut, treści erotycznych, fałszywych sklepów lub produktów, których strona nigdy nie oferowała.
Tytuły mogą być napisane po japońsku, chińsku, rosyjsku lub angielsku. Czasami po otwarciu takiego adresu administrator widzi błąd 404, natomiast robot wyszukiwarki otrzymuje wygenerowaną treść spamerską. Taki mechanizm jest często określany jako spam SEO lub cloaking.
3. Hosting wykrył złośliwe pliki
Firma hostingowa może wysłać wiadomość o zainfekowanych plikach PHP, wysyłce spamu, nadmiernym użyciu procesora, próbach atakowania innych serwerów, wykryciu phishingu, automatycznym zablokowaniu domeny lub zawieszeniu całego konta hostingowego.
Pliki wskazane przez hosting nie muszą być źródłem włamania — często są tylko jednym z elementów większej infekcji. Usunięcie wyłącznie plików wymienionych w wiadomości nie daje pewności, że napastnik utracił dostęp.
4. Na serwerze pojawiają się nieznane pliki PHP
Szczególną uwagę należy zwrócić na pliki PHP w katalogach przeznaczonych głównie na multimedia lub pamięć podręczną, takich jak /images/, /media/, /tmp/, /cache/, podkatalogach szablonów czy katalogach rozszerzeń.
Podejrzane mogą być:
- pliki o losowych nazwach
- pliki podszywające się pod elementy systemowe
- kilka plików o niemal identycznej zawartości
- skrypty odtwarzające się po usunięciu
- kod zawierający długie zakodowane ciągi
- odwołania do zewnętrznych serwerów
Nie każdy plik PHP w nietypowym katalogu jest wirusem. Nie wolno usuwać go wyłącznie na podstawie nazwy lub lokalizacji.
5. Pojawił się nieznany administrator
Sprawdź użytkowników posiadających uprawnienia Super Users, Administrator, Manager lub innych grup z dostępem do zaplecza. Należy zweryfikować mapowanie użytkowników do grup bezpośrednio w bazie danych.
Niepokojące są:
- nieznany użytkownik w grupie Super Users
- zmieniony adres e-mail administratora
- nowe konto założone bez wiedzy właściciela
- konto o nazwie przypominającej element systemowy
- nieoczekiwana zmiana hasła lub utrata dostępu do zaplecza
6. Zmienił się plik .htaccess
Złośliwe reguły w .htaccess mogą przekierowywać użytkowników, ukrywać spamerskie podstrony, uruchamiać pliki o nietypowych rozszerzeniach jako PHP, blokować administratorowi dostęp lub wyświetlać inne treści robotom Google.
Sprawdź zarówno główny plik .htaccess, jak i pliki w podkatalogach. Nie zastępuj automatycznie całej konfiguracji standardowym plikiem htaccess.txt — strona może zawierać prawidłowe reguły dotyczące przekierowań, SSL lub ochrony katalogów.
7. Strona zużywa nadmiernie dużo zasobów
Nagły wzrost wykorzystania CPU, pamięci lub transferu może wynikać z wysyłki spamu, masowego tworzenia podstron, kopania kryptowalut, wykonywania poleceń zdalnych lub generowania dużej liczby błędów. Wymaga jednak sprawdzenia, ponieważ może też wynikać z błędu rozszerzenia lub źle skonfigurowanego cache.
Diagnostyka Joomla 5 krok po kroku
Krok 1. Zabezpiecz kopię aktualnego stanu
Przed rozpoczęciem zmian wykonaj kopię wszystkich plików, bazy danych, logów serwera, konfiguracji hostingu, zadań cron i wiadomości od hostingu. Kopia może być zainfekowana, ale stanowi materiał dowodowy i zabezpieczenie przed utratą danych. Nie przechowuj kopii w publicznie dostępnym katalogu strony.
Krok 2. Sprawdź dokładną wersję Joomla
W zapleczu przejdź do System → Informacje → Informacje o systemie. Joomla 5 udostępnia w tym miejscu dane dotyczące wersji PHP, serwera, bazy danych, konfiguracji oraz uprawnień katalogów. Porównaj zainstalowaną wersję z aktualnym repozytorium — starsze wydania mogą być podatne na znane problemy.
Krok 3. Sprawdź rozszerzenia
W Joomla przejdź do System → Zarządzanie → Rozszerzenia i sprawdź każde rozszerzenie: nazwę, producenta, datę instalacji, wersję, status i zgodność z Joomla 5. Szukaj rozszerzeń, których nie rozpoznajesz. Następnie przejdź do System → Aktualizacje → Rozszerzenia i sprawdź dostępne aktualizacje. Brak informacji o aktualizacji nie oznacza, że rozszerzenie jest bezpieczne.
Krok 4. Sprawdź zadania zaplanowane
W Joomla 5 przejdź do System → Zarządzanie → Zaplanowane zadania i sprawdź każde zadanie, jego typ, harmonogram i status. Od Joomla 5.3 dostępna jest historia wykonania zadań, która może pomóc w wykryciu nietypowej aktywności. Sprawdź również cron skonfigurowany w panelu hostingowym.
Krok 5. Porównaj pliki systemowe
Pobierz pełny pakiet dokładnie tej samej wersji Joomla z oficjalnego źródła i porównaj z plikami na serwerze. Szukaj zmodyfikowanych plików rdzenia, dodatkowych plików w katalogach systemowych, nieznanego kodu na początku lub końcu pliku oraz zmian w katalogach /administrator/, /api/, /includes/, /libraries/ i /plugins/. Nie porównuj wyłącznie rozmiaru pliku — używaj sum kontrolnych.
Krok 6. Przejrzyj configuration.php
Sprawdź dane bazy danych, ścieżki do katalogów logów i tymczasowego, ustawienia debugowania, domenę cookie, wymuszanie HTTPS oraz — przede wszystkim — czy nie ma żadnego dodatkowego kodu przed lub po klasie konfiguracyjnej, dodatkowych instrukcji include lub require ani odwołań do nieznanych plików. Nie publikuj zawartości configuration.php — plik zawiera dane dostępowe do bazy danych.
Krok 7. Sprawdź bazę danych
Kontrola powinna objąć użytkowników i przypisane grupy, listę rozszerzeń, aktywne dodatki systemowe, moduły z własnym HTML, treści artykułów, pozycje menu, konfigurację szablonów, zaplanowane zadania oraz sesje użytkowników.
Szukaj w szczególności skryptów JavaScript, ramek iframe, nieznanych domen, zakodowanych fragmentów, ukrytych linków i kont z wysokimi uprawnieniami. Nie wykonuj globalnej operacji znajdź-i-zamień bez kopii bazy.
Krok 8. Przeanalizuj logi
Sprawdź logi żądań HTTP, błędów PHP, FTP i SFTP, logowania SSH, historię panelu hostingowego, logi zapory WAF oraz logi wysyłki poczty. Szukaj aktywności występującej krótko przed pierwszym pojawieniem się złośliwego pliku lub zgłoszeniem od hostingu. Pamiętaj, że data modyfikacji pliku może zostać zmieniona przez atakującego.
Czy automatyczny skaner wystarczy?
Skaner jest przydatny do wykrywania znanych sygnatur, wskazywania zmodyfikowanych plików, odnajdywania podejrzanych funkcji i sprawdzania domen na listach ostrzeżeń. Nie może jednak samodzielnie potwierdzić, że baza danych jest czysta, nie istnieje ukryte konto administratora, cron nie odtwarza infekcji ani że inne strony na hostingu są bezpieczne.
Wynik "nie znaleziono zagrożeń" nie jest dowodem braku infekcji.
Kiedy potrzebna jest profesjonalna analiza?
Pomoc specjalisty jest wskazana, gdy:
- infekcja powraca
- hosting zablokował konto
- na serwerze działa kilka witryn
- strona przetwarza dane klientów
- nie ma pewnej kopii zapasowej
- w Google pojawił się spam SEO
- doszło do przejęcia konta Super User
- nie można jednoznacznie odróżnić plików prawidłowych od złośliwych