ITBlog

IT Blog w tematach różnych...

  • O blogu…
  • Edukacja
    • Moodle – stare
    • Moodle2
    • Testy
    • Wykłady IT
  • 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 (163)
      • AI (3)
      • Bezpieczeństwo (20)
        • Model AAA (7)
        • Szyfrowanie (1)
      • CCTV (3)
      • Hardware (2)
      • Podstawy informatyki (1)
      • Sieci (50)
        • Cisco (4)
          • Obsługa haseł (2)
        • MikroTik (8)
        • Monitorowanie sieci (6)
        • Pomiary w sieciach LAN (6)
          • iptraf-ng (3)
        • Protokół ARP (5)
        • Symulator sieci GNS3 (5)
        • Tunelowanie ruchu (6)
          • Tunele GRE (2)
          • Tunele SSH (4)
        • WLAN / WiFi (7)
      • Software (78)
        • Bazy danych (13)
        • Programowanie (21)
        • Systemy operacyjne (21)
          • Linux Debian (18)
        • Windows (8)
      • Wirtualizacja (26)
  • Ostatnie wpisy

    • Pomiary prędkości
    • SNMP-Exporter, Prometheus, Grafana + MikroTik
    • Monitorowanie sieci LAN za pomocą SNMP
    • Lokalny model Bielik dla Ollama
    • Hermes agent
  • Strona odwiedzona

    od 11.01.2013

  • Doskonała platforma e-learningowa Uzyskaj certyfikat IT

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

Powered by
Necessary cookies enable essential site features like secure log-ins and consent preference adjustments. They do not store personal data.
None
Functional cookies support features like content sharing on social media, collecting feedback, and enabling third-party tools.
None
Analytical cookies track visitor interactions, providing insights on metrics like visitor count, bounce rate, and traffic sources.
None
Advertisement cookies deliver personalized ads based on your previous visits and analyze the effectiveness of ad campaigns.
None
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
None
Powered by