Skaner złośliwego oprogramowania Imunify360: funkcje, aktualizacje i ograniczenia

Imunify360 jako wielowarstwowe zabezpieczenie hostingu

Imunify360 nie jest samodzielnym programem do wykrywania wirusów, lecz rozwiązaniem zabezpieczającym dla systemu Linux, obejmującym wiele poziomów ochrony. Ten Skaner złośliwego oprogramowania sprawdza pliki pod kątem znanych lub podejrzanych treści. Zapora sieciowa oraz systemy IDS/IPS monitorują i ograniczają nietypową aktywność sieciową, podczas gdy zapora aplikacji internetowych (WAF) ocenia żądania HTTP przed dotarciem do aplikacji na podstawie reguł. Sprawdzanie reputacji dostarcza dodatkowych sygnałów pomocnych w klasyfikacji źródeł i działań.

Ten podział ma kluczowe znaczenie dla operatorów usług hostingowych, ponieważ poszczególne warstwy działają na różnych etapach. Atak HTTP wykorzystujący znaną lukę w zabezpieczeniach może zostać zablokowany przez WAF, zanim WordPress, Joomla lub Magento przetworzą żądanie. Z kolei złośliwy plik przesłany na serwer zostanie wykryty podczas weryfikacji plików. Jeśli zostanie uruchomiona powłoka PHP, może Obrona proaktywna zajmuje się podejrzanym zachowaniem podczas wykonywania kodu PHP; nie jest to jednak analiza całego incydentu z mocą wsteczną.

Model nazywa się Obrona wielopoziomowa: Pojedyncza luka lub przeoczony ślad nie powinny same w sobie decydować o bezpieczeństwie konta klienta. Wykrywanie złośliwego oprogramowania może ujawnić istniejący kod szkodliwy, ale niekoniecznie zapobiega pierwotnemu atakowi. Podobnie, zapora WAF może zablokować atak, nie usuwając jednak już zapisanych plików ani zmanipulowanych treści bazy danych.

Żaden z tych poziomów nie zastępuje podstawowych zadań operacyjnych. Rdzeń systemu CMS, wtyczki, motywy i rozszerzenia wymagają terminowych aktualizacji zabezpieczeń; restrykcyjne uprawnienia do plików oraz oddzielne dane dostępowe ograniczają skutki włamania na konto. Sprawdzone kopie zapasowe umożliwiają przywrócenie danych, a w przypadku wykrycia incydentu dopiero analiza incydentu pozwala ustalić sposób włamania, zasięg i ewentualną trwałość zagrożenia. Imunify360 dostarcza w tym zakresie sygnały ostrzegawcze i wskazujące, a nie pełny dowód na to, że otoczenie jest bezpieczne.

Różnice między Imunify360, ImunifyAV i ImunifyAV+

Listy funkcji należy przypisać do danego produktu. Imunify360 jest bardziej kompleksowym rozwiązaniem w zakresie bezpieczeństwa serwerów; ImunifyAV i ImunifyAV+ to odrębne produkty oferujące funkcje związane z ochroną przed złośliwym oprogramowaniem. Kto utożsamia te nazwy, może na przykład pomylić istniejącą funkcję skanowania z ochroną w postaci zapory sieciowej, zabezpieczeniami działającymi w czasie rzeczywistym lub ochroną PHP, co może prowadzić do błędnych oczekiwań dotyczących serwera zarządzanego lub serwera dla resellerów.

Szczególnie istotne jest to, że zgodnie z dokumentacją producenta funkcje skanowania w czasie rzeczywistym (Real-Time Scanning) i proaktywnej ochrony (Proactive Defense) nie są dostępne w programach ImunifyAV ani ImunifyAV+ w taki sam sposób, jak w Imunify360. Skanowanie w czasie rzeczywistym pozwala na szybkie wykrywanie nowych lub zmodyfikowanych plików; funkcja „Proactive Defense” traktuje wykonywanie kodu PHP jako odrębny punkt interwencji. Obie funkcje uzupełniają planowe skanowanie plików, ale nie czynią go zbędnym ani nie zastępują konserwacji aplikacji.

Również rozszerzenie WordPress o nazwie Imunify Security Plugin nie stanowi samodzielnego zamiennika agenta serwerowego. Jest ono zarządzane przez agenta Imunify i nie jest udostępniane za pośrednictwem katalogu WordPress.org. W panelu administracyjnym WordPressa może ona udostępniać informacje dotyczące skanowania i ochrony; jednak to, które funkcje są widoczne, zależy od używanego produktu Imunify oraz wymaganych wersji agenta i rozszerzenia.

W celu prowadzenia dokumentacji operacyjnej zaleca się zatem sporządzenie przejrzystego zestawienia: wariant produktu, zainstalowana wersja agenta, panel hostingowy oraz aktywowane moduły ochronne powinny znaleźć się w dokumentacji zmian. Administrator WordPressa może wówczas klasyfikować komunikaty w panelu administracyjnym, nie zakładając, że wtyczka kontroluje reguły zapory sieciowej lub chroni inne konta użytkowników na serwerze. Decydujące znaczenie ma architektura bezpieczeństwa po stronie serwera.

Co tak naprawdę oznaczają wykryte złośliwe oprogramowania

Skanowanie w tle i na żądanie udostępnia wyniki w interfejsie administracyjnym wraz z datą i godziną, ścieżką do pliku oraz przyczyną wykrycia. Informacje te stanowią punkt wyjścia do selekcji: ścieżka przypisuje wykryte pliki do konta klienta i aplikacji, a czas pomaga w porównaniu z wdrożeniami, przesłanymi plikami lub podejrzanymi wpisami w logach. Nie zastępują one jednak sprawdzenia konkretnej treści i sposobu jej powstania.

Dla ustalenia priorytetów istotny jest rodzaj wykrycia. Kod złośliwy wstrzyknięty do pliku, który poza tym jest legalny, często wskazuje na konieczność zbadania pochodzenia tego pliku, wprowadzonych w nim zmian oraz dalszych manipulacji na tym samym koncie. Z kolei plik rozpoznany jako samodzielnie szkodliwy może wskazywać na umieszczoną tam webshell, dropper lub niepożądane narzędzie administracyjne. Oba przypadki wymagają uwzględnienia kontekstu zamiast wyciągania automatycznych wniosków.

Wykrycie nie dowodzi, że każdy plik na koncie został naruszony, ani nie określa automatycznie zakresu włamania. Z drugiej strony skanowanie bez wykrytych zagrożeń nie potwierdza całkowitej integralności: nowatorskie exploity, ukryty kod lub mechanizmy utrzymywania się poza skanowanym obszarem mogą wymagać dodatkowej analizy. Również brak wykrycia przez WAF lub skaner nie stanowi dowodu na to, że atak nie miał miejsca.

Jeśli skaner wykryje na przykład plik PHP w ramach wtyczki WordPressa, administrator powinien najpierw zapisać historię wykryć i ścieżkę dostępu, a następnie porównać ten plik z plikiem pochodzącym z zaufanego źródła producenta lub ze sprawdzoną kopią zapasową. Następnie należy sprawdzić wersję wtyczki, administratorów, dane dostępowe oraz ewentualne backdoory. W zakresie organizacyjnego wdrożenia kilku projektów WordPress pomocne są wskazówki dotyczące Wymagania dotyczące bezpieczeństwa w hostingu dla blogerów, nie zastępują jednak analizy kryminalistycznej dostosowanej do konkretnego przypadku.

Metody skanowania, wymagania i zasięg

Regularne skanowanie plików w Imunify360 obejmuje pliki przechowywane w zasobach hostingowych. Nadaje się ono zarówno do cyklicznych operacji w tle, jak i do ukierunkowanej kontroli w odpowiedzi na sygnał z monitoringu lub działu wsparcia. Wyniki tych skanowań dotyczą jednak wyłącznie sprawdzanego zbioru plików: treści w bazie danych, atak podczas żądania HTTP lub już nadużyty dostęp wymagają dodatkowych kontroli i warstw zabezpieczeń.

Der Skanowanie w czasie rzeczywistym rozszerza tę kontrolę na określone kanały transmisji. Dokumentacja podaje, że do skanowania przesyłek HTTP i HTTPS wymagany jest ModSecurity; przesyłki FTP wymagają natomiast Pure-FTPd. Należy zatem sprawdzić dla każdego serwera, czy usługi te są aktywne i odpowiednio skonfigurowane. Funkcja ta nie jest dostępna automatycznie dla każdego kanału przesyłania wyłącznie poprzez instalację agenta.

Zakres skanowania obejmuje również sprawdzanie archiwów. Zgodnie z dokumentacją archiwa ZIP są skanowane domyślnie od wersji Imunify360 6.2. Jest to szczególnie przydatne w przypadku pakietów wtyczek, archiwów kopii zapasowych lub przesłanych rozszerzeń, nie mówi jednak nic o tym, czy aplikacja rozpakuje archiwum w sposób niebezpieczny, ani czy jego zawartość jest dopuszczalna z technicznego punktu widzenia.

Der Skaner bazy danych złośliwego oprogramowania (MDS) uzupełnia skanowanie plików w przypadku, gdy złośliwy kod został umieszczony np. w wpisach, opcjach lub treściach widżetów systemu CMS. Jego udokumentowana obsługa ogranicza się do WordPressa, Joomli i Magento 2. W przypadku własnych aplikacji, odmiennych struktur baz danych lub innych systemów sklepowych nie należy zakładać, że zapewnia to pełną obsługę baz danych.

Planowanie skanowania RapidScan i kontroli baz danych

RapidScan zmienia sposób przeprowadzania powtarzających się skanowań, a nie zasadniczy cel skanowania w poszukiwaniu złośliwego oprogramowania. W tym celu Imunify360 zapisuje lokalnie metadane plików i skróty, a następnie porównuje je z bazą danych w chmurze. Podczas kolejnych cykli skanowania analiza lokalna może skupiać się na plikach, które uległy zmianie lub są jeszcze nieznane.

Pierwsze uruchomienie wymaga najpierw standardowej kontroli zasobów. Producent podaje, że kolejne skanowania mogą przebiegać od pięciu do dwudziestu razy szybciej. Zakres ten stanowi orientacyjną informację producenta zależną od konkretnej sytuacji, a nie wiążącą gwarancję dla każdego serwera: na wynik mają wpływ wielkość i skład zasobów plików, częstotliwość zmian, dostępna wydajność operacji wejścia/wyjścia oraz warunki sieciowe.

Z punktu widzenia planowania oznacza to, że serwer zawierający wiele niezmienionych plików internetowych może zostać RapidScan przynosi większe korzyści niż konto, które na bieżąco generuje pliki przesyłane, pamięć podręczną lub pliki dziennika. Dlatego nie należy mierzyć wyłącznie całkowitego czasu działania, ale przed wprowadzeniem zmian należy udokumentować ścieżki, które mają na to wpływ, liczbę operacji na plikach oraz czas oczekiwania na operacje wejścia/wyjścia. W ten sposób można określić okna skanowania i wykluczenia na podstawie konkretnych przyczyn, a nie domysłów.

W przypadku zmanipulowanych wpisów w WordPressie lub skryptów wprowadzonych do ustawień samo skanowanie plików może okazać się niewystarczające. MDS może najpierw uruchomić skanowanie obsługiwanych baz danych WordPressa w trybie nieinwazyjnym --scan sprawdzić. Ten krok nie powoduje żadnych zmian w danych i stanowi podstawę do oceny lokalizacji, wpływu na stronę internetową oraz możliwości przywrócenia danych przed podjęciem decyzji.

Natomiast czyszczenie lub przywracanie danych to działania mające wpływ na treści produkcyjne. Przed ich wykonaniem potrzebna jest aktualna, sprawdzona kopia zapasowa, zgoda techniczna dotycząca danej strony internetowej oraz plan awaryjny na wypadek zmiany prawidłowych treści. W przypadku wielu oddzielnych projektów klientów pomocne jest wyraźne rozdzielenie treści, tak jak ma to miejsce również w przypadku Hosting wielodomenowy Co ważne: ogranicza zakres kompetencji i ułatwia przypisywanie znalezisk.

MDS nie zastępuje pełnej analizy incydentu. Ponowne pojawienie się złośliwego kodu w bazie danych może wskazywać na podatną na ataki wtyczkę, skompromitowane dane dostępowe lub backdoor w pliku. Po wykryciu takiego kodu należy zatem zbadać nie tylko zawartość bazy danych, ale także system CMS, rozszerzenia, konta użytkowników oraz źródło operacji zapisu.

Integracja z WordPressem i kontrolowane aktualizacje WAF

Wtyczka WordPress o nazwie Imunify Security Plugin jest zarządzana przez agenta Imunify na serwerze i nie jest udostępniana za pośrednictwem katalogu WordPress.org. Umożliwia ona administratorom WordPressa wyświetlanie informacji o stanie oraz, w zależności od używanego produktu Imunify, dodatkowych funkcji bezpieczeństwa w panelu administracyjnym. Stanowi zatem interfejs i uzupełnienie, ale nie zastępuje mechanizmów skanowania i ochrony po stronie serwera.

W przypadku funkcji podstawowych dokumentacja wymienia co najmniej wersję Imunify360 8.4.1 po stronie serwera. Funkcje takie jak integracja z WAF czy zarządzanie botami oparte na sztucznej inteligencji są rozwijane oddzielnie i powiązane z konkretnymi wersjami agentów i wtyczek. Dlatego przed wdrożeniem należy sprawdzić konkretną kombinację wersji, zamiast wyciągać wnioski o obecności określonej funkcji ochronnej wyłącznie na podstawie samego istnienia wtyczki.

Również WAF powinien działać jako oddzielna warstwa. Od imunify360-firewall 8.6.0 Dostępna jest udokumentowana procedura pozwalająca wyłączyć automatyczne aktualizacje reguł ModSecurity, wyświetlić listę dostępnych wersji reguł oraz wybrać konkretną wersję. Umożliwia to operatorom usług hostingowych kontrolowane planowanie zmian reguł oraz, w razie potrzeby, powrót do znanego stanu.

Rozsądna procedura polega na tym, że nowa wersja reguły jest najpierw wdrażana na serwerze testowym zawierającym reprezentatywne strony WordPress, promocje sklepowe i przesłane pliki. Dopiero gdy nie zostaną wykryte żadne istotne przypadki błędnego blokowania ani problemy z działaniem, następuje stopniowe wdrażanie do środowiska produkcyjnego. Kontrola wersji dotyczy w tym przypadku reguł ModSecurity, a nie ogólnych sygnatur złośliwego oprogramowania, całego agenta ani innych komponentów Imunify.

Kontrolowane Aktualizacje reguł WAF Nie zapobiegają one wszystkim awariom, ale zapewniają przejrzysty podział obowiązków: kto weryfikuje zmiany, jakie aplikacje służą jako przypadki testowe i kiedy należy przywrócić poprzednią wersję? Te pytania powinny znaleźć się w procesie operacyjnym. Nadal konieczne są terminowe aktualizacje systemu CMS i rozszerzeń, restrykcyjne uprawnienia oraz sprawdzone kopie zapasowe, ponieważ żadna zapora WAF nie eliminuje znanych luk w zabezpieczeniach zainstalowanego oprogramowania.

Bezpieczne sprawdzanie i usuwanie wykrytych złośliwych programów

Wykrycie złośliwego oprogramowania to procedura badawcza, a nie automatyczna instrukcja usunięcia. Najpierw sprawdź w interfejsie historię wykryć, datę, pełną ścieżkę oraz powód wykrycia. Informacje te pomogą ustalić, czy plik należy do wtyczki, motywu, katalogu plików przesłanych czy też do aplikacji opracowanej indywidualnie, a także czy ten sam wynik został już wcześniej odnotowany.

Porównaj podejrzany plik PHP z wiarygodnym źródłem producenta tej samej wersji lub ze sprawdzoną kopią zapasową. W przypadku standardowych komponentów dokładne ponowne porównanie jest zazwyczaj bardziej miarodajne niż izolowana analiza pojedynczych, potencjalnie zamaskowanych wierszy kodu. Przed wprowadzeniem jakichkolwiek zmian należy zabezpieczyć znaleziony plik oraz powiązane logi, aby w przyszłości można było odtworzyć drogę, jaką przeszedł złośliwy kod.

Rzeczywista analiza przyczyn wykracza poza zgłoszoną ścieżkę: zaktualizuj podatne na atak wersje systemu CMS, wtyczek i motywów, sprawdź konta użytkowników, a w przypadku uzasadnionego podejrzenia zmień dane dostępowe. Poszukaj również innych webshelli, nieznanych administratorów oraz podejrzanych zaplanowanych zadań. Usunięcie pliku nie wyklucza, że atakujący pozostawił drugą drogę dostępu.

Wynik wyszukiwania w bazie danych wymaga szczególnej ostrożności, ponieważ działania naprawcze mogą zmienić treść lub ustawienia. Skanowanie jest przede wszystkim sprawdzaniem; czyszczenie lub przywracanie danych wymaga dostępnej kopii zapasowej, zatwierdzenia przez specjalistę oraz planu awaryjnego. Skaner baz danych złośliwego oprogramowania obsługuje wyłącznie udokumentowane przypadki dotyczące WordPressa, Joomli i Magento 2 i nie stanowi ogólnego sprawdzania dowolnych schematów aplikacji.

Jeśli wykryto Adminer, narzędzie to może być zainstalowane zgodnie z przeznaczeniem, jednak ze względu na zakres funkcji, które mogą sprzyjać nadużyciom, jego wykrycie jest zrozumiałe. Zamiast globalnie wyłączać kategorię wykrywania, należy sprawdzić potrzebę istnienia, integralność oraz zabezpieczenia dostępu do konkretnego pliku. Jeśli wyjątek jest nieunikniony, wąskie wykluczenie ścieżki lepiej ogranicza lukę w zabezpieczeniach niż dezaktywacja wykrywania na poziomie konta lub serwera.

Analiza obciążenia, fałszywych alarmów i trwałości

Jeśli wzrasta obciążenie procesora lub czas oczekiwania na operacje wejścia/wyjścia, wykluczenie tej przyczyny nie powinno być pierwszym krokiem. Najpierw należy zebrać dane dotyczące zdarzeń skanowania, ścieżek, których to dotyczy, częstotliwości zmian, aktywnych procesów oraz okresu występowania obciążenia. Dopiero korelacja czasowa pokaże, czy przyczyną może być skanowanie w czasie rzeczywistym, czy też może kopia zapasowa, import, wadliwe aplikacje lub inna usługa zużywają zasoby.

Często opisywane pliki dziennika mogą wielokrotnie wywoływać operacje skanowania, co może stanowić potencjalną przyczynę dodatkowego obciążenia. W jednym z udokumentowanych zgłoszeń do pomocy technicznej omówiono ten schemat w odniesieniu do plików dziennika WordPressa, jednak nie potwierdza to istnienia ogólnej zasady przyczynowo-skutkowej dla każdego obciążonego serwera. Dlatego należy dokładnie sprawdzić ścieżki do plików i częstotliwość zapisu, zamiast profilaktycznie usuwać całe katalogi klientów z Skaner złośliwego oprogramowania wyjąć.

Wyjątki muszą mieć ściśle określony cel, wyznaczoną osobę odpowiedzialną oraz podlegać regularnej kontroli. W przypadku legalnie utworzonej, bardzo aktywnej ścieżki dostępu ograniczony wyjątek może być uzasadniony po przeprowadzeniu analizy. Nie wolno jednak rozszerzać go niepostrzeżenie na katalogi plików przesyłanych lub katalogi aplikacji, w których osoby atakujące mogłyby umieszczać lub modyfikować pliki.

Powtarzające się wyniki po oczyszczeniu wskazują na konieczność zbadania pod kątem Wytrwałość zamiast zwykłego usunięcia. Oprócz zawartości plików i bazy danych, kontrola powinna obejmować zadania cron, nieznane konta administratorów, dane dostępowe, logi serwera WWW oraz uruchomione procesy. Zwłaszcza zaplanowane zadania mogą ponownie pobrać złośliwy kod lub zastąpić usuniętą powłokę internetową.

Od wersji 6.10 Imunify360 dokumentuje skanowanie plików crontab systemu i użytkowników jako funkcję eksperymentalną, domyślnie wyłączoną. Rozszerza to zakres kontroli, ale nie zastępuje ręcznej oceny podejrzanego zadania. Przed aktywacją należy sprawdzić obciążenie, kompatybilność oraz wpływ na własny przebieg operacyjny; nie oznacza to jednak, że należy ją aktywować automatycznie w każdym środowisku hostingowym.

Podjąć decyzję w sprawie eksploatacji, migracji i wdrożenia

W przypadku niewielkiego serwera obsługującego kilka stron internetowych wystarczające mogą być planowane skanowania w tle, przejrzyste powiadomienia oraz ręczne zatwierdzanie działań. Natomiast w środowiskach hostingu resellerskiego i współdzielonego rosną wymagania dotyczące Procedury eskalacji: Kto ocenia zgłoszenia, kto kontaktuje się z klientami, kto może zatwierdzać wyjątki i kiedy konto zostaje zablokowane? Ustalone na piśmie kompetencje zapobiegają sytuacji, w której działania naprawcze lub luki w zabezpieczeniach pozostają nierozwiązane między działem wsparcia a administracją.

Ochrona w czasie rzeczywistym, częstotliwość skanowania i powiadomienia muszą być dostosowane do tempa zmian oraz zasobów serwera. Wiele niezależnych kont klientów czerpie korzyści ze spójnych procedur i przejrzystego protokołowania. Pojedynczy projekt o kluczowym znaczeniu dla działalności często wymaga dodatkowo skoordynowanego procesu konserwacji i zatwierdzania. Niezależnie od tego nadal konieczne są podstawowe środki ochronne, takie jak aktualizacje, minimalne uprawnienia i przetestowane kopie zapasowe.Kryteria wyboru odpowiedniej oferty hostingu

Repozytorium produkcyjne i instalacje testowe należy ściśle oddzielić. Producent stopniowo wdraża stabilne wersje w kanale produkcyjnym, a czas trwania tego procesu wynosi maksymalnie około dwóch tygodni. Funkcja, która jest dostępna wyłącznie w repozytorium testowym lub po instalacji za pomocą --beta To, co jest widoczne, nie oznacza zatem automatycznie, że jest ogólnie dostępne w stabilnej wersji.

Kontrolowany Rollout Rozpoczyna się od sprawdzenia wersji oraz uruchomienia reprezentatywnego serwera testowego lub pilotażowego. Po aktualizacji sprawdzasz stan agenta, zarządzanie pakietami, nietypowe wpisy w logach oraz funkcje istotne dla klientów. Dopiero po upewnieniu się, że wszystko przebiega bez zakłóceń, następuje stopniowe wdrażanie. Nie eliminuje to wszystkich zagrożeń, ale pozwala szybciej wykryć odchylenia i ułatwia podjęcie ukierunkowanych działań.

Dobrowolna migracja do Patchmana jest decyzją operacyjną, a nie automatyczną modernizacją. Po migracji nie będzie już możliwe przywrócenie plików z dotychczasowej kwarantanny Patchmana; zgodnie z dokumentacją Imunify tworzy kopie zapasowe oczyszczonych plików. Przed przeprowadzeniem migracji operatorzy powinni zatem w sposób wiążący wyjaśnić kwestie dotyczące przechowywania danych, ścieżek przywracania, komunikacji z klientami oraz podziału obowiązków.

Konkretny problem z aktualizacją w przypadku imunify-common Według producenta problem z wersją 1.3.21-1 w systemie CloudLinux 8 z bazą danych RPM opartą na Berkeley DB został rozwiązany począwszy od wersji 1.3.22-2. Nie stanowi to jednak ogólnego argumentu przeciwko aktualizacjom. Podkreśla to jednak, dlaczego okna serwisowe, udokumentowane wersje i kontrole następcze systemu zarządzania pakietami stanowią integralną część profesjonalnej procedury aktualizacji.