ITBlog

IT Blog w tematach różnych...

  • O blogu…
  • Edukacja
    • Moodle – stare
    • Moodle2
    • Testy
  • Firma

Model AAA – Rozliczanie (część 2)

Napisane przez Igor Brzeżek on 23 października 2025
Napisane w: Model AAA.

Contents
  1. AAA: Rozliczanie w Praktyce – Centralne Logowanie
  2. Część 1: Budowa fundamentu – Centralny Serwer Syslog na Linux
  3. Krok 1: Instalacja i podstawowa konfiguracja `rsyslog`
  4. Krok 2: Automatyczna segregacja logów
  5. Krok 3: Finalizacja konfiguracji serwera
  6. Część 2: Konfiguracja urządzenia Cisco IOS
  7. Krok 1: Synchronizacja czasu (NTP) – Krok zerowy!
  8. Krok 2: Konfiguracja wysyłania logów Syslog
  9. Krok 3 (Zaawansowany): Rozliczanie każdej komendy z TACACS+
  10. Część 3: Konfiguracja urządzenia MikroTik RouterOS
  11. Krok 1: Synchronizacja czasu (NTP)
  12. Krok 2: Definiowanie zdalnej akcji Syslog
  13. Krok 3: Tworzenie reguł logowania
  14. Krok 4: Konfiguracja Firewalla do logowania
  15. Część 4: Analiza zebranych logów
  16. 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+

Uwaga: Poniższy przykład ma charakter poglądowy. Wymaga on działającego serwera TACACS+ (innego niż Syslog), ale doskonale ilustruje potęgę mechanizmów rozliczania.

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óż!

Nawigacja

← Anatomia ramki Ethernet i kwestia MTU
Model AAA – Rozliczanie (część 1) →
  • Szukaj

  • Kategorie

    • IT ogólnie (88)
      • Bezpieczeństwo (17)
        • Model AAA (7)
      • CCTV (3)
      • Hardware (1)
      • Sieci (17)
        • MikroTik (7)
        • Pomiary w sieciach LAN (6)
          • iptraf-ng (3)
        • Symulator sieci GNS3 (2)
      • Software (40)
        • Programowanie (2)
        • Systemy operacyjne (15)
          • Linux Debian (14)
        • Windows (7)
      • WiFi (2)
      • Wirtualizacja (26)
    • Różne (1)
  • Ostatnie wpisy

    • Elementy analizy ruchu sieci WiFi
    • Analiza ruchu w sieci LAN za pomocą iptraf-ng
    • Model AAA – wprowadzenie
    • Model AAA – Autentykacja (część 1)
    • Model AAA – Autentykacja (część 2)
  • Strona odwiedzona

    od 11.01.2013

  • Doskonała platforma e-learningowa Uzyskaj certyfikat IT

Proudly powered by WordPress Theme: Parament by Automattic.
7ads6x98y