Naprawiamy zhakowane strony i sklepy na WordPressie oraz starsze systemy na CodeIgniterze: usuwamy złośliwy kod, zamykamy drogę, którą napastnik wszedł, i zabezpieczamy serwis tak, żeby infekcja nie wróciła po tygodniu. Pracujemy na plikach, bazie i logach, a nie tylko na wyniku skanera.
Objawy, z którymi przychodzą klienci
- Google pokazuje w wynikach obce frazy, japońskie lub farmaceutyczne tytuły, a strona dla odwiedzających wygląda normalnie,
- przeglądarka albo Google Ads ostrzega przed niebezpieczną stroną,
- w panelu pojawili się nieznani administratorzy,
- hosting zablokował konto lub wysyłkę poczty z powodu spamu,
- strona przekierowuje część odwiedzających na obce adresy, zwykle tylko z telefonów albo tylko z Google,
- po „wyczyszczeniu” wtyczką infekcja wraca.
Jak naprawiamy
- Zabezpieczenie dowodów — kopia plików, bazy i logów przed jakąkolwiek zmianą. Bez tego nie da się ustalić, którędy wszedł napastnik.
- Porównanie z oryginałem — pliki rdzenia WordPressa, motywów i wtyczek porównane z wersjami producenta; każdy plik spoza listy do wyjaśnienia.
- Przegląd bazy i kont — nieznani administratorzy, wstrzyknięte skrypty w treściach i opcjach, zaplanowane zadania.
- Ustalenie wejścia — logi serwera, podatne wtyczki, stare wersje PHP i biblioteki, wycieki haseł, formularze wgrywania plików.
- Czyszczenie i odtworzenie — usunięcie tylnych furtek, odtworzenie plików z czystych źródeł, zmiana wszystkich haseł i kluczy.
- Utwardzenie — aktualizacje, ograniczenie dostępu do panelu, blokada wykonywania skryptów tam, gdzie nie są potrzebne, ograniczenie dostępu PHP do katalogów domeny, zapora aplikacyjna.
- Kontrola po naprawie — ponowne sprawdzenie plików po kilku dniach i zgłoszenie strony do ponownej weryfikacji w Google.
Co znajdujemy najczęściej
| Znalezisko | Dlaczego skaner go nie widzi |
|---|---|
| Tylne furtki w plikach wyglądających jak część WordPressa | nazwy i miejsca podobne do plików rdzenia, kod zaciemniony |
| Treści pokazywane tylko robotom Google | odwiedzający widzi normalną stronę, więc nikt nie zauważa problemu |
| Nieznane konta administratorów | konta z nazwami podobnymi do prawdziwych |
| Stare biblioteki z publicznie znanymi podatnościami | np. menedżery plików w starszych edytorach treści, dołączane do motywów i autorskich systemów |
| Błędy w obsłudze płatności | zamówienie oznaczane jako opłacone, zanim bramka płatnicza to potwierdzi |
Starsze systemy i stare PHP
Część ataków zaczyna się od serwisów, których nikt nie aktualizował od lat: PHP 5.6 czy 7.3, stary CodeIgniter, dołączone do edytora menedżery plików. Przenosimy takie serwisy na aktualne PHP 8 i bieżące wersje frameworka, bez przepisywania całej strony od zera — to zwykle tańsze niż nowy serwis, a zamyka całą klasę podatności.
Pytania, które dostajemy najczęściej
Czy wtyczka bezpieczeństwa wystarczy
Wtyczka pomaga wykryć część zmian, ale nie ustali, którędy wszedł napastnik, i nie usunie furtek, których nie zna. Jeśli po czyszczeniu wtyczką infekcja wraca, to znak, że wejście nadal jest otwarte.
Czy strona straci pozycje w Google
Jeśli Google zaindeksował obce treści, pozycje zwykle spadają. Po usunięciu infekcji zgłaszamy stronę do ponownej weryfikacji i usuwamy obce adresy z indeksu — im szybciej, tym mniejsze straty.
Czy zabezpieczacie sklepy WooCommerce
Tak. W sklepie sprawdzamy dodatkowo obsługę płatności, konta klientów i dostęp do interfejsu programistycznego sklepu, przez który można masowo pobierać dane.
Jak szybko zaczynacie
Przy aktywnej infekcji zaczynamy od zabezpieczenia kopii i odcięcia oczywistych furtek, a pełną analizę robimy w kolejnym kroku.
Bezpłatna wycena
Podaj adres strony, opisz objawy i napisz, na jakim hostingu stoi serwis. Odpowiemy, od czego zacząć i ile to kosztuje. Zapytaj o wycenę albo napisz na office@auranet.com.pl.