Logging e Log Aggregation - Syslog, Windows Event e SIEM

Cos'e'

#

Il logging e' la registrazione sistematica degli eventi di sistema, rete e applicazione. Senza aggregazione centralizzata, i log restano distribuiti su centinaia di sistemi e un analista dovrebbe controllarne ognuno manualmente. La log aggregation risolve questo: porta tutto in un posto, normalizza i formati, e rende possibile la correlazione.

TL;DR

#

Ogni sistema genera log in formati diversi. Windows scrive Event ID nel formato XML. Linux scrive su /var/log in testo libero. Un firewall usa CEF. Un'app Node usa JSON. La log aggregation li raccoglie tutti, li porta a un server centrale via Syslog (UDP 514), li normalizza in un formato comune, e li rende disponibili per la correlazione SIEM. Senza questo pipeline, la detection di un attacco che attraversa sistemi diversi e' impossibile.

Mappa Logging

#

Sorgenti di Log

#

I log provengono da decine di sistemi diversi in formati diversi. Senza aggregazione, un analista SOC che indaga un incidente dovrebbe aprire ogni sistema separatamente, difficolta' amplificata se i sistemi sono centinaia in ambienti enterprise.

Windows Event Log

#

Windows organizza i log in canali. Per il Blue Team, il canale piu' rilevante e' il Security log, che registra tutti gli eventi di audit.

Event ID critici da conoscere:

Strumento di accesso: Event Viewer (GUI) o wevtutil / PowerShell per query programmatiche.

Linux /var/log

#

Linux distribuisce i log in file separati per categoria. La directory /var/log e' il punto di partenza per qualsiasi analisi.

Per visualizzazione e filtro: journalctl (systemd), grep, tail -f per real-time.

Nota: con systemd moderno, molti log passano per journald prima di arrivare in /var/log. journalctl interroga direttamente il journal binario con filtri avanzati per unit, priorita', e timerange. Vedi journalctl-vs-var-log per i dettagli.

Firewall Logs

#

I firewall log ogni connessione accettata o rifiutata, con IP sorgente, IP destinazione, porta, protocollo e bytes trasferiti. Per il Blue Team sono cruciali per: rilevare port scan (molti tentativi su porte diverse da stesso IP), identificare connessioni verso IP noti come C2, analizzare il traffico in uscita durante un'esfiltrazione.

DNS Logs

#

Tutti i resolver DNS moderni possono loggare ogni query. Questo e' particolarmente prezioso per il Blue Team perche' il traffico DNS e' quasi universalmente permesso in uscita, rendendolo un vettore preferito per C2 e DNS tunneling. Un dominio con 500 query in 10 minuti verso sottodomini casuali e' un segnale di DGA (Domain Generation Algorithm).

Protocollo Syslog

#

Syslog e' lo standard per trasmettere log da qualsiasi dispositivo (server, firewall, switch, router) verso un aggregatore centrale. E' il protocollo di trasporto, non un sistema di correlazione: i log arrivano, non vengono analizzati automaticamente.

graph LR
    HOST1[Server Linux
/var/log/auth.log]
    HOST2[Firewall Cisco
session log]
    HOST3[Windows Server
Event Log]
    HOST4[App Node
winston log]

    SYSLOG[Syslog Server
UDP 514 / TCP 6514]
    NORM[Normalizzazione
CEF / JSON]
    SIEM[SIEM
Correlazione]

    HOST1 -->|rsyslog| SYSLOG
    HOST2 -->|syslog UDP 514| SYSLOG
    HOST3 -->|NXLog / WEC| SYSLOG
    HOST4 -->|syslog-ng| SYSLOG
    SYSLOG --> NORM
    NORM --> SIEM

Syslog definisce formato e trasporto, NON la correlazione. La correlazione e' compito del SIEM.

Livelli di Severita' Syslog

#

I livelli vanno da 0 (Emergency) a 7 (Debug). In produzione, tipicamente si inviano al SIEM i livelli da 0 a 5 (fino a Notice). Il livello 7 (Debug) genera troppo rumore e viene tenuto locale.

NTP e Correlazione Temporale

#

Tutti i sistemi che inviano log al SIEM devono essere sincronizzati con lo stesso server NTP. Senza timestamp coerenti, la correlazione temporale diventa impossibile: un evento su Windows e la risposta su Linux potrebbero apparire in ordine inverso se i clock differiscono di 30 secondi.

Log Normalization

#

Ogni sistema scrive log in formati diversi. Prima di poter correlare, il SIEM deve normalizzare: tradurre tutto in un formato comune con campi standardizzati.

Esempio concreto:

PRIMA della normalizzazione:
- Windows: "An account failed to log on. Subject: Account Name: -. Failure Reason: Unknown user name or bad password. Source Network Address: 10.0.0.50"
- Linux: "Dec 15 14:32:01 server sshd[12345]: Failed password for root from 10.0.0.50 port 54321 ssh2"
- Firewall: "Dec 15 2026 14:32:01 fw01: %ASA-6-302013: Built inbound TCP connection for interface OUTSIDE:10.0.0.50/54321 to INSIDE:192.168.1.10/22"

DOPO la normalizzazione (campo comune nel SIEM):
{
  "timestamp": "2026-12-15T14:32:01Z",
  "event_type": "auth_failure",
  "source_ip": "10.0.0.50",
  "dest_ip": "192.168.1.10",
  "username": "root",
  "protocol": "SSH",
  "source": "linux_sshd"
}

Con i tre eventi normalizzati, il SIEM puo' correlare: stesso IP sorgente 10.0.0.50 ha tentato login su Windows, SSH su Linux, e aperto connessione TCP verso porta 22 in 1 secondo. Potenziale brute force distribuito.

Retention dei Log

#

Il periodo di conservazione dei log non e' solo una scelta tecnica ma un requisito di compliance.

Architettura tipica: storage caldo per i log recenti (30-90 giorni, su SSD, immediatamente ricercabili), storage freddo per l'archivio (S3, tape, meno costoso, retrieval piu' lento).

Dev parallel: in un'app Symfony/Node in produzione, i log applicativi esistono gia' (Monolog in Symfony, Winston in Node). Il passo da developer a security engineer e' questo: centralizzare quei log su ELK, Graylog o CloudWatch, aggiungere gli eventi di sicurezza che mancano (login, logout, cambio password, accesso a dati sensibili, chiamate ad endpoint critici), impostare alert su pattern anomali (1000 richieste allo stesso endpoint in 60s → brute force, non bug), e rispettare la retention minima richiesta. Il tuo /var/log/app.log in produzione non e' un file da leggere con tail -f in emergenza: e' una syslog source potenziale che dovrebbe stare gia' nel pipeline di aggregazione.

Scenario Reale

#

Un analista DFIR viene chiamato per investigare un breach. I dati esfiltrati erano dati clienti del database. Grazie alla log aggregation centralizzata, ricostruisce la timeline in ordine inverso: il firewall log mostra un trasferimento di 4GB verso un IP cinese alle 03:14. Il SIEM correla: alle 03:10 un account di servizio ha eseguito una query SELECT * massiva (log applicativo). Alle 02:58 quell'account e' stato autenticato da un IP in Romania invece che dal server applicativo solito (Windows Event 4624). Alle 02:45 un Event ID 4625 su quell'account con password sbagliata per 3 volte (brute force). Senza aggregazione centralizzata, ciascuno di questi 4 log sarebbe rimasto nel suo sistema e l'investigazione avrebbe richiesto giorni invece di ore.

Collegato a

#

• log — hub categoria logging
• siem-soar — il SIEM e' il consumer principale dei log aggregati
• auth-log — analisi pratica di /var/log/auth.log
• journalctl-vs-var-log — journald vs file-based logging su Linux
• wazuh-architecture — implementazione pratica di log aggregation nel vault
• dns-tunneling — rilevabile tramite DNS query logging