Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



25.02.2020

Koszty w górę

Zmiany w licencjach VMware
24.02.2020

VPN na nowo

WireGuard w Linuksie
24.02.2020

Wydajność pod kontrolą

Citrix Analytics for Performance
24.02.2020

Zaawansowany backup

Veeam Availability Suite v10
20.02.2020

Serwery Enterprise

OVHCloud stawia na Ryzeny
20.02.2020

Monitory dla biznesu

Newline IP
20.02.2020

Przemysłowe SSD

Dyski Transcend M.2 NVMe
23.01.2020

Google Project Zero

Inicjatywa Google Project Zero
23.01.2020

Ochrona tylko w chmurze

Kaspersky Security Cloud Free

Wdrożenie systemu monitorowania sieci

Data publikacji: 26-09-2019 Autor: Piotr Kałuża
RYS. 1. SCHEMAT DZIAŁANIA...

Dobrze przemyślany proces wdrożenia jest kluczem do jego sukcesu. Wiedząc już z poprzedniego numeru, czym jest netflow, jakich informacji nam dostarcza oraz jakich informacji dostarcza sonda na podstawie analizy kopii ruchu, możemy takie wdrożenie skutecznie zaplanować.

 

W pierwszej kolejności zastanówmy się, jakie obszary w naszej sieci w ogóle występują. Sieć LAN, wydzielona sieć dla serwerów czy klasyczny DMZ, sieć dla gości i urządzenia dostępowe do internetu to najczęściej spotykane typy podsieci w infrastrukturach IT przedsiębiorstw. Zazwyczaj są one jeszcze dodatkowo dzielone, np. LAN jest dzielony na podsieci ze względu na przynależność do poszczególnych działów czy urządzenia w tych podsieciach działające. Tutaj pojawia nam się pierwsze pytanie – czy chcemy albo musimy monitorować ruch wewnątrz takich podsieci, czy wystarczy nam monitorowanie komunikacji między nimi?

Drugie pytanie brzmi: jak szczegółowy ma być ten monitoring? Jeśli potrzebujemy jedynie statystyki takiego ruchu, to w zupełności wystarczą dane dostarczane w netflow. Należy wtedy tylko sprawdzić, czy urządzenia, przez które odbywa się komunikacja, mogą generować netflow, w jakiej wersji oraz czy dane są poprawne. W tym miejscu możemy napotkać trudności związane z generowaniem flowów przez urządzenia, niską jakością danych dostarczanych z urządzeń, a nawet z błędnymi danymi przesyłanymi przez urządzenia. Jeśli te problemy uda nam się rozwiązać, to świetnie, ale jeśli są one nie do rozwiązania – np. konieczna jest wymiana sprzętu lub potrzebujemy dodatkowych danych o ruchu sieciowym, które nie są zawarte w netflow – to niezbędne okaże się użycie specjalnej sondy, czyli Flowmon Probe.

> INSTALACJA SONDY

Jak już powiedziano w poprzednim numerze, sonda na podstawie kopii ruchu dostarczy nam nie tylko netflow, a więc danych z warstwy L2–L4, ale również metadanych z warstwy aplikacji L7 oraz metryk o wydajności sieci. Najczęściej sondy są instalowane do monitorowania ruchu z sieci LAN lub z internetu do sieci DMZ, gdzie są umieszczone serwery aplikacyjne. Wtedy mierzymy głównie metryki wydajności sieci, tzn. parametry takie jak Round Trip Time (RTT), czyli opóźnienie wprowadzane przez sieć, Server Response Time (SRT), czyli opóźnienie wprowadzane przez serwer, oraz inne parametry, takie jak retransmisje pakietów, pakiety Out of Order oraz opóźnienia (Delay) i zmienność tych opóźnień w czasie (Jitter). Umieszczenie sondy w takim miejscu do monitorowania ruchu może być również przydatne na dalszym etapie korzystania z rozwiązań Flowmon, w których do monitorowania aplikacji webowych i bazodanowych będziemy mogli użyć modułu Application Performance Monitor.

Innym istotnym miejscem instalacji sondy może być styk sieci wewnętrznych z internetem. Dzięki analizie tej komunikacji uzyskamy nie tylko wiedzę, z kim komunikują się komputery w naszej sieci, co w połączeniu z analizą w module ADS pozwala wykryć komunikację z hostami sklasyfikowanymi jako maszyny rozsyłające spam, będącymi częścią botnetów czy zwyczajnie rozsyłającymi zainfekowane dane, ale także dowiemy się, jaka była treść tej komunikacji. Zebranie tych informacji przyczyni się nie tylko do ochrony naszej sieci, ale również do badania historycznych incydentów i pozwoli określić, skąd zagrożenie przedostało się do sieci, kto był pierwszym zaatakowanym ogniwem naszej sieci i jak atak obejmował kolejne obszary sieci.

Dla klientów mających linie produkcyjne i powiązane z nimi sieci przemysłowe (sieci OT) przydatna może się okazać analiza ruchu wewnątrz tych sieci. Na podstawie analizy netflow z ruchu w takich sieciach da się wykrywać wiele anomalii w nich występujących – np. podłączenie nowego urządzenia do sieci, użycie nowego, dotychczas niewykorzystywanego protokołu czy sposobu komunikacji sieciowej – a nawet wykonywać detekcję uszkodzonych czujników działających w sieci. Po rozszerzeniu instalacji Flowmona w tych sieciach o sondę możemy analizować nie tylko netflow, ale również protokoły charakterystyczne dla tych sieci. Obecnie jest to pięć protokołów przemysłowych, takich jak COAP lub IEC104, ale liczba wspieranych protokołów wciąż rośnie i w najbliższym czasie wprowadzane będą kolejne.

Jeśli na etapie planowania poprawnie przewidzieliśmy, które punkty naszej sieci będziemy monitorować, to nasz system powinien być dobrze wyskalowany i powinniśmy mieć kolektor odpowiedniej pojemności, sondy z odpowiednią liczbą i typem interfejsów do monitorowania ruchu oraz licencje poszczególnych modułów dostosowane do ilości ruchu w sieci. Gorzej, jeśli system do monitoringu został źle zaplanowany i brakuje nam przestrzeni dyskowej na kolektorze, nie monitorujemy za pomocą sond wszystkich punktów sieci, które chcielibyśmy monitorować, a ADS pozwala na analizę tylko części ruchu. Spokojnie – to jedynie niedogodność, którą z czasem rozwiążemy, rozbudowując system. Tak, rozbudowując system, gdyż Flowmon to elastyczne rozwiązanie, łatwe do rozbudowy i skalowania nawet do potrzeb monitorowania bardzo dużych i rozległych sieci.

> DZIAŁANIE KOLEKTORÓW

Jak już zostało powiedziane, kolektor występuje w formie fizycznej maszyny lub wirtualnego urządzenia korzystającego z zasobów wirtualizatora. Kolektor licencjonowany jest na wielkość przestrzeni służącej do gromadzenia logów. Liczba monitorowanych urządzeń czy ilość ruchu nie mają w tej sytuacji znaczenia, liczy się tylko dostępna przestrzeń dyskowa. Oznacza to, że kolektor możemy albo rozbudować, co w przypadku maszyny wirtualnej wiąże się ze zmianą licencji i przypisaniem większych zasobów dyskowych, albo będziemy przechowywali logi z krótszego okresu, niż pierwotnie zakładaliśmy. Jeśli nie doszacowaliśmy liczby potrzebnych sond, nie ma problemu. Sondy są urządzeniami niezależnymi, możemy dowolnie zwiększać ich liczbę i typ, ważne tylko, żebyśmy mogli konfigurować kolejne SPAN/Mirror porty, aby dostarczać z nich ruch do następnych sond. W przypadku modułów Flowmon, takich jak Anomaly Detection System czy Traffic Recorder, rozbudowa systemu odbywa się poprzez rozszerzenie licencji. Wówczas rozbudowa jest najszybsza i najłatwiejsza.

Przy rozbudowie systemu warto wziąć pod uwagę również ekstremalne sytuacje, kiedy infrastruktura może się bardzo rozrosnąć – czy to w wyniku rozwoju firmy, czy połączenia się z inną firmą. Kiedy dochodzi do tak dużego wzrostu, może się okazać, że jedynym sposobem na skalowanie systemu jest zastosowanie architektury rozproszonej (Distributed Architecture). Idea działania modelu DA polega na użyciu wielu (co najmniej dwóch) kolektorów, których zadaniem jest odbieranie i magazynowanie danych z urządzeń sieciowych i sond Flowmon, oraz centralnego kolektora, tzw. Master Collector, służącego do zarządzania nimi i wizualizacji danych na nich zmagazynowanych.

W uproszczony sposób działanie kolektorów w architekturze rozproszonej można zobrazować schematem widocznym na rys. 1. Jak widać, dane są gromadzone na kolektorach działających w poszczególnych oddziałach firmy (na tzw. Slave units), natomiast centralny kolektor – Master unit – komunikuje się z nimi tylko w celu zarządzania danymi i ich wizualizacji. Możliwe są również bardziej skomplikowane modele wdrożeń, w których występuje dodatkowo tzw. Proxy unit, czyli kolektor będący magazynem danych dla wielu mniejszych kolektorów i pośredniczący w zarządzaniu nimi.

Z kolei schemat widoczny na rys. 2 obrazuje mieszany przykład wdrożenia, czyli z bezpośrednim dostępem do Slave units i z wykorzystaniem kolektorów pośredniczących Proxy unit. Jak widać, w obu przykładach środowisko takie jest praktycznie w dowolny sposób skalowalne, a zarządzać nim można zarówno na poziomie centralnym, jak i uzyskując dostęp do lokalnie zgromadzonych danych na kolektorach w oddziałach firmy.

> KONFIGURACJA SYSTEMU

Najprostszym w konfiguracji elementem Flowmona jest sonda. Wdrożenie sondy odbywa się w dosłownie kilku krokach obejmujących konfigurację ogólnych ustawień systemu, takich jak jego nazwa, czas lub serwer czasu, z którego sonda będzie się synchronizowała, oraz konfiguracja ustawień dostępu i haseł dla administratorów. Dalszym krokiem będzie konfiguracja adresów IP, za pomocą których będziemy łączyli się z sondy i z których sonda będzie się komunikowała z kolektorem. Ostatnim krokiem jest konfiguracja interfejsów monitorujących, do których za pomocą SPAN/Mirror portu lub urządzeń TAP będziemy dostarczali kopię ruchu. Ostatnim krokiem jest zdefiniowanie adresów IP odbiorców flowów wraz ze zdefiniowaniem, w jakiej wersji NetFlow lub IPFIX mają być wysyłane dane. Po takiej konfiguracji sonda staje się urządzeniem bezobsługowym, do którego będziemy się logowali tylko wtedy, kiedy będziemy wgrywać nową licencję lub wersję firmware.

Wdrożenie kolektora jest tylko nieco bardziej skomplikowane, bo poza czynnościami związanymi z ogólną konfiguracją systemu, które są takie same jak w przypadku sondy, konfiguracja obejmuje jeszcze sposób zapisywania i przedstawiania ruchu sieciowego w formie statystyk, wykresów, raportów i alarmów. Pierwszą czynnością jest konfiguracja profili, czyli wstępnie przefiltrowanych danych pozwalających na wgląd w interesujące nas statystyki ruchu sieciowego. Profile tworzymy, stosując filtry agregujące ruch określonego typu, np. ruch w ramach zdefiniowanej podsieci, określonego protokołu, portu lub typu usługi. Dzięki temu, że profile dają się łatwo zagnieżdżać, możemy najpierw stworzyć statystyki dla poszczególnych segmentów naszej sieci, a później szczegółowe statystyki ruchu osobno dla każdej z podsieci. Zobaczymy wtedy, w której sieci jest najwięcej ruchu, jakiego typu (protokół, port) jest to ruch oraz kto go generuje.

 

[...]

 

Presales Engineer we Flowmon Networks, gdzie jest odpowiedzialny za projekty związane z monitoringiem i analizą behawioralną ruchu sieciowego oraz monitoringiem aplikacji. Wcześniej doświadczenia zdobywał jako administrator IT, inżynier wsparcia technicznego i team leader. Od lat trener w zakresie administracji systemami z rodziny Microsoft (MCT) i Linux oraz technologii sieciowych. 

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"