Newsletter 7.0.5: Update majowy

Witajcie!

Powracamy z nowym zestawem informacji dotyczących Energy Logserver i jego aktualnej wersji - 7.0.5. Tym razem pragniemy zwrócić Waszą uwagę na nowe możliwości zarządzania danymi oraz naszą reakcję na obecne problemy z CentOS 7&8. Mam nadzieję, że poniższa wiedza będzie dla Was przydatna!

 

Możliwości zarządzania danymi

ARCHIWIZACJA WYBRANYCH PÓL

Podczas gdy przechowywanie logów ze względu na zgodność z przepisami jest czymś, co widzimy w prawie każdej organizacji, z którą współpracujemy – zakres dokumenty logu, który chcą przechowywać - jest różny. Dzięki nowo wprowadzonemu „archiwizowaniu wybranych pól” możesz wybrać dokładnie te pola z logu, które chcesz zapisać na swoim dysku. Po prostu utwórz nowe zadanie „Archive” i przefiltruj nazwy, które chcesz uwzględnić w raporcie:

W ten sposób może znacząco zoptymalizować swoją przestrzeń dyskową i szybkość wyszukiwania!

 

OBJECT PERMISSION - USUWANIE POWIĄZANYCH OBIEKTÓW

Teraz, usuwając obiekt, w polu „Object Permission” możesz zaznaczyć powiązane obiekty do usunięcia w tym samym czasie. Ma to na celu skrócenie czasu zarządzania dashboardami dzięki naszemu rozwiązaniu. Pamiętasz, kiedy trzeba było ręcznie usuwać każdą wizualizację z zapisanego dashboardu?

To już nie problem!

Nie, kiedy robisz to następująco:
Saved search à Visualization à Dashboard  -  Możesz usuwać dashboardy wraz z wszystkimi powiązanymi obiektami.

 

HARMONOGRAMOWANIE EKSPORTU DANYCH

Nowo dodany harmonogram pomaga zachować zgodność z powtarzającymi się żądaniami raportowania. Ta funkcja jest przydatna, gdy chcesz:

  1. Zautomatyzować określone zadania raportowania (np. Miesięczny raport wydajności aplikacji)
  2. Przygotować raport z określonej nadchodzącej daty (z harmonogramem nie musisz o tym pamiętać)
  3. Zrzucić surowe dane w zaplanowany sposób

Ta funkcja może być doskonałym dodatkiem zarówno do funkcji związanych ze zgodnością z regulacjami, jak i zarządzaniem danymi.

 

Aktualizacje techniczne

 IMPLEMENTACJA MOŻLIWA DLA ORACLE LINUX 7/8, CENTOS STREAM & SCIENTIFIC LINUX

Nasze implementacje są teraz dodatkowo możliwe dla Oracle Linux 7/8, Scientific Linux 7, Centos Stream (a także pierwotnie dla Centos 7/8 i RedHat7 / 8). Zdecydowaliśmy się na wprowadzenie nowych możliwości wdrożeniowych ze względu na ostatnie problemy z dystrybucją Linux Centos. Więcej w poniższym artykule: CentOS Linux is dead—and Red Hat says Stream is “not a replacement

 

Jako Twoje techniczne wsparcie - z przyjemnością omówimy tą sytuację i pomożemy Ci przygotować się na przyszłość!

Newsletter 7.0.5: Nowa wersja i ulepszone raportowanie

Witajcie.

Nadeszła nowa wersja! Energy Logserver jest obecnie w wersji 7.0.5. Planowaliśmy, że ta aktualizacja będzie mniejsza, obejmująca głównie zmiany w zakresie optymalizacji i stabilizacji. Okazało się jednak, że dodaliśmy istotne funkcje, nad którymi pracowaliśmy już przez jakiś czas. Poniżej znajduje się kilka najważniejszych informacji.

 

Główne zmiany

SUNBURST IOC

Dodaliśmy wykrywanie SUNBURST IOC do Energy Logserver. SUNBURST to poważne zagrożenie, które może zostać wykorzystać do wykradania poufnych informacji z organizacji, a nawet przejęcia kontroli nad zainfekowanymi systemami. Atak ten jest bardzo poważny i warto monitorować jego aktywność. Energy Logserver został wyposażony w predefiniowane alerty, których można użyć do wykrywania SUNBURST. Możesz przeczytać więcej tutaj https://energylogserver.pl/pl/detekcja-sunburst/

Alert przez syslog

Dodano funkcję do interfejsu alertów. Możesz wybrać metodę alarmowania jako wiadomość syslog. Jest to bardzo przydatne do integracji Energy Logserver z wieloma różnymi rozwiązaniami, które mogą odbierać dane lub sygnał za pośrednictwem syslog. Możesz wybrać hosta, port, protokół, severity i facility tej metody powiadamiania.

Obsługa znaków narodowych

Energy Logserver ma teraz pełne wsparcie dla znaków narodowych. Dzięki temu jest całkowicie gotowy na wszelkie niestandardowe dane z nietypowych źródeł. Każdy moduł Energy Logserver jest przygotowany do przetwarzania i działania ze 100% wydajnością z takimi danymi.

Ulepszone raportowanie

Raporty i eksporty zostały wzbogacone o dodatkowe informacje. Teraz możesz zobaczyć, kto i kiedy utworzył raport lub zadanie eksportu. Harmonogram raportów został zoptymalizowany i przeniesiony do tej samej karty, co twórca raportów. Dzięki tej aktualizacji masz jeszcze większą kontrolę i informacje o użytkownikach Energy Logserver. To kolejny krok w kierunku, aby zarządzanie użytkownikami Energy Logserver było tak łatwe i przejrzyste, jak to tylko możliwe.

 

Zajęliśmy się również jednym z najbardziej zagmatwanych tematów w elasticsearch: Keyword i Text - jaka jest różnica.

Zapraszam do przeczytania krótkiego artykułu tutaj: https://energylogserver.pl/pl/roznica-miedzy-text-a-keyword/

Jeśli cię to zaintereoswało, to kilka słów o optymalizacji powinno być czymś, o czym chcesz się dowiedzieć 🙂

Przeczytaj więcej na naszym blogu: https://energylogserver.pl/pl/slow-kilka-o-optymalizacji/

 

Bądźcie bezpieczni i szczęśliwego wyszukiwania!

Zespół Energy Logserver

Detekcja SUNBURST

SUNBURST to zagrożenie, które wykorzystuje oprogramowanie SolarWinds. Zagrożenie uzyskuje dostęp się do infrastruktury poprzez fałszywą aktualizację oprogramowania. Malware skonstruowany został tak dobrze, że pozostawał niewykryty przez długi czas. Bardzo sprytnie maskuje swoją komunikacje, udając prawdziwe połączenia. Wykorzystuje nawet natywne dla kraju adresy IP, celem uniknięcia rozpoznania anomalii.

Co nam grozi? Przede wszystkim ten wyrachowany atak ma na celu przekazanie informacji personalnych, loginach i hasłach użytkowników, danych osobistych, ale również – wgląd w tajemnice organizacji
i własności intelektualne, takie jak technologie i projekty. Finalnie SUNBURST pozwala osobom nieautoryzowanym na przejęcie kontroli nad systemem. Zagrożenie ze strony tej podatności jest bardzo poważne.

W Energy Logserver zebraliśmy dużą ilość informacji o tym zagrożeniu, a na ich bazie przygotowaliśmy zestaw reguł, pozwalających wykryć obecność SUNBURST w naszym środowisku.

Chociaż aktywność SUNBURST jest dobrze zamaskowana, nie jest niewykrywalna. Wbudowany w Energy Logserver system Threat Intelligence, po skonfigurowaniu jest w stanie łatwo zaobserwować ślady tej podatności. Agenci po dodaniu przynajmniej dwóch obiektów monitoringu mogą wysłać kluczowe informacje, które pomogą zidentyfikować zagrożenie.

Obiekty do monitoringu mogą być tak podstawowe, jak podsystem Windows Defendera oraz TaskScheduler. Zarówno Windows Defender jak i TaskScheduler mogą dostrzec próby charakterystyczne dla aktywności SUNBURST.

Ponadto nasza baza Threat Intelligence zawiera ponad 2100 charakterystycznych obiektów, które są identyfikowane z aktywnością SUNBURST lub malware związanych z SolarWinds. Ich typy dotyczą m.in. hashów plików, adresów IP, domen, itd.

Energy Logserver może zostać wzbogacony o paczkę predefiniowanych alertów dotyczących detekcji SUNBURST. Dodatkowo, wykorzystując metody dostępne w Energy Logserver, jesteśmy w stanie dokonać ulepszenia parserów celem precyzyjnej detekcji aktywności malware w środowiskach SolarWinds.

Słów kilka o optymalizacji

Pracjąc z elasticsearch nie sposób jest ominąć tematu optymalizacji shardów. Prędzej czy później każdy użytkownik bardziej rozbudowanego systemu będzie musiał podjąć się tego tematu. Niezoptymalizowane środowisko elasticsearch może skutkować powolnym indeksowanie danych, zwracaniem odpowiedzi, a nawet niestabilnym działaniem całego środowiska.

Im szybciej zrozumiemy skąd ten problem się bierze i im szybciej go zaadresujemy tym lepiej. Planowanie polityk shardów elasticsearch jest niezbędne aby zapewnić długotrwałe i stabilne działanie clustra. Warto też pamiętać, że shardy są niczym innym jak silnikiem Lucene, na bazie którego elasticsearch powstał.

 

Czym jest shard?

Index składa się z shardów i dzielimy je na primary i replica. Każdy shard trzyma jakąś część danych zgromadzonych w indexie, więc zbiór shardów primary w indexie będzie działał jak RAID 0. Dodatkowo każdy shard primary może mieć swoją replikę 1:1. Gwarantuje to dostępność danych w przypadku awarii clustra. Jeśli któryś shard primary przestanie być dostępny, jego replika go zastępuje.

 

Dyski

Często zdarza się, że środowiska elasticsearch, które odbierają dane nie są poprawnie zarządzane pod względem przestrzeni. Oznacza to, że dane wpuszczone do środowiska tam zostają na długi czas, niejako zapomniane. Indeksowanie dużej ilości danych bez odpowiedniego zarządzania szybko może pochłonąć nawet ogromne zasoby dyskowe. Powodem tego jest fakt, że repliki są kopiami 1:1 shardów primary.

Trzymając index (np. 100GB) z 4 shardów i każdy z nich ma swoje trzy repliki oznacza, że w mamy w sumie 15 shardów (4 primary + 12 replik) i 400 GB danych. Nietrudno zauważyć jak nieuwaga może doprowadzić do szybkiego zapełnienia dysku w takim scenariuszu.

Optymalizacja polega na kategoryzowaniu danych i przypisywaniu im odpowiedniej ilości shardów oraz replik. Oczywiście, każda replika zabrana oznacza większa podatność na permanentną utratę danych w przypadku awarii. Wiadome jest jednak, że nie każdy index jest krytyczny i dla tych o mniejszym priorytecie warto rozważyć jakiej ilości replik wymagają.

 

Pamięć

Elasticsearch jest oprogramowaniem stworzonym w java. Przypisany heap jest więc kluczowy dla poprawnego działania środowiska. Niepoprawne zaplanowanie zasobów pamięci serwera może przyczynić się do poważnej awarii wynikającej z braku dostępnej pamięci.

Jak ocenić ile pamięci węzeł elasticsearch wymaga? To zależy od wielkości clustra i ilości danych, które gromadzimy. Elasticsearch przetrzymuje dużo danych w pamięci, celem szybkiego dostępu. Rekomendowane jest, by węzeł elasticsearch nie posiadał więcej niż 25 shardów (primary jak i replik) na 1 GB pamięci w heap. Warto zaznaczyć, że elasticsearch nie jest w stanie tego limitować za nas. Jest to jedna z fundamentalnych czynności administratora, aby monitorować ilość shardów per pamięć heap.

 

Performance

Jeśli chodzi o optymalizację zapytań, tuta żadną wiedzą tajemną nie jest fakt, że głównym elementem jest struktura zapytania i zakres danych, na których te zapytanie jest wyzwolone. Innymi słowy: szybciej zwrócona zostanie odpowiedź z danych o wielkości 100GB niż z danych o wielkości 500GB.

Im bardziej skomplikowane zapytanie i na większej ilości danych zostanie uruchomione tym później otrzymamy odpowiedź. Dlatego ważne jest wyrównanie zależności pomiędzy ilością shardów, a ich rozmiarem.

Rekomendowane jest, by jeden shard zawierał pomiędzy 20GB a 40GB danych. Dlatego jeśli mamy index o wielkości 100GB danych, warto przydzielić mu sumarycznie 4 shardy primary. Repliki nie są wliczane do tego zabiegu optymalizacji, jako że trzymają one kopie danych 1:1 shardów primary.

 

Podsumowanie

Powyższe aspekty pokazują, że chociaż elasticsearch jest potężnym narzędziem i jednym z najlepszych silników do zarządzania dużą ilością danych, to wciąż wymaga dokładnej uwagi pod względem optymalizacji. Dobre zaplanowanie struktury indexów i shardów pozwoli cieszyć się stabilnym i bardzo wydajnym środowiskiem clustra.

Różnica między Text a Keyword

W elasticsearch występują dwa typy danych, które często bywają kłopotliwe dla osób niedoświadczonych w pracy z systemem – Keyword i Text. Oba typy są rodzajem stringa, ale elasticsearch inaczej je interpretuje, przez co można na nich wykonać inne operacje.

 

Skąd się bierze typ pola?

Ogółem, to jakim typem jest pole, określa template. Jest to wzorzec tworzenia indexów w elasticsearch – w tym mapowania pól. Jeśli dany template nie określa jasno jakiego typu ma być dane pole, elasticsearch domyślnie stworzy dynamiczny mapping dla typów Keyword i Text. Nie jest jednak to rekomendowane ze względu na przestrzeń dyskową jaką można zaoszczędzić poprzez planowanie przypisanych typów do pól.

 

Index odwrócony

Aby zrozumieć wagę problemu, należy spojrzeć na odwrócony index elasticsearch[1].  Jest to specyficzny sposób w jaki system zapisuje dane i to dzięki temu rozwiązaniu elasticsearch jest bardzo szybki w zwracaniu odpowiedzi nawet w dużej skali czasu.

Odwrócony index działa podobnie do indexu w niektórych książkach. Na końcu książki można znaleźć listę wyrazów z informacją na których stronach się te wyrazy pojawiły. Elasticsearch robi dokładnie to samo dla każdego wyrazu z informacją w którym dokumencie się znajduje.

Przykład dokumentu

Dla przykładu spójrzmy na dokument o id "moj-dokument". Ma on pole "adres", a wartość tego pola to "Wiejska 20, Warszawa".
POST "localhost:9200/moj-index/_doc/moj-dokument" -d'
{
"adres" : "Wiejska 20, Warszawa"
}'

Poniżej prezentacja, jak widzi to elasticsearch w odwróconym indexie dla typów

Keyword

 

Text

Różnica w zapytaniu

Elasticsearch po otrzymaniu zapytania najpierw sprawdza index odwrócony pod względem dopasowania. Jeśli je znajdzie, wyświetla dokumenty, które odpowiadają temu zapytaniu. Dlatego jeśli odpytamy elasticsearch o wartość „Warszawa”, dokument z typem Keyword może nie zwrócić rezultatu, ponieważ wartość to dosłownie „Wiejska 20, Warszawa”. Odwrotnie jest w przypadku typu Text - ponieważ zawartość pola została przeanalizowana, elasticsearch jest w stanie odnaleźć pojedyncze wyrazy w odwróconym indexie i zwrócić odpowiedź w postaci dokumentu.

Oczywiście istnieją jeszcze różne rodzaje zapytań do Elasticsearch i w zależności od tego, które zostaną użyte, można otrzymać różne wyniki. Ta kwestia jednak nie dotyka bezpośrednio różnic w samych typach pól.

 

Podsumowując

Różnice między tymi dwoma polami są znaczące. Generalnie używamy typów keyword dla stałych wartości w danych, których nie chcemy analizować, np. nazwa kraju, aplikacji, itp. Typu Text używamy, kiedy musimy skorzystać z mocy przeszukiwania pełnotekstowego, np. w polu message, które zawiera oryginalną wiadomość z systemu.

 

 

 

[1] Po prawdzie, odwrócony index jest właściwością silnika Apache Lucene, na bazie którego powstał Elasticsearch. Celem ułatwienia zrozumienia problemu, użyto skrótu myślowego.

Newsletter 7.0.4 aktualizacja luty: Wiki

Witamy

Drugi miesiąc minął naprawdę szybko w Energy Logserver. Jesteśmy pełni motywacji, bo wydaje się, że każdy dzień przynosi nowe wyzwania.

Obecnie pracujemy nad kilkoma przełomowymi modułami dla Energy Logserver. W tej chwili zakończyliśmy dopracowywanie i aktualizację istniejących funkcji i chętnie podzielimy się informacjami. Aby poznać interesujące funkcje, zarejestruj się na nasze webinarium, więcej informacji poniżej:

 

Webinar Energy Logserver 7.0.4 – Widoki użytkownika i zaawansowane uprawnienia

25.03.2021 10:00 czasu polskiego

https://zoom.us/webinar/register/WN_UZscLOiwRbm1FzHa0_mPeQ

 

Główne zmiany

Widoki niestandardowe
Role mogą teraz mieć przypisane uprawnienia do modułów, które pozwolą tworzyć dedykowane widoki użytkowników. Ta zaawansowana, ale łatwa w użyciu funkcja pozwala na takie przypadki użycia, jak:
- Tworzenie dedykowanego widoku wizualizacji dla zespołów analitycznych, które nie muszą widzieć tekstowych danych.
- Widoki SOC, które muszą widzieć jasne informacje i muszą mieć możliwość przełączania się między danymi z różnych modułów.
- Twórzenie przejrzystych i oddzielnych widoków dla różnych działów, nawet jeśli dane są nadal scentralizowane w jednym środowisku.

Wiki
Energy Logserver ma teraz wbudowane rozwiązanie wiki. Pozwala to tworzyć i zachować łatwą do odczytania dokumentację i informacje o Twojej infrastrukturze. Używając Wiki z Energy Logserver, upewniasz się, że informacje są łatwe do odczytania i dostępne tylko dla tych, którzy powinni mieć do nich dostęp.

WEC
Windows Event Forwarding (WEF) to częsty temat rozmów w środowisku z dużą infrastrukturą systemu Windows. Chodzi o to, aby mieć możliwość udostępniania danych bez instalowania agenta. Dlatego też wymagane jest, aby kolektor zdarzeń, zwany Windows Event Collector (WEC) był jednocześnie komputerem z systemem Windows, co powoduje pewne problemy w utrzymaniu i monitorowaniu. Opracowaliśmy niezależne rozwiązanie, które jest przeznaczone do wysyłania danych z systemów Windows do systemu Linux!
Energy Event Collector jest zaprojektowany do korzystania z natywnej technologii Windows, ale rozszerza jego funkcje z zamkniętego środowiska i pozwala na bardziej elastyczne podejście.
Więcej informacji można znaleźć tutaj: www.eventcollector.com

Archiwum
Automatyczna archiwizacja danych jest ważnym aspektem zarządzania przestrzenią dyskową wewnątrz Energy Logserver. Ten moduł został wprowadzony w poprzednim biuletynie. Warto podkreślić, jak ważne jest zarządzanie retencją danych. Stale ulepszamy i optymalizujemy funkcje modułu archiwum.

Jeśli przegapiliście nasz ostatni webinarium na temat modułu archiwum, zapraszamy do obejrzenia nagranego materiału na naszym kanale Youtube tutaj: https://youtu.be/FsB29W7bqGI

Bądźcie bezpieczni i szczęśliwego wyszukiwania!
Zespół Energy Logserver

Integracja ze skanerami podatności

Luki i podatności są częstym problemem w społeczności IT. Niektóre są poważne, inne - nie tak bardzo. Najważniejsze jest, aby wiedzieć, czy w naszych systemach występują, jak bardzo są one krytyczne i jak można je naprawić. Istnieją narzędzia, które mogą pomóc w uzyskaniu tych informacji, zwane skanerami podatności.

Skanery podatności sprawdzają Twoje systemy i aplikacje, szukając znanych exploitów lub backdoorów. Podobnie jak oprogramowanie antywirusowe, programy te mają własne bazy danych, które wymagają regularnej aktualizacji. Raporty z takiego skanu mogą być jednak długie i trudne do analizy.

Energy Logserver ma dobrą wiadomość dla wszystkich, którzy chcą zwiększyć widoczność i korelację bezpieczeństwa w swoim środowisku. Obecnie integrujemy się z wiodącymi rozwiązaniami: Qualys, Tennable.sc i oczywiście OpenVAS 🙂

Oprócz tej integracji dodaliśmy również nowy dashboard przeznaczony dla skanerów podatności. Oznacza to, że możemy nie tylko zbierać dane i integrować się ze skanerami podatności, ale także dajemy ci możliwość dokładnego spojrzenia w to, co zostało wykryte w twojej infrastrukturze i skorelowania te informacje z danymi z różnych źródeł.

Interaktywny dashboard jest wyposażony w listę znalezionych problemów i zalecanych rozwiązań, listę głównych hostów z wykrytymi lukami oznaczonymi kolorami i wiele innych.

Jeśli jesteś zainteresowany tą funkcjonalnością lub twoja wersja Energy Logserver nie posiada tej integracji skontaktuj się z naszym zespołem lub wyślij maila na sales[at]energylogserver.pl

Newsletter 7.0.4 i Webinar: Moduł archiwum

Witamy.

Na wstępie życzymy szczęśliwego Nowego Roku od całego zespołu Energy Logserver.
Z przyjemnością informujemy, że Energy Logserver jest obecnie w wersji 7.0.4.
Ta wersja przynosi niesamowite zmiany wraz z nowym modułem - archiwum, który pozwala zarządzać automatyczną archiwizacją danych. Więcej o tym poniżej.

Jeśli chcesz zobaczyć nowe funkcje w akcji, zapraszamy na nadchodzący webinarium!

Webinar Energy Logserver 7.0.4 - Moduł archiwum
21.01.2021 10:00 AM

https://zoom.us/webinar/register/WN_sseWJaxzRmW6m_a7hR93uA

Główne zmiany

Nowy moduł: Archiwum
Pozwala skonfigurować automatyczną archiwizację wybranych indeksów i wysyłać je we wskazane miejsce. Co więcej, dzięki temu modułowi możesz przeszukiwać zarchiwizowane dane bez przenoszenia ich z powrotem do systemu. Proces przywracania również jest naprawdę prosty - po prostu wybierz archiwa, które chcesz przywrócić i gotowe!

Ulepszony moduł zarządzania agentami
Zarządzanie agentami nie tylko wygląda lepiej, ale teraz daje również możliwość zdalnej kontroli żądanego agenta. Ponadto możesz monitorować / zmieniać konfiguracje niestandardowe, niezwiązane z agentami Energy Logserver.

Nowa domyślna integracja
Dodaliśmy nową integrację do Energy Logserver. Teraz Energy Logserver 7.0.4 jest domyślnie zintegrowany ze skanerami luk w zabezpieczeniach i oferuje niesamowity pulpit nawigacyjny do wizualizacji wszystkich zebranych danych.

Ulepszone alerty
Moduł alertów obsługuje teraz zmianę nazw istniejących alertów (wiemy, że wielu z Was na to czekało 😉 ) ale co więcej, można grupować alerty, np. grupa dla Windows, itp. Ponadto dodaliśmy obsługę GUI do powiadamiania na Slack i OP5 Monitor. I wreszcie - dodaliśmy dwie nowe opcje:
• Calendar, który pozwala zarządzać czasem powiadomień o alertach w oparciu o format cron
• Escalate, która powoduje eskalację alarmu po określonym czasie.

Pełna lista zmian znajduje się na stronie: https://kb.energylogserver.pl/en/latest/CHANGELOG.html

Jeśli szukasz interesujących przypadków użycia Energy Logserver, znajdziesz kilka poniżej lub możesz też je przeczytać na blogu na naszej stronie:

Wykrywanie i alertowanie logowań po godzinach pracy
https://energylogserver.pl/pl/wykrywanie-i-alertowanie-logowan-po-godzinch-pracy

Wykrywanie i alertowanie anomalii w ruchu sieciowym
https://energylogserver.pl/pl/wykrywanie-i-alertowanie-anomalii-w-ruchu-sieciowym

Wykrywanie i alertowanie ataków ddos w energy logserver
https://energylogserver.pl/pl/wykrywanie-i-alertowanie-atakow-ddos-w-energy-logserver

Bądźcie bezpieczni i szczęśliwego wyszukiwania!
Zespół Energy Logserver

Wykrywanie i alertowanie logowań po godzinch pracy

Jest to jeden z najczęstszych alertów i można go łatwo stworzyć z pomocą Energy Logserver. Co więcej - taki alert jest już zdefiniowany i domyślnie umieszczany w paczce instalacyjnej systemu Energy Logserver. W przypadku użytkowników systemu Windows wykrywamy logowania w nocy.

W niektórych wdrożeniach, alert ten został zmodyfikowany dla użytkowników systemu Linux lub użytkowników usług dedykowanych, które nie są związane z określonym systemem operacyjnym.
Taka konfiguracja reguł nie może być prostsza:

Co więcej, do każdego alertu możemy dodać opcję kalendarza, więc taki alert będzie wyzwalany na podstawie formatu crontab, na przykład:

calendar:
  schedule: "* 0-8,16-23 * * mon-fri"

Wykrywanie i alertowanie anomalii w ruchu sieciowym

Do monitorowania anomalii w ruchu używamy różnych podejść. Oczywiście możemy obsługiwać takie zdarzenia w Energy Logserver dedykowaną sondą sieciową, która jest wyposażona w moduł Netflow Analazing i domyślnie wykrywa anomalie. Takie sondy odbierają przepływ sieciowy z wybranego span portu i mogą być również używane jako urządzenie wirtualne.

Niezależnie od zastosowania sondy - w Energy Logserver używamy do tego naszego modułu alarmowego, w którym wybieramy odpowiednie podejście.
W przypadku niektórych klientów używamy typu Metric Aggregation, w którym ustalamy próg wysyłanych / odbieranych danych.

Ale Energy Logserver ma również zestaw predefiniowanych alertów, a wśród nich są: Netflow - DNS traffic abnormal typu Spike. Ta reguła działa na zasadzie porównaniu rzeczywistych ram czasowych z poprzednimi i obliczeniu różnicy między nimi. W ten sposób wykrywamy nagły wzrost (lub spadek) wybranego wzoru.

Innym podejściem jest monitorowanie nowych, nie widzianych wcześniej wartości w wybranym polu (jak nowy adres url w naszych logach) per użytkownik, źródło lub inny parametr.

 

Energy Logserver może łączyć ze sobą wiele alertów w jeden, skorelowany przez pola i warunki z typami Chain lub Logical.