Graylog – centralne zarządzanie logami i analiza zdarzeń
Graylog to platforma do centralnego zbierania, przetwarzania, wyszukiwania i analizy logów. Jest szczególnie przydatna w środowiskach, gdzie mamy wiele serwerów, firewalli, aplikacji i urządzeń sieciowych.
W naszym zestawie narzędzi Graylog można umieścić tutaj:
INFRASTRUCTURE
|
+------------+------------+
| | |
Linux Firewall Network
| | |
+------------+------------+
|
Logs
|
v
Graylog
|
+----------+----------+
| | |
Search Alerts Dashboards
Graylog vs Loki vs Wazuh
To ważne, bo wszystkie trzy narzędzia pracują z logami, ale mają inne priorytety:
| Narzędzie | Główne zastosowanie |
|---|---|
| Loki | Logi + observability |
| Graylog | Centralne log management + analiza |
| Wazuh | Security monitoring / SIEM / XDR |
| Grafana | Wizualizacja |
| Prometheus | Metryki |
W uproszczeniu:
Loki → "Przechowaj i przeszukuj logi"
Graylog → "Zbierz, przetwórz i analizuj logi"
Wazuh → "Wykryj zdarzenia bezpieczeństwa"
Grafana → "Pokaż dane"
Architektura Graylog
Typowe środowisko wygląda mniej więcej tak:
Servers
Firewalls
Switches
Applications
|
v
Graylog
|
+----+----+
| |
Inputs Pipelines
| |
+----+----+
|
v
Search / Analysis
|
v
Dashboard
Graylog może przyjmować logi z bardzo wielu źródeł.
Syslog
Jednym z podstawowych zastosowań jest centralizacja sysloga.
Przykład:
Linux Server 1 ─┐
Linux Server 2 ─┤
Linux Server 3 ─┤
Firewall ───────┤
Router ─────────┤
Switch ─────────┤
|
v
Graylog
Zamiast logować się na każdą maszynę osobno, administrator ma jedno miejsce do analizy.
Graylog i firewall
To bardzo praktyczne zastosowanie.
Firewall
|
+-------------+-------------+
| | |
Allowed Blocked NAT
| | |
+-------------+-------------+
|
v
Graylog
Możemy później wyszukiwać:
source_ip
destination_ip
destination_port
protocol
action
timestamp
Graylog i urządzenia sieciowe
Graylog może centralizować logi:
- routerów,
- switchy,
- firewalli,
- VPN,
- serwerów,
- aplikacji.
Przykład:
Router
Switch
Firewall
VPN
|
| Syslog
v
Graylog
Dla administratora sieci jest to znacznie wygodniejsze niż analiza pojedynczych urządzeń.
Graylog Inputs
Graylog wykorzystuje Inputs do odbierania danych.
Przykładowo:
Syslog UDP
Syslog TCP
GELF
Beats
HTTP
Schemat:
Linux -------- Syslog ----\
Firewall ----- Syslog -----\
Application -- GELF --------> Graylog
Server ------- HTTP -------/
Graylog i GELF
GELF – Graylog Extended Log Format – jest formatem przeznaczonym do przesyłania strukturalnych logów do Grayloga.
Zamiast:
ERROR database connection failed
możemy mieć dane strukturalne:
level=ERROR
service=api
host=web01
message="database connection failed"
Dzięki temu znacznie łatwiej je później filtrować.
Log Processing
Graylog może przetwarzać dane przed ich zapisaniem.
Schemat:
Incoming Log
|
v
Parsing
|
v
Normalization
|
v
Enrichment
|
v
Storage
Przykładowo:
"Failed SSH login from 10.10.10.25"
może zostać rozbity na:
event=ssh_failed
source_ip=10.10.10.25
service=ssh
Pipelines
Graylog posiada mechanizm Pipelines, który pozwala definiować reguły przetwarzania logów.
Przykład logiczny:
IF
message contains "Failed password"
THEN
event_type = "ssh_auth_failure"
Następnie możemy:
ssh_auth_failure
|
+--> dashboard
+--> alert
+--> search
Streams
Graylog pozwala również organizować dane za pomocą Streams.
Przykładowo:
All Logs
|
+--> Linux
|
+--> Windows
|
+--> Firewall
|
+--> VPN
|
+--> Applications
|
+--> Security
To bardzo ułatwia organizację dużych ilości danych.
Graylog i wyszukiwanie
Jedną z największych zalet Grayloga jest możliwość szybkiego wyszukiwania.
Przykładowo:
source:10.10.10.25
albo:
level:ERROR
Możemy również zawężać wyniki po czasie, źródle czy określonych polach.
Graylog i SSH
Przykładowy przypadek:
SSH
|
+--> Failed login
+--> Failed login
+--> Failed login
+--> Successful login
|
v
Graylog
Możemy następnie sprawdzić:
Source IP
Username
Time
Host
Number of attempts
Graylog i brute force
Możemy zbudować regułę:
5 failed SSH logins
within 5 minutes
|
v
Alert
Schemat:
Failed login
Failed login
Failed login
Failed login
Failed login
|
v
Threshold
|
v
ALERT
To już przypomina funkcjonalność typową dla systemów bezpieczeństwa.
Graylog Alerting
Graylog może generować alerty na podstawie określonych warunków.
Przykład:
IF
HTTP 500 > 100
THEN
ALERT
albo:
IF
Failed SSH > 20 / 5 min
THEN
ALERT
Graylog + Wazuh
Te dwa rozwiązania mogą się uzupełniać.
Servers
|
+--------+--------+
| |
Graylog Wazuh
| |
Log Management Security Detection
| |
+--------+--------+
|
Analysis
Graylog może służyć jako centralna platforma log management, natomiast Wazuh jako warstwa bezpieczeństwa.
Graylog + Loki
Możliwe jest również wykorzystanie obu systemów, ale trzeba mieć konkretny powód.
Applications
|
+--------> Loki
|
+--------> Graylog
Nie zawsze jest to najlepsze rozwiązanie.
Jeżeli Graylog i Loki przechowują dokładnie te same logi, możemy niepotrzebnie podwoić:
- storage,
- transfer,
- koszty,
- obciążenie,
- administrację.
Dlatego warto wcześniej określić role:
Loki
→ observability
Graylog
→ central log management
Wazuh
→ security monitoring
Graylog + Grafana
Graylog posiada własne mechanizmy wizualizacji, ale może również współistnieć z Grafaną w większym środowisku.
Przykładowa architektura:
Prometheus ------> Grafana
|
Loki --------------- Grafana
Graylog -----------> Graylog UI
Wazuh -------------> Wazuh Dashboard
Nie trzeba więc wrzucać wszystkiego do jednego interfejsu.
Graylog + Kubernetes
W Kubernetes liczba logów może bardzo szybko rosnąć.
Kubernetes
|
+-------------+-------------+
| | |
Pod Pod Pod
| | |
Logs Logs Logs
+-------------+-------------+
|
Collector
|
v
Graylog
Możemy organizować dane według:
namespace
pod
container
node
application
environment
Graylog + Docker
Podobnie w Dockerze:
Docker Host
|
+--> nginx
+--> api
+--> redis
+--> postgres
|
v
Logs
|
v
Graylog
Dzięki centralizacji łatwiej analizować problemy występujące w wielu kontenerach jednocześnie.
Graylog jako element SIEM
Graylog może być używany jako element architektury SIEM, szczególnie do:
Log Collection
Log Processing
Search
Correlation
Alerting
Dashboards
Ale warto odróżnić platformę log management od kompletnego SOC.
Przykładowo:
Graylog
|
+--> Collect
+--> Parse
+--> Search
+--> Alert
|
v
Security Analyst
Graylog i bezpieczeństwo
Możemy centralizować:
Authentication
Firewall
VPN
SSH
Web Server
Database
Application
DNS
Network
A następnie budować reguły wykrywania.
Przykład:
VPN login
+
SSH login
+
New privileged account
|
v
Suspicious Activity
Graylog + Suricata
Możemy przesyłać zdarzenia Suricaty do Grayloga:
Network
|
Suricata
|
IDS/IPS Events
|
v
Graylog
|
+------------+------------+
| |
Search Alert
Daje to wygodny sposób centralnego analizowania zdarzeń IDS/IPS.
Graylog + Zeek
Podobnie można przesyłać dane z Zeeka:
Zeek
|
+--> conn
+--> dns
+--> http
+--> ssl
+--> ssh
|
v
Graylog
Dzięki temu Graylog może stać się centralnym miejscem analizy danych sieciowych.
Graylog + pfSense / OPNsense
W kontekście naszej wcześniejszej architektury jest to bardzo ciekawe.
Internet
|
pfSense / OPNsense
|
+--> Firewall Logs
+--> VPN Logs
+--> DNS Logs
|
v
Graylog
|
v
Security Dashboard
Administrator może wtedy analizować zdarzenia z firewalla razem z logami serwerów.
Centralny Security Log Management
Możemy zbudować:
Graylog
|
+---------------+---------------+
| | |
Linux Windows Network
| | |
SSH Event Log Firewall
| | |
+---------------+---------------+
|
Central Search
To jest jeden z podstawowych powodów stosowania Grayloga.
Graylog vs Wazuh
Najprościej:
| Cecha | Graylog | Wazuh |
|---|---|---|
| Centralne logi | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Wyszukiwanie logów | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Log processing | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Dashboardy | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| FIM | ❌ | ⭐⭐⭐⭐⭐ |
| Vulnerability Detection | ograniczone | ⭐⭐⭐⭐⭐ |
| Endpoint Security | ograniczone | ⭐⭐⭐⭐⭐ |
| SIEM/Security Detection | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Network logs | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
Czyli:
Graylog → Log Management
Wazuh → Security Platform
Graylog vs Loki
| Cecha | Graylog | Loki |
|---|---|---|
| Centralne logi | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Search | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Log processing | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Observability | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Grafana integration | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Kubernetes | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Security log analysis | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| SIEM use cases | ⭐⭐⭐⭐ | ⭐⭐ |
W środowisku mocno opartym o Grafanę + Prometheus Loki jest naturalnym wyborem.
Jeżeli priorytetem jest centralne log management, przetwarzanie i analiza logów z wielu urządzeń, Graylog staje się bardzo interesujący.
Graylog w pełnej architekturze
Patrząc na całą serię:
INTERNET
|
Firewall
|
+----------+----------+
| |
Suricata Zeek
| |
+----------+----------+
|
Network Security
|
+----------------+----------------+
| |
Servers Kubernetes
| |
+------+------+ +------+------+
| | | |
Wazuh Logs Wazuh Logs
| | | |
| Graylog | Graylog
| | | |
+-------------+--------------------+-------------+
|
Security / Logs
OBSERVABILITY
|
+----------+----------+
| |
Prometheus Loki
| |
+----------+----------+
|
Grafana
Najważniejsza różnica
Jeżeli mielibyśmy zapamiętać cały zestaw jednym zdaniem:
Prometheus → metryki
Loki → logi dla observability
Grafana → wizualizacja
Graylog → centralne zarządzanie i analiza logów
Wazuh → bezpieczeństwo endpointów + detekcja
Suricata → IDS/IPS
Zeek → analiza ruchu sieciowego
Graylog jest więc bardzo ciekawym ogniwem pomiędzy zwykłym centralnym logowaniem a pełnym monitoringiem bezpieczeństwa. Szczególnie dobrze pasuje tam, gdzie mamy dużo źródeł typu Linux + Windows + firewall + VPN + urządzenia sieciowe + aplikacje i chcemy mieć jedno miejsce do ich przeszukiwania, filtrowania, korelacji i generowania alertów.
Pierwsze uruchomienie laptopa Asus Pierwsze uruchomienie nowego laptopa Asus może być ekscytującym doświadczeniem. Jednak przed rozpoczęciem korzystania z komputera należy Czytaj dalej
Menedżer urządzeń – nieznane urządzenie – identyfikator ACPI\TOS6205. Co to jest? Sterownik Bluetooth – nie można zainstalować urządzenia. W laptopach Czytaj dalej
