<![CDATA[Monitoring Serwerów - Forum o monitoringu infrastruktury IT - Scrutinizer]]> https://monitoringserwerow.pl/ Wed, 06 May 2026 12:31:37 +0000 MyBB <![CDATA[Podatność na ataki DDOS NTP]]> https://monitoringserwerow.pl/showthread.php?tid=48 Tue, 30 Jul 2019 12:29:36 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=48 Atak typu NTP Denial od Service Network Time Protocol Distributed Reflective Denial of Service (NTP DDoS) is atakiem typu Amplification Attack który bazuje na wykorzystaniu powszechnie dostępnych serwerów czasu NTP aby dociążyć system zapytaniami UDP. Protokól NTP tradycyjnie wykorzystuje połączenia UDP na portcie 123 i jednocześnie jest najstarszym protokołem wykorzystywanym do synchronizacji czasu pomiędzy komputerami w sieci.

Cechą szczególną tego ataku, która sprawia, że jest on tak skuteczny jest efekt skali działania. Komenda która jest wysyłana z inicjacją zapytania NTP może zawierać bardzo małą porcję danych, jednak odpowiedź na nią jest wielokrotnie większa. Jest kilka sposobów na wygenerowanie odpowiedniego wzmocnienia dla ataku i najczęstszym jest użycie komendy ‘monlist’ w zapytaniu NTP.
Ta komenda powoduje wysłanie listy ostatnich 600 adresów IP które łączyły się z serwerem NTP do naszego serwera NTP. 
Lista ta jest jednocześnie wynikiem fałszywych połączeń i zawiera adresy atakowanych hostów. 
Zatem formalny atak DDOS jest realizowanych z serwerów NTP, którym została wstrzyknięta lista 600 adresów pochodzących z serwerów publicznych.
[Image: NTP-DDoS.jpg]

Detekcja ataku NTP DDOS
Najszybszym i najtańszym sposobem zrozumienia co się dzieje w naszej sieci jest analiza protokołu Netflow/IPFIX. Monitoring bezpieczeństwa za pomocą Netflow pozwala na obserwację nie tylko aktualnego ruchu, ale także zmian w transmisji. Ta obserwacja zmian jest kluczowa do wykrycia ataku NTP DDOS. Ruch NTP jest wystawiony na świat, ale jego skala nie powinna się zmieniać w perspektywie czasu.

Organizacja The United States Computer Emergency Readiness Team (CERT) zaleca następujące zachowanie w kontekście wykrycia ataku Reflective DDOS. :

“Detekcja ataków DRDOS nie jest prosta, z uwagi na zastosowanie w jego przebiegu dużych i publicznych serwerów udostępniających serwisy UDP. Będąc operatorem systemów pośredniczących w tych atakach należy szczególnie przyjrzeć się anomalią ruchu sieciowego zwłaszcza pod kątem ilościowym. ”

Trudność w spełnieniu tego zalecenia wynika z faktu, że nasze publiczne IP generalnie nie pojawi się na zestawieniu TOP N w analizie DDOS ponieważ skala tego ruchu jest niewielka, jedynie liczba jest większa niż zazwyczaj. W poniższym widoku obserwujemy docelowy system z portem 10Gbps - ruch NTP nie pojawił się w zestawieniu TopN w raporcie paired conversation. - jednak w podsumowaniu aplikacja UDP 123 wyświetlona jest jako Nume 1. 
[Image: NetFlow-DDoS-Detection.png]


NetFlow Security Monitoring

Czy w swojej infrastrukturze sieciowej monitorujesz ruch, co pozwoli Ci uchronić swoje systemy przed takimi i podobnymi atakami UDP DDOS ? Czy weryfikujesz jakie zmiany zachodzą na twoim serwerze NTP aby zatrzymać temu podobne ataki ? 

Jeżeli chciałbyś sprawdzić jak Scrutinizer sprawdzi się w tej sytuacji, daj naj znać.
http://it.emca.pl]]> Atak typu NTP Denial od Service Network Time Protocol Distributed Reflective Denial of Service (NTP DDoS) is atakiem typu Amplification Attack który bazuje na wykorzystaniu powszechnie dostępnych serwerów czasu NTP aby dociążyć system zapytaniami UDP. Protokól NTP tradycyjnie wykorzystuje połączenia UDP na portcie 123 i jednocześnie jest najstarszym protokołem wykorzystywanym do synchronizacji czasu pomiędzy komputerami w sieci.

Cechą szczególną tego ataku, która sprawia, że jest on tak skuteczny jest efekt skali działania. Komenda która jest wysyłana z inicjacją zapytania NTP może zawierać bardzo małą porcję danych, jednak odpowiedź na nią jest wielokrotnie większa. Jest kilka sposobów na wygenerowanie odpowiedniego wzmocnienia dla ataku i najczęstszym jest użycie komendy ‘monlist’ w zapytaniu NTP.
Ta komenda powoduje wysłanie listy ostatnich 600 adresów IP które łączyły się z serwerem NTP do naszego serwera NTP. 
Lista ta jest jednocześnie wynikiem fałszywych połączeń i zawiera adresy atakowanych hostów. 
Zatem formalny atak DDOS jest realizowanych z serwerów NTP, którym została wstrzyknięta lista 600 adresów pochodzących z serwerów publicznych.
[Image: NTP-DDoS.jpg]

Detekcja ataku NTP DDOS
Najszybszym i najtańszym sposobem zrozumienia co się dzieje w naszej sieci jest analiza protokołu Netflow/IPFIX. Monitoring bezpieczeństwa za pomocą Netflow pozwala na obserwację nie tylko aktualnego ruchu, ale także zmian w transmisji. Ta obserwacja zmian jest kluczowa do wykrycia ataku NTP DDOS. Ruch NTP jest wystawiony na świat, ale jego skala nie powinna się zmieniać w perspektywie czasu.

Organizacja The United States Computer Emergency Readiness Team (CERT) zaleca następujące zachowanie w kontekście wykrycia ataku Reflective DDOS. :

“Detekcja ataków DRDOS nie jest prosta, z uwagi na zastosowanie w jego przebiegu dużych i publicznych serwerów udostępniających serwisy UDP. Będąc operatorem systemów pośredniczących w tych atakach należy szczególnie przyjrzeć się anomalią ruchu sieciowego zwłaszcza pod kątem ilościowym. ”

Trudność w spełnieniu tego zalecenia wynika z faktu, że nasze publiczne IP generalnie nie pojawi się na zestawieniu TOP N w analizie DDOS ponieważ skala tego ruchu jest niewielka, jedynie liczba jest większa niż zazwyczaj. W poniższym widoku obserwujemy docelowy system z portem 10Gbps - ruch NTP nie pojawił się w zestawieniu TopN w raporcie paired conversation. - jednak w podsumowaniu aplikacja UDP 123 wyświetlona jest jako Nume 1. 
[Image: NetFlow-DDoS-Detection.png]


NetFlow Security Monitoring

Czy w swojej infrastrukturze sieciowej monitorujesz ruch, co pozwoli Ci uchronić swoje systemy przed takimi i podobnymi atakami UDP DDOS ? Czy weryfikujesz jakie zmiany zachodzą na twoim serwerze NTP aby zatrzymać temu podobne ataki ? 

Jeżeli chciałbyś sprawdzić jak Scrutinizer sprawdzi się w tej sytuacji, daj naj znać.
http://it.emca.pl]]> <![CDATA[Nagios Network Analyzer: Wsparcie dla NetFlow]]> https://monitoringserwerow.pl/showthread.php?tid=47 Tue, 30 Jul 2019 12:25:16 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=47 Nagios jest jednym z najpopularniejszych darmowych narzędzi do monitoringu sieci dostępnych również w wersji komercyjnej. Przez lata społeczność Nagiosa polegała na narzędziach NetFlow Analysis uważając, że jest to najlepsze rozwiązanie. Ostatnio Nick Scott ogłosił, że owszem, Nagios Network Analyzer wspiera NetFlow v5, v7 oraz v9, lecz niestety brak mu wsparcia dla Flexible NetFlow i IPFIX. Co to oznacza?
Wielu producentów w tym Citrix, nBox, Plixer, czy SonicWALL (wkrótce dołączy do nich Cisco) eksportują w swoich flowach takie detale jak URL. Do tego dochodzą szczegóły dotyczące opóźnień, jittera, utraty pakietów, identyfikatora rozmówcy itp. To właśnie z tak szczegółowych danych chce korzystać klient korelując, raportując i filtrując swoje dane. Nagios na tym polu ma wiele do nadrobienia. Zazwyczaj, gdy klienci dowiadują się co można zrobić korzystając z technologii NetFlow, chcą więcej i więcej. Gdy tego nie dostają rozglądają się za innym narzędziem. To dlatego koncentrujemy się tylko na jednej technologii. Analiza NetFlow, IPFIX czy sFlow to wszystko na czym się znamy i robimy najlepiej. Nasza koncentracja na analizie przepływów w sieci poprowadziła nas do sukcesu i dalszego rozwoju firmy.
Jako przykład weźmy nasz product Cisco Performance Monitoring (Medianet). Nie tylko dostarcza szczegółowych danych dotyczących całego ruchu opartego o protokół TCP (np. usługi chmurowe) jak również o protokół UDP, takich jak voice, strumieniowanie video ale również pozwala na szybkie diagnozowanie takich chociażby zdarzeń jak przycinająca się transmisja video. Do tej pory NetFlow tego nie potrafił. Dzięki nam jest to już możliwe.

[Image: scrutinizer1.png]

Myślę, że warta wzmianki jest nasza obecność na stronach Cisco w dziale Performance Routing.
Firmy takie jak Dell czy Uptime Devices kupują naszego analizatora NetFlow i IPFIx ponieważ wiedzą, że dostają to, co najlepsze na rynku od firmy, która nie rozmienia się na drobne próbując włączać do swej oferty takie technologie jak na przykład SNMP. Nie można być dobrym we wszystkim, więc my skupiamy się tylko na jednej technologii - NetFlow. Nimsoft oraz Zenoss polecają naszego Scrutinizera ponieważ skupiają się na monitoringu sieci. Nasz produkt jest na tyle otwarty, że umożliwia bezproblemową integrację z rozwiązaniami firm trzecich. Umożliwiamy to przez proste użycie URL i zapytania do bazy danych.
Integracja naszego produktu z Nagiosem jest łatwa w konfiguracji oraz zapewnia najlepsze wsparcie dla sFlow, IPFIX i NetFlow. Jeżeli chcesz aby Twój Nagios wspierał NetFlow wybierz Scrutinizer NetFlow Analyzer.

Brian@Plixer]]> Nagios jest jednym z najpopularniejszych darmowych narzędzi do monitoringu sieci dostępnych również w wersji komercyjnej. Przez lata społeczność Nagiosa polegała na narzędziach NetFlow Analysis uważając, że jest to najlepsze rozwiązanie. Ostatnio Nick Scott ogłosił, że owszem, Nagios Network Analyzer wspiera NetFlow v5, v7 oraz v9, lecz niestety brak mu wsparcia dla Flexible NetFlow i IPFIX. Co to oznacza?
Wielu producentów w tym Citrix, nBox, Plixer, czy SonicWALL (wkrótce dołączy do nich Cisco) eksportują w swoich flowach takie detale jak URL. Do tego dochodzą szczegóły dotyczące opóźnień, jittera, utraty pakietów, identyfikatora rozmówcy itp. To właśnie z tak szczegółowych danych chce korzystać klient korelując, raportując i filtrując swoje dane. Nagios na tym polu ma wiele do nadrobienia. Zazwyczaj, gdy klienci dowiadują się co można zrobić korzystając z technologii NetFlow, chcą więcej i więcej. Gdy tego nie dostają rozglądają się za innym narzędziem. To dlatego koncentrujemy się tylko na jednej technologii. Analiza NetFlow, IPFIX czy sFlow to wszystko na czym się znamy i robimy najlepiej. Nasza koncentracja na analizie przepływów w sieci poprowadziła nas do sukcesu i dalszego rozwoju firmy.
Jako przykład weźmy nasz product Cisco Performance Monitoring (Medianet). Nie tylko dostarcza szczegółowych danych dotyczących całego ruchu opartego o protokół TCP (np. usługi chmurowe) jak również o protokół UDP, takich jak voice, strumieniowanie video ale również pozwala na szybkie diagnozowanie takich chociażby zdarzeń jak przycinająca się transmisja video. Do tej pory NetFlow tego nie potrafił. Dzięki nam jest to już możliwe.

[Image: scrutinizer1.png]

Myślę, że warta wzmianki jest nasza obecność na stronach Cisco w dziale Performance Routing.
Firmy takie jak Dell czy Uptime Devices kupują naszego analizatora NetFlow i IPFIx ponieważ wiedzą, że dostają to, co najlepsze na rynku od firmy, która nie rozmienia się na drobne próbując włączać do swej oferty takie technologie jak na przykład SNMP. Nie można być dobrym we wszystkim, więc my skupiamy się tylko na jednej technologii - NetFlow. Nimsoft oraz Zenoss polecają naszego Scrutinizera ponieważ skupiają się na monitoringu sieci. Nasz produkt jest na tyle otwarty, że umożliwia bezproblemową integrację z rozwiązaniami firm trzecich. Umożliwiamy to przez proste użycie URL i zapytania do bazy danych.
Integracja naszego produktu z Nagiosem jest łatwa w konfiguracji oraz zapewnia najlepsze wsparcie dla sFlow, IPFIX i NetFlow. Jeżeli chcesz aby Twój Nagios wspierał NetFlow wybierz Scrutinizer NetFlow Analyzer.

Brian@Plixer]]> <![CDATA[Open vSwitch NetFlow]]> https://monitoringserwerow.pl/showthread.php?tid=46 Tue, 30 Jul 2019 12:23:33 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=46 Włączenie usługi NetFlow na OpenvSwitch umożliwia monitorowanie wchodzącego i wychodzącego ruchu sieciowego zarówno na wirtualnym przełączniku ( vSwitchu) jak również pomiędzy wirtualnymi maszynami. Biorąc pod uwagę liczne korzyści związane z technologią IP flow, virtual switch NetFlow nie tylko w znacznym stopniu ułatwia zabezpieczenie wirtualnego środowiska, ale dostarcza również platformę do analizy, diagnostyki i troubleshootingu sieci w zwirtualizowanej sieci.

Gwoli przypomnienia - NetFlow, IPFIX oraz sFlow to protokoły zbierające dane o ruchu sieciowym. Protokoły te są szeroko wspierane przez wszystkich producentów aktywnych urządzeń sieci. Jeżeli chodzi o wirtualne przełączniki to NetFlow jest stosunkowo nowym rozwiązaniem biorąc pod uwagę to, jak długo istnieje IP flow. Ale od kilku lat obserwujemy wzrost jego implementacji, ponieważ coraz więcej osób uświadamia sobie jak ważny jest monitoring i analiza ruchu wirtualnej infrastruktury.

Do podstawowych danych eksportowanych do NetFlow lub IPFIX należą: adres źródłowy IP, adres docelowy IP, port źródłowy, port docelowy, protokół, użycie łącza, numery systemów autonomicznych, klasy usług itp. Dlatego w środowisku wirtualnym, NetFlow ujawnia kto, co, kiedy, gdzie i jak kształtuje się ruch sieciowy generowany przez wirtualne maszyny. Używając analizatorów NetFlow i IPFIX można zwizualizować wszystkie szczegóły dotyczące przepływu w sieci i analizować:
• Ruch pomiędzy maszynami wirtualnymi umieszczonymi na tym samym hoście,
• Ruch pomiędzy maszynami wirtualnymi znajdującymi się na innych hostach,
• Ruch z maszyny wirtualnej do innych, nie wirtualnych maszyn.

Co więcej, można również:
• Przechowywać dane historyczne zebranych statystyk
• Generować raporty i wysyłać je do określonych odbiorców
• Dokonywać behawioralnych analiz ruchu 
• Wykrywać potencjalne zagrożenia

Załóżmy, że adres IP naszego kolektora NetFlow i sFlow to 10.10.10.10 i że nasłuchuje on na porcie 2055. Oto, jak szybko uruchomić OpenvSwitch IPFIX, OpenvSwitch NetFlow oraz OpenvSwitch sFlow:

IPFIX: Konfiguracja mostu br0, aby wysyłał jeden IPFIX flow record na próbkę do hosta 10.10.10.10 na port 2055. Observation Domain ID 123, Observation Point ID456.

KOD: ZAZNACZ CAŁY
Code:
ovs−vsctl − − set Bridge br0 ipfix=@i −− −−id=@i create IPFIX targets=\”10.10.10.10:2055\” obs_domain_id=123 obs_point_id=456


NETFLOW: Konfiguracja mostu br0, aby wysyłał NetFlow do maszyny 10.10.10.10 na port UDP 2055 z uwzględnieniem active-timeout 60 sekund. 

KOD: ZAZNACZ CAŁY
Code:
ovs−vsctl − − set Bridge br0 netflow=@nf −− −−id=@nf create NetFlow targets=\”10.10.10.10:2055\” active−timeout=60

Timeout musi być ustawiony na 60 sekund ponieważ analizator NetFlow spodziewa się danych przychodzących co minutę.

SFLOW: Konfiguracja mostu br0 wysyłającego dane sFlow do maszyny 10.10.10.10 na port 2055 używając adresu IP interfejsu eth1 jako źródła z określonymi parametrami próbki.

KOD: ZAZNACZ CAŁY
Code:
ovs−vsctl – -id=@s create sFlow agent=eth1 target=\”10.10.10.10:2055\” header=128 sampling=64 polling=10 \ −− set Bridge br0 sflow=@s


Open vSwitch jest wspierany przez kilka platform wirtualizacyjnych włączając w to XenServer 6.0 i Xen Cloud. Jest on zintegrowany z takimi systemami zarządzania wirtualizacją jak openQRM, OpenStack oraz oVirt. Istnieją pakiety instalacyjne dla Ubuntu, Debiana i Fedory.

Więcej informacji dotyczących konfiguracji OpenvSwitch Netflow można uzyskać na stronie Open vSwitch lub kontaktując się z nami.

Danny@plixer]]> Włączenie usługi NetFlow na OpenvSwitch umożliwia monitorowanie wchodzącego i wychodzącego ruchu sieciowego zarówno na wirtualnym przełączniku ( vSwitchu) jak również pomiędzy wirtualnymi maszynami. Biorąc pod uwagę liczne korzyści związane z technologią IP flow, virtual switch NetFlow nie tylko w znacznym stopniu ułatwia zabezpieczenie wirtualnego środowiska, ale dostarcza również platformę do analizy, diagnostyki i troubleshootingu sieci w zwirtualizowanej sieci.

Gwoli przypomnienia - NetFlow, IPFIX oraz sFlow to protokoły zbierające dane o ruchu sieciowym. Protokoły te są szeroko wspierane przez wszystkich producentów aktywnych urządzeń sieci. Jeżeli chodzi o wirtualne przełączniki to NetFlow jest stosunkowo nowym rozwiązaniem biorąc pod uwagę to, jak długo istnieje IP flow. Ale od kilku lat obserwujemy wzrost jego implementacji, ponieważ coraz więcej osób uświadamia sobie jak ważny jest monitoring i analiza ruchu wirtualnej infrastruktury.

Do podstawowych danych eksportowanych do NetFlow lub IPFIX należą: adres źródłowy IP, adres docelowy IP, port źródłowy, port docelowy, protokół, użycie łącza, numery systemów autonomicznych, klasy usług itp. Dlatego w środowisku wirtualnym, NetFlow ujawnia kto, co, kiedy, gdzie i jak kształtuje się ruch sieciowy generowany przez wirtualne maszyny. Używając analizatorów NetFlow i IPFIX można zwizualizować wszystkie szczegóły dotyczące przepływu w sieci i analizować:
• Ruch pomiędzy maszynami wirtualnymi umieszczonymi na tym samym hoście,
• Ruch pomiędzy maszynami wirtualnymi znajdującymi się na innych hostach,
• Ruch z maszyny wirtualnej do innych, nie wirtualnych maszyn.

Co więcej, można również:
• Przechowywać dane historyczne zebranych statystyk
• Generować raporty i wysyłać je do określonych odbiorców
• Dokonywać behawioralnych analiz ruchu 
• Wykrywać potencjalne zagrożenia

Załóżmy, że adres IP naszego kolektora NetFlow i sFlow to 10.10.10.10 i że nasłuchuje on na porcie 2055. Oto, jak szybko uruchomić OpenvSwitch IPFIX, OpenvSwitch NetFlow oraz OpenvSwitch sFlow:

IPFIX: Konfiguracja mostu br0, aby wysyłał jeden IPFIX flow record na próbkę do hosta 10.10.10.10 na port 2055. Observation Domain ID 123, Observation Point ID456.

KOD: ZAZNACZ CAŁY
Code:
ovs−vsctl − − set Bridge br0 ipfix=@i −− −−id=@i create IPFIX targets=\”10.10.10.10:2055\” obs_domain_id=123 obs_point_id=456


NETFLOW: Konfiguracja mostu br0, aby wysyłał NetFlow do maszyny 10.10.10.10 na port UDP 2055 z uwzględnieniem active-timeout 60 sekund. 

KOD: ZAZNACZ CAŁY
Code:
ovs−vsctl − − set Bridge br0 netflow=@nf −− −−id=@nf create NetFlow targets=\”10.10.10.10:2055\” active−timeout=60

Timeout musi być ustawiony na 60 sekund ponieważ analizator NetFlow spodziewa się danych przychodzących co minutę.

SFLOW: Konfiguracja mostu br0 wysyłającego dane sFlow do maszyny 10.10.10.10 na port 2055 używając adresu IP interfejsu eth1 jako źródła z określonymi parametrami próbki.

KOD: ZAZNACZ CAŁY
Code:
ovs−vsctl – -id=@s create sFlow agent=eth1 target=\”10.10.10.10:2055\” header=128 sampling=64 polling=10 \ −− set Bridge br0 sflow=@s


Open vSwitch jest wspierany przez kilka platform wirtualizacyjnych włączając w to XenServer 6.0 i Xen Cloud. Jest on zintegrowany z takimi systemami zarządzania wirtualizacją jak openQRM, OpenStack oraz oVirt. Istnieją pakiety instalacyjne dla Ubuntu, Debiana i Fedory.

Więcej informacji dotyczących konfiguracji OpenvSwitch Netflow można uzyskać na stronie Open vSwitch lub kontaktując się z nami.

Danny@plixer]]> <![CDATA[Firewalle Palo Alto Networks]]> https://monitoringserwerow.pl/showthread.php?tid=45 Tue, 30 Jul 2019 12:21:25 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=45 Najnowszej generacji firewalle Palo Alto Networks posiadają eksporty protokołu Netflow umożliwiające firmom IT monitoring dostępu do sieci poprzez identyfikację typu danych przechodzących przez tą sieć.
Ostatnio podczas rozmowy z Brianem Davenportem, naszym kierownikiem sprzedaży na Środkowy Zachód dyskutowaliśmy o naprawdę fantastycznej sprawie jaką jest application visibility, technologii dostarczanej przez Palo Alto Networks. Pomyśleliśmy, że warto wspomnieć na naszym blogu o niektórych jej aspektach.
Wykorzystując eksporty protokołu Netflow dostępne na firewallach Palo Alto, można tworzyć raporty przydatne w monitoringu dostępu do sieci, aby:
Identyfikować aplikacje oraz najbardziej aktywnych użytkowników sieci
Urządzenia Palo Alto przeprowadzają głęboką analizę pakietów w celu zidentyfikowania takich aplikacji jak Skype, BitTorrent, Webex i wielu innych. Dzięki temu można stosować dynamiczne filtry pokazujące specyficznego użytkownika, czy też aplikację.

[Image: paloaltlo1.png]

Tworzyć raporty dotyczące Network Address Translations (NAT)

Dzięki korelacji pomiędzy prywatnym adresem IP użytkownika oraz adresem publicznym, można uzyskać wgląd w to, kto komunikuje się z jakimi usługami.

[Image: paloaltlo2.png]

Generować dynamicznie raporty oraz filtry dotyczące dowolnego rodzaju ruchu w sieci

Ponad 100 predefiniowanych filtrów daje możliwość dotarcia do poszukiwanej informacji za pomocą jednego lub dwóch kliknięć myszką.
Za ich pomocą można:
• Sprawdzać zachowanie się ruchu w dowolnym przedziale czasowym
• Rozwiązać „stare” problemy
• Wiedzieć kto, co, gdzie i jak często
• Tworzyć spersonalizowane raporty dostosowane do potrzeb.

Aktywnie monitorować ruch wyłapując ataki DoS, skanowanie portów lub inne zagrożenia płynące z Internetu

Dzięki Flow Analytics™ można tworzyć alarmy automatycznie uruchamiane przy wykryciu wirusów, skanowaniu portów, czy łączeniu się z hostami znajdującymi się na „czarnej liście”. To samo dotyczy także ataków DoS. Alarmy, raz zainicjowane, natychmiast zidentyfikują napastnika jeżeli zechce ponownie zaatakować naszą sieć.

NetFlow uzupełnia analizę pakietów oraz narzędzia SIM (Security information and event management)

Używając zaawansowanych możliwości raportowania NetFlow z łatwością można analizować interesujący nas ruch sieciowy bez używania bardziej skomplikowanych, a co za tym idzie bardziej zasobo i czasożernych aplikacji.

A więc czego się dowiedzieliśmy?

Raportowanie NetFlow na firewallach Palo Alto Networks zapewnia:
• Widoczność aplikacji oraz użytkowników.
• Monitorowanie stopnia użycia aplikacji.
• Analizę zachowania się ruchu w sieci oraz tworzenie alarmów.
• Planowanie ruchu w sieci.
• Tworzenie spersonalizowanych raportów.
Większość firm tworzących firewalle implementuje NetFlow w swoich rozwiązaniach. Pytane tylko, jakiej widoczności Ty potrzebujesz?

Scott Robertson@plixer]]> Najnowszej generacji firewalle Palo Alto Networks posiadają eksporty protokołu Netflow umożliwiające firmom IT monitoring dostępu do sieci poprzez identyfikację typu danych przechodzących przez tą sieć.
Ostatnio podczas rozmowy z Brianem Davenportem, naszym kierownikiem sprzedaży na Środkowy Zachód dyskutowaliśmy o naprawdę fantastycznej sprawie jaką jest application visibility, technologii dostarczanej przez Palo Alto Networks. Pomyśleliśmy, że warto wspomnieć na naszym blogu o niektórych jej aspektach.
Wykorzystując eksporty protokołu Netflow dostępne na firewallach Palo Alto, można tworzyć raporty przydatne w monitoringu dostępu do sieci, aby:
Identyfikować aplikacje oraz najbardziej aktywnych użytkowników sieci
Urządzenia Palo Alto przeprowadzają głęboką analizę pakietów w celu zidentyfikowania takich aplikacji jak Skype, BitTorrent, Webex i wielu innych. Dzięki temu można stosować dynamiczne filtry pokazujące specyficznego użytkownika, czy też aplikację.

[Image: paloaltlo1.png]

Tworzyć raporty dotyczące Network Address Translations (NAT)

Dzięki korelacji pomiędzy prywatnym adresem IP użytkownika oraz adresem publicznym, można uzyskać wgląd w to, kto komunikuje się z jakimi usługami.

[Image: paloaltlo2.png]

Generować dynamicznie raporty oraz filtry dotyczące dowolnego rodzaju ruchu w sieci

Ponad 100 predefiniowanych filtrów daje możliwość dotarcia do poszukiwanej informacji za pomocą jednego lub dwóch kliknięć myszką.
Za ich pomocą można:
• Sprawdzać zachowanie się ruchu w dowolnym przedziale czasowym
• Rozwiązać „stare” problemy
• Wiedzieć kto, co, gdzie i jak często
• Tworzyć spersonalizowane raporty dostosowane do potrzeb.

Aktywnie monitorować ruch wyłapując ataki DoS, skanowanie portów lub inne zagrożenia płynące z Internetu

Dzięki Flow Analytics™ można tworzyć alarmy automatycznie uruchamiane przy wykryciu wirusów, skanowaniu portów, czy łączeniu się z hostami znajdującymi się na „czarnej liście”. To samo dotyczy także ataków DoS. Alarmy, raz zainicjowane, natychmiast zidentyfikują napastnika jeżeli zechce ponownie zaatakować naszą sieć.

NetFlow uzupełnia analizę pakietów oraz narzędzia SIM (Security information and event management)

Używając zaawansowanych możliwości raportowania NetFlow z łatwością można analizować interesujący nas ruch sieciowy bez używania bardziej skomplikowanych, a co za tym idzie bardziej zasobo i czasożernych aplikacji.

A więc czego się dowiedzieliśmy?

Raportowanie NetFlow na firewallach Palo Alto Networks zapewnia:
• Widoczność aplikacji oraz użytkowników.
• Monitorowanie stopnia użycia aplikacji.
• Analizę zachowania się ruchu w sieci oraz tworzenie alarmów.
• Planowanie ruchu w sieci.
• Tworzenie spersonalizowanych raportów.
Większość firm tworzących firewalle implementuje NetFlow w swoich rozwiązaniach. Pytane tylko, jakiej widoczności Ty potrzebujesz?

Scott Robertson@plixer]]> <![CDATA[Generowanie Netflow z Windows]]> https://monitoringserwerow.pl/showthread.php?tid=44 Tue, 30 Jul 2019 12:18:18 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=44 Typowym zastosowaniem analizatora Scrutinizer jest uruchomienie go we współpracy z zarządzalnymi routerami Cisco oraz switchami. Czasami jednak z różnych przyczyn chcemy zaobserwować ruch pochodzący z pojedynczej stacji. Takim przykładem jest konieczność analizy ruchu sieciowego serwerów kolokowanych w obcej infrastrukturze, gdzie nie mamy dostępu do urządzeń sieciowych.

Zajmijmy się monitoringiem ruchu sieciowego z typowego serwera Windows. ( Unixy i Linuxy zadziałają na tej samej zasadzie )

To co jest nam potrzebne, to program generujący nam informacje netflow na bazie analizy lokalnych portów sieciowych Windowsa. Do tego celu użyjemy popularnego projektu nProbe.
http://www.ntop.org/products/nprobe/

Nprobe jest projektem darmowym, rozpowszechnianym na licencji GPL, jednak za funkcjonalną wersję dla Windows musimy kilka euro zapłacić. Na szczęście na nasze potrzeby możemy wykorzystać wersję demo.

Zainstalowany nProbe jeszcze nie wykonuje dla nas żadnej pracy. Konfigurację przeprowadzimy z poziomu linii poleceń.

Komenda
KOD: ZAZNACZ CAŁY
Code:
nprobe /c -h

wyświetla nam opis wykorzystania.

Warto wyświetlić sobie pomoc, ponieważ musimy zanotować numer interfejsu z którego chcemy raportować ruch. Jest to sekcja mniej więcej wyglądająca tak:

[Image: nprobe_help.png]

W moim przypadku interesuje mnie interfejs numer 6.
Komenda :
KOD: ZAZNACZ CAŁY
Code:
nprobe /i nprobe_service --collector 10.4.4.115:2055 --interface 6 --flow-version 5 --lifetime-timeout 60 --idle-timeout 15

utworzy dla nas serwis w konfiguracji windowsa, który będzie odpowiedzialny za generowanie informacji na potrzeby Scrutinizera.

[Image: service.png]

Najważniejsze opcje:
/i nprobe_service - instalacja serwisu o nazwie nprobe_service
--collector - adres maszyny z aplikacją Scrutinizer
--interface - numer interfejsu sieciowego windowsa do raportowania

W wyniku naszej pracy Scrutinizer zgłosi nam nowy interfejs jako Netflow Exporter

[Image: windows_exporter.png]

a stąd już tylko krok do generowania interesujących nas statystyk z nowego źródła danych.

[Image: windows_station_report.png]

Na koniec, skoro pokazałem jak założyć serwis, to jeszcze zobaczmy jak po sobie posprzątać. Kasowanie serwisu:

KOD: ZAZNACZ CAŁY
Code:
nprobe /r nprobe_service


Pełna dokumentacja nProbe
http://www.nmon.net/UsersGuide.pdf]]> Typowym zastosowaniem analizatora Scrutinizer jest uruchomienie go we współpracy z zarządzalnymi routerami Cisco oraz switchami. Czasami jednak z różnych przyczyn chcemy zaobserwować ruch pochodzący z pojedynczej stacji. Takim przykładem jest konieczność analizy ruchu sieciowego serwerów kolokowanych w obcej infrastrukturze, gdzie nie mamy dostępu do urządzeń sieciowych.

Zajmijmy się monitoringiem ruchu sieciowego z typowego serwera Windows. ( Unixy i Linuxy zadziałają na tej samej zasadzie )

To co jest nam potrzebne, to program generujący nam informacje netflow na bazie analizy lokalnych portów sieciowych Windowsa. Do tego celu użyjemy popularnego projektu nProbe.
http://www.ntop.org/products/nprobe/

Nprobe jest projektem darmowym, rozpowszechnianym na licencji GPL, jednak za funkcjonalną wersję dla Windows musimy kilka euro zapłacić. Na szczęście na nasze potrzeby możemy wykorzystać wersję demo.

Zainstalowany nProbe jeszcze nie wykonuje dla nas żadnej pracy. Konfigurację przeprowadzimy z poziomu linii poleceń.

Komenda
KOD: ZAZNACZ CAŁY
Code:
nprobe /c -h

wyświetla nam opis wykorzystania.

Warto wyświetlić sobie pomoc, ponieważ musimy zanotować numer interfejsu z którego chcemy raportować ruch. Jest to sekcja mniej więcej wyglądająca tak:

[Image: nprobe_help.png]

W moim przypadku interesuje mnie interfejs numer 6.
Komenda :
KOD: ZAZNACZ CAŁY
Code:
nprobe /i nprobe_service --collector 10.4.4.115:2055 --interface 6 --flow-version 5 --lifetime-timeout 60 --idle-timeout 15

utworzy dla nas serwis w konfiguracji windowsa, który będzie odpowiedzialny za generowanie informacji na potrzeby Scrutinizera.

[Image: service.png]

Najważniejsze opcje:
/i nprobe_service - instalacja serwisu o nazwie nprobe_service
--collector - adres maszyny z aplikacją Scrutinizer
--interface - numer interfejsu sieciowego windowsa do raportowania

W wyniku naszej pracy Scrutinizer zgłosi nam nowy interfejs jako Netflow Exporter

[Image: windows_exporter.png]

a stąd już tylko krok do generowania interesujących nas statystyk z nowego źródła danych.

[Image: windows_station_report.png]

Na koniec, skoro pokazałem jak założyć serwis, to jeszcze zobaczmy jak po sobie posprzątać. Kasowanie serwisu:

KOD: ZAZNACZ CAŁY
Code:
nprobe /r nprobe_service


Pełna dokumentacja nProbe
http://www.nmon.net/UsersGuide.pdf]]> <![CDATA[Tworzenie raportów wydajności sieci]]> https://monitoringserwerow.pl/showthread.php?tid=43 Tue, 30 Jul 2019 12:10:22 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=43 Najczęstszym pytaniem jakie dostaję podczas wdrażania narzędzia Scrutinizer jest "Jak mogę stworzyć raport pokazujący wydajność mojej sieci" ? Napiszę kilka wskazówek jak poruszać się pomiędzy danymi Netflow i jak z nich czerpać informacje których oczekujemy.

[Image: network-traffic-monitoring_default24-hour.png]

W pierwszym kroku tworzenia raportów musimy przejść do zakładki "Status". Ukarze się nam lista interfejsów, posortowanych według obciążenia. To jest według mnie najlepsze miejsce do rozpoczęcia pracy z raportami.
Z zakładki Status wybieramy interfejs, z którego chcemy raportować. Wybierzmy wzór "Default 24 Hour Report (Jeżeli otrzymasz pytanie o template, wybierz All Templates > Default 24 Hour Report).

Po wybraniu opcji Default 24-Hour Report pojawi się zestawienie ruchu Pair >> Conversation WKP ( Well-Known Port) dla ostatnich 24 godzin.

Zawężanie ilości informacji 
Skoro już mamy podstawowy raport utworzony z danego interfejsu dla ostatnich 24 godzin to zastanówmy się jak doszukać się informacji bardziej szczegółowych. Pokarzę teraz opcje filtrowania, które możemy obejrzeć z lewej strony ekranu powyżej : Current Filter.
Jeżeli wybierzesz tę opcję to zobaczysz w jaki sposób na wcześniejszy wykres możemy nałożyć dodatkowe kryteria. To jest miejsce gdzie możemy dodać lub odjąć kryterium.
Wyobraźmy sobie, że interesuje mnie raport z wyłączeniem ruchu z mojego adresu IP. Wybierzmy kryterium IP Host i wciśnijmy zielony znak plus (+), który teraz zamieni się na czerwony minus (-) . Poprzez wybór niebieskiego znaku plus (+) pozwoli nam na wpisanie adresu IP którego ruch będzie usunięty z raportu.

Na ekranie zobaczymy nowy wykres, uwzględniający kryteria filtracji.

[Image: network-traffic-monitoring_filtered-report1-300x110.png]

Jeśli chcemy dojść do jeszcze większych szczegółów wystarczy abyśmy najechali myszką na wykres. Zaznaczając myszką czas, który chcemy dokładniej przeanalizować wykres automatycznie zostanie wyskalowany, prezentując bardziej szczegółowe dane. Ta metoda doskonale nadaje się do obserwacji ruchu w okolicach szczytów i anomalii wykresów.

Innym sposobem na na uzyskanie szczegółowych wykresów jest zmiana częstotliwości próbkowania. Standardem dla wykresu typu 24 godziny jest interwał 30 minut, ale z łatwością możemy to zmienić na 1 minutę. Raport 1 minutowy dostarcza wszystkich informacji w zadanym oknie czasowym. Pamiętajmy jednak, że ten typ raportu będzie większym obciążeniem dla zasobów serwera.

[Image: network-traffic-monitoring_data-granularity.png]

Zapisywanie Raportów
Skoro już wiemy jak tworzyć raporty, spróbujmy je zapisać. Aby to zrobić, wystarczy nadać nazwę naszemu raportowi i wcisnąć świecącą dyskietkę po lewej stronie okna. Jeżeli będziemy potrzebowali tego raportu w przyszłości, wybieramy go z pozycji "Saved reports" u dołu strony.

Jak widzicie, tworzenie i filtrowanie raportów jest na prawdę proste o bardzo elastyczne. Jeżeli będziecie nadal mieli z tym problem, piszcie do nas...

Artur Bicki]]> Najczęstszym pytaniem jakie dostaję podczas wdrażania narzędzia Scrutinizer jest "Jak mogę stworzyć raport pokazujący wydajność mojej sieci" ? Napiszę kilka wskazówek jak poruszać się pomiędzy danymi Netflow i jak z nich czerpać informacje których oczekujemy.

[Image: network-traffic-monitoring_default24-hour.png]

W pierwszym kroku tworzenia raportów musimy przejść do zakładki "Status". Ukarze się nam lista interfejsów, posortowanych według obciążenia. To jest według mnie najlepsze miejsce do rozpoczęcia pracy z raportami.
Z zakładki Status wybieramy interfejs, z którego chcemy raportować. Wybierzmy wzór "Default 24 Hour Report (Jeżeli otrzymasz pytanie o template, wybierz All Templates > Default 24 Hour Report).

Po wybraniu opcji Default 24-Hour Report pojawi się zestawienie ruchu Pair >> Conversation WKP ( Well-Known Port) dla ostatnich 24 godzin.

Zawężanie ilości informacji 
Skoro już mamy podstawowy raport utworzony z danego interfejsu dla ostatnich 24 godzin to zastanówmy się jak doszukać się informacji bardziej szczegółowych. Pokarzę teraz opcje filtrowania, które możemy obejrzeć z lewej strony ekranu powyżej : Current Filter.
Jeżeli wybierzesz tę opcję to zobaczysz w jaki sposób na wcześniejszy wykres możemy nałożyć dodatkowe kryteria. To jest miejsce gdzie możemy dodać lub odjąć kryterium.
Wyobraźmy sobie, że interesuje mnie raport z wyłączeniem ruchu z mojego adresu IP. Wybierzmy kryterium IP Host i wciśnijmy zielony znak plus (+), który teraz zamieni się na czerwony minus (-) . Poprzez wybór niebieskiego znaku plus (+) pozwoli nam na wpisanie adresu IP którego ruch będzie usunięty z raportu.

Na ekranie zobaczymy nowy wykres, uwzględniający kryteria filtracji.

[Image: network-traffic-monitoring_filtered-report1-300x110.png]

Jeśli chcemy dojść do jeszcze większych szczegółów wystarczy abyśmy najechali myszką na wykres. Zaznaczając myszką czas, który chcemy dokładniej przeanalizować wykres automatycznie zostanie wyskalowany, prezentując bardziej szczegółowe dane. Ta metoda doskonale nadaje się do obserwacji ruchu w okolicach szczytów i anomalii wykresów.

Innym sposobem na na uzyskanie szczegółowych wykresów jest zmiana częstotliwości próbkowania. Standardem dla wykresu typu 24 godziny jest interwał 30 minut, ale z łatwością możemy to zmienić na 1 minutę. Raport 1 minutowy dostarcza wszystkich informacji w zadanym oknie czasowym. Pamiętajmy jednak, że ten typ raportu będzie większym obciążeniem dla zasobów serwera.

[Image: network-traffic-monitoring_data-granularity.png]

Zapisywanie Raportów
Skoro już wiemy jak tworzyć raporty, spróbujmy je zapisać. Aby to zrobić, wystarczy nadać nazwę naszemu raportowi i wcisnąć świecącą dyskietkę po lewej stronie okna. Jeżeli będziemy potrzebowali tego raportu w przyszłości, wybieramy go z pozycji "Saved reports" u dołu strony.

Jak widzicie, tworzenie i filtrowanie raportów jest na prawdę proste o bardzo elastyczne. Jeżeli będziecie nadal mieli z tym problem, piszcie do nas...

Artur Bicki]]> <![CDATA[Konfiguracja NetFlow na CISCO 6500 Sup2T]]> https://monitoringserwerow.pl/showthread.php?tid=42 Tue, 30 Jul 2019 12:08:12 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=42 Ponieważ Cisco 6500 Supervisor Engine 2T eksportuje Flexible NetFlow, konfiguracja używana w starszym modelu 6509 NetFlow nie jest niestety kompatybilna. W tym wpisie zostanie omówiona instalacja właśnie nowej wersji routera.

[Image: how-to-configure-cisco-6500-sup2t-netflow-300x150.png]

Wstęp

Instrukcja dotyczy wersji 15 IOS-a Cisco. W tej wersji eksporter NetFlow zlicza jedynie pakiety typu „CEF-switched”. Pakiety typu „transit-switched” oraz ruch generowany lokalnie nie są zliczane. Instalacja składa się z czterech zasadniczych komponentów: konfiguracja rekordu NetFlow, eksporter Flow, monitor Flow, implementacja Flow monitora.

Konfiguracja rekordu NetFlow

Podczas instalacji routera jest możliwość wyboru pomiędzy predefiniowanym rekordem NetFlow lub stworzeniem własnego. Ten pierwszy emuluje NefFlow v9 i jego konfiguracja jest szybka. Jeśli natomiast zdecydujesz się na własną konfigurację, zyskasz możliwość eksportowania dodatkowych informacji takich jak Cisco Medianet Performance Monitoring, Cisco NetFlow NBAR (rozpoznawanie aplikacji oparte na sieci) oraz MAC adresy. W tym przykładzie użyjemy akurat predefiniowanego rekordu, a zainteresowanych jego zindywidualizowaną wersją odsyłamy do przykładów.

Konfiguracja eksportera NetFlow

Flow eksporter w Cisco 6500 SupT2 „mówi” ruterowi gdzie ma wysyłać dane NetFlow. W poniższym przykładzie należy zmienić docelowe IP oraz prawdopodobnie interfejs źródła

KOD: ZAZNACZ CAŁY
Code:
!

configure terminal

flow exporter scrutinizer

description Exports to Scrutinizer

destination 10.1.1.1

source loopback0

template data timeout 60

transport udp 2055

end

!


Konfiguracja Flow Monitora

Monitor Flow tworzy cache danych NetFlow, który urządzenie wykorzystuje do ich gromadzenia. Funkcją Flow Monitora jest również „spięcie” rekordu NetFlow z eksporterem Flow. W bieżącej wersji rutera Cisco wielkość cache-u została powiększona, by uniknąć problemów napotykanych w poprzedniej jego wersji.

KOD: ZAZNACZ CAŁY
Code:
!

configure terminal

flow monitor netflow-original

description This flow monitor uses the NetFlow original
record and exports to Scrutinizer

record netflow-original

cache timeout active 60

exporter scrutinizer

end

!


Implementacja Flow Monitora w interfejsie

Finalnym krokiem jest implementacja flow monitora w interfejsach, które zamierzasz monitorować. Poniższy fragment kodu należy powtórzyć wymaganą ilość razy.

KOD: ZAZNACZ CAŁY
Code:
!

configure terminal

interface ethernet 0/0

ip flow monitor netflow-original input

end

!


Narzędzie do raportowania z wykorzystaniem Cisco 6500 Sup2T NetFlow
NetFlow Scrutinizer jest wydajnym narzędziem do raportowania m.in. na omawianym tu ruterze. Zapraszamy do wypróbowania produktu przez okres testowy.

Paul@PLIXER]]> Ponieważ Cisco 6500 Supervisor Engine 2T eksportuje Flexible NetFlow, konfiguracja używana w starszym modelu 6509 NetFlow nie jest niestety kompatybilna. W tym wpisie zostanie omówiona instalacja właśnie nowej wersji routera.

[Image: how-to-configure-cisco-6500-sup2t-netflow-300x150.png]

Wstęp

Instrukcja dotyczy wersji 15 IOS-a Cisco. W tej wersji eksporter NetFlow zlicza jedynie pakiety typu „CEF-switched”. Pakiety typu „transit-switched” oraz ruch generowany lokalnie nie są zliczane. Instalacja składa się z czterech zasadniczych komponentów: konfiguracja rekordu NetFlow, eksporter Flow, monitor Flow, implementacja Flow monitora.

Konfiguracja rekordu NetFlow

Podczas instalacji routera jest możliwość wyboru pomiędzy predefiniowanym rekordem NetFlow lub stworzeniem własnego. Ten pierwszy emuluje NefFlow v9 i jego konfiguracja jest szybka. Jeśli natomiast zdecydujesz się na własną konfigurację, zyskasz możliwość eksportowania dodatkowych informacji takich jak Cisco Medianet Performance Monitoring, Cisco NetFlow NBAR (rozpoznawanie aplikacji oparte na sieci) oraz MAC adresy. W tym przykładzie użyjemy akurat predefiniowanego rekordu, a zainteresowanych jego zindywidualizowaną wersją odsyłamy do przykładów.

Konfiguracja eksportera NetFlow

Flow eksporter w Cisco 6500 SupT2 „mówi” ruterowi gdzie ma wysyłać dane NetFlow. W poniższym przykładzie należy zmienić docelowe IP oraz prawdopodobnie interfejs źródła

KOD: ZAZNACZ CAŁY
Code:
!

configure terminal

flow exporter scrutinizer

description Exports to Scrutinizer

destination 10.1.1.1

source loopback0

template data timeout 60

transport udp 2055

end

!


Konfiguracja Flow Monitora

Monitor Flow tworzy cache danych NetFlow, który urządzenie wykorzystuje do ich gromadzenia. Funkcją Flow Monitora jest również „spięcie” rekordu NetFlow z eksporterem Flow. W bieżącej wersji rutera Cisco wielkość cache-u została powiększona, by uniknąć problemów napotykanych w poprzedniej jego wersji.

KOD: ZAZNACZ CAŁY
Code:
!

configure terminal

flow monitor netflow-original

description This flow monitor uses the NetFlow original
record and exports to Scrutinizer

record netflow-original

cache timeout active 60

exporter scrutinizer

end

!


Implementacja Flow Monitora w interfejsie

Finalnym krokiem jest implementacja flow monitora w interfejsach, które zamierzasz monitorować. Poniższy fragment kodu należy powtórzyć wymaganą ilość razy.

KOD: ZAZNACZ CAŁY
Code:
!

configure terminal

interface ethernet 0/0

ip flow monitor netflow-original input

end

!


Narzędzie do raportowania z wykorzystaniem Cisco 6500 Sup2T NetFlow
NetFlow Scrutinizer jest wydajnym narzędziem do raportowania m.in. na omawianym tu ruterze. Zapraszamy do wypróbowania produktu przez okres testowy.

Paul@PLIXER]]> <![CDATA[Cisco ASA Cyber Threat Defense - z czym to się je?]]> https://monitoringserwerow.pl/showthread.php?tid=41 Tue, 30 Jul 2019 12:04:54 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=41 Cisco ASA Cyber Threat Defence składa się z trzech komponentów. Pierwszy z nich należy do podstawowych narzędzi monitorujących zagrożenia i jest obecny we wszystkich ASA-ch w wersjach firmware-u wyższych niż 8.0 (2). Jego funkcja to sprawdzanie ilości pakietów zagubionych przez ASA. Jednak ponieważ dane te odnoszą się całej sieci, trudno jest stwierdzić co jest źródłem problemu. Dopiero kiedy użyjemy oprogramowania do analizy logów z użyciem NSEL lub syslog, możemy mieć nadzieję na znalezienie źródła zagrożenia.

1. Podstawowa detekcja zagrożeń w ASA (Basic Threat Detection) szuka następujących eventów:

• ACL Drop (acl-drop) – pakiety są odrzucone przez listy dostępu
• Bad Pkts (bad-packet-drop) - błędne formaty pakietów, włącznie z nagłówkami L3 i L4 które nie są zgodne ze standardem RFC
• Conn Limit (conn-limit-drop) – pakiety, które przekroczyły skonfigurowany lub globalny limit połączenia
• DoS Attack (dos-drop) – atak typu „Denial of Service (DoS)
• Firewall (fw-drop) – podstawowe sprawdzenie bezpieczeństwa firewalla
• ICMP Atttack (icmp-drop) – podejrzane pakiety ICMP
• Inspect (inspect-drop) - odrzucenie przez inspekcję aplikacji
• Interface (interface-drop) – pakiety zgubione przez sprawdzanie interface-u
• Scanning (scanning-threat) – ataki skanujące wymierzone w sieć/hosta
• SYN Attack (syn-attack) – ataki typu „niedokończona sesja”; wliczając w to ataki TCP SYN oraz sesje UDP nie zawierające danych

[Image: cisco-asa.png]

Dla każdego z powyższych typów eventów wyznaczone są wartości krytyczne, po których przekroczeniu uznaje się go za zagrożenie. Określone są zarówno maksymalne wartości chwilowe, jak i średnie maksymalne określane dla przedziałów liczonych w sekundach a nawet w okresie 30 dni (zależnie od typu eventu). Statystyki dotyczące częstości występowania eventów w poszczególnych kategoriach można uzyskać z pomocą komendy „show threat-detection”. Podstawowa detekcja zagrożeń ASA (o której cały czas mówimy) nie podejmuje jednak żadnych działań które zapobiegły zidentyfikowanym problemom.

2. Zaawansowana Detekcja Zagrożeń (Advanced Threat Detection)

Drugi komponent Cisco ASA Cyber Threat Defence wgłębia się w bardziej szczegółowe parametry takie jakie jak IP hosta, porty, protokoły, ACL oraz serwery zabezpieczone przez TCP intercept. Jest to domyślne ustawienie statystyk ACL. Otrzymujemy informację o najważniejszych 10-ciu ACE-ach (zarówno dot. pozwolenia jak i odrzucenia dostępu) które osiągnęły największe wartości w danym przedziale czasowym. Dla tychże typów informacji Zaawansowana Detekcja Zagrożeń zwróci informacje o pakietach, bajtach i zagubionych danych zarówno otrzymanych jak i wysłanych przez dany obiekt w określonym przedziale czasowym. Jednak podobnie do Podstawowej Detekcji Zagrożeń, jej Detekcja Zaawansowana również ma funkcję czysto informacyjną. Wnioski płynące ze statystyk nie przekładają się na żadne działania zmierzające od wyeliminowania zagrożeń.

3. Skanująca Detekcja Zagrożeń (Scanning Threat Detection)
Ten komponent Cisco ASA Cyber Threat Defence ma za zadanie nadzór nad domniemanymi źródłami zagrożeń, które nawiązują połączenia ze zbyt dużą ilością hostów w podsieci, lub ze zbyt dużą ilością portów na hoście lub w danej podsieci. Ta funkcjonalność jest domyślnie wyłączona i jest bardzo podobna do Podstawowej Detekcji Zagrożeń, z tym że tworzy bazę domniemanych źródeł zagrożeń oraz wyznaczać ich adresy IP. A to z kolei pozwala na ich automatyczne blokowanie. Jak widać, trzeci typ detekcji zagrożeń posiada możliwość aktywnego przeciwdziałania atakom.

Pomimo że firewalle typu ASA są flagowymi urządzeniami chroniącym sieć, ich automatyka oparta na porównywaniu podpisów nie jest pozbawiona dziur. Dopiero użycie narzędzi do analizy NetFlow (którą to analizę te urządzenia umożliwiają) pozwala sięgnięcie do poziomu reputacji IP i osiągnięcie wystarczającego poziomu zabezpieczenia. Nowe standardy wynikają z ewolucji złośliwego oprogramowania, które aktualnie najczęściej wykorzystuje połączenia kodowane. To oznacza, że używana w przeszłości analiza pakietów przestaje mieć jakikolwiek sens.

Na marginesie, te najbardziej złośliwe typy wirusów pojawiające się w sieci są najczęściej wyłapywane przez niezależne ciała typu agencje działające na zlecenie rządu. W ten sposób „cywilna” ochrona nie ma szansy zdobyć dostatecznej wiedzy nt. Tych zagrożeń. A przecież dobre narzędzie do monitoringu sieci może zgromadzić dostateczną ilość danych do analizy i włączyć w nią logi z konkretnych urządzeń. Taka kombinacja zapewnia najbardziej wnikliwą ochronę.

Cisco Cyber Threat Defence dostarcza proaktywne narzędzia detekcji zagrożeń, które już zdołały spenetrować sieć. W inteligentny sposób jest w stanie prześwietlić ruch, aby ostatecznie odpowiedzieć na pytanie „kto, co, kiedy, gdzie, dlaczego oraz jak” spowodował anomalie.

Bezpieczeństwo sieciowe to stale ewolujący świat. Motorem tej ewolucji są stale pojawiające się nowe typy zagrożeń, które wykorzystują dotychczasowe metody. Koncentracja wysiłków zwykle celuje w zagrożenia płynące z internetu. Ale zaawansowane zagrożenia często przychodzą ze strony mediów zewnętrznych, „spear phishing”, „social ingineering” lub w formie malware czy trojanów. Niezależnie od źródła, zaawansowane zagrożenia pojawiają się niezauważone i funkcjonują w ukryciu przez długi czas.

[Image: asa_5520_netflow-300x84.jpg]

Pod osłoną zwykłego ruchu sieciowego zaawansowane wirusy mogą z powodzeniem rozprzestrzeniać się po kolejnych celach. Zabezpieczenia parametryczne „nie widzą” tych zagrożeń. Pod nieobecność użytkownika zainfekowany system może próbować wykorzystać dane dot. internetowych płatności czy nawet wykradać po kawałku własność intelektualną firmy. Oznaki tej przestępczej działalności mogą nie być w ogóle widoczne, a jej skutki przewidywalne.

Cisco Cyber Threat Defence pozwala na wyłowienie i szybkie naświetlenie tych ukrytych anomalii. Informacje te mogą być użyte w odniesieniu z danymi typu flow zebranymi z innych urządzeń. Dobry analizator NetFlow musi posiadać funkcję korelacji eventów oraz klasyfikację na poziomie aplikacji. Te dwa narzędzia są niesłychanie pomocne w walce z intruzami i złośliwym oprogramowaniem.

Połączenie działań z wykorzystaniem kilku technologii monitoringu sieciowego jest najlepszą metodą wykrycia zagrożeń w twojej sieci. Dane z analizy NetFlow mogą być użyte do analizy behawioralnej i ujawnić złe adresy IP. Zebranie danych udostępnianych przez współczesne urządzenia sieciowe i wykorzystanie ich przez scentralizowany software do raportowania i ostrzegania da nam w efekcie:
  • analizę korelacyjną w czasie rzeczywistym

  • wizualizację

  • raportowanie na podstawie danych skonsolidowanych z NeFlow oraz analizy tożsamości (z ang. „identity analysis”)
Jimmy@PLIXER
Link do oryginalnego artykułu.]]> Cisco ASA Cyber Threat Defence składa się z trzech komponentów. Pierwszy z nich należy do podstawowych narzędzi monitorujących zagrożenia i jest obecny we wszystkich ASA-ch w wersjach firmware-u wyższych niż 8.0 (2). Jego funkcja to sprawdzanie ilości pakietów zagubionych przez ASA. Jednak ponieważ dane te odnoszą się całej sieci, trudno jest stwierdzić co jest źródłem problemu. Dopiero kiedy użyjemy oprogramowania do analizy logów z użyciem NSEL lub syslog, możemy mieć nadzieję na znalezienie źródła zagrożenia.

1. Podstawowa detekcja zagrożeń w ASA (Basic Threat Detection) szuka następujących eventów:

• ACL Drop (acl-drop) – pakiety są odrzucone przez listy dostępu
• Bad Pkts (bad-packet-drop) - błędne formaty pakietów, włącznie z nagłówkami L3 i L4 które nie są zgodne ze standardem RFC
• Conn Limit (conn-limit-drop) – pakiety, które przekroczyły skonfigurowany lub globalny limit połączenia
• DoS Attack (dos-drop) – atak typu „Denial of Service (DoS)
• Firewall (fw-drop) – podstawowe sprawdzenie bezpieczeństwa firewalla
• ICMP Atttack (icmp-drop) – podejrzane pakiety ICMP
• Inspect (inspect-drop) - odrzucenie przez inspekcję aplikacji
• Interface (interface-drop) – pakiety zgubione przez sprawdzanie interface-u
• Scanning (scanning-threat) – ataki skanujące wymierzone w sieć/hosta
• SYN Attack (syn-attack) – ataki typu „niedokończona sesja”; wliczając w to ataki TCP SYN oraz sesje UDP nie zawierające danych

[Image: cisco-asa.png]

Dla każdego z powyższych typów eventów wyznaczone są wartości krytyczne, po których przekroczeniu uznaje się go za zagrożenie. Określone są zarówno maksymalne wartości chwilowe, jak i średnie maksymalne określane dla przedziałów liczonych w sekundach a nawet w okresie 30 dni (zależnie od typu eventu). Statystyki dotyczące częstości występowania eventów w poszczególnych kategoriach można uzyskać z pomocą komendy „show threat-detection”. Podstawowa detekcja zagrożeń ASA (o której cały czas mówimy) nie podejmuje jednak żadnych działań które zapobiegły zidentyfikowanym problemom.

2. Zaawansowana Detekcja Zagrożeń (Advanced Threat Detection)

Drugi komponent Cisco ASA Cyber Threat Defence wgłębia się w bardziej szczegółowe parametry takie jakie jak IP hosta, porty, protokoły, ACL oraz serwery zabezpieczone przez TCP intercept. Jest to domyślne ustawienie statystyk ACL. Otrzymujemy informację o najważniejszych 10-ciu ACE-ach (zarówno dot. pozwolenia jak i odrzucenia dostępu) które osiągnęły największe wartości w danym przedziale czasowym. Dla tychże typów informacji Zaawansowana Detekcja Zagrożeń zwróci informacje o pakietach, bajtach i zagubionych danych zarówno otrzymanych jak i wysłanych przez dany obiekt w określonym przedziale czasowym. Jednak podobnie do Podstawowej Detekcji Zagrożeń, jej Detekcja Zaawansowana również ma funkcję czysto informacyjną. Wnioski płynące ze statystyk nie przekładają się na żadne działania zmierzające od wyeliminowania zagrożeń.

3. Skanująca Detekcja Zagrożeń (Scanning Threat Detection)
Ten komponent Cisco ASA Cyber Threat Defence ma za zadanie nadzór nad domniemanymi źródłami zagrożeń, które nawiązują połączenia ze zbyt dużą ilością hostów w podsieci, lub ze zbyt dużą ilością portów na hoście lub w danej podsieci. Ta funkcjonalność jest domyślnie wyłączona i jest bardzo podobna do Podstawowej Detekcji Zagrożeń, z tym że tworzy bazę domniemanych źródeł zagrożeń oraz wyznaczać ich adresy IP. A to z kolei pozwala na ich automatyczne blokowanie. Jak widać, trzeci typ detekcji zagrożeń posiada możliwość aktywnego przeciwdziałania atakom.

Pomimo że firewalle typu ASA są flagowymi urządzeniami chroniącym sieć, ich automatyka oparta na porównywaniu podpisów nie jest pozbawiona dziur. Dopiero użycie narzędzi do analizy NetFlow (którą to analizę te urządzenia umożliwiają) pozwala sięgnięcie do poziomu reputacji IP i osiągnięcie wystarczającego poziomu zabezpieczenia. Nowe standardy wynikają z ewolucji złośliwego oprogramowania, które aktualnie najczęściej wykorzystuje połączenia kodowane. To oznacza, że używana w przeszłości analiza pakietów przestaje mieć jakikolwiek sens.

Na marginesie, te najbardziej złośliwe typy wirusów pojawiające się w sieci są najczęściej wyłapywane przez niezależne ciała typu agencje działające na zlecenie rządu. W ten sposób „cywilna” ochrona nie ma szansy zdobyć dostatecznej wiedzy nt. Tych zagrożeń. A przecież dobre narzędzie do monitoringu sieci może zgromadzić dostateczną ilość danych do analizy i włączyć w nią logi z konkretnych urządzeń. Taka kombinacja zapewnia najbardziej wnikliwą ochronę.

Cisco Cyber Threat Defence dostarcza proaktywne narzędzia detekcji zagrożeń, które już zdołały spenetrować sieć. W inteligentny sposób jest w stanie prześwietlić ruch, aby ostatecznie odpowiedzieć na pytanie „kto, co, kiedy, gdzie, dlaczego oraz jak” spowodował anomalie.

Bezpieczeństwo sieciowe to stale ewolujący świat. Motorem tej ewolucji są stale pojawiające się nowe typy zagrożeń, które wykorzystują dotychczasowe metody. Koncentracja wysiłków zwykle celuje w zagrożenia płynące z internetu. Ale zaawansowane zagrożenia często przychodzą ze strony mediów zewnętrznych, „spear phishing”, „social ingineering” lub w formie malware czy trojanów. Niezależnie od źródła, zaawansowane zagrożenia pojawiają się niezauważone i funkcjonują w ukryciu przez długi czas.

[Image: asa_5520_netflow-300x84.jpg]

Pod osłoną zwykłego ruchu sieciowego zaawansowane wirusy mogą z powodzeniem rozprzestrzeniać się po kolejnych celach. Zabezpieczenia parametryczne „nie widzą” tych zagrożeń. Pod nieobecność użytkownika zainfekowany system może próbować wykorzystać dane dot. internetowych płatności czy nawet wykradać po kawałku własność intelektualną firmy. Oznaki tej przestępczej działalności mogą nie być w ogóle widoczne, a jej skutki przewidywalne.

Cisco Cyber Threat Defence pozwala na wyłowienie i szybkie naświetlenie tych ukrytych anomalii. Informacje te mogą być użyte w odniesieniu z danymi typu flow zebranymi z innych urządzeń. Dobry analizator NetFlow musi posiadać funkcję korelacji eventów oraz klasyfikację na poziomie aplikacji. Te dwa narzędzia są niesłychanie pomocne w walce z intruzami i złośliwym oprogramowaniem.

Połączenie działań z wykorzystaniem kilku technologii monitoringu sieciowego jest najlepszą metodą wykrycia zagrożeń w twojej sieci. Dane z analizy NetFlow mogą być użyte do analizy behawioralnej i ujawnić złe adresy IP. Zebranie danych udostępnianych przez współczesne urządzenia sieciowe i wykorzystanie ich przez scentralizowany software do raportowania i ostrzegania da nam w efekcie:
  • analizę korelacyjną w czasie rzeczywistym

  • wizualizację

  • raportowanie na podstawie danych skonsolidowanych z NeFlow oraz analizy tożsamości (z ang. „identity analysis”)
Jimmy@PLIXER
Link do oryginalnego artykułu.]]> <![CDATA[Pożegnanie z Syslogd, niech żyje IPFIX!]]> https://monitoringserwerow.pl/showthread.php?tid=40 Tue, 30 Jul 2019 11:14:53 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=40 Komenda Syslogd jest najczęściej stosowana do zamiany wiadomości maszynowych albo syslogów w eventy przeznaczone do dalszego przetwarzania. Celem ostatecznym procesu jest uruchomienie alarmów czy powiadomień. Jednak problem z formatem danych generowanych przez tę komendę jest taki, że mają nieustandaryzowaną, luźną strukturę. Ten post pokazuje powody odejścia od standardu syslogd na rzecz IPFIX głównie przez fakt, że dane generowane przez ten drugi mają wysoko uporządkowaną strukturę.

[Image: cisco-asa-syslog-reporting.png]

Jeśli zamierzałbyś wkroczyć na rynek telewizorów z nowym produktem, prawdopodobnie nie wybrałbyś staromodnej technologii CRT. Aby konkurować na rynku, musiałbyś zaprojektować super-płaski telewizor o takich cechach jak niewielka waga, funkcja 3D czy kompatybilność z bluetooth. Analogicznie, jeśli planowałbyś osiągnąć sukces w produkcji switchów, ruterów, firewalli czy IPSów, prawdopodobnie nie podkreślałbyś w reklamach ich wsparcia dla SNMP czy syslog. Dla większości użytkowników to standard. Dla ludzi z branży modna jest teraz technologia flow, w zakresie przede wszystkim NetFlow oraz IPFIX. Nie bez powodu liderzy w branży skupiają się właśnie na tej funkcjonalności urządzeń. Weźmy za przykład takie marki jak Cisco, Palo Alto Networks, czy SonicWall – wszystkie wspierają NetFlow oraz IPFIX i są liderami rynku firewall-i. Vmware jest z kolei topowym brandem serwerów virtualnych i oczywiście wspiera zarówno NetFlow jak i IPFIX.

Czy wyżej wspomniany sprzęt obsługuje syslog? Naturalnie, jednak w obliczu różnorodnych zagrożeń typu malware, rekonesans z użyciem tylko syslogów jest zbyt ograniczony w porównaniu z technologią flow. Również SNMP jest za mało skuteczny w walce ze złośliwym oprogramowaniem. Powodów jest kilka.

Informacja w formacie IPFIX składa się z elementów wspólnych dla standardu, oraz tych definiowanych przez użytkownika. IPFIX umożliwia przydzielenie indywidualnych ID dla tych dodatkowych, zdefiniowanych elementów. Znacznie ułatwia to eksport informacji ważnych dla danej sytuacji. Można eksportować nie tylko SNMP, ale właściwie każdy rodzaj danych.

Inna zaleta standardu IPFIX to definiowanie typów danych o dowolnej długości. Przykładowo, SonicWall pozwala na definiowanie zmiennych o dramatycznie różnej wielkości: HTTP URL, User Name, Application Detection, Detected Intrusions, Detected Viruses i kilka innych. Podobnie działają urządzenia Enterasys, nTon, Juniper i wielu innych.

A co zrobić, jeśli pracujesz ze starszym systemem (bez wsparcia IPFIX) który jeszcze się dostatecznie nie zwrócił, by móc go wymienić na nowszy? Rozwiązaniem jest np. IPFIXify, który konwertuje syslogi do formatu IPFIX. Kiedy dane uzyskają już w ten sposób odpowiednią strukturę, łatwiej zanalizować je jako dane typu „meta” czy też typu kontekstualnego co z kolei ułatwia porównanie logów pomiędzy różnymi systemami. Możemy przykładowo „wyłowić” nazwy podejrzanych użytkowników analizując strumień IPFIX z Cisco ISE.

Podsumowując, nadszedł czas żeby pożegnać się z syslogami i zacząć w pełni korzystać z zalet technologii ustrukturyzowanych danych. IPFIX jest przyszłością analizy logów.

Danny@PLIXER]]> Komenda Syslogd jest najczęściej stosowana do zamiany wiadomości maszynowych albo syslogów w eventy przeznaczone do dalszego przetwarzania. Celem ostatecznym procesu jest uruchomienie alarmów czy powiadomień. Jednak problem z formatem danych generowanych przez tę komendę jest taki, że mają nieustandaryzowaną, luźną strukturę. Ten post pokazuje powody odejścia od standardu syslogd na rzecz IPFIX głównie przez fakt, że dane generowane przez ten drugi mają wysoko uporządkowaną strukturę.

[Image: cisco-asa-syslog-reporting.png]

Jeśli zamierzałbyś wkroczyć na rynek telewizorów z nowym produktem, prawdopodobnie nie wybrałbyś staromodnej technologii CRT. Aby konkurować na rynku, musiałbyś zaprojektować super-płaski telewizor o takich cechach jak niewielka waga, funkcja 3D czy kompatybilność z bluetooth. Analogicznie, jeśli planowałbyś osiągnąć sukces w produkcji switchów, ruterów, firewalli czy IPSów, prawdopodobnie nie podkreślałbyś w reklamach ich wsparcia dla SNMP czy syslog. Dla większości użytkowników to standard. Dla ludzi z branży modna jest teraz technologia flow, w zakresie przede wszystkim NetFlow oraz IPFIX. Nie bez powodu liderzy w branży skupiają się właśnie na tej funkcjonalności urządzeń. Weźmy za przykład takie marki jak Cisco, Palo Alto Networks, czy SonicWall – wszystkie wspierają NetFlow oraz IPFIX i są liderami rynku firewall-i. Vmware jest z kolei topowym brandem serwerów virtualnych i oczywiście wspiera zarówno NetFlow jak i IPFIX.

Czy wyżej wspomniany sprzęt obsługuje syslog? Naturalnie, jednak w obliczu różnorodnych zagrożeń typu malware, rekonesans z użyciem tylko syslogów jest zbyt ograniczony w porównaniu z technologią flow. Również SNMP jest za mało skuteczny w walce ze złośliwym oprogramowaniem. Powodów jest kilka.

Informacja w formacie IPFIX składa się z elementów wspólnych dla standardu, oraz tych definiowanych przez użytkownika. IPFIX umożliwia przydzielenie indywidualnych ID dla tych dodatkowych, zdefiniowanych elementów. Znacznie ułatwia to eksport informacji ważnych dla danej sytuacji. Można eksportować nie tylko SNMP, ale właściwie każdy rodzaj danych.

Inna zaleta standardu IPFIX to definiowanie typów danych o dowolnej długości. Przykładowo, SonicWall pozwala na definiowanie zmiennych o dramatycznie różnej wielkości: HTTP URL, User Name, Application Detection, Detected Intrusions, Detected Viruses i kilka innych. Podobnie działają urządzenia Enterasys, nTon, Juniper i wielu innych.

A co zrobić, jeśli pracujesz ze starszym systemem (bez wsparcia IPFIX) który jeszcze się dostatecznie nie zwrócił, by móc go wymienić na nowszy? Rozwiązaniem jest np. IPFIXify, który konwertuje syslogi do formatu IPFIX. Kiedy dane uzyskają już w ten sposób odpowiednią strukturę, łatwiej zanalizować je jako dane typu „meta” czy też typu kontekstualnego co z kolei ułatwia porównanie logów pomiędzy różnymi systemami. Możemy przykładowo „wyłowić” nazwy podejrzanych użytkowników analizując strumień IPFIX z Cisco ISE.

Podsumowując, nadszedł czas żeby pożegnać się z syslogami i zacząć w pełni korzystać z zalet technologii ustrukturyzowanych danych. IPFIX jest przyszłością analizy logów.

Danny@PLIXER]]> <![CDATA[Wsparcie NetFlow oraz VPN w Cisco ASA]]> https://monitoringserwerow.pl/showthread.php?tid=39 Tue, 30 Jul 2019 11:08:47 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=39 W codziennej pracy ze sprzętem sieciowym mam do czynienia z przeróżnymi urządzeniami. Dziś opisuję jedno z nich – Cisco ASA. Postaram się wyjaśnić funkcjonalność tego routera w odniesieniu do monitoringu VPN, o który często pytają moi klienci.

Czym jest VPN?

Wirtualna Sieć Prywatna VPN (z ang. Virtual Private Network) to rozszerzenie klasycznej sieci wewnętrznej o użytkowników znajdujących się fizycznie poza nią. Dzięki VPN mają oni możliwość zalogowania się jako pełnoprawni jej użytkownicy i korzystania w pełni z jej funkcjonalności. Zmartwieniem administratorów takich sieci jest rzekomo nierozwiązywalny problem z monitorowaniem aktywności takich „zewnętrznie zalogowanych” użytkowników. Gdy pokazuję jak mogą łatwo pozbyć się tego zmartwienia, czapki spadają im z głów.

Monitorowanie VPN za pomocą NetFlow

Poniżej załączam raport ruchu VPN w sieci PLIXERa sprzed kilku dni. Raport został wygenerowany z CISO ASA, jednak podobny obraz otrzymamy z każdego innego urządzenia VPN eksportującego NetFlow lub inny rodzaj danych flow. Widoczny rezultat to efekt założenia filtrów na porty skojarzone z VPN/połączenia szyfrowane oraz na połączenia UDP. Na pozostałą krótką listę składają się nasi użytkownicy VPN z Maine, Turcji, Florydy i New Hampshire. Jak możecie podejrzewać, szybki dostęp do tych danych może być bardzo przydatny w zidentyfikowaniu przyczyny spowolnienia w sieci czy zagrożenia płynącego właśnie przez VPN.

[Image: juniper-vpn-report.png]

Przykład ten pokazuje, jak nasz analizer wspaniale radzi sobie z monitoringiem VPN przez zwyczajne filtrowanie na podstawie portu/protokołu. Potem wystarczy już tylko podrążyć w aktywności wyznaczonych użytkowników, żeby uzyskać obraz tego co aktualnie dzieje się w sieci. Oznacza to prawdziwą, 100% przejrzystość sytuacji.

Jake@PLIXER]]> W codziennej pracy ze sprzętem sieciowym mam do czynienia z przeróżnymi urządzeniami. Dziś opisuję jedno z nich – Cisco ASA. Postaram się wyjaśnić funkcjonalność tego routera w odniesieniu do monitoringu VPN, o który często pytają moi klienci.

Czym jest VPN?

Wirtualna Sieć Prywatna VPN (z ang. Virtual Private Network) to rozszerzenie klasycznej sieci wewnętrznej o użytkowników znajdujących się fizycznie poza nią. Dzięki VPN mają oni możliwość zalogowania się jako pełnoprawni jej użytkownicy i korzystania w pełni z jej funkcjonalności. Zmartwieniem administratorów takich sieci jest rzekomo nierozwiązywalny problem z monitorowaniem aktywności takich „zewnętrznie zalogowanych” użytkowników. Gdy pokazuję jak mogą łatwo pozbyć się tego zmartwienia, czapki spadają im z głów.

Monitorowanie VPN za pomocą NetFlow

Poniżej załączam raport ruchu VPN w sieci PLIXERa sprzed kilku dni. Raport został wygenerowany z CISO ASA, jednak podobny obraz otrzymamy z każdego innego urządzenia VPN eksportującego NetFlow lub inny rodzaj danych flow. Widoczny rezultat to efekt założenia filtrów na porty skojarzone z VPN/połączenia szyfrowane oraz na połączenia UDP. Na pozostałą krótką listę składają się nasi użytkownicy VPN z Maine, Turcji, Florydy i New Hampshire. Jak możecie podejrzewać, szybki dostęp do tych danych może być bardzo przydatny w zidentyfikowaniu przyczyny spowolnienia w sieci czy zagrożenia płynącego właśnie przez VPN.

[Image: juniper-vpn-report.png]

Przykład ten pokazuje, jak nasz analizer wspaniale radzi sobie z monitoringiem VPN przez zwyczajne filtrowanie na podstawie portu/protokołu. Potem wystarczy już tylko podrążyć w aktywności wyznaczonych użytkowników, żeby uzyskać obraz tego co aktualnie dzieje się w sieci. Oznacza to prawdziwą, 100% przejrzystość sytuacji.

Jake@PLIXER]]> <![CDATA[Wtyczka Zenpack dla konsoli Zenoss]]> https://monitoringserwerow.pl/showthread.php?tid=38 Tue, 30 Jul 2019 10:31:22 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=38 Informujemy o nowej wtyczce „Zenpack” dla urządzenia Zenoss. Integruje ona Zenossa z naszym Scrutinizerem. Rozwiązywanie problemów sieciowych jest teraz płynnym procesem kontrolowanym bezpośrednio z konsoli Zenoss, ale funkcjonalność rozwiązania nie kończy się na analizie NetFlow. Dostarcza ono raporty syslog a następnie porównuje dane ze strumieniami NetFlow oraz IPFIX.

Zenpack jest kompatybilny z wersjami 3.x oraz 4.x Zenoss-a. Pozwala administratorowi na uzyskanie danych o:

- najaktywniejszych aplikacjach, hostach, protokołach, jak również tradycyjne raporty NetFlow
- raportowanie o urządzeniach typu BYOD (z ang. Bring Your Own Device) w kontekście obciążenia, które powodują i zagrożeń z nimi związanych
- monitorowanie usług w chmurze – w zakresie takich parametrów jak dostępność czy czas odpowiedzi
pomiary dźwięku i video w zakresie takich parametrów jak jitter, utrata pakietów czy priorytet
wsparcie dla Xirrus, SonicWALL oraz Cisco w zakresie urządzeń bezprzewodowych
- monitoring Amazon EC2
- detekcja różnego typu zagrożeń, włączając APT-y, zagrożenia wynikające z zachowań użytkowników, ataki DoS, boty a nawet wyciek danych
- ścieżki audytu (audit trails) dla ruchu sieciowego, umożliwiające szybką reakcję na problemy w sieci
- wsparcie dla Firewalli: Barracuda, Cisco ASA, PaloAlto, SonicWALL, Enterasys Dragon IPS itd.

[Image: zenoss-netflow.png]

Zenpack integruje z Zenossem wszystkie funkcjonalności w zakresie analizy NetFlow, włączając te stworzone dla Cisco, Citrix, Enterasys, SonicWALL, Palo Alto Networks dla wielu innych producentów. Przykładowo, dodaliśmy właśnie wsparcie dla Cisco Application Visibility and Control (AVC) który jest pakietem usług w urządzeniach sieciowych Cisco, obsługiwanym z poziomu aplikacji. Umożliwia klasyfikację, monitoring i kontrolę przepływu danych. Zwiększa wydajność krytycznych dla biznesu aplikacji, pomaga w zarządzaniu i planowaniu, a także redukuje koszty operacyjne. Więcej informacji o AVC możesz znaleźć na naszej stronie oraz na stronie producenta.

Thomas@PLIXER]]> Informujemy o nowej wtyczce „Zenpack” dla urządzenia Zenoss. Integruje ona Zenossa z naszym Scrutinizerem. Rozwiązywanie problemów sieciowych jest teraz płynnym procesem kontrolowanym bezpośrednio z konsoli Zenoss, ale funkcjonalność rozwiązania nie kończy się na analizie NetFlow. Dostarcza ono raporty syslog a następnie porównuje dane ze strumieniami NetFlow oraz IPFIX.

Zenpack jest kompatybilny z wersjami 3.x oraz 4.x Zenoss-a. Pozwala administratorowi na uzyskanie danych o:

- najaktywniejszych aplikacjach, hostach, protokołach, jak również tradycyjne raporty NetFlow
- raportowanie o urządzeniach typu BYOD (z ang. Bring Your Own Device) w kontekście obciążenia, które powodują i zagrożeń z nimi związanych
- monitorowanie usług w chmurze – w zakresie takich parametrów jak dostępność czy czas odpowiedzi
pomiary dźwięku i video w zakresie takich parametrów jak jitter, utrata pakietów czy priorytet
wsparcie dla Xirrus, SonicWALL oraz Cisco w zakresie urządzeń bezprzewodowych
- monitoring Amazon EC2
- detekcja różnego typu zagrożeń, włączając APT-y, zagrożenia wynikające z zachowań użytkowników, ataki DoS, boty a nawet wyciek danych
- ścieżki audytu (audit trails) dla ruchu sieciowego, umożliwiające szybką reakcję na problemy w sieci
- wsparcie dla Firewalli: Barracuda, Cisco ASA, PaloAlto, SonicWALL, Enterasys Dragon IPS itd.

[Image: zenoss-netflow.png]

Zenpack integruje z Zenossem wszystkie funkcjonalności w zakresie analizy NetFlow, włączając te stworzone dla Cisco, Citrix, Enterasys, SonicWALL, Palo Alto Networks dla wielu innych producentów. Przykładowo, dodaliśmy właśnie wsparcie dla Cisco Application Visibility and Control (AVC) który jest pakietem usług w urządzeniach sieciowych Cisco, obsługiwanym z poziomu aplikacji. Umożliwia klasyfikację, monitoring i kontrolę przepływu danych. Zwiększa wydajność krytycznych dla biznesu aplikacji, pomaga w zarządzaniu i planowaniu, a także redukuje koszty operacyjne. Więcej informacji o AVC możesz znaleźć na naszej stronie oraz na stronie producenta.

Thomas@PLIXER]]> <![CDATA[Zawyżone wskazania przepływów NetFlow - przyczyny]]> https://monitoringserwerow.pl/showthread.php?tid=37 Tue, 30 Jul 2019 10:22:26 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=37 Czy zdarzyło ci się monitorować sieć i nabrać podejrzeń, że wskazywany przez strumienie ruch jest przesadzony? W pierwszej kolejności należy wówczas przyjrzeć się ustawieniom szybkości interfejsu. Ponieważ dane z urządzenia są przesyłane przez protokół SNMP, może zdarzyć że ten parametr będzie źle ustawiony. Po drugie, jeśli analizowany jest przepływ typu NetFlow, należy upewnić się, że parametr „ip flow-cache timeout active 1” został skonfigurowany w ruterze. Bez tej komendy wskazania przepływów będą często przeszacowane albo niedoszacowane.

[Image: netflow-using-udp-or-sctp.png]

Ten artykuł wyjaśnia, jak i dlaczego strumienie są eksportowane.

W klasycznym ujęciu dane o ruchu w sieci, gromadzone w tabeli cache-u strumieni są eksportowane w czterech przypadkach:

1. Wygasa timer dla strumieni trwających przez dłuższy czas. Zwykle jest on ustalony na 60 sekund, i większość narzędzi raportujących używa interwału o długości jednej minuty. Przykładowo, jeśli połączenie lub strumień dla ściąganego pliku trwa 4,5 minuty, jego zawartość określona przez wartość „delta byte count” będzie eksportowana co 60s. W piątej minucie strumień się zakończy i wyeksportowana zostanie pozostała ilość danych oraz pakietów strumienia NetFlow. Sam strumień jest również usunięty z pamięci podręcznej. Analogicznie, jeśli wartość „time-out” jest ustawiona na dłuższy okres (np. na 5 minut), strumień trwający 2 lub 3 minuty może być wyeksportowany za jednym razem. Z timerem ustawionym na 5 minut może pojawić się problem: jeśli narzędzie raportujące oczekuje danych w interwale 1 minuty, na wykresie „data trend” pojawią się czerwone piki oznaczające użycie większe niż 100%. Aby uniknąć tego problemu, należy zawsze ustawiać timer na 60 sekund.
2. Strumień pozostaje nieaktywny po czasie określanym przez parametr „inactive timeout”. Najczęściej jest on ustawiony na 15s. Taka sytuacja ma miejsce kiedy na połączeniu TCP nie ma ruchu lub kiedy strumień używa UDP.
3. Strumień zakończył się, co jest sygnalizowane przez „flagę TCP”: Zakończony (FIN) lub zresetowany (RST). WAŻNE: nie wszystkie urządzenia posiadają tę funkcję.
4. Strumienie są eksportowane wcześniej, jeśli zapełni się cache. W przypadku Cisco nazywa się to „awaryjne wygaśnięcie” i wówczas wybrane losowo strumienie są eksportowane kiedy cache jest zapełniony w 90%.

Eksportować przez UDP czy SCTP?

W filmiku youtube zatytułowanym „Configuring Flexible Netflow”, krok 2 określa komendę „transport udp 2055”. Numer portu może się zmieniać, jednak UDP jest jak dotąd najbardziej popularną warstwą transportową do przesyłu strumieni. Nie jest jednak jedyny. Ponieważ UDP nie jest do końca wiarygodny jeśli chodzi o przesył datagramów, Cisco oferuje alternatywę w postaci protokołu Stream Control Transmission Protocol (SCTP). W sieci można znaleźć mnóstwo materiałów na ten temat, więc tutaj tylko skrótowo:

W informatyce sieci komputerowych, SCTP to warstwa transportowa posiadająca cechy wspólne popularnych protokołów takich jak TCP czy UDP: przesyła informacje w postaci ukształtowanych wiadomości (jak UDP) i zapewnia wiarygodny, sekwencyjny przesył z kontrolą zatłoczenia (podobnie do TCP).

Pomimo, że UDP nie gwarantuje dostawy pakietów, inżynierowie z Cisco udostępnili mechanizm weryfikacji liczby strumieni. Nosi on nazwę „flow sequence number”. Ale jednocześnie zagubione strumienie będą wskazywać zaniżone przepływy – ale to jest temat na kolejny post na naszym blogu.

Ryan@PLIXER
Link do oryginalnego artykułu.]]> Czy zdarzyło ci się monitorować sieć i nabrać podejrzeń, że wskazywany przez strumienie ruch jest przesadzony? W pierwszej kolejności należy wówczas przyjrzeć się ustawieniom szybkości interfejsu. Ponieważ dane z urządzenia są przesyłane przez protokół SNMP, może zdarzyć że ten parametr będzie źle ustawiony. Po drugie, jeśli analizowany jest przepływ typu NetFlow, należy upewnić się, że parametr „ip flow-cache timeout active 1” został skonfigurowany w ruterze. Bez tej komendy wskazania przepływów będą często przeszacowane albo niedoszacowane.

[Image: netflow-using-udp-or-sctp.png]

Ten artykuł wyjaśnia, jak i dlaczego strumienie są eksportowane.

W klasycznym ujęciu dane o ruchu w sieci, gromadzone w tabeli cache-u strumieni są eksportowane w czterech przypadkach:

1. Wygasa timer dla strumieni trwających przez dłuższy czas. Zwykle jest on ustalony na 60 sekund, i większość narzędzi raportujących używa interwału o długości jednej minuty. Przykładowo, jeśli połączenie lub strumień dla ściąganego pliku trwa 4,5 minuty, jego zawartość określona przez wartość „delta byte count” będzie eksportowana co 60s. W piątej minucie strumień się zakończy i wyeksportowana zostanie pozostała ilość danych oraz pakietów strumienia NetFlow. Sam strumień jest również usunięty z pamięci podręcznej. Analogicznie, jeśli wartość „time-out” jest ustawiona na dłuższy okres (np. na 5 minut), strumień trwający 2 lub 3 minuty może być wyeksportowany za jednym razem. Z timerem ustawionym na 5 minut może pojawić się problem: jeśli narzędzie raportujące oczekuje danych w interwale 1 minuty, na wykresie „data trend” pojawią się czerwone piki oznaczające użycie większe niż 100%. Aby uniknąć tego problemu, należy zawsze ustawiać timer na 60 sekund.
2. Strumień pozostaje nieaktywny po czasie określanym przez parametr „inactive timeout”. Najczęściej jest on ustawiony na 15s. Taka sytuacja ma miejsce kiedy na połączeniu TCP nie ma ruchu lub kiedy strumień używa UDP.
3. Strumień zakończył się, co jest sygnalizowane przez „flagę TCP”: Zakończony (FIN) lub zresetowany (RST). WAŻNE: nie wszystkie urządzenia posiadają tę funkcję.
4. Strumienie są eksportowane wcześniej, jeśli zapełni się cache. W przypadku Cisco nazywa się to „awaryjne wygaśnięcie” i wówczas wybrane losowo strumienie są eksportowane kiedy cache jest zapełniony w 90%.

Eksportować przez UDP czy SCTP?

W filmiku youtube zatytułowanym „Configuring Flexible Netflow”, krok 2 określa komendę „transport udp 2055”. Numer portu może się zmieniać, jednak UDP jest jak dotąd najbardziej popularną warstwą transportową do przesyłu strumieni. Nie jest jednak jedyny. Ponieważ UDP nie jest do końca wiarygodny jeśli chodzi o przesył datagramów, Cisco oferuje alternatywę w postaci protokołu Stream Control Transmission Protocol (SCTP). W sieci można znaleźć mnóstwo materiałów na ten temat, więc tutaj tylko skrótowo:

W informatyce sieci komputerowych, SCTP to warstwa transportowa posiadająca cechy wspólne popularnych protokołów takich jak TCP czy UDP: przesyła informacje w postaci ukształtowanych wiadomości (jak UDP) i zapewnia wiarygodny, sekwencyjny przesył z kontrolą zatłoczenia (podobnie do TCP).

Pomimo, że UDP nie gwarantuje dostawy pakietów, inżynierowie z Cisco udostępnili mechanizm weryfikacji liczby strumieni. Nosi on nazwę „flow sequence number”. Ale jednocześnie zagubione strumienie będą wskazywać zaniżone przepływy – ale to jest temat na kolejny post na naszym blogu.

Ryan@PLIXER
Link do oryginalnego artykułu.]]> <![CDATA[Lancope Stealthwatch kontra Plixer Scrutinizer]]> https://monitoringserwerow.pl/showthread.php?tid=36 Tue, 30 Jul 2019 10:18:08 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=36 Ostatnio jeden z klientów poprosił mnie o dokumentację, która pomogłaby mu dokonać wyboru pomiędzy Lancope Stealthwatch a Plixer Scrutinizer. Uznałem to za dobrą okazję żeby parę rzeczy wyjaśnić. Po tym jak klient zapoznał się z naszą białą księgą stopy zwrotu inwestycji na poziomie 2500% i po odbyciu trzech telekonferencji (oceniających produkt) stało się dla niego jasne co tak naprawdę jest istotne w obu ofertach.

Technika sprzedaży oprogramowania opiera się często na punktowaniu słabych stron rozwiązań konkurencji i oczywiście podkreślaniu mocnych stron własnego produktu. Dla klienta jest to także oczywiste. Nierzadko padają pytania o właśnie takie zestawienia. To, co jest istotne, to źródło tych informacji.
Zgodzę się, że nie jest złym pomysłem pytać przedstawiciela Mercedesa, o porównanie z BMW. Dowiemy się o wspaniałych rozwiązaniach technologicznych w zakresie sterowności, układu hamowania, przekładni biegów czy też o nagrodach jakie otrzymała firma. Odpowiedź BMW będzie podobna w tonie.

[Image: 4ycb9.jpg]

Które funkcje mają tak naprawdę dla nas wartość?

Moja sugestia jest taka, żeby listę tych wszystkich zalet jednej firmy przekazać drugiej i żądać rzeczowej odwiedzi. Powód? Sprzedawcy zwykle próbują przekonać klienta, że przedstawiona przez nich lista to cechy produktu nie tylko unikatowe, ale również absolutnie niezbędne. Proponuję przyjrzeć dokładnie rzeczom z kategorii „tylko u nas”. Przekonamy się wówczas jaką tak naprawdę mają wartość dla naszej firmy.

Weźmy za przykład poniższą listę ze strony Lancope, wydawcy StealthWatch:

[Image: lancope-stealthwatch-vs-plixer-scrutinizer1.png]

Lancope określił to jako porównanie ich produktu ze Scrutinizer-em lub Solarwind-em. Przyjrzyjmy się zatem mu z punktu widzenia Plixer-a:

1. „Niska cena”: Owszem, Scrutinizer jest tańszy niż Stealthwatch. Czy to jest wada? Przyczyną jest pewnie to, że mamy prywatnego właściciela i zero kredytu. Nie musimy również spowiadać się udziałowcom. A kapitał Lancope w większości należy do udziałowców i posiada spory kredyt. My inwestujemy zyski w dział badań i rozwoju.
2. „Tylko software”: Scrutinizer zarówno wersję software-ową jaki sprzętową. Podobnie jak Stealthwatch. Więc w jakim znaczeniu Plixer jest bardziej „software-owy”?
3. „Skalowalność”: Scrutinizer może gromadzić ponad 100 tys. strumieni na sekundę. StealthWatch twierdzi że obsługuje 120 tys. strumieni na sekundę. Interesująca gra słów, nieprawdaż? Udało nam się obsłużyć 180 tysięcy strumieni NetFlow v5 w testach laboratoryjnych, ale czy to powinno znaleźć się naszych materiałach promocyjnych? Nie robimy tego z kilku powodów, ale nasze cyfry są wiarygodne. Możliwości Scrutinizer-a to bardzo duża liczba równoczesnych strumieni. Jest w stanie wychwycić chwilowe skoki sięgające kilkuset tysięcy strumieni. Ale tego również nie znajdziecie w naszych materiałach promocyjnych.
4. „Archiwizacja danych”: Scrutinizer może zachowywać zapis strumieni na dekady, i daje do nich natychmiastowy dostęp (w przeciągu sekund). Dane są gromadzone w następujących interwałach: 1min, 5min, 30min, 2 godziny, 12 godzin, 1 dzień oraz 1 tydzień. Nie notujemy zbyt wiele reklamacji na tym obszarze. Mechanizm archiwizacji jest przystosowany do wymogów prawnych dot. gromadzenia danych.
5. „Zdolność do identyfikacji”: Scrutinizer wykorzystuje dane z firewalla żeby uzyskać Informacje odnośnie pracy w domenie Windows, schodząc do takich szczegółów jak adres IP czy nazwa użytkownika. Często wówczas wystarczy parę kliknięć żeby dojść do nazwiska.
6. „Logiczne podejście od zidentyfikowania problemu do znalezienia rozwiązania”: To tylko hasło reklamowe. Nasze brzmi akurat „Lista, identyfikacja, wybór”.

A oto kilka faktów na temat Scrutinizer-a, o których Lancope nie chciałby, żebyś się dowiedział:

1. Detekcja zagrożeń: Scrutinizer stale monitoruje wszystkie strumienie w poszukiwaniu wzorów podejrzanych zachowań
2. Powiadmienia: Scrutinizer nie potrzebuje dodatkowych wtyczek z funkcją wysyłania powiadomień na e-mail. Ma wbudowany również mechanizm oceny.
3. Jeden magazyn: Scrutinizer gromadzi wszystkie rodzaje strumieni NetFow (w tym np. J-Flow) oraz sFlow w jednym magazynie
4. Funkcja „IP Host Reputatation”: Scrutinizer jako jeden z pierwszych programów do analizy strumieni miał funkcję porównywania hostów z listą reputacji adresów IP.
5. Elastyczne fitrowanie: Scrutinizer pozwala na nielimitowaną liczbę warunków filtra. Może użyć warunków „wszystkie z” lub „wszystkie bez” w ramach wyrażeń logicznych. „Jakiekolwiek” lub „wszystkie” warunki będą również uwzględnione w wynikach. W przypadku spraw dochodzeń sądowych taka funkcjonalność jest absolutną koniecznością.
6. Widoczność „od początku do końca”: Scrutinizer posiada funkcję „Flow Hopper” pozwalającą na śledzenie toru danego strumienia w czasie jego wędrówki po sieci, w obie strony. Staramy się o patent na to rozwiązanie.
7. Zaprojektuj własny raport: Jeśli w gotowych funkcjach Scrutinizer-a nie ma raportu, który ci jest potrzebny, możesz stworzyć go samemu. Pojawi się on na interfejsie sieciowym na którymkolwiek urządzeniu, które dostarczy danych niezbędnych do raportu.
8. Scrutinizer obsługuje 100% pól strumienia NeFlow (tzw. elementów) eksportowanych przez urządzenia Cisco. Możesz otrzymać raport czasu podróży między serwerem a klientem, parametr „VoIP jitter”, straty pakietów, rozmiar pakietów, retransmity i URL-e. Wszystkie te parametry mogą być eksportowane ze strumieni NetFlow oraz IPFIX i nie musisz czekać na nowsze wersje naszego oprogramowania, żeby mieć tę funkcjonalność.

Nie ma kogoś, kto podjął by za ciebie decyzję dotyczącą inwestycji w infrastrukturę NetFlow czy IPFIX. Musisz zacząć od określenia swoich celów biznesowych, następnie funkcjonalności narzędzi, które pomogą ci ten cel osiągnąć. Potem zostaje zadawanie pytań, porównywanie i ocena rozwiązań. To jest sprawdzony sposób na dokonanie najlepszego zakupu dla twojej firmy.

Jimmy@PLIXER
Link do oryginalnego artykułu.]]> Ostatnio jeden z klientów poprosił mnie o dokumentację, która pomogłaby mu dokonać wyboru pomiędzy Lancope Stealthwatch a Plixer Scrutinizer. Uznałem to za dobrą okazję żeby parę rzeczy wyjaśnić. Po tym jak klient zapoznał się z naszą białą księgą stopy zwrotu inwestycji na poziomie 2500% i po odbyciu trzech telekonferencji (oceniających produkt) stało się dla niego jasne co tak naprawdę jest istotne w obu ofertach.

Technika sprzedaży oprogramowania opiera się często na punktowaniu słabych stron rozwiązań konkurencji i oczywiście podkreślaniu mocnych stron własnego produktu. Dla klienta jest to także oczywiste. Nierzadko padają pytania o właśnie takie zestawienia. To, co jest istotne, to źródło tych informacji.
Zgodzę się, że nie jest złym pomysłem pytać przedstawiciela Mercedesa, o porównanie z BMW. Dowiemy się o wspaniałych rozwiązaniach technologicznych w zakresie sterowności, układu hamowania, przekładni biegów czy też o nagrodach jakie otrzymała firma. Odpowiedź BMW będzie podobna w tonie.

[Image: 4ycb9.jpg]

Które funkcje mają tak naprawdę dla nas wartość?

Moja sugestia jest taka, żeby listę tych wszystkich zalet jednej firmy przekazać drugiej i żądać rzeczowej odwiedzi. Powód? Sprzedawcy zwykle próbują przekonać klienta, że przedstawiona przez nich lista to cechy produktu nie tylko unikatowe, ale również absolutnie niezbędne. Proponuję przyjrzeć dokładnie rzeczom z kategorii „tylko u nas”. Przekonamy się wówczas jaką tak naprawdę mają wartość dla naszej firmy.

Weźmy za przykład poniższą listę ze strony Lancope, wydawcy StealthWatch:

[Image: lancope-stealthwatch-vs-plixer-scrutinizer1.png]

Lancope określił to jako porównanie ich produktu ze Scrutinizer-em lub Solarwind-em. Przyjrzyjmy się zatem mu z punktu widzenia Plixer-a:

1. „Niska cena”: Owszem, Scrutinizer jest tańszy niż Stealthwatch. Czy to jest wada? Przyczyną jest pewnie to, że mamy prywatnego właściciela i zero kredytu. Nie musimy również spowiadać się udziałowcom. A kapitał Lancope w większości należy do udziałowców i posiada spory kredyt. My inwestujemy zyski w dział badań i rozwoju.
2. „Tylko software”: Scrutinizer zarówno wersję software-ową jaki sprzętową. Podobnie jak Stealthwatch. Więc w jakim znaczeniu Plixer jest bardziej „software-owy”?
3. „Skalowalność”: Scrutinizer może gromadzić ponad 100 tys. strumieni na sekundę. StealthWatch twierdzi że obsługuje 120 tys. strumieni na sekundę. Interesująca gra słów, nieprawdaż? Udało nam się obsłużyć 180 tysięcy strumieni NetFlow v5 w testach laboratoryjnych, ale czy to powinno znaleźć się naszych materiałach promocyjnych? Nie robimy tego z kilku powodów, ale nasze cyfry są wiarygodne. Możliwości Scrutinizer-a to bardzo duża liczba równoczesnych strumieni. Jest w stanie wychwycić chwilowe skoki sięgające kilkuset tysięcy strumieni. Ale tego również nie znajdziecie w naszych materiałach promocyjnych.
4. „Archiwizacja danych”: Scrutinizer może zachowywać zapis strumieni na dekady, i daje do nich natychmiastowy dostęp (w przeciągu sekund). Dane są gromadzone w następujących interwałach: 1min, 5min, 30min, 2 godziny, 12 godzin, 1 dzień oraz 1 tydzień. Nie notujemy zbyt wiele reklamacji na tym obszarze. Mechanizm archiwizacji jest przystosowany do wymogów prawnych dot. gromadzenia danych.
5. „Zdolność do identyfikacji”: Scrutinizer wykorzystuje dane z firewalla żeby uzyskać Informacje odnośnie pracy w domenie Windows, schodząc do takich szczegółów jak adres IP czy nazwa użytkownika. Często wówczas wystarczy parę kliknięć żeby dojść do nazwiska.
6. „Logiczne podejście od zidentyfikowania problemu do znalezienia rozwiązania”: To tylko hasło reklamowe. Nasze brzmi akurat „Lista, identyfikacja, wybór”.

A oto kilka faktów na temat Scrutinizer-a, o których Lancope nie chciałby, żebyś się dowiedział:

1. Detekcja zagrożeń: Scrutinizer stale monitoruje wszystkie strumienie w poszukiwaniu wzorów podejrzanych zachowań
2. Powiadmienia: Scrutinizer nie potrzebuje dodatkowych wtyczek z funkcją wysyłania powiadomień na e-mail. Ma wbudowany również mechanizm oceny.
3. Jeden magazyn: Scrutinizer gromadzi wszystkie rodzaje strumieni NetFow (w tym np. J-Flow) oraz sFlow w jednym magazynie
4. Funkcja „IP Host Reputatation”: Scrutinizer jako jeden z pierwszych programów do analizy strumieni miał funkcję porównywania hostów z listą reputacji adresów IP.
5. Elastyczne fitrowanie: Scrutinizer pozwala na nielimitowaną liczbę warunków filtra. Może użyć warunków „wszystkie z” lub „wszystkie bez” w ramach wyrażeń logicznych. „Jakiekolwiek” lub „wszystkie” warunki będą również uwzględnione w wynikach. W przypadku spraw dochodzeń sądowych taka funkcjonalność jest absolutną koniecznością.
6. Widoczność „od początku do końca”: Scrutinizer posiada funkcję „Flow Hopper” pozwalającą na śledzenie toru danego strumienia w czasie jego wędrówki po sieci, w obie strony. Staramy się o patent na to rozwiązanie.
7. Zaprojektuj własny raport: Jeśli w gotowych funkcjach Scrutinizer-a nie ma raportu, który ci jest potrzebny, możesz stworzyć go samemu. Pojawi się on na interfejsie sieciowym na którymkolwiek urządzeniu, które dostarczy danych niezbędnych do raportu.
8. Scrutinizer obsługuje 100% pól strumienia NeFlow (tzw. elementów) eksportowanych przez urządzenia Cisco. Możesz otrzymać raport czasu podróży między serwerem a klientem, parametr „VoIP jitter”, straty pakietów, rozmiar pakietów, retransmity i URL-e. Wszystkie te parametry mogą być eksportowane ze strumieni NetFlow oraz IPFIX i nie musisz czekać na nowsze wersje naszego oprogramowania, żeby mieć tę funkcjonalność.

Nie ma kogoś, kto podjął by za ciebie decyzję dotyczącą inwestycji w infrastrukturę NetFlow czy IPFIX. Musisz zacząć od określenia swoich celów biznesowych, następnie funkcjonalności narzędzi, które pomogą ci ten cel osiągnąć. Potem zostaje zadawanie pytań, porównywanie i ocena rozwiązań. To jest sprawdzony sposób na dokonanie najlepszego zakupu dla twojej firmy.

Jimmy@PLIXER
Link do oryginalnego artykułu.]]> <![CDATA[Nowy Cisco Catalyst 3850 ze wsparciem NetFlow]]> https://monitoringserwerow.pl/showthread.php?tid=35 Tue, 30 Jul 2019 10:15:40 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=35 Miło nam poinformować o kolejnym urządzeniu wspieranym przez aktualne wersje Scrutinizer-a. Jest nim Cisco Catalyst 3850. To cacko, w odróżnieniu od wersji 3750 może komunikować się bezprzewodowo. Równie istotne jest to, że natywnie wspiera NetFlow (bez wcześniej wymaganego modułu 3KX). Ten switch pozwala na wielopoziomową analizę wydajności w oparciu o takie dane jak: SSID (identyfikator sieci), klient, aplikacja czy „fair share policy” dla sieci bezprzewodowej, podczas gdy współpracujący z nim Scrutinizer monitoruje ruch sieciowy, jak również wszystkie powyższe parametry.

[Image: km_79293_large-300x159.jpg]

Może już wiecie, że Cisco wypuścił własną wersję sieci określanej przez oprogramowanie - SDN (z ang. software-defined-network) pod nazwą Open Network One (ONE). Będzie ona wspierana przez Scrutinizer-a wkrótce. Technologia NetFlow bowiem będzie pełnić ważną rolę w monitoringu sieci SDN. Nasze oprogramowanie dostarczy szczegółowe dane dotyczące ruchu w twojej sieci w ramach NBAR czy VoIP.

Jak już wspomniano, switch Cisco Catalyst 3850 łączy bezprzewodowo przez wyjście o przepustowości 40 G, dla 50 punktów dostępu i 2000 użytkowników jednocześnie. A to nie wszystko! Mamy tutaj takie zaawansowane funkcje, jak wysokiej wydajności port GE 24/48, stakowanie typu 480G, funkcję Power over Ethernet Plus oraz StackPower. No i najważniejsze - na wszystkich portach mamy obsługę Flexible Netflow.

Jak widzicie, Cisco zrobił kawał porządnej roboty przy projektowaniu tego switch-a. Jeśli taki hardware zestawicie ze Scrutinizer-em, otrzymacie zestaw, który pozwoli wam swobodnie monitorować sieć.

Jeśli macie już jakieś doświadczenia z wykorzystaniem Scrutinzer na Cisco Catalyst 3850 – dajcie nam znać w komentarzach!

Jake@PLIXER
Link do oryginalnego postu.]]> Miło nam poinformować o kolejnym urządzeniu wspieranym przez aktualne wersje Scrutinizer-a. Jest nim Cisco Catalyst 3850. To cacko, w odróżnieniu od wersji 3750 może komunikować się bezprzewodowo. Równie istotne jest to, że natywnie wspiera NetFlow (bez wcześniej wymaganego modułu 3KX). Ten switch pozwala na wielopoziomową analizę wydajności w oparciu o takie dane jak: SSID (identyfikator sieci), klient, aplikacja czy „fair share policy” dla sieci bezprzewodowej, podczas gdy współpracujący z nim Scrutinizer monitoruje ruch sieciowy, jak również wszystkie powyższe parametry.

[Image: km_79293_large-300x159.jpg]

Może już wiecie, że Cisco wypuścił własną wersję sieci określanej przez oprogramowanie - SDN (z ang. software-defined-network) pod nazwą Open Network One (ONE). Będzie ona wspierana przez Scrutinizer-a wkrótce. Technologia NetFlow bowiem będzie pełnić ważną rolę w monitoringu sieci SDN. Nasze oprogramowanie dostarczy szczegółowe dane dotyczące ruchu w twojej sieci w ramach NBAR czy VoIP.

Jak już wspomniano, switch Cisco Catalyst 3850 łączy bezprzewodowo przez wyjście o przepustowości 40 G, dla 50 punktów dostępu i 2000 użytkowników jednocześnie. A to nie wszystko! Mamy tutaj takie zaawansowane funkcje, jak wysokiej wydajności port GE 24/48, stakowanie typu 480G, funkcję Power over Ethernet Plus oraz StackPower. No i najważniejsze - na wszystkich portach mamy obsługę Flexible Netflow.

Jak widzicie, Cisco zrobił kawał porządnej roboty przy projektowaniu tego switch-a. Jeśli taki hardware zestawicie ze Scrutinizer-em, otrzymacie zestaw, który pozwoli wam swobodnie monitorować sieć.

Jeśli macie już jakieś doświadczenia z wykorzystaniem Scrutinzer na Cisco Catalyst 3850 – dajcie nam znać w komentarzach!

Jake@PLIXER
Link do oryginalnego postu.]]> <![CDATA[Problemy z eksportem NetFlow w Cisco ASA]]> https://monitoringserwerow.pl/showthread.php?tid=34 Tue, 30 Jul 2019 10:07:10 +0000 ArturB]]> https://monitoringserwerow.pl/showthread.php?tid=34 Problemy z funkcją „flow-export active-refresh interval” w urządzeniach Cisco ASA

[Image: cisco-asa-netflow-flow-export-active-ref...oblems.png]

Jeśli właśnie zaktualizowałeś oprogramowanie Cisco ASA i natrafiłeś na problemy z funkcją „flow-export active-refresh interval”, to nie jesteś osamotniony z tym problemem. Sprawa dotyczy wersji 8.5(1), 8.6(1), 8.7(1), 9.0(1) oraz 9.1(1). Co ciekawe, w tych wersjach pojawiło się jednocześnie wiele przydatnych funkcji z zakresu Netflow Security Event Logging (NSEL). Więc o co tu chodzi?

Quote:
NSEL – wyjaśnienie
Funkcja „flow update” została stworzona po to, by móc okresowo zliczać bajty w danym strumieniu. Można ten okres (interwał) wydłużać lub skracać. Można również ustalić do jakiego analizatora zostanie wysłany strumień danych w jakim rozmiarze. W naszym oprogramowaniu występuję komenda „flow-export active refresh-interval”. Jest ona modyfikacją następującej komendy: „flow-export event-type”. Zaznaczam, że nasza funkcja nie jest dostępna w następujących wersjach oprogramowania Cisco ASA: 8.5(1), 8.6(1), 8.7(1), 9.0(1) oraz 9.1(1).


Najwyraźniej funkcjonalność związana z dwukierunkowym przesyłem strumieni oraz możliwość wykorzystania komendy „flow-export active refresh-interval” (interwał 1 minuta) zostały w jakiś sposób pominięte w nowszych wersjach softu Cisco. Warto wiedzieć, do czego te rzeczy służą:

Dwukierunkowy NetFlow: Większość rozwiązań bazujących na protokołach NetFlow lub IPFIX jest jednokierunkowa. Oznacza to, że połączenie TCP między dwoma hostami skutkuje dwoma strumieniami – np. A do B i z B do A. Brzmi to mało wydajnie, ale już wyjaśniam dlaczego musi tak być. Otóż generalnie oprogramowanie do analizy strumieni działa tak, że jest w stanie obsłużyć jeden strumień na jednym interfejsie. Stąd dwa strumienie – dla połączeń przychodzących i wychodzących. A powinno być tak, że obsługa strumieni dwukierunkowych jest zaimplementowania w oprogramowaniu zgodnie ze standardem RFC 5103, gdzie jeden strumień reprezentuje przepływ z A do B i jednocześnie z B do A. Naturalnie rozmiar takiego strumienia się podwaja, ale jednocześnie ilość strumieni jest dwukrotnie mniejsza, co ma znaczenie przy analizatorach obsługujących dużą ilość strumieni NetFlow. Jak dotąd, jedynie SonicWall IPFIX jest jedynym dostawcą, który wprowadził standard DFC 5103.
Cisco ASA natomiast wprowadził zamieszanie w wersjach softu powyżej 8.4(5). Nowsze wersje bowiem owszem, eksportują w jednym strumieniu informacje o przesyle w obie strony, ale podają informację o łącznej ilości danych przesłanych w obie strony. Nie dowiemy się natomiast, ile było wysłane z A do B, a ile z B do A.

Komenda "flow-export active refresh-interval": eksportery NetFlow posiadają funkcję określającą jak często strumień jest wysyłany do analizatora NetFlow. W przypadku ruterów Cisco jest to komenda „ip flow-cache timeout active”. Z kolei w Cisco ASA NetFlow jest to „flow-export active-refresh interval”. Problem w tym, że ta komenda jest dostępna tylko dla wersji Cisco ASA v8.4(5). We wszystkich innych wersjach eksport strumienia następuje dopiero po zakończeniu konwersacji. Staje się to problematyczne przy długich, ciągłych strumieniach. Trzeba wówczas czekać, aż tzw. tunel zostanie przerwany i wówczas eksportować dużą ilość danych za jednym razem, zamiast robić to co np. minutę. Na szczęście wieści z Cisco są takie, że komenda flow-export active refresh-interval będzie ponownie wprowadzona do wersji ASA v9.1(2).

Jeszcze słowo o dwukierunkowym NetFlow. Cisco ASA był pierwszym firewall-em który miał funkcję eksportera NetFlow, ale na rynku są też inni dostawcy podobnych rozwiązań. Dell SonicWALL i firewall-e firmy Palo Alto Networks również obsługują dwukierunkowy NetFlow. W przypadku SonicWALL akurat jest standard IPFIX który jest nieco innym standardem. Może też spotkać się z firewall-em Fortinet z eksporterem sFlow, jak również Barracudą ze wsparciem IPFIX.

Jak widać, Cisco ASA był pierwszy na rynku, ale od tego czasu konkurencja nie próżnuje. Inni producenci oferują w większości również bogate funkcje w zakresie informacji kontekstowych strumieni, takich jak nazwa użytkownika, status ACL (lista kontroli dostępu), adres MAC itd. Zaznaczam - „większość” dostawców, ponieważ np. eksporter sFlow Fortinet takich informacji nie podaje, a do tego jego dokładność jest problematyczna z uwagi na to, że strumień jest próbkowany.

Jeśli natrafiliście na problemy podobne do opisanych, zapraszamy do dyskusji.

Paul@PLIXER
Link do oryginalnego postu.]]> Problemy z funkcją „flow-export active-refresh interval” w urządzeniach Cisco ASA

[Image: cisco-asa-netflow-flow-export-active-ref...oblems.png]

Jeśli właśnie zaktualizowałeś oprogramowanie Cisco ASA i natrafiłeś na problemy z funkcją „flow-export active-refresh interval”, to nie jesteś osamotniony z tym problemem. Sprawa dotyczy wersji 8.5(1), 8.6(1), 8.7(1), 9.0(1) oraz 9.1(1). Co ciekawe, w tych wersjach pojawiło się jednocześnie wiele przydatnych funkcji z zakresu Netflow Security Event Logging (NSEL). Więc o co tu chodzi?

Quote:
NSEL – wyjaśnienie
Funkcja „flow update” została stworzona po to, by móc okresowo zliczać bajty w danym strumieniu. Można ten okres (interwał) wydłużać lub skracać. Można również ustalić do jakiego analizatora zostanie wysłany strumień danych w jakim rozmiarze. W naszym oprogramowaniu występuję komenda „flow-export active refresh-interval”. Jest ona modyfikacją następującej komendy: „flow-export event-type”. Zaznaczam, że nasza funkcja nie jest dostępna w następujących wersjach oprogramowania Cisco ASA: 8.5(1), 8.6(1), 8.7(1), 9.0(1) oraz 9.1(1).


Najwyraźniej funkcjonalność związana z dwukierunkowym przesyłem strumieni oraz możliwość wykorzystania komendy „flow-export active refresh-interval” (interwał 1 minuta) zostały w jakiś sposób pominięte w nowszych wersjach softu Cisco. Warto wiedzieć, do czego te rzeczy służą:

Dwukierunkowy NetFlow: Większość rozwiązań bazujących na protokołach NetFlow lub IPFIX jest jednokierunkowa. Oznacza to, że połączenie TCP między dwoma hostami skutkuje dwoma strumieniami – np. A do B i z B do A. Brzmi to mało wydajnie, ale już wyjaśniam dlaczego musi tak być. Otóż generalnie oprogramowanie do analizy strumieni działa tak, że jest w stanie obsłużyć jeden strumień na jednym interfejsie. Stąd dwa strumienie – dla połączeń przychodzących i wychodzących. A powinno być tak, że obsługa strumieni dwukierunkowych jest zaimplementowania w oprogramowaniu zgodnie ze standardem RFC 5103, gdzie jeden strumień reprezentuje przepływ z A do B i jednocześnie z B do A. Naturalnie rozmiar takiego strumienia się podwaja, ale jednocześnie ilość strumieni jest dwukrotnie mniejsza, co ma znaczenie przy analizatorach obsługujących dużą ilość strumieni NetFlow. Jak dotąd, jedynie SonicWall IPFIX jest jedynym dostawcą, który wprowadził standard DFC 5103.
Cisco ASA natomiast wprowadził zamieszanie w wersjach softu powyżej 8.4(5). Nowsze wersje bowiem owszem, eksportują w jednym strumieniu informacje o przesyle w obie strony, ale podają informację o łącznej ilości danych przesłanych w obie strony. Nie dowiemy się natomiast, ile było wysłane z A do B, a ile z B do A.

Komenda "flow-export active refresh-interval": eksportery NetFlow posiadają funkcję określającą jak często strumień jest wysyłany do analizatora NetFlow. W przypadku ruterów Cisco jest to komenda „ip flow-cache timeout active”. Z kolei w Cisco ASA NetFlow jest to „flow-export active-refresh interval”. Problem w tym, że ta komenda jest dostępna tylko dla wersji Cisco ASA v8.4(5). We wszystkich innych wersjach eksport strumienia następuje dopiero po zakończeniu konwersacji. Staje się to problematyczne przy długich, ciągłych strumieniach. Trzeba wówczas czekać, aż tzw. tunel zostanie przerwany i wówczas eksportować dużą ilość danych za jednym razem, zamiast robić to co np. minutę. Na szczęście wieści z Cisco są takie, że komenda flow-export active refresh-interval będzie ponownie wprowadzona do wersji ASA v9.1(2).

Jeszcze słowo o dwukierunkowym NetFlow. Cisco ASA był pierwszym firewall-em który miał funkcję eksportera NetFlow, ale na rynku są też inni dostawcy podobnych rozwiązań. Dell SonicWALL i firewall-e firmy Palo Alto Networks również obsługują dwukierunkowy NetFlow. W przypadku SonicWALL akurat jest standard IPFIX który jest nieco innym standardem. Może też spotkać się z firewall-em Fortinet z eksporterem sFlow, jak również Barracudą ze wsparciem IPFIX.

Jak widać, Cisco ASA był pierwszy na rynku, ale od tego czasu konkurencja nie próżnuje. Inni producenci oferują w większości również bogate funkcje w zakresie informacji kontekstowych strumieni, takich jak nazwa użytkownika, status ACL (lista kontroli dostępu), adres MAC itd. Zaznaczam - „większość” dostawców, ponieważ np. eksporter sFlow Fortinet takich informacji nie podaje, a do tego jego dokładność jest problematyczna z uwagi na to, że strumień jest próbkowany.

Jeśli natrafiliście na problemy podobne do opisanych, zapraszamy do dyskusji.

Paul@PLIXER
Link do oryginalnego postu.]]>