Audyt i naprawa strony WWW

Zakres

Z czym przychodzą klienci

Strona nie działa

Biała strona, błąd krytyczny, komunikat o problemie z bazą danych, pętla przekierowań. Najczęściej po nieudanej aktualizacji, konflikcie wtyczek albo zmianie na hostingu. Zwykle da się to odwrócić bez utraty treści.

Włamanie i spam w Google

Przekierowania na obce strony, doklejone podstrony z lekami czy kasynami, ostrzeżenie w wynikach wyszukiwania. Usuwamy infekcję, zamykamy lukę i składamy wniosek o ponowne sprawdzenie witryny.

Strona działa, ale źle

Formularz, który nie wysyła maili, koszyk gubiący produkty, układ rozjeżdżający się na telefonie, kilkanaście sekund ładowania. Objawy są różne, ale przyczyn zwykle kilka i dają się wskazać.

Porzucony projekt

Strona po wykonawcy, z którym nie ma kontaktu, bez dostępów albo bez dokumentacji. Odzyskujemy panowanie nad witryną, domeną i hostingiem i porządkujemy to, co zostało.

Proces

Jak wygląda naprawa

Zgłoszenie i pierwsza ocena

Opisujecie objawy i to, co działo się tuż przed awarią — aktualizacja, zmiana hostingu, nowa wtyczka. Ta informacja skraca diagnozę bardziej niż cokolwiek innego.

Zabezpieczenie stanu

Zanim cokolwiek ruszymy, robimy pełną kopię plików i bazy. Nawet uszkodzona strona jest punktem odniesienia, do którego można wrócić.

Diagnoza

Logi serwera, logi błędów PHP, wyłączanie wtyczek metodą połówkową, porównanie plików z czystą wersją WordPressa. Szukamy przyczyny, nie objawu.

Przywrócenie działania

Naprawa albo powrót do ostatniej sprawnej wersji. Przy włamaniu usuwamy złośliwy kod, sprawdzamy konta użytkowników i zadania cykliczne, w których często zostaje furtka.

Zamknięcie luki

Aktualizacja tego, co było wektorem ataku, zmiana haseł i kluczy, przegląd uprawnień i konfiguracji serwera. Sama naprawa bez tego kroku oznacza powtórkę za kilka tygodni.

Raport i zalecenia

Opisujemy, co się stało, co zrobiliśmy i co trzeba zmienić, żeby się nie powtórzyło. Część zaleceń da się wdrożyć od razu, część wymaga decyzji o budżecie.

Najczęstsze przyczyny awarii

Z naszego doświadczenia: nieudana aktualizacja wtyczki lub motywu, konflikt dwóch wtyczek robiących to samo, wyczerpany limit pamięci PHP, zmiana wersji PHP po stronie hostingu bez sprawdzenia zgodności, wyczerpane miejsce na serwerze oraz włamanie przez znaną lukę w porzuconym dodatku. Prawie zawsze da się wskazać moment, w którym coś się zmieniło — dlatego pierwsze pytanie brzmi nie „co się stało”, tylko „co robiliście przedtem”.

Włamanie: co się dzieje krok po kroku

Zaatakowana strona rzadko przestaje działać, bo atakującemu zależy na tym, żeby nikt nie zauważył. Typowy scenariusz to doklejone przekierowanie widoczne tylko dla ruchu z Google, ukryte podstrony z linkami albo konto administratora, o którym nikt nie wie. Efekt widać dopiero wtedy, gdy spada ruch albo wyszukiwarka oznacza witrynę jako niebezpieczną. Usunięcie samego kodu nie wystarcza — trzeba sprawdzić konta, zadania cron, pliki wgrane przez formularze i kopie zapasowe, w których infekcja też mogła zostać zapisana.

Ile kosztuje naprawa

Diagnoza zaczyna się od 300 zł netto i kończy się informacją, co jest przyczyną i ile potrwa naprawa — nawet jeśli zdecydujecie się jej nie zlecać. Proste przypadki, jak cofnięcie nieudanej aktualizacji czy naprawa formularza, mieszczą się zwykle w jednej–dwóch godzinach pracy. Usunięcie skutków włamania razem z zabezpieczeniem to kilka godzin do kilkunastu, zależnie od tego, jak długo infekcja była na serwerze i ile plików objęła.

Nie mam dostępów do własnej strony

To częstsza sytuacja, niż mogłoby się wydawać — wykonawca przestał odbierać telefon, domena jest zarejestrowana na jego firmę, a hosting opłacany z nieznanego konta. Zaczynamy od ustalenia, co jest na kogo zapisane: domenę sprawdzamy w rejestrze, hosting u operatora. Odzyskanie domeny bywa procedurą formalną po stronie rejestratora i nie zawsze da się je przyspieszyć, ale zwykle kończy się odzyskaniem kontroli. Równolegle zabezpieczamy kopię strony, żeby mieć z czego odtworzyć witrynę.

Kiedy naprawa nie ma sensu

Czasem uczciwa odpowiedź brzmi: taniej zbudować od nowa. Dzieje się tak, gdy motyw jest od lat porzucony przez autora, gdy strona stoi na wersji PHP, której hosting już nie obsługuje, albo gdy kod był modyfikowany bezpośrednio w plikach motywu i każda aktualizacja kasuje zmiany. Mówimy to wprost i pokazujemy różnicę w kosztach, zamiast liczyć godziny za podtrzymywanie czegoś, co posypie się znowu. Alternatywą jest wtedy nowa strona z zachowaniem adresów i pozycji.

FAQ

Najczęściej zadawane pytania

Zgłoszenia awaryjne bierzemy priorytetowo w godzinach pracy. Przy stronie, która całkiem nie działa, pierwszą ocenę robimy zwykle tego samego dnia roboczego.

W większości przypadków nie. Przed jakąkolwiek ingerencją robimy kopię, a przy odtwarzaniu z backupu tracicie najwyżej zmiany wprowadzone po jego wykonaniu. Najgorsze scenariusze zdarzają się tam, gdzie kopii nie było w ogóle.

Tak, to większość zgłoszeń. Nie ma znaczenia, kto budował witrynę — istotne jest, czy mamy dostęp do plików i bazy.

Da się pracować bez niej, choć jest trudniej. Kopiujemy aktualny stan przed naprawą, a przy włamaniu porównujemy pliki z czystą wersją WordPressa i wtyczek, żeby odróżnić kod dodany przez atakującego od oryginalnego.

Po usunięciu infekcji składa się w Search Console wniosek o ponowne sprawdzenie. Zwykle ostrzeżenie znika w ciągu kilku dni, pod warunkiem że witryna jest rzeczywiście czysta — powtórne zgłoszenie zainfekowanej strony wydłuża cały proces.

Aktualizacje wykonywane regularnie, kopie zapasowe poza serwerem strony, usunięcie wtyczek, których nikt nie używa, i mocne hasła z dwuskładnikowym logowaniem. Jeśli nie ma komu tego pilnować, sensowniejsza od kolejnej naprawy jest stała opieka techniczna.

Audyt i naprawa strony