Il log di traffico è l’unica prova di cosa una policy ha davvero fatto a una sessione: quale regola l’ha presa, se ha tradotto gli indirizzi, quanti byte sono passati, come si è chiusa. In esame arriva sotto forma di estratto da leggere, quindi servono due cose: saper interpretare i campi e conoscere le impostazioni che decidono se quel log esiste. La seconda parte è quella che manda in crisi più candidati.

logtraffic: tre valori e un default che sorprende

Su ogni firewall policy il parametro logtraffic accetta tre valori. Con all vengono registrate tutte le sessioni accettate o negate dalla policy; con utm solo il traffico a cui è applicato un security profile; con disable il logging della policy è spento del tutto. Il default è utm.

Da qui nasce metà dei casi «la policy non logga». Una policy senza alcun security profile, lasciata al default, non produce nessun traffic log: non è il disco pieno e non è un bug, semplicemente non c’è nulla che generi la riga. Se ti serve visibilità piena su quella regola devi impostare all, sapendo che il volume cresce di conseguenza.

logtraffic-start, disabilitato per default, aggiunge un log all’apertura della sessione oltre a quello di chiusura. È utile sulle sessioni lunghe, che altrimenti compaiono solo quando terminano, ma raddoppia le righe: non abilitarlo a tappeto.

config firewall policy
    edit 1
        set name "LAN-to-WAN"
        set logtraffic all
        set logtraffic-start disable
    next
end

Anche le policy di deny loggano, se glielo chiedi: è così che si tiene traccia del violation traffic. L’implicit deny in fondo alla lista invece non produce nulla di suo, quindi per vedere cosa viene scartato serve una deny esplicita con il log attivo posizionata sopra di esso.

Dove finiscono le righe

Il FortiGate può scrivere in memoria di sistema, su disco locale, oppure spedire a FortiAnalyzer, FortiManager, FortiGate Cloud o syslog. Sul disco il logging va abilitato esplicitamente; per default i log più vecchi di sette giorni vengono cancellati e circa il 75% dello spazio è disponibile per lo storage, verificabile con diagnose sys logdisk usage.

config log disk setting
    set status enable
    set maximum-log-age 30
end

Verso FortiAnalyzer e FortiManager si usa lo stesso comando, config log fortianalyzer setting, dove l’opzione di upload sceglie fra invio in tempo reale e accumulo periodico; circa il 5% della memoria di sistema serve a bufferizzare questi log. Per syslog si possono configurare fino a quattro server, con formato default, CSV, CEF, RFC 5424 o JSON.

Su ogni destinazione si può filtrare in modo indipendente per severità e per categoria di traffico: forward, local, multicast e sniffer. È la leva giusta quando FortiAnalyzer deve ricevere tutto ma il syslog di terze parti solo gli eventi di sicurezza.

Un dettaglio che vale la pena ricordare: il local traffic logging, cioè il traffico diretto al FortiGate stesso, è disabilitato per default proprio per il volume che genererebbe. Si abilita in Log & Report, sezione Log Settings.

Leggere un estratto

Un traffic log di forwarding, ridotto ai campi che contano, si presenta così.

type="traffic" subtype="forward" srcip=10.1.100.102 srcport=56572
srcintf="port18" dstip=157.240.3.29 dstport=443 dstintf="port17"
policyid=1 poluuid="b740d418-8ed3-51e9-5a7b-114e99ab6370"
sessionid=42445 proto=6 action="server-rst" user="Jack" group="QA"
service="HTTPS" trandisp="snat" transip=172.16.200.2 transport=56572
duration=6 sentbyte=276 rcvdbyte=745 utmaction="allow"

Il campo subtype dice subito quale piano hai davanti: forward è traffico che attraversa il dispositivo, local è traffico da o verso il FortiGate stesso. policyid è la regola che ha preso la sessione e poluuid la identifica in modo stabile anche se gli ID vengono rinumerati: la presenza degli UUID nei traffic log è un interruttore nelle impostazioni globali, separato per policy e per indirizzi.

action non è mai «accept» e basta: valori come server-rst, timeout o deny raccontano come la sessione si è chiusa, ed è lì che si distingue un blocco del firewall da un reset arrivato dal server. trandisp e transip sono la prova che il source NAT è avvenuto e con quale indirizzo, il modo più rapido per verificare un IP pool senza aprire la session table. sentbyte e rcvdbyte sono relativi alla direzione originale della sessione, non al client. Infine utmaction riporta il verdetto dei security profile, che è cosa diversa dall’azione della policy.

Verificare che i log ci siano davvero

Sul dispositivo il logging è diviso fra tre demoni: miglogd costruisce e pubblica i log, locallogd gestisce la scrittura locale, fgtlogd l’invio remoto. Conoscerli serve perché i comandi di verifica sono separati.

execute log filter device disk
execute log filter category traffic
execute log display

diagnose test application locallogd 3
diagnose test application fgtlogd 1

Il primo blocco interroga i log memorizzati; locallogd 3 mostra i contatori per tipo di log divisi fra memoria e disco, ed è il modo più diretto per capire se le righe si stanno generando; fgtlogd 1 restituisce lo stato della connessione a FortiAnalyzer, incluso il filtro attivo e le sottocategorie di traffico abilitate.

Ultima cosa da sapere sui traffic log: il threat weight è attivo per default e aggiunge i campi crlevel, crscore e craction, che alimentano la dashboard Top Threats. Se in un estratto d’esame vedi un punteggio di rischio in una riga di traffico, viene da lì.