IPS w Data Center jako moduł NSX-t

Od początku istnienia rozwiązania NSX-t główną funkcją bezpieczeństwa był dystrybuowany firewall. W wersji 3.0 dostaliśmy IDS a od wersji 3.1 dostajemy pełnego IPS’a, który rozszerza portfolio bezpieczeństwa dla rozwiązania NSX. Wiadomo, potrzebna jest nam dodatkowa subskrypcja (NSX Advanced Threat Prevention Add-On), aby móc cieszyć się tym rozwiązaniem. Z każdą nową wersją NSX jest rozbudowywany o rozwiązania z dziedziny bezpieczeństwa. Dziś odpowiem na trzy kluczowe pytania związane z IPS/IDS.

Czy dziś IPS/IDS jest nam potrzebny?

Moim skromnym zdaniem tak. Jeszcze razem z NSX’em, pozawala nam na zbudowanie reguły jak najbliżej wirtualnej maszyny, dzięki temu zwiększmy nasze bezpieczeństwo w ramach rozwiązania SDDC. Do tej pory taki ruch musieliśmy wysłać do sieci fizycznej lub dedykowanej wirtualnej maszyny. Co często wiązało się z problemami typu, jak zawinąć ruch, aby przeszedł przez IPS/IDS. Dziś, wykorzystując NSX’a nie musimy aż tak o tym myśleć, bo to dzieje się na poziomie hyperwizora, działa w jednym flow razem z dystrybułowanym firewallem. Pamiętajmy, że reguła dla IPS/IDS przemieszcza się razem z wirtualną maszyną w ramach SDDC.

Rozwiązanie to pozwala nam znacząco precyzyjniej i szybciej spełniać wymagania związane z bezpieczeństwem, stawiane przez różne instytucje jak np. PCI DSS, czy Polskie KSC.

https://evoila.com/pl/akcja-integracja-avi-z-nsx-t-czesc-1/

Ale jak działa ten IPS/IDS?

Samo rozwiązanie jest adaptacją rozwiązania Suricata na poziom hypervizora. Samo rozwiązanie jest rozbudowane o informacje z Lastline, SecureWorks czy Trustwave – pozawala na dokładne działanie z wykorzystaniem sygnatur. Całość to opiera się na sygnaturach dostarczanych przez wyżej wymienione źródła.

Centralne zarządzenie z wykorzystaniem NSX Managera, na którym:

• Przypisujemy licencję
• Uruchamiamy IPS/IDS
• Pobieramy lub wrzucamy bazę sygnatur
• Tworzymy reguły IPS/IDS i je publikujemy
• Monitorujemy na poziomie dashboardów

Usługę IPS/IDS możemy przypisać na dwóch poziomach:

• Gateway T1 dla ruchu na północ – południe
• Do klastra vSphere dla ruchu wschód zachód.

https://evoila.com/pl/akcja-instalacja-avi-i-controllera-nsx-czesc-2/

Podobnie sytuacja wygląda, gdy mamy do stworzenia reguły na dwóch płaszczyznach tak jak widzimy na poniższym obrazku:

• Distrybuted Rules – ruch wschód zachód
• Gateway Rules – ruch na północ-południe

Ważnym elementem jest skonfigurowanie odpowiedniego profilu, który zostanie wykorzystany do budowania reguły w polityce IPS/IDS, tak jak pokazuje poniższa grafika:

Jak widzimy powyżej, mamy duże pole manewru do konfiguracji, możemy skonfigurować profil wykorzystując filtry:

• Intrusion Severities – wybieramy stopień zagrożenia, na dzień pisania artykułu filtrujemy z 10194 sygantur
• Attack Types – rodzaj ataku wybieramy, na dzień pisania artykułu 32 pozycji
• Attack Targets – rodzaj serwera, który chronimy, na dzień pisania artykułu 20 pozycji
• CVSS – określamy krytyczność podatności
• Products Affected – rodzaj systemu czy aplikacji, na dzień pisania artykułu 395 pozycji

Dzięki temu jesteśmy w stanie bardzo starannie zdefiniować regułę dla konkretnego systemu operacyjnego czy funkcji pełniącej.

Co do definiowania samych reguł, to mamy możliwość przypisania ich podobnie, jak reguły DFW, czyli do całego środowiska lub do wybranych security groups. Jedyną różnicą jest tryb działania (mode), który daje nam dwie możliwości:

• Detect & Prevent
• Detect Only

Tak jak poniżej widzimy stworzoną politykę IPS, którą możemy opublikować.

Co z wydajnością?

Wydajność rozwiązania nie jest ograniczona do jednego pudełka, które jest gdzieś w sieci, jak to ma miejsce w przypadku rozwiązań klasycznych. Przy IPS/IDS w wydaniu VMware wydajność rozkłada się na wszystkie fizyczne serwery pracujące w ramach infrastruktury NSX-t.

Dodatkowo budowanie reguł IPS/IDS w sposób bardzo granuralny pozwala na przekierowanie konkretnego ruchu do inspekcji, a co za tym idzie również ograniczamy w ten sposób ilość skanowanego ruchu.

Tak jak widzimy, przy rozwiązaniu z zastosowaniem NSX-t nie jesteśmy ograniczani do jednego klastra lub wielu które są umieszczane w sieci dokładnie mówiąc w ścieżce ruchu. , co często wiązało się ze skanowaniem 100% ruchu przez dedykowane rozwiązanie i znacząco wpływało na wydajność jak również i bezpieczeństwo.

Mam nadzieję, że wyżej opisane zagadnienie pozwoliły pomyśleć czy warto wykorzystać moduł IPS/IDS w ramach rozwiązania NSX.

Artykuł powstał przy współpracy z dostawcą usługi VMware NSX-t <klik>