Log Analytics oraz syslog – dla początkujących

Mam w domu wiele urządzeń – zarówno sieciowych jak i IoT. Większość z nich potrafi wysyłać logi za pomocą syslog. Parę lat temu, aby mieć wgląd co się dzieje w mojej infrastrukturze na małym wirtualnym Linux postawiłem syslog-ng i wpadają tam różne zdarzenia z sieci.

Sęk w tym, że poza samym zbieractwem niewiele to wnosi. Oczywiście raz na jakiś czas przeglądam te logi, wyłapuję czy nie ma jakiś nieoczekiwanych zdarzeń w sieci itp. ale niestety za rzadko.

Prosi się o jakiś mechanizm, który będzie na bieżąco te logi śledził i wykonywał jakieś akcje po wykryciu danego zdarzenia. Niech będzie to choćby mail z informacją.

Tak – wiem, że da się to zrobić za pomocą samego Linuxa czy wykorzystując darmowe oprogramowanie… ja zrobiłem to wykorzystując chmurę.

Czemu chmurę?

1. Mam bezpieczny magazyn dla danych
2. Mam tam skalowalne rozwiązania, które „nie boją się” dowolnej ilości danych
3. Jest to okazja to poznania nowego narzędzia 🙂
   

Azure Log Analytics

Log Analytics to część większego zestawu rozwiązań Azure do monitoringu (Azure Monitor), prócz samego agregatora logów mamy jeszcze inne rozwiązania – takie jak Azure Automation do automatyzacji procesów, Security Center do analizy zdarzeń bezpieczeństwa w naszej infrastrukturze czy też Sentinel – SIEM w modelu SaaS.

Sam Log Analytics umożliwia zbieranie logów czy też zdarzeń z wielu źródeł, zawiera też dość złożone mechanizmy do analizy tych logów i automatyzacji zdarzeń (alertów). W połączeniu z innymi usługami pozwala również na wizualizację danych, telemetrię i inne. Skupmy się na tym co istotne – czyli jak wykorzystać Log Analytics do monitoringu zdarzeń z sysloga.

Co będzie nam potrzebne?

1. Dostęp do subskrypcji Azure.
   Log Analytics można uruchomić za darmo (https://azure.microsoft.com/free/)
2. Utworzona usługa Log Analytics
   Instrukcja tworzenia przestrzeni (Workspace) dla Log Analytics: https://docs.microsoft.com/azure/azure-monitor/logs/quick-create-workspace
3. Dowolny Linux, który znajduje się w naszej lokalizacji z zainstalowaną usługą syslog lub syslog-ng oraz agentem Azure Monitor (OMS)
   Instrukcja instalacji tego drugiego: https://docs.microsoft.com/azure/azure-monitor/agents/data-sources-syslog#configuring-syslog

Monitoring zdarzeń i tworzenie altertów

Jeśli zrealizowaliście punkty powyżej to do usługi Log Analytics powinny spływać już pierwsze zdarzenia z Waszego sysloga – można to sprawdzić wchodząc do menu General/Logs. W oknie zapytań wpisując polecenie „Syslog” (dużą literą) i klikając „Run”.

Jak widać na zdjęciu wyżej – w moim Log Analytics pojawiło się kilkanaście wpisów pochodzących z jednego z Mikrotików. Czas na wyfiltrowanie wpisów, które mają dla nas jakieś znaczenie z punktu widzenia np. bezpieczeństwa sieciowego.

Wyszukajmy w logach firewall Mikrotika zdarzeń, gdzie jakaś próba komunikacji została zablokowana, w moim przypadku będzie to próba połączenia z nieautoryzowanym serwerem DNS – innym niż domyślny, który kontroluję. W tym celu musimy utworzyć zapytanie w języku Kusto Query Language (KQL), by odfiltrować zdarzenia.
Definicje języka znajdziecie pod tym adresem https://docs.microsoft.com/azure/data-explorer/kusto/query/

Syslog
| project EventTime, HostIP, SyslogMessage, ProcessName
| where ProcessName == "firewall,info" and SyslogMessage has ":53,"
| sort by EventTime desc

Co realizuje powyższe zapytanie (w składni zbliżone do SQL):

1. (project) Określa kolumny jakie chcemy widzieć w raporcie
2. (where) Filtruje dane w określonych kolumnach – wyszukując zapytania o DNS szukam po prostu wpisu „:53,” w logach – na pewno można to zrobić w bardziej zaawansowany sposób – ale dla tego przykładu jest wystarczające…
3. (sort) to już dla własnej wygody – sortuję od najnowszych do najstarszych zdarzeń

Po weryfikacji czy zapytanie działa możemy przystąpić to utworzenia Alertu. W tym celu klikamy w górne menu i wybieramy opcję „+ New Alert rule”. Musimy zdefiniować tutaj kilka ustawień:

1. Scope
   Tu mamy filtr czego dotyczy alert. Domyślnie wybrana jest nasza subskrypcja Azure
2. Condition
   Kryteria, kiedy alert ma zostać wywołany – klikamy na pierwszą utworzoną domyślnie regułę.
   Możemy tam wybrać:
   1. Zmodyfikować treść zapytania
   2. Ustawić logikę alertów – np. ustalić przy jakiej ilości zdarzeń ma ona zostać wywołana
   3. I na końcu określić jaki zakres czasowy nas interesuje i jak często usługa ma sprawdzać, czy pojawiło się nowe zdarzenie.
3. Actions
   Tutaj definiujemy co ma się zdarzyć, po wystąpieniu alertu – np. możemy określić np. adres e-mail, na który ma zostać wysłany raport, określić tytuł wiadomości.
   Można również wykonać tutaj bardziej zaawansowane zdarzenia – automatyzację, która wykona jakąś operację za nas (np. wprowadzi zmiany w firewall na routerze).

Podgląd alertów

Każde zdarzenie wyłapane przez Log Analytics i reguły Alertów będzie widoczne w usłudze – w sekcji Monitoring/Alerts możemy podejrzeć historię zdarzeń, określić, które z nich rozwiązaliśmy (zamknąć alert).

To oczywiście nie koniec, wręcz początek przygody z usługą Log Analytics. Jeśli macie jakieś uwagi, ciekawe pomysły które można by zrealizować za pomocą Log Analytics dla domowej sieci – dajcie znać. Z chęcią umieszczę je na GitHub.