Przekierowanie na stronę kasyna, setki obcych podstron widocznych w Google, nowe konto administratora albo formularz płatności zachowujący się inaczej niż dzień wcześniej — tak częściej wygląda początek incydentu z WordPressem niż komunikat „strona została zhakowana”. Problem w tym, że widoczny objaw niewiele mówi o skali włamania. Usunięcie jednego podejrzanego pliku może potrwać minutę. Ustalenie, skąd ten plik się wziął, co jeszcze uruchamiał i czy napastnik nadal ma dostęp, potrafi zająć kilka godzin.
Określenie „wirus na WordPressie” jest zresztą wygodnym skrótem. Pod nim mogą kryć się zupełnie różne problemy: backdoor PHP, webshell, wstrzyknięty JavaScript, SEO spam, phishing, złośliwe przekierowania, przejęte konto administratora albo wykorzystana podatność wtyczki. Czasem sam WordPress jest tylko jednym z elementów incydentu, bo przejęte zostało całe konto hostingowe albo dane dostępowe do SFTP czy SSH.
To właśnie dlatego firmy płacą za tę usługę znacznie więcej niż za zwykłą aktualizację WordPressa. Nie kupują „skanowania antywirusem”. Kupują możliwie szybkie ustalenie, co zostało przejęte, jak zatrzymać dalsze szkody i jak nie dopuścić do ponownej infekcji po kilku dniach.
Za co firma naprawdę płaci podczas awarii WordPressa
Na polskim rynku nie istnieje jedna uczciwa stawka za „usunięcie wirusa”. W aktualnych cennikach można znaleźć usługi rozpoczynające się od około 350–500 zł netto, częściej od 600–1100 zł netto, a rozbudowana analiza sklepu WooCommerce, kilku instalacji albo mocno zaniedbanego środowiska może wejść w przedział 1500–3000 zł netto lub wyżej.
Sam rozrzut cen powinien być pierwszym ostrzeżeniem. Dwie usługi opisane jako „odwirusowanie WordPressa” mogą oznaczać zupełnie inną pracę.
Najtańszy wariant zwykle sprowadza się do przeskanowania instalacji, znalezienia podejrzanych plików i usunięcia wykrytego kodu. To może wystarczyć przy prostym przypadku, ale nie daje odpowiedzi na ważniejsze pytanie: dlaczego malware znalazło się na serwerze?
Pełna interwencja powinna objąć przynajmniej:
-
wykonanie kopii plików i bazy przed rozpoczęciem czyszczenia;
-
zabezpieczenie dostępnych logów;
-
ustalenie, czy problem dotyczy jednej instalacji czy całego konta hostingowego;
-
analizę rdzenia WordPressa, wtyczek, motywu i katalogu
wp-content; -
kontrolę kont administratorów i ostatnio utworzonych użytkowników;
-
analizę
wp_options, zadań WP-Cron i reguł w.htaccess; -
sprawdzenie nietypowych zmian plików;
-
kontrolę bazy pod kątem wstrzykniętego JavaScriptu, spamu SEO i obcych adresów URL;
-
ustalenie prawdopodobnej drogi wejścia;
-
usunięcie backdoorów i innych mechanizmów reinfekcji;
-
aktualizację lub wymianę podatnych komponentów;
-
rotację tych danych dostępowych, które mogły zostać przejęte;
-
testy po uruchomieniu strony;
-
obserwację środowiska po zakończeniu czyszczenia.
Skaner jest narzędziem, a nie dowodem, że witryna jest czysta. Wordfence, Sucuri Security czy inne rozwiązanie może znaleźć znany wzorzec malware, ale nie potwierdzi automatycznie, że napastnik nie dodał własnego pliku, nie utworzył administratora albo nie pozostawił mechanizmu uruchamianego przez cron.
Podobnie jest z liczbą znalezionych infekcji. Sto wykrytych plików nie musi oznaczać stu niezależnych problemów. Jeden backdoor mógł zmodyfikować wszystkie. Z kolei jeden znaleziony plik nie oznacza, że incydent jest mały.
Szczególnie podejrzane są między innymi:
-
pliki PHP pojawiające się w
wp-content/uploads; -
pliki o przypadkowo wyglądających nazwach utworzone w okresie rozpoczęcia problemów;
-
nowe pliki w
wp-adminlubwp-includes, które nie należą do standardowej instalacji; -
nieznane wpisy administratorów;
-
zadania cron, których nie da się przypisać do używanej funkcji lub wtyczki;
-
obcy JavaScript zapisany w bazie danych;
-
zmienione reguły przekierowań w
.htaccess; -
ciągi wykorzystujące funkcje takie jak
eval,base64_decodeczygzinflatew miejscu, w którym nie powinno ich być.
Ostatni punkt wymaga ostrożności. Sama obecność base64_decode nie jest dowodem infekcji. Legalna wtyczka również może używać takich funkcji. Liczy się kontekst, pochodzenie pliku, moment jego utworzenia i porównanie z czystą wersją komponentu.
Tu wychodzi różnica między prawdziwą analizą a mechanicznym wyszukiwaniem podejrzanych fragmentów kodu.
Dobrze widać to na przykładzie integralności WordPressa. Przy dostępie do WP-CLI można użyć:
wp core verify-checksums
Polecenie porównuje pliki rdzenia z checksumami odpowiadającymi oficjalnej wersji WordPressa. Warto rozszerzyć kontrolę również na katalog główny:
wp core verify-checksums --include-root
Dla wtyczek dostępnych w oficjalnym repozytorium przydatne jest:
wp plugin verify-checksums --all --strict
To daje znacznie więcej informacji niż komunikat „skaner niczego nie wykrył”. Nadal nie rozwiązuje jednak całego problemu. Wtyczka premium, komponent napisany na zamówienie albo pliki motywu mogą nie mieć dostępnych oficjalnych checksum. Wtedy pozostaje porównanie z oryginalną paczką tej samej wersji albo analiza ręczna.
Jest jeszcze jeden praktyczny problem: instalacja może przejść sprawdzenie rdzenia, a nadal być zainfekowana. Malware może znajdować się wyłącznie w wp-content, bazie danych albo dodatkowym pliku, którego standardowy test nie traktuje jako zmodyfikowanego elementu WordPressa.
Dlatego cena 300–500 zł za automatyczny skan i cena 1500–3000 zł za analizę rozbudowanego incydentu nie dotyczą faktycznie tej samej pracy.
Niedogodność jest prosta: rzetelnej wyceny często nie da się zrobić wyłącznie po zrzucie ekranu z Wordfence’a. Wykonawca powinien wiedzieć przynajmniej, ile instalacji znajduje się na koncie, czy działa WooCommerce, czy są logi, jak stare są backupy i czy podejrzewa się przejęcie hostingu.
Jeżeli ktoś gwarantuje z góry, że „wirus już nigdy nie wróci”, deklaruje więcej, niż może technicznie kontrolować. Nie kontroluje przyszłych podatności, komputerów pracowników, nowych haseł ani kolejnych instalowanych wtyczek. Można usunąć znane mechanizmy infekcji i mocno ograniczyć ryzyko powrotu. Stuprocentowej gwarancji na przyszłość nie da się uczciwie wystawić.
Procedura techniczna: najpierw zatrzymać incydent, potem znaleźć drogę wejścia
Pierwszym odruchem właściciela strony jest często kasowanie tego, co wygląda podejrzanie. To może być błąd.
Jeżeli strona nadal przekierowuje odwiedzających, wyświetla phishing, rozsyła malware albo ingeruje w checkout WooCommerce, najwyższy priorytet ma ograniczenie szkód. Czasowe wyłączenie sprzedaży jest bolesne, ale dalsze kierowanie klientów na podstawiony formularz płatności jest gorsze.
Przed usuwaniem plików warto zabezpieczyć:
-
pełną kopię plików;
-
eksport bazy danych;
-
access log i error log;
-
informacje o ostatnich logowaniach, jeśli hosting je udostępnia;
-
listę użytkowników WordPressa;
-
listę aktywnych i nieaktywnych wtyczek;
-
konfigurację zadań cron.
Kopia zainfekowanej strony nie służy do późniejszego przywrócenia jej na produkcję. Jest materiałem do analizy. Podejrzany plik skasowany bez zachowania kopii mógł zawierać nazwę innego komponentu, adres serwera sterującego albo mechanizm wskazujący, co uruchamiało malware.
Następnie trzeba odpowiedzieć na pytanie, jaki jest zakres kompromitacji.
Są trzy typowe poziomy:
-
Przejęto jedną instalację WordPressa — na przykład przez podatną wtyczkę.
-
Przejęto dane dostępowe — administratora WordPressa, panelu hostingu, SFTP albo SSH.
-
Problem obejmuje całe środowisko — kilka stron działających w obrębie tego samego konta hostingowego.
Trzeci przypadek jest szczególnie zdradliwy. Można perfekcyjnie wyczyścić domenę firmową, ale pozostawić starego WordPressa uruchomionego w katalogu /old, /test albo na zapomnianej subdomenie. Jeżeli wszystkie instalacje działają z uprawnieniami pozwalającymi na wzajemną modyfikację plików, napastnik może wrócić z sąsiedniej strony.
Dlatego profesjonalna diagnoza nie powinna zatrzymywać się na katalogu jednej domeny.
Co sprawdza się w samej instalacji?
W plikach interesują przede wszystkim daty modyfikacji oraz odstępstwa od oryginalnych wersji. PHP w uploads jest mocnym sygnałem ostrzegawczym, ponieważ ten katalog zasadniczo przechowuje przesłane media. Nie oznacza to jednak automatycznie włamania — najpierw trzeba ustalić, skąd plik pochodzi.
W wp-config.php sprawdza się nie tylko dane bazy, ale również obce fragmenty kodu, dołączane pliki i nietypowe definicje. W .htaccess szuka się reguł przekierowań oraz warunków uruchamianych tylko dla określonych użytkowników, urządzeń lub źródeł ruchu.
To ważny niuans. Złośliwe przekierowanie może nie wystąpić administratorowi zalogowanemu do WordPressa. Może uruchamiać się tylko:
-
na telefonach;
-
przy pierwszej wizycie;
-
dla ruchu z Google;
-
dla określonych user-agentów;
-
po wejściu na konkretną podstronę.
Dlatego test „otworzyłem stronę u siebie i już nie przekierowuje” nie wystarcza.
W bazie danych sprawdza się między innymi wp_options, treści postów, ustawienia wtyczek oraz nietypowe adresy URL i fragmenty JavaScriptu. Przy zmianie prefiksu tabel wp_ oczywiście nazwy będą inne.
Potem użytkownicy. Nowy administrator o nazwie podobnej do systemowej albo adresie e-mail, którego nikt w firmie nie rozpoznaje, jest oczywistym alarmem. Mniej oczywista sytuacja to legalne konto administratora, którego hasło zostało przejęte. Sama lista użytkowników nie rozstrzygnie wtedy problemu.
Trzeba również sprawdzić WP-Cron. Usunięcie backdoora niewiele daje, jeżeli za godzinę zadanie cron pobierze lub odtworzy ten sam plik.
Następny etap to pytanie, którego nie wolno pominąć: jak napastnik wszedł?
Najczęstsze kategorie przyczyn to:
-
podatna lub nieaktualna wtyczka;
-
stary motyw pozostawiony na serwerze;
-
porzucony komponent, którego nikt już nie aktualizuje;
-
przejęte hasło administratora;
-
przejęte dane panelu hostingowego;
-
skradzione dane SFTP/SSH;
-
zainfekowany komputer osoby administrującej stroną;
-
druga podatna witryna na tym samym koncie;
-
błędne uprawnienia plików;
-
pozostawiona stara instalacja testowa.
Nie każdą drogę wejścia da się udowodnić. Jeżeli hosting przechowuje bardzo krótką historię logów, a włamanie nastąpiło miesiąc wcześniej, część śladów może już nie istnieć. Wtedy należy odróżnić potwierdzony wektor ataku od najbardziej prawdopodobnego.
Typowy scenariusz diagnostyczny może wyglądać tak: firma zauważa przekierowanie na telefonach. Skaner wskazuje jeden zmodyfikowany plik wtyczki. Po jego usunięciu problem znika. Na tym łatwo zakończyć pracę.
Tyle że dalsza analiza pokazuje PHP w uploads, nieznane zadanie WP-Cron oraz tę samą datę modyfikacji kilku innych plików. W logach widać wcześniejsze nietypowe żądania kierowane do jednego z komponentów. W takiej sytuacji pierwszy znaleziony plik nie był „wirusem do skasowania”, lecz jednym z elementów większego mechanizmu.
Dopiero po ustaleniu zakresu można przejść do czyszczenia.
W przypadku rdzenia WordPressa zwykle bezpieczniejsze od ręcznego poprawiania zainfekowanego pliku jest zastąpienie go czystą wersją odpowiadającą właściwemu wydaniu. Podobnie z publicznie dostępnymi wtyczkami: jeżeli pliki zostały zmodyfikowane, ponowna instalacja z zaufanej paczki daje większą pewność niż usuwanie pojedynczych linijek.
Inaczej wygląda sytuacja z motywem lub wtyczką zawierającą własne modyfikacje. Bez sprawdzenia zmian można razem z malware skasować kod potrzebny stronie. To jeden z powodów, dla których automatyczna podmiana wszystkich plików nie jest uniwersalną receptą.
Backup również nie jest magicznym przyciskiem cofania włamania.
Jeżeli pierwsze widoczne objawy pojawiły się w poniedziałek, nie oznacza to, że infekcja zaczęła się w niedzielę. Backdoor mógł działać bezobjawowo od kilku tygodni.
Przy wyborze kopii trzeba zestawić:
-
moment pojawienia się pierwszych objawów;
-
daty zmian podejrzanych plików;
-
historię administratorów;
-
dostępne logi;
-
kilka kolejnych backupów.
Celem nie jest znalezienie najstarszego backupu, tylko ostatniej wersji, którą można rozsądnie uznać za czystą.
Nawet wtedy pozostaje druga część problemu. Jeżeli backup zawiera podatną wtyczkę, która umożliwiła włamanie, przywróciliśmy czystą stronę razem z otwartymi drzwiami.
Po właściwym oczyszczeniu przychodzi czas na rotację dostępów. Zakres zależy od incydentu. Do rozważenia są:
-
hasła administratorów WordPressa;
-
hasło panelu hostingowego;
-
dane SFTP/SSH;
-
hasło użytkownika bazy;
-
konta techniczne;
-
SMTP;
-
klucze API;
-
klucze używane przez integracje sklepu;
-
sekrety webhooków i innych usług, jeżeli mogły zostać ujawnione.
Zmiana danych dostępowych do bazy ma również stronę praktyczną: nowe hasło trzeba natychmiast wprowadzić do konfiguracji aplikacji, inaczej WordPress straci połączenie z bazą.
Warto również wygenerować nowe klucze bezpieczeństwa i SALT WordPressa. Ich zmiana unieważnia istniejące cookies uwierzytelniające, więc użytkownicy zostaną wylogowani. To celowe działanie podczas incydentu, a nie metoda usuwania malware.
2FA nie należy traktować jako czegoś, co „ma sens dopiero na końcu”. Jeżeli istnieje podejrzenie przejęcia kont administratorów, zabezpieczenie tych kont może być częścią wczesnego zatrzymania incydentu. Jednocześnie 2FA nie pomoże, gdy na serwerze nadal działa backdoor pozwalający wykonywać kod bez logowania.
Po czyszczeniu można dodatkowo utwardzić środowisko: usunąć nieużywane komponenty, wymusić 2FA dla kont uprzywilejowanych, ograniczyć liczbę administratorów i wyłączyć możliwość edycji plików z panelu WordPressa przez DISALLOW_FILE_EDIT.
Ta ostatnia opcja jest dodatkową warstwą ochronną. Nie blokuje wszystkich sposobów przesyłania złośliwych plików i nie może być przedstawiana jako zabezpieczenie przed włamaniem.
Najważniejsze pytanie brzmi teraz: po czym wiadomo, że WordPress jest czysty?
Nie po tym, że strona znowu się otwiera.
Minimalna kontrola po incydencie powinna dać odpowiedź, czy:
-
rdzeń przechodzi kontrolę integralności;
-
wtyczki i motyw zostały zweryfikowane lub zastąpione czystymi wersjami;
-
nie ma nieznanych administratorów;
-
usunięto podejrzane zadania cron;
-
baza nie zawiera znanych elementów infekcji;
-
reguły serwera są prawidłowe;
-
nie pozostały podejrzane pliki;
-
usunięto lub ograniczono ustaloną drogę wejścia;
-
przejęte poświadczenia zostały unieważnione;
-
strona zachowuje się prawidłowo dla użytkownika niezalogowanego;
-
na urządzeniach mobilnych nie występują ukryte przekierowania;
-
logi po ponownym uruchomieniu nie pokazują kolejnych prób odtwarzania malware.
Dobrze jest obserwować stronę jeszcze po naprawie. Powrót podejrzanego pliku po 20 minutach jest często cenniejszą informacją diagnostyczną niż kolejny automatyczny skan.
Gdy zainfekowany WordPress zaczyna kosztować więcej niż sama naprawa
Przy stronie firmowej awaria może oznaczać kilka godzin bez formularza kontaktowego. Przy WooCommerce ten sam incydent ma zupełnie inną wagę.
Poza standardową analizą trzeba wtedy sprawdzić:
-
konta klientów;
-
administratorów i pracowników sklepu;
-
dane zamówień;
-
proces checkout;
-
wtyczki operatorów płatności;
-
webhooki;
-
klucze REST API;
-
integracje z ERP, CRM i systemami magazynowymi;
-
mechanizmy wysyłające wiadomości transakcyjne;
-
zmiany w kodzie uruchamianym na stronie płatności.
Szczególnie niebezpieczna jest sytuacja, w której złośliwy JavaScript ingeruje w formularz lub przebieg płatności. Wtedy pytanie „czy sklep znowu przyjmuje zamówienia?” jest zdecydowanie za małe. Trzeba ustalić, co użytkownik wpisywał podczas trwania infekcji i czy informacje mogły zostać wysłane do osoby trzeciej.
Tu problem techniczny może zmienić się w problem dotyczący ochrony danych osobowych.
Samo znalezienie malware nie oznacza automatycznie obowiązku zgłoszenia incydentu Prezesowi UODO. Najpierw trzeba ocenić, czy doszło do naruszenia ochrony danych osobowych, czyli między innymi nieuprawnionego dostępu, ujawnienia, utraty, zniszczenia lub zmiany danych.
Jeżeli naruszenie może powodować ryzyko naruszenia praw lub wolności osób fizycznych, administrator co do zasady powinien zgłosić je organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż 72 godziny od stwierdzenia naruszenia. Wyjątkiem jest sytuacja, w której wystąpienie takiego ryzyka jest mało prawdopodobne.
Jeżeli natomiast naruszenie może powodować wysokie ryzyko, może powstać również obowiązek poinformowania osób, których dane dotyczą, bez zbędnej zwłoki.
Jest jeszcze jeden element często pomijany podczas technicznej akcji ratunkowej: naruszenie trzeba odpowiednio udokumentować również wtedy, gdy po przeprowadzeniu oceny zapadnie decyzja, że nie wymaga ono zgłoszenia organowi.
Dlatego przy sklepie internetowym, portalu klienta czy dużej bazie formularzy nie powinno się kończyć incydentu na informacji „wyczyściliśmy pliki”.
Podobnie wygląda sprawa z Google.
Jeżeli Search Console pokazuje Problem dotyczący bezpieczeństwa, samo usunięcie jednego adresu URL nie wystarczy. Google oczekuje naprawienia problemu w całej witrynie. Dopiero po usunięciu wszystkich wykrytych problemów należy poprosić o ponowne sprawdzenie. Weryfikacja nie musi być natychmiastowa — Google podaje, że w zależności od przypadku może potrwać od kilku dni do kilku tygodni.
Jeżeli z serwera rozsyłano spam, osobno trzeba sprawdzić reputację adresu IP, konta pocztowe i konfigurację wysyłki. W takiej sytuacji wyczyszczony WordPress nie musi automatycznie oznaczać, że poczta firmy następnego dnia przestanie trafiać do spamu.
Przed zamówieniem interwencji warto więc ustalić dokładny zakres. Dobre pytania do wykonawcy są bardziej wartościowe niż pytanie „ile za usunięcie wirusa?”.
Trzeba sprawdzić:
-
czy cena obejmuje tylko pliki, czy również bazę;
-
czy analizowane są logi;
-
czy wykonawca szuka drogi wejścia;
-
czy kontroluje konta administratorów i cron;
-
czy sprawdza inne strony na tym samym hostingu;
-
czy w cenie jest zabezpieczenie po naprawie;
-
czy obejmuje WooCommerce i jego integracje;
-
czy wykonawca pomaga przy ponownej weryfikacji w Google;
-
czy po czyszczeniu przewidziany jest monitoring;
-
co dokładnie oznacza ewentualna „gwarancja”.
Czas realizacji również należy czytać razem z zakresem. Na rynku można znaleźć deklaracje przywrócenia strony w 24 godziny, realizacji w 24–48 godzin albo w 1–3 dni robocze. To rozsądne orientacyjne wartości dla wielu standardowych przypadków, ale nie termin gwarantowany dla każdego incydentu.
Mały WordPress z jedną rozpoznaną infekcją może zostać obsłużony w ciągu kilku godzin pracy. Sklep z wieloletnią historią, dużą bazą, kilkudziesięcioma wtyczkami, własnym kodem i kilkoma instalacjami na jednym hostingu może wymagać kilku dni.
Najwięcej czasu nie zawsze pochłania samo kasowanie malware. Znacznie droższe potrafi być udowodnienie, że nie pozostawiono mechanizmu, który odtworzy infekcję.
To jest właśnie część usługi, za którą firma płaci podczas sytuacji awaryjnej.
FAQ
Czy da się wyczyścić WordPressa bez wyłączania strony?
Tak, jeżeli charakter infekcji na to pozwala. Jeżeli witryna tylko zawiera podejrzany plik, ale nie szkodzi aktualnie użytkownikom, część prac można wykonać bez pełnego wyłączenia serwisu. Jeżeli strona prowadzi phishing, przekierowuje klientów, rozsyła malware albo istnieje podejrzenie podmiany checkoutu, ciągłość sprzedaży przestaje być priorytetem. Najpierw ogranicza się szkody.
Dlaczego malware wróciło kilka dni po wyczyszczeniu?
Najczęściej dlatego, że usunięto widoczny objaw, ale pozostał backdoor, podatna wtyczka, zadanie cron albo aktywne przejęte dane dostępowe. Druga możliwość to inna zainfekowana instalacja działająca na tym samym koncie hostingowym. Powrót identycznego pliku jest wskazówką diagnostyczną — trzeba ustalić, jaki proces go odtwarza.
Czy wystarczy przywrócić backup?
Tylko wtedy, gdy masz podstawy, aby uznać kopię za czystą, i jednocześnie zamkniesz drogę wykorzystaną do włamania. Backup sprzed dwóch dni nie pomoże, jeżeli backdoor znajdował się na stronie od miesiąca. Przywrócenie kopii z podatną wersją wtyczki może bardzo szybko odtworzyć warunki do kolejnego ataku.
Po czym poznać, że backup jest czysty?
Nie da się tego wiarygodnie określić na podstawie samej daty pliku. Trzeba zestawić historię backupów z momentem pierwszych objawów, datami modyfikacji podejrzanych plików, dostępnymi logami i zmianami użytkowników. Jeżeli nie ma odpowiedniej historii, pewność będzie ograniczona i trzeba to powiedzieć wprost.
Czy skaner Wordfence lub innego systemu wystarczy do potwierdzenia, że strona jest bezpieczna?
Nie. Skaner jest dobrym elementem diagnostyki, ale nie zastępuje kontroli integralności, kont, bazy danych, zadań cron, logów i środowiska hostingowego. „Zero wykrytych zagrożeń” oznacza tylko, że dany mechanizm skanowania niczego nie wykrył.
Czy po infekcji trzeba zmienić wszystkie hasła?
Zakres powinien wynikać z tego, co mogło zostać przejęte. Jeżeli napastnik uzyskał dostęp do plików konfiguracyjnych albo całego panelu hostingu, trzeba traktować poważnie możliwość wycieku większej liczby danych dostępowych. Jeżeli incydent ograniczył się do jednego mechanizmu we wtyczce, zakres może być mniejszy. Zmiana jedynie hasła administratora WordPressa nie ma sensu, jeśli nadal działa backdoor.
Czy 2FA zabezpieczy WordPressa przed ponownym włamaniem?
Chroni przede wszystkim logowanie do konta. Nie naprawi podatnej wtyczki i nie usunie złośliwego pliku. Jest bardzo sensownym zabezpieczeniem kont uprzywilejowanych, ale musi być częścią większej procedury, a nie zamiennikiem czyszczenia.
Czy PHP w katalogu uploads zawsze oznacza włamanie?
Nie zawsze, ale jest wystarczająco nietypowe, żeby taki plik sprawdzić. Liczy się jego treść, pochodzenie, data utworzenia oraz to, czy można przypisać go do legalnego komponentu strony. Automatyczne kasowanie każdego pliku PHP bez analizy może uszkodzić niestandardową instalację.
Ile kosztuje profesjonalne czyszczenie WordPressa?
W aktualnych polskich ofertach najprostsze usługi zaczynają się od około 350–500 zł netto, wiele ofert startuje w okolicach 600–1100 zł netto, natomiast trudniejszy incydent WooCommerce, kilka instalacji albo analiza obejmująca szersze środowisko może oznaczać koszt 1500–3000 zł netto lub więcej. Cena ma sens dopiero razem z zakresem: skan plików i pełna analiza incydentu to dwie różne usługi.
Ile trwa usuwanie malware?
Przy prostszym incydencie można mówić o kilku godzinach właściwej pracy technicznej, ale rynkowe terminy całej realizacji często wynoszą około 24–48 godzin albo 1–3 dni robocze. Przy sklepie, kilku witrynach, braku logów lub problemach z backupami analiza może potrwać dłużej. Najkrótszy czas nie zawsze oznacza najlepszą usługę — plik można skasować w minutę, trudniej potwierdzić, że nie ma drugiego.
Czy po infekcji trzeba zgłaszać sprawę do UODO?
Nie automatycznie. Najpierw trzeba ustalić, czy doszło do naruszenia ochrony danych osobowych i ocenić ryzyko dla osób, których dane dotyczą. Jeżeli naruszenie może powodować takie ryzyko, obowiązuje co do zasady termin do 72 godzin od jego stwierdzenia na zgłoszenie organowi. Przy wysokim ryzyku może być konieczne również zawiadomienie osób. Sam incydent należy odpowiednio udokumentować także wtedy, gdy po ocenie nie zostaje zgłoszony.
Co sprawdzić jako pierwsze po wykryciu zainfekowanego WordPressa?
Najpierw ustal, czy witryna w tej chwili szkodzi użytkownikom. Jeżeli przekierowuje ich na obce domeny, prowadzi phishing, rozsyła malware albo istnieje podejrzenie ingerencji w płatności, ogranicz publiczny dostęp. Następnie zabezpiecz kopię plików, bazę i logi. Dopiero potem zaczynaj kasować malware. Najdroższym błędem nie jest pozostawienie strony wyłączonej przez kilka godzin. Jest nim szybkie usunięcie widocznego objawu bez zabezpieczenia śladów i bez ustalenia, którędy napastnik może wrócić.
Dodatkowe informacje na: https://hd-biznes.com/blog.