Monarx – bezpieczeństwo, prywatność i problemy dla PrestaShop oraz autorskich aplikacji

Jestem dużym zwolennikiem prywatności i bardzo poważnie podchodzę do bezpieczeństwa danych — zarówno własnych, jak i danych naszych klientów. W praktyce oznacza to, że wiele informacji, które posiadamy, w ogóle nie trafia do zewnętrznych usług, popularnych chmur czy przypadkowych dostawców SaaS. Jeżeli nie ma technicznej potrzeby, aby dane opuściły infrastrukturę firmy, wolę, żeby jej nie opuszczały.

Nie wynika to z założenia, że każda zewnętrzna firma chce zrobić z naszymi danymi coś złego. Chodzi o prostą zasadę bezpieczeństwa: im mniej podmiotów musi mieć dostęp do danych, kodu i infrastruktury, tym mniejsza powierzchnia ryzyka. Każdy dodatkowy dostawca oznacza kolejne systemy, procedury, aktualizacje, pracowników, potencjalne podatności i elementy infrastruktury, nad którymi nie mamy pełnej kontroli.

Z tego powodu mam bardzo duże zastrzeżenia do rozwiązań takich jak Monarx.

Monarx może zwiększać bezpieczeństwo serwera i niewątpliwie ma zastosowania, w których jego obecność jest korzystna. Jednocześnie jest to kolejna uprzywilejowana warstwa pomiędzy właścicielem aplikacji a środowiskiem, w którym ta aplikacja działa. Może analizować kod i zachowanie aplikacji, klasyfikować określone operacje jako niebezpieczne oraz aktywnie je blokować.

I właśnie tutaj zaczyna się problem.

Czym jest Monarx?

Monarx to komercyjne, zamknięte oprogramowanie bezpieczeństwa kierowane przede wszystkim do firm hostingowych. Nie jest to zwykły plugin do WordPressa czy moduł instalowany przez właściciela strony. Poszczególne komponenty Monarx mogą działać na poziomie serwera oraz bezpośrednio w środowisku PHP.

Jednym z elementów platformy jest ochrona typu RASP, czyli Runtime Application Self-Protection. W dużym uproszczeniu oznacza to, że system nie ogranicza się do okresowego sprawdzania, czy na dysku pojawił się podejrzany plik. Może obserwować działanie aplikacji podczas wykonywania requestów i reagować wtedy, kiedy określone zachowanie zostanie uznane za niebezpieczne.

Z punktu widzenia bezpieczeństwa brzmi to dobrze. Jeżeli atakujący wykorzystuje podatność i próbuje wykonać niebezpieczną operację w PHP, możliwość zatrzymania jej jeszcze podczas wykonywania może być znacznie skuteczniejsza niż znalezienie infekcji kilka godzin później.

Problem w tym, że system musi zdecydować, które zachowanie jest atakiem, a które prawidłową funkcją aplikacji.

A ta granica nie zawsze jest oczywista.

Monarx wygląda najlepiej tam, gdzie strony zachowują się podobnie

Wyobraźmy sobie dużą firmę hostingową. Na jej serwerach działają tysiące WordPressów, PrestaShopów, Joomli i innych popularnych CMS-ów. Część z nich jest nieaktualizowana, część korzysta ze starych pluginów, a część została porzucona przez właścicieli kilka lat wcześniej.

Dla hostingu to ogromny problem. Jedna zainfekowana strona może wysyłać spam, obciążać CPU, uczestniczyć w atakach, generować tysiące requestów albo powodować problemy z reputacją adresów IP. Każda taka sytuacja oznacza pracę administratorów i supportu.

Automatyczny system ochrony może więc przynieść hostingowi bardzo konkretne korzyści:

• mniej infekcji i malware,
• mniej wykorzystania zasobów przez przejęte strony,
• mniej spamu i nadużyć,
• mniej ręcznej pracy administratorów,
• mniej zgłoszeń do supportu,
• niższe koszty utrzymania infrastruktury.

Z perspektywy operatora hostingu Monarx może mieć bardzo dużo sensu.

Problem polega na tym, że interes hostingu i interes właściciela konkretnej aplikacji nie zawsze są identyczne. Hosting optymalizuje bezpieczeństwo tysięcy stron jednocześnie. Właściciel systemu biznesowego oczekuje natomiast, że jego konkretna aplikacja będzie działała prawidłowo i przewidywalnie.

Jeżeli zabezpieczenie poprawnie zatrzyma tysiące ataków i błędnie zablokuje jeden legalny request, z perspektywy statystyki może wyglądać znakomicie. Jeżeli tym jednym requestem było potwierdzenie płatności, webhook integracji albo operacja potrzebna klientowi do pobrania zakupionego produktu, właściciel aplikacji może mieć zupełnie inną ocenę sytuacji.

Największe problemy zaczynają się przy autorskim oprogramowaniu

Popularne systemy mają jedną ogromną przewagę: są przewidywalne.

Miliony stron działają na WordPressie. Ogromna liczba sklepów korzysta z PrestaShop. Znane są typowe pliki, moduły, schematy działania, podatności i zachowania tych aplikacji.

Sytuacja zmienia się, gdy zaczynamy korzystać z własnych rozwiązań. Może to być autorski CMS, system licencyjny, dedykowane API, własny mechanizm aktualizacji, nietypowy moduł PrestaShop albo integracja przygotowana wyłącznie dla kilku klientów.

Taki system może wykonywać operacje, które są całkowicie prawidłowe z punktu widzenia jego autora, ale jednocześnie wyglądają nietypowo dla mechanizmu bezpieczeństwa.

Przykładowo aplikacja może przyjmować archiwum ZIP, zapisywać je na serwerze, rozpakowywać, modyfikować pliki PHP i wykonywać proces aktualizacji. Dla właściciela aplikacji jest to normalny aktualizator. Z punktu widzenia systemu bezpieczeństwa sekwencja „upload archiwum → utworzenie plików PHP → modyfikacja kodu” może wyglądać znacznie bardziej podejrzanie.

Jeżeli Monarx błędnie sklasyfikuje taką operację, może ją zablokować. Kod aplikacji nie musi się przy tym w ogóle zmienić. Zmieniły się reguły ochrony i wcześniej działająca funkcja nagle przestaje działać.

To właśnie jest dla mnie jeden z największych problemów tego modelu.

Pierwszy problem, który zobaczyliśmy u siebie

W naszym przypadku problem pojawił się podczas zwykłej operacji wykonywanej przez autorski CMS. System przesyłał przez HTTP kilka plików ZIP. Mechanizm wcześniej działał i nie był próbą wykorzystania podatności.

W pewnym momencie request został jednak zaklasyfikowany przez Monarx jako exploit, a wykonujący go adres IP został zablokowany.

Po kontakcie z hostingiem otrzymaliśmy potwierdzenie, że blokada wynikała właśnie z detekcji Monarx.

I nie chodzi tu nawet o to, kto miał rację w pojedynczym incydencie. Można analizować konkretny request, zastanawiać się, jaki jego element uruchomił regułę, poprawić kod albo zgłosić false positive.

Znacznie ważniejszy jest problem systemowy.

Mechanizm działał wcześniej. My nie podjęliśmy decyzji o zmianie jego zachowania. Mimo to produkcyjne środowisko zaczęło traktować legalną operację jako atak.

Co gorsza, dotyczyło to procesów powiązanych z obsługą klientów, między innymi zarządzaniem licencjami i pobieraniem związanych z nimi zasobów. W praktyce dodatkowa warstwa bezpieczeństwa zaczęła wpływać na normalne funkcje naszego biznesu.

I co zostanie zablokowane następnym razem?

Pojedynczy false positive nie jest największym problemem. Konkretne zdarzenie można przeanalizować i naprawić.

Problemem jest brak przewidywalności.

Dzisiaj system blokuje upload ZIP. Po kolejnej zmianie reguł problem może dotyczyć innego rodzaju requestu. W przypadku rozbudowanej aplikacji potencjalnymi punktami konfliktu są między innymi webhooki, API, importy danych, automatyczne aktualizacje, nietypowe formularze czy operacje wykonywane przez dedykowane moduły.

Nie twierdzę, że Monarx będzie te rzeczy blokował. Twierdzę, że właściciel aplikacji często nie jest w stanie zagwarantować, że nie zacznie.

Jeżeli sam zarządzam WAF-em, mogę sprawdzić konkretną regułę, przeanalizować logi, dodać wyjątek, przełączyć zabezpieczenie w tryb obserwacji i dokładnie przetestować zmianę. Jeżeli system został wdrożony i jest kontrolowany przez hosting, moje możliwości mogą być znacznie mniejsze.

W efekcie odpowiadam za działanie aplikacji, ale nie mam pełnej kontroli nad wszystkimi elementami, które mogą ją zatrzymać.

PrestaShop jest szczególnie dobrym przykładem

Teoretycznie można powiedzieć, że PrestaShop jest popularnym systemem i powinien być dobrze rozpoznawalny przez rozwiązania bezpieczeństwa.

Tyle że prawdziwy sklep bardzo szybko przestaje być „standardowym PrestaShopem”.

Po kilku latach działania często posiada moduły płatności, integracje kurierskie, BaseLinker, Apilo, system ERP, integrację z księgowością, marketplace, własne CRON-y, automatyczny import produktów, eksport zamówień, niestandardowe webhooki i kilka modułów napisanych specjalnie na potrzeby konkretnego sklepu.

Sam rdzeń PrestaShop może być popularny, ale konkretna kombinacja modułów, integracji i własnego kodu jest już unikalna.

Szczególnie interesują mnie mniej popularne moduły. Jeżeli rozwiązanie jest używane przez kilkadziesiąt sklepów zamiast kilkudziesięciu tysięcy, system bezpieczeństwa ma znacznie mniej materiału porównawczego. Jeszcze dalej idą rozwiązania przygotowywane indywidualnie dla jednej firmy.

Im bardziej nietypowe zachowanie aplikacji, tym większe znaczenie ma jakość klasyfikacji i możliwość szybkiego reagowania na false positive.

False positive na serwerze to nie tylko fałszywy alarm

W przypadku antywirusa na komputerze false positive często oznacza niewygodny komunikat i konieczność dodania pliku do wyjątków.

W aplikacji produkcyjnej konsekwencje mogą być znacznie poważniejsze.

Błędna blokada może oznaczać, że klient nie pobierze zakupionego pliku, system magazynowy przestanie się synchronizować, webhook nie dotrze, API nie wykona operacji albo administrator nie będzie mógł uruchomić określonego procesu.

I co szczególnie ważne — taka awaria nie musi wyłączyć całej strony.

Sklep może działać. Produkty mogą się wyświetlać. Koszyk może działać prawidłowo. Jednocześnie jedna integracja może przestać wykonywać część operacji.

To najgorszy rodzaj problemu, bo bardzo łatwo go przeoczyć.

Bezpieczeństwo zaczyna generować dodatkowy koszt monitorowania

Oczywiście odpowiedzią na taki problem może być monitoring.

Możemy kontrolować statusy CRON-ów, wykonywać syntetyczne requesty, sprawdzać API, monitorować webhooki, analizować logi i tworzyć alerty dla kolejnych procesów.

Tylko że wszystko to kosztuje.

Jeżeli wprowadzamy dodatkowy system bezpieczeństwa, który może aktywnie ingerować w działanie aplikacji, właściciel systemu otrzymuje również dodatkowy element, którego zachowanie powinien uwzględnić w monitoringu.

Z punktu widzenia hostingu Monarx może ograniczyć koszty wynikające z infekcji i obsługi problematycznych stron. Z punktu widzenia autora bardziej rozbudowanego systemu część tych kosztów może pojawić się ponownie w postaci dodatkowej diagnostyki, testowania i monitorowania.

Dlatego korzyści nie można analizować wyłącznie z perspektywy firmy hostingowej.

Programista zaczyna metodą prób i błędów walczyć z zabezpieczeniem

Jest w tym również pewien paradoks.

System bezpieczeństwa ma utrudniać atakującemu znalezienie sposobu na wykonanie niedozwolonej operacji. Tymczasem przy false positive legalny programista może zostać zmuszony do podobnego eksperymentowania.

Nie zna dokładnej logiki klasyfikacji, więc sprawdza, co właściwie powoduje blokadę. Zmienia strukturę requestu, sposób wysyłania danych albo kolejność wykonywania operacji i obserwuje, kiedy zabezpieczenie przestaje reagować.

W praktyce zamiast rozwijać aplikację, zaczyna poznawać zachowanie warstwy bezpieczeństwa metodą prób i błędów.

I nawet jeśli znajdzie rozwiązanie, nadal nie ma gwarancji, że po kolejnej zmianie reguł problem nie pojawi się ponownie w innym miejscu.

Prywatność: co dzieje się z naszym kodem?

Drugim obszarem, który budzi moje zastrzeżenia, jest sposób analizy plików.

Monarx nie działa wyłącznie jako całkowicie lokalny skaner. Według dokumentacji producenta agent współpracuje z infrastrukturą Monarx Cloud. Do systemu mogą trafiać informacje o plikach, a w określonych przypadkach pełna kopia interesującego z punktu widzenia systemu pliku może zostać przesłana do dalszej analizy.

Dla standardowego pliku popularnego CMS-a nie musi być to szczególnie istotne. W przypadku autorskiej aplikacji sytuacja jest inna.

Własny kod może zawierać logikę biznesową, informacje o architekturze systemu, integracje, niestandardowe mechanizmy komunikacji i rozwiązania przygotowane specjalnie dla klienta.

Dlatego chcę wiedzieć:

• kiedy pełny plik może opuścić serwer,
• gdzie jest przechowywany,
• jak długo jest przechowywany,
• kto może uzyskać do niego dostęp,
• czy może zostać przekazany do analizy człowiekowi,
• czy można całkowicie wyłączyć przesyłanie plików do zewnętrznej infrastruktury.

Nie oznacza to, że Monarx robi z kodem coś niewłaściwego. Problem polega na czymś innym: zmienia się model zaufania.

Jeżeli wcześniej kod znajdował się wyłącznie na naszym serwerze, a po instalacji systemu ochrony określone pliki potencjalnie mogą trafić do dodatkowego podmiotu, jest to informacja, którą chcę znać przed wdrożeniem, a nie dowiadywać się o niej po fakcie.

A co z danymi klientów?

Tutaj trzeba zachować precyzję.

Nie ma podstaw, aby twierdzić, że Monarx automatycznie przesyła do swojej chmury pełną zawartość wszystkich requestów POST czy wszystkie dane wpisywane przez klientów.

Jednocześnie komponent ochronny działający w środowisku PHP znajduje się bardzo blisko samej aplikacji. Jeżeli ma analizować zachowanie requestów i wykrywać ataki, musi posiadać odpowiednią widoczność tego, co aplikacja robi.

Producent informuje również o przesyłaniu określonej telemetry związanej ze zdarzeniami bezpieczeństwa, obejmującej między innymi adres IP, URL i nagłówki.

Z punktu widzenia administratora systemu obsługującego dane klientów są to informacje istotne. Chcę dokładnie wiedzieć, co jest analizowane wyłącznie lokalnie, co opuszcza serwer, co jest anonimizowane, jak długo jest przechowywane i gdzie znajduje się infrastruktura przetwarzająca te dane.

Samo stwierdzenie, że jest to „telemetria bezpieczeństwa”, nie powinno kończyć dyskusji.

Czy Monarx daje zbyt duże uprawnienia zewnętrznemu systemowi?

Nie nazywałbym Monarx klasycznym atakiem man in the middle. To nie jest właściwe technicznie określenie.

Znacznie trafniej jest traktować go jako bardzo uprzywilejowaną warstwę bezpieczeństwa działającą blisko samego środowiska aplikacji.

Właśnie z tego powodu wymagania dotyczące zaufania powinny być wysokie.

Im więcej system może zobaczyć i im więcej operacji może zatrzymać, tym bardziej interesują mnie jego transparentność, logowanie, konfiguracja, aktualizacje oraz możliwość wyłączenia określonych mechanizmów.

Nie chodzi o podejrzewanie producenta o złą wolę. Dokładnie tak samo powinno się oceniać każdy EDR, WAF, RASP czy inny agent posiadający szerokie uprawnienia.

Bezpieczeństwo dostawcy nie jest automatycznie bezpieczeństwem mojego biznesu

To bardzo ważne rozróżnienie.

Hosting chce chronić całą infrastrukturę. Chce ograniczyć malware, spam, zużycie CPU, włamania i liczbę zgłoszeń.

Ja chcę osiągnąć dokładnie to samo, ale mam dodatkowy warunek: legalne procesy biznesowe muszą nadal działać.

Można zbudować zabezpieczenie, które jest bardzo skuteczne w blokowaniu podejrzanych operacji, ale jednocześnie zbyt agresywne dla konkretnego rodzaju aplikacji.

To nie oznacza, że zabezpieczenie jest obiektywnie złe.

Oznacza, że może być złym wyborem dla konkretnego środowiska.

Szczególnie problematyczne jest wdrażanie takich zmian bez wcześniejszej informacji

W naszym przypadku jednym z najważniejszych problemów było to, że o wpływie dodatkowej warstwy ochrony dowiedzieliśmy się dopiero wtedy, kiedy zaczęła ona wpływać na działanie naszych procesów.

To podejście uważam za niewłaściwe w przypadku systemów, które mogą aktywnie ingerować w wykonywanie aplikacji.

Jeżeli hosting wdraża nową warstwę bezpieczeństwa, która może blokować requesty PHP, właściciel aplikacji powinien mieć możliwość wcześniejszego przygotowania się. Można wtedy przetestować krytyczne endpointy, sprawdzić integracje, przeanalizować dokumentację dotyczącą prywatności i zdecydować, czy taki model ochrony jest akceptowalny.

Dowiedzenie się o zmianie poprzez awarię jest najgorszym możliwym scenariuszem.

Monarx może być bardzo dobrym rozwiązaniem dla jednej strony i bardzo złym dla innej

Nie uważam, że Monarx jest pozbawiony sensu.

Wręcz przeciwnie — dla hostingu pełnego nieaktualizowanych WordPressów może być bardzo wartościowym zabezpieczeniem. Jeżeli alternatywą jest pozostawienie tysięcy stron praktycznie bez ochrony, dodatkowa automatyczna warstwa może zapobiec wielu realnym infekcjom.

Ale autorska platforma biznesowa to inna sytuacja.

Jeżeli mamy własny CMS, niestandardowe API, rozbudowany sklep PrestaShop, mało popularne moduły czy specjalistyczne integracje, potrzebujemy przede wszystkim kontroli i przewidywalności.

W takim środowisku nie chcę systemu, o którym wiem tylko tyle, że „coś uznał za exploit”. Potrzebuję dokładnej informacji, jaka reguła zadziałała, co ją uruchomiło, kiedy została zmieniona i jak mogę bezpiecznie skonfigurować wyjątek.

Jeżeli nie mam takich możliwości, zabezpieczenie staje się kolejną zależnością infrastrukturalną, nad którą nie mam wystarczającej kontroli.

Jakich informacji oczekiwałbym od hostingu?

Przed uruchomieniem podobnego rozwiązania na serwerze obsługującym aplikację biznesową chciałbym otrzymać jasną informację o tym:

• jakie komponenty Monarx są aktywne,
• czy system może automatycznie blokować requesty,
• czy właściciel konta może wyłączyć RASP lub konkretną regułę,
• jakie dane i pliki mogą opuszczać serwer,
• gdzie są przetwarzane i jak długo są przechowywane,
• czy klient ma dostęp do pełnych logów detekcji,
• jak wygląda procedura obsługi false positive,
• w jaki sposób klient jest informowany o zmianach mogących wpłynąć na zachowanie aplikacji.

Dopiero posiadając takie informacje można świadomie ocenić bilans korzyści i ryzyka.

Bezpieczeństwo i niezawodność to dwie różne rzeczy

To chyba najważniejszy wniosek.

System może zwiększać bezpieczeństwo przed atakami i jednocześnie zmniejszać przewidywalność działania aplikacji. Te dwa stwierdzenia nie są ze sobą sprzeczne.

Wyobraźmy sobie, że Monarx przez miesiąc prawidłowo zatrzymał dziesięć tysięcy automatycznych prób ataku. To bardzo dobry wynik.

Jeżeli jednak ten sam system błędnie zablokuje jeden krytyczny webhook od operatora płatności, statystyka skuteczności nadal może wyglądać doskonale, ale właściciel sklepu będzie miał realny problem biznesowy.

Dlatego nie wystarczy pytać:

„Ile ataków Monarx zatrzymał?”

Trzeba również zapytać:

„Jaki jest koszt sytuacji, w której się pomyli?”

Czy chciałbym Monarx na swoim serwerze?

Wszystko zależy od zastosowania.

Na typowym koncie z popularnymi CMS-ami, szczególnie jeśli właściciel strony nie zajmuje się aktywnie bezpieczeństwem, dodatkowa automatyczna ochrona może być korzystna.

W przypadku naszych autorskich rozwiązań mam znacznie większe zastrzeżenia.

Jeżeli system może zmieniać zachowanie produkcyjnej aplikacji, chcę mieć nad nim kontrolę. Chcę widzieć reguły, mieć dostęp do logów, móc utworzyć wyjątek i wiedzieć, kiedy zmienia się konfiguracja.

Jeżeli tego nie mam, dodatkowa warstwa bezpieczeństwa może dla mnie oznaczać więcej problemów niż korzyści.

Szczególnie wtedy, gdy odpowiadam nie tylko za własną stronę, ale za systemy wykorzystywane przez klientów.

Podsumowanie

Monarx może być korzystnym rozwiązaniem dla firm hostingowych. Automatyzuje wykrywanie i usuwanie zagrożeń, ogranicza liczbę infekcji i potencjalnie zmniejsza koszty utrzymania dużej infrastruktury.

Nie oznacza to jednak, że jego wdrożenie jest automatycznie korzystne dla każdego właściciela strony.

Przy autorskich aplikacjach, niestandardowych integracjach, mniej popularnych modułach PrestaShop i systemach realizujących krytyczne procesy biznesowe pojawia się dodatkowe ryzyko: legalne zachowanie może zostać uznane za zagrożenie i zablokowane przez system, którego właściciel aplikacji nie kontroluje.

Do tego dochodzą pytania o prywatność, analizę własnego kodu, przesyłanie wybranych plików do zewnętrznej infrastruktury, zakres telemetry i dostęp do konfiguracji.

Nie jest więc wystarczające pytanie, czy Monarx poprawia bezpieczeństwo serwera.

Trzeba spojrzeć szerzej.

Czy poprawia bezpieczeństwo całego systemu, jeżeli jednocześnie wprowadza nowy punkt awarii, nową zależność i nowy element infrastruktury, którego zachowania właściciel aplikacji nie jest w stanie w pełni przewidzieć?

W przypadku standardowych stron odpowiedź może być pozytywna.

W przypadku autorskiego oprogramowania odpowiedziałbym znacznie ostrożniej.

Bo dobre bezpieczeństwo nie polega tylko na blokowaniu jak największej liczby potencjalnych zagrożeń. Dobre bezpieczeństwo powinno również zapewniać kontrolę, przewidywalność i pewność, że prawidłowe funkcje systemu będą działały wtedy, kiedy są potrzebne.

I właśnie tego najbardziej brakuje mi w modelu, w którym zamknięty system bezpieczeństwa może zostać wdrożony przez hosting, zmieniać swoje reguły niezależnie od aplikacji i dopiero po fakcie informować właściciela strony, że jego prawidłowy request został uznany za exploit.