Test QNAP ADRA NDR - system zabezpieczeń sieciowych klasy NDR. Co to jest, jakie oferuje możliwości i jak działa w praktyce?

Test QNAP ADRA NDR – Testy skuteczności działania

Pora w końcu sprawdzić, jak bohater dzisiejszego testu radzi sobie w boju. Jego głównym zadaniem jest wykrywanie i ewentualne reagowanie na zagrożenia pojawiające się przede wszystkim w warstwie sieciowej komunikacji między komputerami, ale nie tylko. Firma QNAP charakteryzuje QNE ADRA NDR jako narzędzie, które będzie w stanie wyłapać exploitację podatności na maszynach w sieci. Nie pozostaje zatem nic innego, jak zorganizować sobie prostą infrastrukturę sieciową i wcielić się w rolę złoczyńcy. Moim zadaniem będzie pierw wykonanie rekonesansu w celu identyfikacji wszystkich aktywnych komputerów w sieci i nasłuchujących na nich aplikacjach w postaci otwartych portów. Ostatecznie warto podjąć próbę wykorzystania podatności np. w celu otrzymania reverse shella (poprzez RCE) lub wykonania ataku DoS odcinając w efekcie atakowaną aplikację od możliwości obsługi tego właściwego ruchu sieciowego.

Platformę testową stanowić będzie redakcyjny serwer, który wykorzystujemy do weryfikacji wydajności sprzętu sieciowego. Gwoli przypomnienia, programowy trzon tej maszyny stanowi hypervisor Proxmox-VE 8. Maszyny wirtualne dają nam bowiem dużą elastyczność w postaci możliwości dostosowania środowiska do wymagań stawianych przez testowany sprzęt. Wobec tego, na potrzeby testów rozwiązania QNE ADRA NDR stworzone zostało środowisko w postaci tegoż urządzenia – czyli przełącznika QNAP QGD-1600P – działającego jako główny switch.
Platformę testową z Proxmox-VE podłączyłem do QGD-1600P w ramach osobnego VLANu, symulując przy okazji prawdziwe środowisko pracy np. w jakiejś firmie, gdzie podział na osobne segmenty sieci przy pomocy VLANów bywa spotykany. Ostatecznie zapewniłem również wyjście na świat wpinając całość do routera. Tutaj serwer DHCP odpowiedzialny był rzecz jasna za przydzielanie adresów IP zarówno dla interfejsów wymaganych do poprawnej pracy ADRA NDR – w ramach domyślnego VLANu – a także dla VLANu testowego. Rolę atakującego pełniła maszyna z systemem Kali Linux 6.8.11, a „ofiary” stanowiły dwie maszyny z systemami Microsoft Windows 10 – jedna w wersji 21H2, druga w znacznie starszej 1511.

Zaznaczyć powinienem, że w wykonanych atakach nie chodzi o ich skuteczność, ale o zbadanie reakcji QNE na ich wystąpienie w sieci. Pierwszym „wrogim” działaniem była próba przeprowadzenia skanowania całej podsieci /24 za pomocą dwóch metod – nmap Ping scan (opcja -sP) oraz rozsyłania żądań ARP – za pomocą narzędzia netdiscover. W tym pierwszym przypadku wykrywanie działających hostów polega na wysyłaniu pakietów ICMP Echo request oraz TCP na port 80 i badaniu odpowiedzi. W obydwu przypadkach ADRA prawidłowo zidentyfikowała intruza, przydzieliła go do grupy „Threat scan” i odnotowała ten fakt (choć równie dobrze mogła mu od razu zablokować ruch wychodzący).

Taka sama reakcja wystąpiła w przypadku próby skanowania portów (TCP SYN scan). Reakcja była natychmiastowa, także w przypadku skanowania konkretnego hosta.

Ataki te były przeprowadzane w ich raczej standardowym i domyślnym wariancie, który wprost bombarduje pakietami sieć. Żeby nie było za nudno postanowiłem pobawić się nieco dostępnymi opcjami, by sprawdzić, jak ADRA NDR zareaguje na znaczne spowolnienie skanowania. Eksperymenty prowadziłem dla wszystkich poprzednich opcji i rozwiązanie QNAPa nie dawało za wygraną skutecznie wykrywając kolejne próby. Ostatecznie jednak udało się tego niezłomnego strażnika pokonać ustawiając siedmiosekundowy odstęp pomiędzy pakietami badawczymi i… voila! Brak wykrycia. Niezależnie od metody (z ciekawości skorzystałem także z modułu metasploita o nazwie auxiliary/scanner/portscan/tcp z ustawiona opcją Delay), spowolnienie ataków nie spowodowało jakichkolwiek reakcji ze strony NDR.

Skanowaniu poddałem również maszynę-pułapkę, tym razem dla odmiany wykorzystując metodę XMAS scan (za pomocą flag FIN, PSH i URG) – również z metasploitowej oferty (auxiliary/scanner/portscan/xmas) z opcją DELAY ustawioną na 40 ms (a więc znacznie mniej niż poprzednio). I cóż – znowu nic nie wykryło :) Skanowanie tą samą metodą za pomocą nmapa wyzwoliło z kolei reakcję QNE.

No dobrze, testy skanowania za nami. Pora na to, co tygryski lubią najbardziej, a więc jakieś ataki na konkretne podatności. W tym celu konieczne było spreparowanie nieco naszych maszyn testowych, by zawierały podatne oprogramowanie. Oto, co zdecydowałem się wyeksploitować:

• RCE w Apache Tomcat <9.0.19 (ja wykorzystałem 9.0.17) na MS Windows - CVE-2019-0232
• RCE w usłudze SMBv1 systemu Microsoft Windows 10 wersji 1703, a więc atak EternalBlue – CVE-2017-0144
• DoS w Apache 2.4.17 również na MS Windows, wykorzystując do tego atak slowloris - CVE-2007-6750

We wszystkich przypadkach do realizacji tych niecnych czynów przysłużył się Metasploit Framework z uaktywnionymi właściwymi modułami, odpowiednio: exploit/windows/http/tomcat_cgi_cmdlineargs, auxiliary/dos/http/slowloris i exploit/windows/smb/ms17_010_eternalblue.

Efekty eksploitacji widać na obrazkach powyżej. ADRA NDR nie zareagowała w przypadku jakiegokolwiek ataku. Trzeba tu zaznaczyć, że każda próba wymagała wyłączenia wbudowanego w Windowsa program Microsoft Defender, który bardzo skutecznie bronił maszyny przed akcjami intruza.

Dotarłem do informacji, jakoby wymagana było przydzielenie atakującej maszyny do grupy Threat Watch. To też miało w istocie miejsce, ale w wykrywaniu ataków nic niestety nie uległo zmianie. Takie rozwiązanie byłoby w mojej ocenie nieakceptowalne, bo uzależniamy jeden mechanizm wykrywania ataków od innego – klasyfikacyjnego. One powinny działać niezależnie starając się wykryć i zalogować możliwie najwięcej podejrzanych prób ataków.

• « pierwsza
• ‹ poprzednia
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• następna ›
• ostatnia »