Synology Threat Prevention: Co wykrywa, a czego nie widzi

Threat Prevention to pakiet, po który większość ludzi sięga w momencie, gdy decyduje się na hostowanie witryny internetowej na serwerze Synology NAS. Działa na routerze, ma ikonę tarczy, a jego pulpit nawigacyjny zlicza ataki w setkach, więc wygląda jak coś, co dba o bezpieczeństwo publicznej witryny. Uruchamiamy go na routerze RT6600ax przed każdą posiadaną maszyną i warto go mieć. Jednak w przypadku samodzielnie hostowanej witryny internetowej jest on niemal całkowicie nietrafiony.

Ten artykuł z serii NAS Hosting 101 otwiera nasz własny router, odczytuje z niego rzeczywisty tydzień zdarzeń i pokazuje dokładnie, gdzie Threat Prevention przestaje być pomocny, używając PHP2Shell jako przykładu ataku, którego Threat Prevention i tak by nie wykrył.

Punkt SynoPower Club: Spędziłem dużo czasu pracując w dziale wsparcia Synology i to pytanie pojawiało się nieustannie: którą opcję mam włączyć, aby zatrzymać ten atak. To właściwy instynkt skierowany do niewłaściwego urządzenia. Przełomem dla mnie było przeczytanie naszej własnej listy zdarzeń zamiast strony opisującej funkcję. Każdy alert zarejestrowany przez nasz router w tym miesiącu dotyczył adresu o złej reputacji, a nie żądania ze szkodliwą zawartością. Gdy to zrozumiesz, przestaniesz wymagać od Threat Prevention inspekcji ruchu, który trzyma w zapieczętowanej kopercie.

Co naprawdę robi Threat Prevention na routerze Synology #

Threat Prevention to system wykrywania i zapobiegania włamaniom wywodzący się z linii Snort i Suricata. Odczytuje pakiety w miarę ich przesyłania przez router, porównuje je z zestawem sygnatur i rejestruje alert albo odrzuca pakiet. Na naszym RT6600ax źródłem sygnatur jest ET Open, bezpłatny poziom zestawu reguł Emerging Threats, odświeżany codziennie o godzinie 09:00.

Z tej konstrukcji wynikają trzy właściwości, i wszystkie trzy mają większe znaczenie niż jakiekolwiek pole wyboru w interfejsie:

• It can only examine packets the router forwards. Traffic that never crosses the routing engine is not slow to inspect, it is invisible.
• It can only match on bytes it can readW Threat Prevention nie ma przechwytywania TLS w żadnym miejscu, więc zaszyfrowana zawartość jest nieczytelna.
• It can only match signatures somebody else wrote. The interface exposes vendor classes to switch on and off, and nothing that accepts a rule you author yourself.

Nic z tego nie jest wadą. Posiadanie IPS na obwodzie sieci jest rozsądne i przydatne. Błędem jest zakładanie, że obwód to miejsce, w którym atakowana jest witryna internetowa.

Threat Prevention a zapora sieciowa aplikacji internetowych (WAF) #

Najjaśniejszym sposobem na dostrzeżenie tej różnicy jest zestawienie Threat Prevention z zaporą aplikacji internetowych (WAF) i zapytanie, co każde z nich posiada w momencie podejmowania decyzji. Threat Prevention trzyma pakiet. WAF trzyma odszyfrowane żądanie HTTP.

Question	Router IPS	Reverse-proxy WAF
Gdzie to biegnie	On the routing path, before TLS ends	At the edge, after TLS ends
What it inspects	Packet headers and any cleartext bytes	Method, path, headers, cookies, body
HTTPS traffic	Opaque	Fully readable
Rules you can add	Vendor classes on or off	Your own expressions, plus managed rulesets
Same-subnet traffic	Never seen	Not applicable, it is upstream of everything
Typical catch	Reputation hits, scans, cleartext exploits, outbound command and control	Injection, traversal, known CVE request shapes, credential stuffing, bots

To nie są produkty konkurencyjne. Obejmują różne odcinki tej samej drogi, a samodzielnie hostowana witryna potrzebuje tego drugiego znacznie bardziej niż pierwszego. Używamy obu i od każdego oczekujemy zupełnie czegoś innego.

Odczyt 595 zdarzeń z jednego tygodnia na naszym własnym routerze #

Oto ekran przeglądu Threat Prevention naszego produkcyjnego routera z dnia 25 października 2026 r. Pięćset dziewięćdziesiąt pięć złośliwych zdarzeń w ciągu siedmiu dni, z czego 75 o wysokim priorytecie. Wygląda to jak mur powstrzymujący powódź.

Dwa szczegóły na tym ekranie są warte więcej niż główna liczba. Pierwszy to fakt, że w sekcji potencjalnych zagrożeń pojawia się tylko jedno urządzenie, i jest to REVERSE_MAIL – maszyna, która kończy połączenie TLS i uruchamia MailPlus. Drugi to data sygnatury obok zielonego znacznika. Teraz otwórz pojedyncze zdarzenie i przeczytaj, co naprawdę się uruchomiło.

Klasyfikacja Misc Attack, priorytet Średni, stan Alert, nazwa sygnatury ET CINS Active Threat Intelligence Poor Reputation IP group 24. Otwórz treść reguły: rozpoczyna się od alert ip, a następnie długiej listy adresów. To jest sprawdzanie na liście blokowanych. Żadna część żądania HTTP nie została odczytana, ponieważ żadna część nie mogła zostać odczytana. Przeanalizowaliśmy próbki zdarzeń dla drugiego celu, naszego hosta Virtual DSM, i znaleźliśmy tę samą klasę reguły z innym numerem grupy.

Szczere podsumowanie jednego tygodnia jest więc następujące: router rozpoznał kilkaset połączeń z adresów, które miały już złą reputację. To jest naprawdę przydatne. Nie jest to jednak wykrywanie ataków internetowych i nikt nie powinien interpretować liczby 595 tak, jakby nim było.

Jak przeprowadzić audyt Threat Prevention w 4 krokach #

Zanim powierzysz cokolwiek pakietowi Threat Prevention, poświęć dziesięć minut na sprawdzenie, co tak naprawdę robi on w Twojej własnej sieci. Każdy z poniższych kroków służy tylko do odczytu i niczego nie zmienia.

Gdzie naprawdę zasługuje na swoje miejsce #

Trzymamy Threat Prevention włączone i nie wynika to z zabobonów. Wykonuje cztery zadania, których nie robi nic innego w naszym środowisku.

• Outbound command and control. This is the strongest case by far. A compromised device has to call home, that call has to leave through the router, and a good share of it is still either cleartext or aimed at a known address. Our router ships the Malware Command and Control Activity class with 3,450 of 3,498 rules enabled, and the Domain Observed Used for C2 class with 7,157 of 7,202.
• Cleartext protocols from the internet. Our mail server answers on port 25, and SMTP is cleartext until STARTTLS. That is real inspectable traffic, and it is no accident that the mail host is the one device our events list keeps naming.
• Scanning and reconnaissance. Port sweeps and fingerprinting are recognised by connection behaviour rather than by payload, so encryption does not hide them.
• Visibility. A searchable log of who knocked and with what reputation is worth having, even when every entry is only a reputation hit. It is monitoring value, and it should be counted as monitoring value rather than as protection.

Wspólną cechą tych czterech zadań jest to, że żadne z nich nie jest atakiem na witrynę internetową.

Dlaczego właściciel witryny wymaga od Threat Prevention niewłaściwych rzeczy #

Gdy hostujesz witrynę na serwerze NAS, ścieżka żądania zazwyczaj zawiera odwrotny serwer proxy. Nasza wygląda tak, a ten układ decyduje o wszystkim:

• The visitor reaches Cloudflare, which answers most requests from cache and inspects the rest in cleartext.
• What is left crosses the router, gdzie Threat Prevention widzi zaszyfrowany strumień TLS i nic więcej.
• Ten reverse proxy NAS terminates TLS and forwards plain HTTP to the machine that runs the site.
• That last hop is on the same subnet, so the frame goes through a switch and the router is not in the path.

Przeczytaj te cztery wiersze razem, a pułapka stanie się oczywista. Jedynym odcinkiem, na którym żądanie istnieje w czytelnej postaci, jest ostatni skok, i jest to ten jedyny odcinek, którego router nie może obserwować. Wszędzie tam, gdzie router może dokonywać obserwacji, żądanie jest zaszyfrowane. Nie ma pola wyboru, które rozwiązałoby taką sprzeczność, a Threat Prevention nie ponosi porażki, gdy milczy. Zgłasza dokładnie informacje o ruchu, którego strukturalnie nie jest w stanie odczytać.

Dlatego również skierowanie Threat Prevention na konkretną witrynę nie działa. Pakiet jest powiązany z interfejsami routera, a nie z nazwami hostów. Nie ma pojęcia, do której z Twoich witryn należy połączenie, ponieważ nigdy nie widzi nagłówka Host.

Trzy powody, dla których PHP2Shell był niewidoczny dla routera #

PHP2Shell, para luk umożliwiających zdalne wykonanie kodu bez uwierzytelnienia (śledzonych jako CVE-2026-109618 i CVE-2026-109619), wyciekła 20 października 2026 r. i została załatana przez twórców oprogramowania następnego dnia. Jest to dokładnie ten rodzaj zagrożenia, od którego obrony oczekuje się po routerowym IPS-ie, i warto dokładnie wyjaśnić, dlaczego nie mógł tego zrobić.

Po pierwsze, ruch był zaszyfrowany na każdym odcinku, który obserwuje router. The exploit lives in the HTTP request, and the HTTP request only exists in the clear after TLS has been terminated, which happens downstream of the router on a hop the router never carries.

Po drugie, nie istnieje żadna sygnatura Threat Prevention, którą można by włączyć. We checked again on 25 October 2026 and found no published Snort or Emerging Threats rule for either CVE. Our feed is ET Open, the free tier, which lags the commercial set, and the Self-Defined Policy screen accepts no rule of your own. So even an operator who knew precisely what to match for had nowhere to put it.

Po trzecie, i co najważniejsze, ten atak nie posiada kształtu ładunku, który można by dopasować do wzorca. The chain takes two requests. The first has to push PHP into exhausting its memory limit, which makes the engine abandon a request through a path that skips cleanup and leaves some global state behind. The second request is ordinary, and it is the one that reaches a stale pointer and turns into code execution.

Pierwsze żądanie definiowane jest przez to, ile pamięci zużywa, a nie przez jakąkolwiek sekwencję bajtów — duży przesyłany plik, ogromna treść JSON, głęboka tablica czy długi ciąg w wyrażeniu regularnym spełniają te kryteria. Drugie nie niesie ze sobą żadnych złośliwych bajtów. IPS podejmuje decyzje dla poszczególnych pakietów i przepływów. Nie ma modelu procesu roboczego przenoszącego skażony stan z jednego żądania do drugiego, a to właśnie tam leży ten błąd.

Wyznacza to również granice obejścia krążącego wówczas w sieci, które polegało na wyłączeniu session.upload_progress w konfiguracji PHP. Usuwa to wprawdzie jeden dobrze udokumentowany sposób na dotarcie do drugiego CVE i na maszynie, której naprawdę nie można załatać, jest to lepsze niż nic. Nie jest to jednak rozwiązanie problemu: wyczerpanie pamięci jest możliwe nie tylko za pośrednictwem tej jednej funkcji, a to ustawienie nie ma żadnego wpływu na CVE-2026-109618. Użyliśmy go jako tymczasowego środka na dokładnie jednym hoście i traktowaliśmy jako kupowanie czasu, a nie jako rozwiązanie. Pełne sprawozdanie z tego, jak przeprowadziliśmy łatanie, znajduje się w naszym PHP2Shell write-up.

Domyślne przekazywanie ruchu przy awarii i dzień, w którym kosztowało nas to naszą pocztę #

Jest jeszcze jedna właściwość, o której warto wiedzieć, zanim potraktujesz Threat Prevention jako zabezpieczenie, na którym można polegać. Domyślnie zalecanym trybem jest priorytet stabilności sieci, a interfejs bez żadnych eufemizmów wyjaśnia, co to oznacza: gdy ruch przekracza wydajność przetwarzania, oczekujące pakiety są przepuszczane bez filtrowania. Alternatywa, czyli tryb priorytetu bezpieczeństwa, zamiast tego odrzuca je i ostrzega, że połączenie będzie niestabilne do czasu rozwiązania problemu.

To rozsądne ustawienie domyślne dla routera domowego. Oznacza to jednak, że Threat Prevention jest najsłabszy dokładnie w momencie, w którym najbardziej potrzebujesz jego siły, ponieważ zalew ruchu jest zarówno rzeczą, którą chcesz przefiltrować, jak i rzeczą, która przekracza wydajność.

Mamy również odnotowany drugi tryb awarii. 2 sierpnia 2026 r. ktoś zaatakował nasz reverse proxy 116 razy eksploitem na błąd w PHP-CGI w systemie Windows, który w ogóle nie może zadziałać na Linuksie. Threat Prevention odrzucił wystarczająco dużo pakietów, aby zablokować własny stan, a następnie zaczął odrzucać ruch wychodzący maszyny, której miał bronić. Nasza kolejka pocztowa utknęła, a objaw wyglądał dokładnie jak awaria DNS. Ponowne uruchomienie routera rozwiązało problem. W dzienniku dostępu proxy nic się nie pojawiło, ponieważ nic nigdy do niego nie dotarło. Atak, który strukturalnie nie miał prawa się udać, i tak doprowadził do przerwy w działaniu — za sprawą narzędzia, które miało mu zapobiec.

Przy okazji spójrz na liczbę aktywnych reguł na tej liście. Web Application Attack pokazuje 5928 z 6010 aktywnych reguł, a proporcja jest podobna w pozostałych klasach, które nas interesują. Włączenie klasy nie powoduje włączenia każdej reguły w jej wnętrzu, a interfejs nie daje żadnego sposobu, aby sprawdzić, których z pozostałych reguł brakuje.

Umieść proxy z przodu, a następnie zablokuj dostęp bezpośredni do serwera źródłowego #

Jeśli udostępniasz witrynę internetową z serwera NAS, mechanizmem kontroli, który wykonuje zadanie, jakiego nie potrafi zrobić router, jest WAF typu reverse-proxy. Używamy Cloudflare, a powodem jest raczej jego pozycja niż marka: szyfrowanie TLS kończy się na brzegu sieci, więc całe żądanie jest czytelne w momencie podejmowania decyzji. Metoda, ścieżka, zapytanie, nagłówki, pliki cookie i treść (body) są w pełni dostępne dla reguły.

Dlatego właśnie zabezpieczenia przed PHP2Shell pojawiły się tam, a nie na routerze. Gdy ujawniono luki CVE, zarządzany zestaw reguł wzbogacił się o siedem reguł dla tej pary w ciągu dwóch dni i działały one we wszystkich czterech obsługiwanych przez nas strefach, zanim jeszcze skończyliśmy przebudowywać własne kontenery. Żaden odpowiednik nigdy nie pojawił się w kanale Threat Prevention, a pięć dni później nadal nie ma publicznej reguły Snort ani Emerging Threats do zainstalowania.

Jedno ostrzeżenie, które ma większe znaczenie niż wybór dostawcy. Proxy z przodu pomaga tylko wtedy, gdy nie można go obejść. Jeśli Twój adres źródłowy odpowiada bezpośrednio w publicznym internecie, każdy, kto go odkryje, pominie każdą regułę brzegową, którą utworzyłeś. Ogranicz port 443 na serwerze źródłowym do zakresów sieciowych proxy, pobieraj te zakresy z punktu końcowego dostawcy, zamiast wpisywać je na sztywno, i zweryfikuj blokadę, wywołując stronę bezpośrednio z jej adresu. Nasza szersza konfiguracja oraz cztery warstwy za tą opisane są w the five layers we run.

Ograniczenia i uwagi dotyczące bezpieczeństwa Threat Prevention #

Threat Prevention wymaga pamięci zewnętrznej na routerze i nie jest dostępne w każdym modelu, dlatego przed zaplanowaniem jego użycia upewnij się, że Twój sprzęt go obsługuje. Silnik ten jest również najbardziej obciążającym elementem pracy routera, a w urządzeniach konsumenckich jest komponentem, który najczęściej staje się wąskim gardłem przepustowości. Wykonaj pomiary przed i po, zamiast ufać danym marketingowym.

Traktuj każdą liczbę na ekranie przeglądu jako liczbę dopasowań sygnatur, a nie liczbę powstrzymanych ataków. Te dwie wartości różnią się w obu kierunkach. Wykrycie skanera o złej reputacji, który i tak nic by nie osiągnął, zawyża ogólną sumę, a spokojny tydzień niczego nie dowodzi w kwestii ruchu HTTPS, którego silnik nie jest w stanie odczytać.

W Threat Prevention status ma tak samo duże znaczenie jak poziom zagrożenia. Opcja „Automatycznie odrzucaj pakiety o wysokim ryzyku” działa tylko na pasmo wysokiego ryzyka, więc wpisy o średnim poziomie zagrożenia są rejestrowane i przesyłane dalej. Interfejs wyświetlający komunikat Alert informuje, że pakiet został dostarczony.

Kanał sygnatur działa jak łańcuch dostaw. ET Open odświeża się według harmonogramu, działa z opóźnieniem w stosunku do komercyjnego zestawu reguł i może nie dostarczyć niczego dla luki wykrytej kilka dni temu. Pulpit nawigacyjny zgłaszający, że baza danych jest aktualna, informuje jedynie, że jest ona zgodna z kanałem, a nie że kanał obejmuje to, co jest obecnie wykorzystywane w atakach.

Nic z tego nie zastępuje łatania. Każda omówiona tutaj warstwa kupuje czas na to, co rzeczywiście usuwa podatność, czyli na aktualizację dotkniętego oprogramowania. W przypadku PHP2Shell oznaczało to nowe pakiety PHP i przebudowane kontenery, i żadna kontrola sieciowa tego nie zastąpiła.

Na koniec oprzyj się pokusie włączania każdej klasy po przeczytaniu ostrzeżenia. Klasy takie jak Misc activity zawierają tysiące reguł o niskiej wartości, które głównie generują szum i zużywają tę samą wydajność, której potrzebują przydatne klasy. Cicha, dobrze dostrojona lista zdarzeń, którą rzeczywiście czytasz, jest lepsza niż głośna, którą uczysz się ignorować.

Często zadawane pytania #

Odniesienia i przewodniki wideo #

Główne źródła dla wszystkiego, co opisano powyżej, plus trzy poradniki warte poświęconego czasu.

• Centrum wiedzy Synology: Threat Prevention covers requirements, modes and model support.
• Synology-SA-26:14 lists the fixed PHP package versions for DSM, including the 7.4 build.
• Synology Statement on PHP2Shell names the affected packages and the one that needs a manual update.
• Cloudflare WAF managed rules explains how managed rulesets are versioned and deployed.
• Zakresy adresów IP Cloudflare is the endpoint to read when locking an origin to the proxy instead of hard-coding addresses.