- AAA: Rozliczanie w Praktyce – Centralne Logowanie
- Część 1: Budowa fundamentu – Centralny Serwer Syslog na Linux
- Krok 1: Instalacja i podstawowa konfiguracja `rsyslog`
- Krok 2: Automatyczna segregacja logów
- Krok 3: Finalizacja konfiguracji serwera
- Część 2: Konfiguracja urządzenia Cisco IOS
- Krok 1: Synchronizacja czasu (NTP) – Krok zerowy!
- Krok 2: Konfiguracja wysyłania logów Syslog
- Krok 3 (Zaawansowany): Rozliczanie każdej komendy z TACACS+
- Część 3: Konfiguracja urządzenia MikroTik RouterOS
- Krok 1: Synchronizacja czasu (NTP)
- Krok 2: Definiowanie zdalnej akcji Syslog
- Krok 3: Tworzenie reguł logowania
- Krok 4: Konfiguracja Firewalla do logowania
- Część 4: Analiza zebranych logów
- Podsumowanie Serii
AAA: Rozliczanie w Praktyce – Centralne Logowanie
Witaj w wielkim finale naszej serii o modelu AAA! W poprzednim artykule teoretycznym zrozumieliśmy, dlaczego Rozliczanie (Accounting) jest cyfrową pamięcią naszej infrastruktury, która odpowiada na kluczowe pytanie: „Co się wydarzyło?”. Dzisiaj zamieniamy tę wiedzę w działający, solidny system. Zbudujemy od podstaw centralny serwer logów na Linuksie, a następnie nauczymy nasze urządzenia sieciowe Cisco i MikroTik, jak posłusznie meldować mu o każdym swoim działaniu.
Ten artykuł to czysta esencja praktyki. Przejdziemy przez każdy krok instalacji i konfiguracji, od synchronizacji czasu po filtrowanie i analizę logów. Po ukończeniu tego tutorialu będziesz posiadać fundament pod profesjonalny system monitoringu i audytu, który jest absolutnie niezbędny do zapewnienia widoczności i odpowiedzialności w każdej sieci. Zakaszmy rękawy, bo czeka nas sporo konkretnej, technicznej pracy!
Część 1: Budowa fundamentu – Centralny Serwer Syslog na Linux
Naszym celem jest stworzenie jednego, bezpiecznego miejsca, do którego będą spływać logi ze wszystkich urządzeń. Użyjemy do tego demona rsyslog, który jest standardem w większości dystrybucji Linuksa (np. Debian, Ubuntu, CentOS).
Krok 1: Instalacja i podstawowa konfiguracja `rsyslog`
Zakładamy, że masz świeżo zainstalowany serwer Linux (np. Ubuntu Server 22.04). `rsyslog` jest zazwyczaj preinstalowany. Jeśli nie, instalacja jest prosta:
# sudo apt update && sudo apt install rsyslog
Teraz musimy skonfigurować rsyslog, aby nasłuchiwał na logi przychodzące z sieci. Edytujemy główny plik konfiguracyjny:
# sudo nano /etc/rsyslog.conf
Znajdź i odkomentuj (usuń znak `#` na początku) następujące linie, aby włączyć nasłuchiwanie na porcie 514 dla protokołów UDP i TCP.
# provides UDP syslog reception
module(load="imudp")
input(type="imudp" port="514")
# provides TCP syslog reception
module(load="imtcp")
input(type="imtcp" port="514")
UDP czy TCP? UDP jest szybszy i mniej obciąża zasoby (fire-and-forget), ale nie gwarantuje dostarczenia logów. TCP jest niezawodne (potwierdza dostarczenie), ale generuje większy narzut. Na początek i dla większości zastosowań UDP jest wystarczające. Włączenie obu opcji daje nam elastyczność.
Krok 2: Automatyczna segregacja logów
Nie chcemy, aby logi ze wszystkich urządzeń mieszały się w jednym wielkim pliku. Skonfigurujemy `rsyslog`, aby automatycznie tworzył osobne pliki dla każdego urządzenia na podstawie jego nazwy hosta lub adresu IP. Dodaj poniższy szablon na początku pliku /etc/rsyslog.conf, zaraz po sekcji modułów.
# Szablon do segregacji logów z urządzeń zdalnych
$template RemoteLogs,"/var/log/remotelogs/%HOSTNAME%.log"
*.* ?RemoteLogs
& ~
$template RemoteLogs,...: Definiuje szablon o nazwie „RemoteLogs”, który jako ścieżkę pliku wykorzystuje katalog/var/log/remotelogs/i dynamicznie wstawia nazwę hosta urządzenia wysyłającego log (%HOSTNAME%).*.* ?RemoteLogs: Ta reguła mówi: „Wszystkie logi (`*.*`) z urządzeń zdalnych przekieruj do szablonu `RemoteLogs`”.& ~: To bardzo ważna linia! Oznacza ona „zatrzymaj przetwarzanie tej wiadomości tutaj”. Bez tego, logi trafiłyby zarówno do naszego nowego pliku, jak i do domyślnych plików systemowych (np./var/log/syslog), powodując duplikację.
Krok 3: Finalizacja konfiguracji serwera
Musimy jeszcze stworzyć katalog na logi i otworzyć port w firewallu.
# sudo mkdir /var/log/remotelogs
# sudo chown syslog:adm /var/log/remotelogs
# sudo ufw allow 514/udp
# sudo ufw allow 514/tcp
# sudo systemctl restart rsyslog
Nasz serwer jest gotowy! Możemy śledzić, co się dzieje, za pomocą polecenia:
# sudo tail -f /var/log/remotelogs/*
Na razie nic się nie pojawi, ale okno z tym poleceniem zostawiamy otwarte. Będziemy obserwować, jak spływają do niego logi z naszych urządzeń.
Część 2: Konfiguracja urządzenia Cisco IOS
Teraz nauczymy nasz router Cisco, jak ma się meldować na serwerze. Zakładamy, że serwer Syslog ma adres IP 192.168.1.100.
Krok 1: Synchronizacja czasu (NTP) – Krok zerowy!
Jak wspominaliśmy w teorii, bez spójnego czasu analiza logów jest niemożliwa. To absolutna podstawa.
Router# configure terminal
Router(config)# ! Używamy publicznego serwera czasu w Polsce
Router(config)# ntp server pl.pool.ntp.org
Router(config)# ! Ustawiamy strefę czasową
Router(config)# clock timezone CET 1
Router(config)# clock summer-time CEST recurring
Krok 2: Konfiguracja wysyłania logów Syslog
To serce konfiguracji. Wskazujemy routerowi, gdzie ma wysyłać logi i jak bardzo ma być „gadatliwy”.
Router(config)# ! Wskazujemy adres naszego serwera
Router(config)# logging host 192.168.1.100
Router(config)# ! Ustawiamy poziom logowania. 'informational' (6) to dobry kompromis.
Router(config)# ! Poziomy: 0-Emergencies, 1-Alerts, 2-Critical, 3-Errors, 4-Warnings, 5-Notifications, 6-Informational, 7-Debugging
Router(config)# logging trap informational
Router(config)# ! Upewniamy się, że logi zawsze mają ten sam adres IP źródłowy (np. interfejsu LAN)
Router(config)# logging source-interface GigabitEthernet0/0
Router(config)# ! Dodajemy znaczniki czasu do logów
Router(config)# service timestamps log datetime msec
Router(config)# end
Router# write memory
W tym momencie w oknie konsoli serwera Syslog powinieneś zobaczyć pierwsze logi napływające z routera Cisco, zapisywane do pliku o nazwie hosta Twojego routera!
Krok 3 (Zaawansowany): Rozliczanie każdej komendy z TACACS+
Protokół TACACS+ pozwala na audyt każdej pojedynczej komendy wykonanej przez administratora. To najwyższy poziom odpowiedzialności.
Router(config)# ! Najpierw definiujemy serwer TACACS+
Router(config)# tacacs server MOJ_TACACS
Router(config-server-tacacs)# address ipv4 192.168.1.101
Router(config-server-tacacs)# key SekretDoTacacs
Router(config)# exit
Router(config)# ! Włączamy model AAA
Router(config)# aaa new-model
Router(config)# ! Włączamy rozliczanie dla wszystkich komend na poziomie 15
Router(config)# aaa accounting commands 15 default start-stop group MOJ_TACACS
Od teraz, każde polecenie wpisane w trybie `enable` (np. `show running-config`, `reload`) zostanie odnotowane na serwerze TACACS+ wraz z informacją o użytkowniku i dokładnym czasem.
Część 3: Konfiguracja urządzenia MikroTik RouterOS
RouterOS oferuje bardzo elastyczny system logowania oparty na tematach i akcjach. Skonfigurujemy go tak, aby wysyłał logi o bezpieczeństwie i firewallu na nasz serwer.
Krok 1: Synchronizacja czasu (NTP)
Podobnie jak w Cisco, zaczynamy od zegara.
[admin@MikroTik] > /system ntp client set enabled=yes primary-ntp=212.2.4.2 secondary-ntp=194.146.251.100
# Używamy polskich serwerów czasu
[admin@MikroTik] > /system clock set time-zone-name=Europe/Warsaw
Krok 2: Definiowanie zdalnej akcji Syslog
Tworzymy „cel”, do którego będziemy wysyłać nasze logi.
[admin@MikroTik] > /system logging action add name=send_to_syslog target=remote remote=192.168.1.100
Krok 3: Tworzenie reguł logowania
Teraz decydujemy, które „tematy” wiadomości mają trafić do naszej zdalnej akcji. To potęga RouterOS – możemy wysyłać różne logi w różne miejsca.
[admin@MikroTik] > # Reguła 1: Wysyłaj wszystkie ważne komunikaty systemowe (błędy, ostrzeżenia)
[admin@MikroTik] > /system logging add topics=critical,error,warning action=send_to_syslog
[admin@MikroTik] > # Reguła 2: Wysyłaj informacje o logowaniu i wylogowaniu użytkowników
[admin@MikroTik] > /system logging add topics=account action=send_to_syslog
[admin@MikroTik] > # Reguła 3: Wysyłaj informacje z firewalla
[admin@MikroTik] > /system logging add topics=firewall action=send_to_syslog
Krok 4: Konfiguracja Firewalla do logowania
Aby temat `firewall` generował jakiekolwiek logi, musimy włączyć logowanie w konkretnych regułach. Stwórzmy regułę, która będzie logować wszystkie próby połączenia z zewnątrz na porcie SSH (22) naszego routera.
[admin@MikroTik] > /ip firewall filter add chain=input protocol=tcp dst-port=22 connection-state=new \
action=add-src-to-address-list address-list="SSH Scanners" address-list-timeout=1d \
log=yes log-prefix="SSH_ATTACK_ATTEMPT"
[admin@MikroTik] > /ip firewall filter add chain=input connection-state=new src-address-list="SSH Scanners" action=drop
Od teraz każda nowa próba połączenia SSH z internetu zostanie zapisana w logu z prefiksem „SSH_ATTACK_ATTEMPT”, a następnie log ten zostanie wysłany na nasz serwer Syslog!
Część 4: Analiza zebranych logów
Wracamy do konsoli naszego serwera Syslog. Po chwili w katalogu /var/log/remotelogs/ powinny pojawić się dwa nowe pliki (lub więcej, jeśli dodałeś inne urządzenia), np. CiscoRouter.log i MikroTik.log.
Możemy teraz obserwować napływające dane i wyszukiwać interesujące nas zdarzenia.
# tail -f /var/log/remotelogs/CiscoRouter.log
Oct 16 22:10:15 CiscoRouter %SYS-5-CONFIG_I: Configured from console by admin on vty0 (192.168.1.50)
# tail -f /var/log/remotelogs/MikroTik.log
Oct 16 22:12:30 MikroTik firewall,info input: in:ether1 out:(none), proto TCP (SYN), 203.0.113.88:54321->192.168.88.1:22, len 52
# grep "Failed" /var/log/remotelogs/CiscoRouter.log
Oct 16 22:15:01 CiscoRouter %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: root] [Source: 10.1.1.1]
Mamy to! Działający, centralny system zbierania logów, który daje nam bezcenny wgląd w to, co dzieje się w naszej sieci. To fundament, który można dalej rozbudowywać, np. integrując go z systemami SIEM (ELK/OpenSearch, Splunk, Graylog) do automatycznej korelacji zdarzeń, analizy i alarmowania.
Podsumowanie Serii
Dotarliśmy do końca naszej podróży przez świat Authentication, Authorization i Accounting. Zaczęliśmy od teorii, a skończyliśmy na działającej, praktycznej implementacji, która jest kręgosłupem bezpieczeństwa każdej profesjonalnej sieci.
- Uwierzytelnianie pozwoliło nam pewnie odpowiedzieć na pytanie „Kim jesteś?”.
- Autoryzacja dała nam narzędzia do precyzyjnego zarządzania odpowiedzią na pytanie „Co Ci wolno?”.
- Rozliczanie, które właśnie wdrożyliśmy, zapewnia nam trwały zapis odpowiedzi na pytanie „Co zrobiłeś?”.
Te trzy filary, działając razem, tworzą solidną, wielowarstwową obronę. Zapewniają kontrolę, widoczność i odpowiedzialność – trzy cechy, bez których niemożliwe jest zbudowanie bezpiecznej i zarządzalnej infrastruktury IT. Mam nadzieję, że ta seria artykułów była dla Ciebie wartościowym i praktycznym przewodnikiem. Dziękuję za wspólną podróż!
