20. PLNOG: And the winner is...

W poprzednim wpisie wspomniałem o tematach zaprezentowanych na dwudziestej edycji PLNOG pod kątem bezpieczeństwa, jak i opisałem krótko swoje wrażenia. Trochę mnie gryzło, że ktoś nie zaznajomiony z PLNOGiem mógłby odnieść wrażenie, że na tej konferencji nie było zbyt wielu rzeczy godnych uwagi, dlatego dziś trochę w innym tonie.

Stwierdziłem, że nie ma sensu opisywać wszystkich prelekcji, a lepiej skupić się na jednej z tych, które były rzeczywiście w stanie przykuć mocno uwagę w temacie bezpieczeństwa IT. Do finału zakwalifikowałem 3 z nich, aby ostatecznie opisać tę poprowadzoną przez Pawła Wałuszko, pod tytułem „Jak zapobiegać wyciekom danych? 7 przykładów proaktywnego monitorowania sieci firmowych”.

Sam niedawno też musiałem stanąć przed wyborem oprogramowania monitorującego u jednego z klientów i generalnie rynek wygląda w ten sposób, że albo mamy do czynienia z ideą open source’ową (w wielu przypadkach jestem jej gorącym zwolennikiem) lub komercyjną, gdzie w przypadku średniej wielkości sieci, koszty licencyjne w razie jej powiększania potrafią rosnąć w tempie rzeżuchy! Niektórzy producenci rozwiązań komercyjnych dopuszczają oczywiście zastosowanie swojego oprogramowania w ograniczonym zakresie całkowicie za darmo (np. znany chyba większości PRTG), jednak w skali 100 sensorów, można to potraktować bardziej jako zabawę w sieci domowej. Niestety skalowalność tych popularnych rozwiązań również jest ograniczona i powyżej wartości kilkuset węzłów zaczynają się pewne problemy, o których można poczytać tu i ówdzie. Oczywiście alternatywą dla maruderów jest zakup jeszcze większego „kombajnu”, jakim chociażby jest SolarWinds. Tu ceny jednak już nie są wygórowane, ale wręcz kosmiczne!

Uważny czytelnik w tym momencie powinien zapytać o wspomniane powyżej rozwiązania open source. Racja. Szczególnie dwa z nich wydają się dość interesujące – Zabbix i Nagios, ale w związku z koniecznością sporego nakładu pracy przy ich konfiguracji i ograniczonej pod wieloma względami funkcjonalności, przełożę ten temat na osobny wpis.

Wracając do rzeczonej prezentacji, postanowiłem ją wyróżnić, bo uświadomiła mi ona kilka aspektów, których nie brałem pod uwagę podczas poszukiwań takiego oprogramowania, a między innymi:

• Kwestia regulacji RODO. Od maja na terenie UE zaczną obowiązywać przepisy, które nakładają na firmy i instytucje obowiązek wyjątkowo ostrożnego przetwarzania i przechowywania danych osobowych. Oprogramowanie monitorujące w większości przypadków jest wręcz niezastąpione w przeciwdziałaniu zagrożeniom, a w razie wycieku danych – zapewnia pełną dokumentację przebiegu procederu w swojej własnej bazie danych, co pozwoli łatwo stworzyć plan zapobiegania tego typu zagrożeniom na przyszłość.
• Prędkość działania aplikacji monitorującej. Przyznaję, że nie zwracałem wcześniej w ogóle uwagi na ten parametr. Uzmysłowiłem sobie za to, dlaczego tego faktu producenci zwykle nie uwypuklają. Podczas gdy większości aplikacji przeskanowanie sieci o wielkości kilkuset węzłów zajmuje godzinę lub więcej, polski NetCrunch tę samą mapę sieci wyświetli już po kilku minutach. Ktoś oczywiście może powiedzieć, że dla niego nie ma to większego znaczenia, ale jeśli popatrzeć na to z perspektywy nawet tylko jednego lub dwóch skanowań na dobę, to okazuje się, że można ograniczyć obciążenie sieci.
• Czytelność pulpitu. Monitorując już tylko kilka tysięcy metryk w niewielkiej sieci, odpowiednia organizacja informacji na ekranie powinna być dla administratora kluczową kwestią. Nie chodzi o to, by cały czas patrzeć w świecące się na zielono kontrolki, ale o to, by możliwie jak najszybciej dostrzec występujące anomalie i ocenić ewentualne zagrożenie.
• Alerty i możliwości ich konfiguracji. Przeczesując rynek programów do monitorowania sieci, nie da się nie zwrócić uwagi na funkcję alertów, natomiast kwestia ich elastycznego dopasowania do własnych potrzeb już nie wszędzie bywa tak oczywista.
• Możliwości szybkiej integracji systemu powiadomień z innymi systemami komunikacji wykorzystywanymi w firmie – Helpdesk, e-mail, SMS, a nawet SocialMedia.
• Wbudowana baza MIB. Jeśli nasz program takiej bazy nie ma, przypadku małych sieci nie będzie to aż tak istotne, ale jeśli mamy przygotować do monitorowania już kilkaset węzłów w niejednorodnej sieci (albo kilka tysięcy), kompilacja MIB do każdego modelu urządzenia może być już wyzwaniem, bez podjęcia którego nie ruszymy.
• Pakiety monitorujące. Automatyczna aplikacja ustawień monitorowania dla poszczególnych typów urządzeń, a także dostosowanie tych parametrów do swoich potrzeb pod kątem np. wartości granicznych potrafi znacznie ułatwić życie.

Jak napisałem już wcześniej, powyższe kwestie to tylko dodatkowe parametry, na które zwróciłem uwagę po zaprezentowaniu NetCruncha na PLNOG i późniejszej rozmowie o jego możliwościach. Nie wymieniałem ich wszystkich, bo od tego jest dokumentacja, a raczej skupiłem się na tych, które z punktu administratora sieci podniosą możliwości monitorowania, albo na dodatek... zrobią za niego to i owo.