I quattro laboratori del modulo M2 sono un’unica catena: da un log si risale alla regola che lo ha prodotto, si corregge la policy, si ricollauda il traffico e solo alla fine si guarda il livello sotto, dove stanno routing e log di stato. Saltare un anello è il modo più comune di arrivare a una conclusione plausibile e sbagliata.

Leggere un log partendo dalla regola

La procedura documentata per analizzare una connessione scartata non comincia da Logs & Events: comincia dalla policy. In SmartConsole si apre Security Policies > Access Control > Policy, si seleziona la regola con azione Drop, e nel riquadro inferiore la scheda Logs mostra i log delle connessioni scartate da quella regola specifica; il doppio clic su una riga apre Log Details. È un filtro implicito, e vale più di qualunque ricerca scritta a mano.

Prima ancora va verificata la colonna Track. Nella Access Control policy il valore predefinito è None, che non genera alcun log: una regola muta non è una regola innocente. Log mostra tutte le informazioni che il Security Gateway ha usato per far corrispondere la connessione. Detailed Log ed Extended Log richiedono Application & URL Filtering, Content Awareness o Mobile Access, ed Extended aggiunge l’elenco completo di URL e file della connessione o della sessione. Accounting aggiorna il log ogni 10 minuti con byte caricati, byte scaricati e durata. A fianco stanno le reazioni — Alert, SNMP, Mail, User Defined Alert — e la modalità di generazione, per Connection oppure per Session.

Tracciare la regola con Packet Mode

La ricerca normale nella Rule Base è testuale: nome completo, prefisso, oppure asterisco per una sottostringa. Packet Mode è un’altra cosa. Simula il modo in cui un Security Gateway elabora un pacchetto reale, scandisce le colonne Source e Destination e restituisce tutte le regole e gli oggetti che corrispondono, gruppi annidati compresi, incluse le regole che usano Any e quelle con campi negati o esclusioni: esattamente le regole che una ricerca testuale non trova mai. Si attiva con Packet Mode > On o scrivendo mode:Packet, e si restringe con la sintassi ColumnName:Criteria. Il limite è dichiarato: Packet Search non supporta IPv6.

Da qui nasce la parte «Craft Policy». Se Packet Mode elenca tre regole candidate, il gateway ne applicherà una sola, la prima che corrisponde: riscrivere la policy significa quasi sempre spostare o restringere una regola troppo generica più in alto, non aggiungerne una nuova in fondo.

Collaudare policy e regole NAT

Un collaudo vale solo se il traffico è quello vero: stessa sorgente, stessa destinazione, stesso servizio. Installata la policy, si genera la connessione e si torna al log per leggere due cose in quest’ordine: quale regola ha fatto match, e quale azione ne è uscita. Se la regola colpita non è quella attesa, il problema è l’ordine della Rule Base. Se è quella giusta e l’azione è Accept ma la connessione non si stabilisce, la policy ha smesso di essere il sospettato e il caso si sposta su NAT, routing o destinazione.

Le regole NAT si collaudano con lo stesso metodo, confrontando gli indirizzi che compaiono nel log con quelli attesi: traffico che arriva a destinazione con l’indirizzo sbagliato è un problema di traduzione, traffico che non arriva e non lascia traccia è un problema più a monte.

Routing e log di stato

L’ultimo laboratorio guarda sotto la policy. Il demone di routing di Gaia può scrivere i propri messaggi in un file dedicato, /var/log/routed_messages, comportamento predefinito dalla R80 in poi: in clish si abilita con set routedsyslog on, si dimensiona con set routedsyslog size e set routedsyslog maxnum, e si rende permanente con save config. Su un cluster va configurato allo stesso modo su tutti i membri.

Il system logging di Gaia si interroga con show syslog logs, anche con l’opzione di ricerca, e con show syslog dmesg per il ring buffer; il file predefinito è /var/log/messages e si cambia con set syslog filename.

Lo stato dei processi si legge con cpwd_admin list: STAT vale E se il processo è in esecuzione e T se è terminato, MON dice se il monitoraggio di WatchDog è attivo (Y) o passivo (N), e #START conta quante volte WatchDog ha già riavviato quel processo. Un contatore #START che cresce mentre cerchi il colpevole nella policy è la risposta che stavi cercando altrove.

Trappole tipiche d’esame

  • Aprire i log prima di sapere quale regola cercare. Lo scenario descrive un sintomo e mostra righe di log: senza aver prima tracciato la regola che quel traffico dovrebbe colpire non hai un riferimento per giudicare se il match è corretto. Traccia, poi leggi.
  • Chiamare «problema di policy» un problema di routing. Se il log riporta Accept sulla regola giusta, la policy non è più la spiegazione. Un Drop registrato e un Accept senza connessione sono sintomi opposti e portano a reparti diversi.
  • Concludere senza aver guardato i log di stato. Prima di dichiarare colpevole una configurazione, verifica che i processi siano vivi e che il demone di routing non stia scrivendo errori: un processo che riparte di continuo produce sintomi identici a una regola sbagliata.
  • Dimenticare il Track. Con Track su None non esistono log: l’assenza di righe non prova che il traffico non sia passato di lì.