Odwirusowanie i naprawa stron

O infekcji rzadko dowiadujesz się od siebie. Zwykle dzwoni klient, że strona przenosi go do obcego sklepu. Albo Google pokazuje w wynikach „Ta witryna może być niebezpieczna”. Albo przeglądarka wyświetla czerwony ekran ostrzeżenia, poczta zaczyna wracać z odbiciami, a hosting przysyła maila o przekroczeniu limitu zasobów. Pierwsza reakcja jest zawsze taka sama: szybko coś zrobić.

I właśnie wtedy najłatwiej pogorszyć sprawę. Poniżej opisujemy, co zrobić w pierwszej godzinie, jak wygląda naprawa po naszej stronie i co dokładnie robi cpGuard — system ochrony działający na naszych serwerach, który większość takich historii kończy, zanim się zaczną.

Pierwsza godzina: niczego nie kasuj

Odruch jest zrozumiały: usunąć podejrzany plik, przeinstalować WordPressa, odtworzyć kopię z wczoraj. Każda z tych trzech rzeczy potrafi zaszkodzić.

• Usunięcie pliku niszczy ślady, a prawie nigdy nie usuwa tylnego wejścia. Włamanie to zwykle kilka plików w różnych miejscach plus jeden niepozorny dodatek w bazie albo w zadaniach cron.
• Przeinstalowanie CMS-a nie rusza wtyczek, motywu ani katalogu z uploadami — a to tam najczęściej siedzi problem.
• Odtworzenie kopii z wczoraj rzadko wystarcza. Infekcje wykrywa się zwykle po tygodniach, więc „wczorajsza” kopia bywa już zainfekowana. Dlatego trzymamy kopie do 30 dni — żeby było z czego wybierać.

Co warto zrobić od razu: zrób pełną kopię plików i bazy, nawet zainfekowaną — to materiał do analizy. Zmień hasła do panelu, FTP i bazy, ale z czystego urządzenia. I napisz do nas, zanim zaczniesz kasować.

Jak wygląda naprawa

Pracujemy zawsze w tej samej kolejności, bo pomijanie kroków kończy się powrotem infekcji po dwóch tygodniach.

1. Izolacja i kopia. Zdejmujemy stronę z ruchu albo stawiamy jej kopię osobno, żeby czyścić w spokoju i bez kolejnych wejść w trakcie pracy.
2. Skan. Pełny skan plików i bazy plus lista plików zmienionych w ostatnim czasie. Ta lista zwykle od razu pokazuje, kiedy i którędy ktoś wszedł.
3. Czyszczenie. Wstrzyknięty kod wycinamy z plików, zamiast kasować pliki w całości. Pliki rdzenia CMS-a, wtyczek i motywu podmieniamy na oryginalne wersje z paczek producenta.
4. Zamykanie wejść. Hasła bazy i kont, nowe klucze zabezpieczeń w konfiguracji WordPressa, przegląd kont administratorów (po włamaniu często jest jedno „nadprogramowe”), zadania cron, pliki PHP w katalogu uploadów, reguły w .htaccess.
5. Usunięcie przyczyny. Aktualizacja CMS-a, wtyczek i motywu, wyrzucenie porzuconych rozszerzeń, przejście na wspieraną wersję PHP. Bez tego kroku czyszczenie to tylko odroczenie.
6. Wyjście z list ostrzeżeń. Zgłoszenie strony do ponownego sprawdzenia w Google Search Console, żeby zniknął komunikat o niebezpiecznej witrynie.
7. Obserwacja. Przez kilka dni po czyszczeniu patrzymy w logi zapory i skanera. Prawdziwym testem nie jest to, że strona działa, ale to, że infekcja nie wraca.

Skąd się to wzięło — cztery typowe drogi

W praktyce prawie wszystko mieści się w czterech scenariuszach:

• Nieaktualna wtyczka albo motyw. Najczęstsza droga. Luka zostaje opublikowana, a boty skanują za nią cały internet w ciągu godzin. Nikt nie wybiera Twojej strony — po prostu ma akurat tę wtyczkę.
• Hasło. Atak słownikowy na panel logowania albo hasło, które wyciekło z zupełnie innego serwisu i było używane ponownie.
• Zapomniana instalacja. Stary WordPress w katalogu /test, kopia sklepu w /old, sprzed trzech lat, bez aktualizacji. Dla atakującego to otwarte drzwi obok zamkniętych.
• Komputer autora strony. Wykradzione dane FTP z zainfekowanego laptopa. Wtedy strona „sama się psuje” po każdym czyszczeniu, dopóki nie posprzątasz komputera.

Jak działa cpGuard

cpGuard to system ochrony zainstalowany na poziomie serwera, zintegrowany z panelem DirectAdmin. Nie jest wtyczką do CMS-a i nie zużywa zasobów Twojego konta na skanowanie. Działa w trzech warstwach, które warto rozumieć osobno, bo odpowiadają na różne rodzaje ataku.

Warstwa 1: zapora aplikacyjna (WAF)

To ModSecurity z komercyjnym zestawem reguł Malware.Expert, dostrojonym pod serwery współdzielone. Filtruje żądania, zanim dotrą do Twojego PHP — i to jest w tym najważniejsze. Blokuje między innymi:

• wstrzyknięcia SQL i próby wykradzenia zawartości bazy,
• ataki XSS (wstrzykiwanie skryptów w treść strony),
• dołączanie plików lokalnych i zdalnych (LFI/RFI),
• nadużycia formularzy wysyłania plików,
• uruchamianie web shelli, czyli paneli zdalnego dostępu podrzucanych po włamaniu,
• ataki na świeżo opublikowane luki, zanim pojawi się łatka.

W zestawie są też reguły pisane konkretnie pod WordPressa, Joomlę i Drupala. Praktyczny wniosek: zapora kupuje Ci czas na aktualizację wtyczki, której jeszcze nie zdążyłeś podbić. Nie zwalnia z aktualizowania — ale różnica między „luka istnieje” a „luka jest wykorzystana” to zwykle właśnie ta warstwa.

Warstwa 2: skaner plików

Skaner obserwuje zmiany plików na bieżąco i dodatkowo przechodzi konto według harmonogramu. Gdy trafi na coś podejrzanego, plik idzie do analizy w silniku chmurowym, a na serwer wraca wersja wyczyszczona — wstrzyknięty fragment zostaje wycięty, a plik zostaje na miejscu i strona dalej działa. To ważna różnica wobec zwykłych antywirusów, które kasują cały plik i przy okazji psują witrynę.

Pliki, których nie da się wyczyścić, trafiają do kwarantanny. Można je z niej przywrócić, i to nie jest szczegół techniczny: skanery czasem mylą własny, nietypowy kod ze złośliwym. Kwarantanna oznacza, że fałszywe trafienie jest odwracalne jednym kliknięciem, a nie utratą pliku.

Warstwa 3: logowanie, boty i reputacja adresów

Tu mieści się wszystko, co dzieje się przed samym atakiem na kod:

• ochrona przed atakami słownikowymi na panele logowania WordPressa i Joomli — zamiast przepuszczać tysiące prób haseł, serwer ucina je u siebie;
• captcha dla botów, która odsiewa automaty bez blokowania ludzi;
• firewall oparty o bazę adresów o złej reputacji (IPDB), aktualizowaną na bieżąco — żądania z adresów znanych z nadużyć nie dochodzą do strony;
• wykrywanie rootkitów oraz podejrzanych linków symbolicznych — czyli sztuczki, którą atakujący próbuje przejść z jednego konta na drugie na wspólnym serwerze.

Co z tego widzisz u siebie: w panelu DirectAdmin masz wgląd w ataki zablokowane na Twoich domenach. Nie musisz nam wierzyć na słowo ani pisać z pytaniem, czy coś się dzieje.

Czego cpGuard nie zrobi

Wolimy to powiedzieć wprost, bo nadmierne obietnice w kwestii bezpieczeństwa kończą się rozczarowaniem w najgorszym momencie.

• Nie zaktualizuje za Ciebie wtyczek. To nadal Twoja strona i Twoje decyzje o tym, co na niej działa.
• Nie naprawi błędu w kodzie własnego motywu ani dziury w autorskiej wtyczce pisanej na zamówienie.
• Nie zastąpi kopii zapasowych. Najlepsza ochrona to taka, po której i tak masz z czego odtworzyć stronę.
• Nie cofnie wycieku hasła. Jeśli ktoś ma Twoje dane do panelu, wchodzi drzwiami, a nie przez lukę.
• Zdarzają się fałszywe trafienia. Reguła zapory potrafi czasem zablokować całkiem legalne działanie — na przykład edytor w CMS-ie albo wtyczkę wysyłającą duże pliki. Wtedy dostosowujemy reguły dla konkretnej domeny. Wystarczy zgłoszenie.

Higiena po naprawie — kwadrans w miesiącu

Po wyczyszczeniu strony zostaje najtrudniejsze: nie dopuścić do powtórki. Lista jest krótka i naprawdę wystarcza:

• aktualizacje raz w miesiącu, z jedną osobą odpowiedzialną za to zadanie;
• wyrzucenie nieużywanych wtyczek i starych instalacji z podkatalogów;
• unikalne hasła i druga weryfikacja przy logowaniu do panelu CMS-a;
• tylko tyle kont z uprawnieniami administratora, ile naprawdę potrzeba;
• sprawdzenie, czy kopia faktycznie się odtwarza — kopia nigdy nieprzetestowana to tylko założenie;
• PHP w wersji, która wciąż dostaje poprawki bezpieczeństwa.

Resztę parametrów ochrony po stronie serwera — czasy reakcji, zakres monitoringu i procedury przy incydencie — opisaliśmy na stronie parametrów bezpieczeństwa.

Jak zacząć

Napisz, co się stało, i podaj adres strony. Jeśli masz komunikat z Google Search Console, raport z wtyczki bezpieczeństwa albo maila od obecnego hostingu — podeślij go, bo zwykle od razu zawęża poszukiwania. Odpowiemy, czy to naprawa na godzinę, czy na pół dnia, i czy stronę da się uratować bez odtwarzania z kopii.

Nie musisz przenosić hostingu, żeby z nami o tym pogadać. A jeśli zostajesz u obecnego dostawcy, powiemy wprost, czego tam brakuje. Jeśli natomiast przenosisz stronę do nas, migracja jest bezpłatna, cpGuard działa od pierwszego dnia bez konfiguracji, a stronę sprawdzamy przy okazji przenosin. Prowadzisz sklep albo serwis na WordPressie? Zajrzyj też na hosting WordPress i hosting WooCommerce, gdzie rozkładamy wymagania tych dwóch przypadków.