Jak naprawiamy zainfekowaną stronę z pomocą AI — i dlaczego AI podejmuje decyzję jako ostatnia

„Naprawa strony przez AI” brzmi jak obietnica, że model przeczyta pliki i sam wszystko ogarnie. W praktyce to najgorszy możliwy projekt: model, który podejmuje decyzje o kasowaniu plików na żywym serwerze, prędzej czy później skasuje coś, czego strona potrzebuje. Dlatego w CleanOps AI jest ostatnią warstwą, nie pierwszą. Oto jak to działa od środka.

Warstwa 1: porównanie z oficjalnym wydaniem

Większość plików na stronie WordPress czy Joomla to pliki rdzenia, które nie powinny się różnić od oryginału. Zamiast zgadywać, czy wp-includes/class-wp.php wygląda podejrzanie, rozpoznajemy wersję CMS-a, pobieramy to konkretne wydanie i porównujemy sumy kontrolne.

• Plik identyczny z wydaniem jest czysty. Koniec analizy, koszt zero.
• Plik różny od wydania jest podejrzany z definicji. Model tylko potwierdza charakter zmiany (wstrzyknięcie, backdoor), a naprawa polega na przywróceniu oryginału — nie na „leczeniu” pliku przez model.

To działa też dla starych instalacji. Widzieliśmy Joomlę 3.8 z 2018 roku, gdzie model bez tej warstwy uznawał stare konstrukcje PHP za podejrzane. Z oryginałem do porównania nie ma o czym dyskutować.

Warstwa 2: reguły na to, co widzieliśmy już tysiące razy

Niektóre wzorce są tak jednoznaczne, że angażowanie modelu to strata czasu i pieniędzy:

• plik .htaccess, który blokuje wszystkie PHP, ale przepuszcza radio.php i lock360.php — to allowlista web‑shelli, nic innego;
• plik wskazany przez ClamAV z nazwą sygnatury;
• znany dropper doklejony na początku index.php.

Takie przypadki rozstrzyga reguła. Co ważniejsze, identyczne pliki dostają jeden werdykt. W jednej z napraw injector rozsiał po stronie ponad 6 tysięcy identycznych .htaccess. Pierwsza wersja naszego skanera analizowała każdy osobno — 558 wywołań modelu, zanim skończyły się środki. Dziś to jeden werdykt i kilka sekund.

Warstwa 3: analiza AI z kontekstem

Dopiero to, co nie jest plikiem rdzenia i nie pasuje do reguł, idzie do modelu: zaciemnione wstawki w motywach, pliki PHP w katalogu na obrazki, nietypowe wtyczki. Model dostaje kontekst, którego skanery nie mają: jaki to CMS, jaka wersja, czy plik jest w oficjalnej paczce, co jest w sąsiednich plikach.

Dwie zasady trzymają to w ryzach:

1. Słabe sygnały przechodzą tańszy przesiew, ale przesiew może orzec wyłącznie „czysty”. Każdy inny wynik jest powtarzany pełną analizą. Żadna akcja na pliku nie opiera się na tańszym przebiegu.
2. Model jest konserwatywny. Jeśli nie potrafi bezpiecznie rozdzielić kodu legalnego od złośliwego, oznacza plik do ręcznej weryfikacji i go nie rusza. Fałszywe usunięcie działającego pliku jest droższe niż jeden plik do sprawdzenia przez człowieka.

Warstwa 4: naprawa, która zachowuje Twoją stronę

Tu większość narzędzi zawodzi: usuwają plik razem z infekcją. My wybieramy źródło naprawy od najpewniejszego:

1. Odcięcie droppera. Jeśli znany dropper jest doklejony przed Twoim kodem, odcinamy prefiks, a resztę zostawiamy. Twój przerobiony szablon z własnym CSS przeżywa.
2. Oryginał z wydania, jeśli to plik rdzenia.
3. Archiwum internetu dla plików statycznych i szablonów, których nie ma w wydaniu — bierzemy migawkę sprzed daty infekcji.
4. Dopiero na końcu wersja oczyszczona przez model, z wyraźną adnotacją w raporcie.

Pliku, którego nie da się bezpiecznie naprawić, nie kasujemy. Trafia do kwarantanny, a kopia wszystkiego, co zmieniliśmy, ląduje u nas, nie na Twoim serwerze. Cofnięcie całej naprawy to jeden przycisk.

Warstwa 5: kontrola po naprawie

Po wykonaniu akcji pobieramy stronę i sprawdzamy, czy odpowiada sensownym HTML-em: kod odpowiedzi, rozmiar, obecność błędów PHP w treści. Jeśli nie, próbujemy odtworzyć zniszczony szablon z archiwum. Rozpoznajemy też sytuację, w której to hosting serwuje blokadę „Malware detected” — wtedy mówimy wprost, że żadna zmiana w plikach jej nie zdejmie.

A potem pytamy Ciebie. Automat sprawdzi, czy strona zwraca HTML; zepsutych styli czy niedziałającego formularza nie zauważy. Ty tak.

Asystent AI: dostęp do serwera, ale z ręką na hamulcu

Jeśli odpowiesz „nie działa”, do akcji wchodzi asystent. To nie chatbot z FAQ. Ma dostęp do plików i logów Twojej strony przez to samo połączenie, którego użył skan, i zna historię naprawy. Sam sprawdza stronę, czyta error_log, sprawdza składnię PHP, ogląda .htaccess.

Różnica wobec „autonomicznego agenta” jest jedna, ale kluczowa: komendy tylko do odczytu wykonuje sam, każdą zmianę proponuje. Zapis pliku czy komenda zmieniająca stan pojawia się jako karta z uzasadnieniem i wykonuje się dopiero po Twoim kliknięciu. Poprzednia wersja pliku jest zachowywana. A jeśli problem przekracza stronę (DNS, konfiguracja hostingu, baza), asystent mówi to wprost i kieruje do człowieka.

Dlaczego to ma znaczenie dla ceny

Każda warstwa przed modelem jest tańsza i pewniejsza od niego. Dzięki temu typowa naprawa mieści się w pierwszym progu cennika, a koszt analizy nie zależy od tego, ile tysięcy identycznych plików podrzucił atakujący. Płacisz za rozstrzygnięcie, nie za liczbę wywołań.

Jeśli chcesz zobaczyć, jak to wygląda na Twojej stronie, sprawdzenie jest bezpłatne i niczego nie zmienia. Raport pokaże, które pliki rozstrzygnęło porównanie z wydaniem, które reguła, a które model — i dlaczego.