↓ Skip to main content
u-random
u-random
  1. Lab-blue/

[TODO] Lab - Syslog Centralizzato: Kali → Ubuntu (rsyslog)

·3 mins
base
Observability
Alessio Barnini
Author
Alessio Barnini
Table of Contents
[TODO] Lab - Syslog Centralizzato: Kali → Ubuntu (rsyslog)

Cosa fa
#

Configura rsyslog su Ubuntu come server centrale (receiver) e su Kali come client (sender). Ogni evento su Kali viene inviato a Ubuntu via UDP 514. Dimostra il concetto Gibson "Centralized Logging" — senza centralizzazione, un attaccante può cancellare i log locali dopo una compromissione.

TL;DR
#

Kali   (192.168.64.200) → rsyslog client: invia log a Ubuntu via UDP 514
Ubuntu (192.168.64.3)   → rsyslog server: riceve e archivia i log di Kali

Il concetto chiave: se Kali viene compromesso, l'attaccante può cancellare /var/log/ su Kali. Ma i log già inviati a Ubuntu sono al sicuro.

Obiettivo finale
#

Come sai che hai finito tutto: un evento generato su Kali (es. logger "test-event-kali") appare in /var/log/remote/192.168.64.200/*.log su Ubuntu entro pochi secondi; tcpdump -i eth0 udp port 514 su Ubuntu cattura i pacchetti syslog in arrivo da Kali.

Fase 1 — Configurazione rsyslog server (Ubuntu)
#

  • Task 1 — Abilita rsyslog come receiver UDP

    • In /etc/rsyslog.conf su Ubuntu: decommenta le righe module(load="imudp") e input(type="imudp" port="514")
    • Come sai che hai finito: ss -ulnp | grep 514 mostra rsyslog in ascolto su UDP 514

  • Task 2 — Configura directory separata per log remoti

    • Aggiungi template in rsyslog.conf per scrivere i log remoti in /var/log/remote/%HOSTNAME%/syslog.log
    • Come sai che hai finito: dopo restart di rsyslog, la directory /var/log/remote/ esiste

Fase 2 — Configurazione rsyslog client (Kali)
#

  • Task 3 — Configura Kali per inviare log a Ubuntu

    • In /etc/rsyslog.conf su Kali: aggiungi *.* @192.168.64.3:514 (UDP) o *.* @@192.168.64.3:514 (TCP)
    • Come sai che hai finito: systemctl restart rsyslog su Kali senza errori

  • Task 4 — Genera un evento di test

    • Da Kali: logger -p auth.warning "TEST: login fallito simulato da Kali"
    • Come sai che hai finito: il messaggio appare in /var/log/remote/ su Ubuntu entro 5 secondi

Fase 3 — Cattura e analisi
#

  • Task 5 — Cattura i pacchetti syslog

    • Su Ubuntu: tcpdump -i eth0 udp port 514 -A mentre generi eventi su Kali
    • Come sai che hai finito: vedi i payload syslog in chiaro — nota che UDP 514 non è cifrato (implicazione di sicurezza)

  • Task 6 — Simula cancellazione log locale

    • Su Kali: genera 3 eventi con logger, poi rm /var/log/syslog (o svuotalo)
    • Come sai che hai finito: il log locale è sparito, ma i 3 eventi sono ancora su Ubuntu — questo è il valore della centralizzazione

  • Task 7 — Differenza UDP vs TCP per syslog

    • Modifica Kali per usare TCP (@@) invece di UDP (@) e ripeti il test
    • Come sai che hai finito: sai rispondere: "perché TCP è preferibile a UDP per syslog in ambienti di sicurezza?" (hint: cosa succede se il server è down?)

Domande di verifica Security+
#

  1. Un attaccante compromette un server e cancella /var/log/auth.log. Se il syslog era centralizzato, cosa rimane? Se non era centralizzato?
  2. rsyslog su UDP 514 trasmette in chiaro. In uno scenario di attacco MITM sulla rete interna, cosa può fare l'attaccante con i pacchetti syslog intercettati?
  3. Syslog, Windows Event Log, e application log sono tre sorgenti diverse. Quale tool Gibson menziona per aggregarle tutte in un unico posto?
  4. Qual è la differenza tra un SIEM (come Wazuh) e un syslog server (come rsyslog)? Uno dei due può fare il lavoro dell'altro?

Collegato a
#

  • [[[DONE] lab-wazuh-siem-brute-force|lab-wazuh-siem-brute-force]] — step successivo: aggiungi analisi degli eventi al syslog centralizzato
  • cap-01-security-fundamentals — teoria Centralized Logging, Syslog, SIEM
  • mustache-project Sprint 1 — prerequisito per Wazuh multi-agent

Related