Iptables mette a disposizione la possibilità di loggare pacchetti per debugging e analisi del traffico.
Di fatto il log generato da iptables può essere utile sia per verificare le funzionalità delle regole inserite sia per essere analizzato da tool per creare statistiche e report.
Il logging viene abilitato tramite target LOG
che lavora in kernel space e usa syslog per scrivere i log o con ULOG
per trasmettere a programmi in user space le informazioni di log.
E' buon senso loggare solo i pacchetti che vengono bloccati, in modo da avere informazioni utili per troubleshooting (in fase di configurazione e test del firewall) e sicurezza (per capire i volumi e la qualità del traffico non desiderato).
A differenza di molti altri, i target LOG e ULOG non interrompono l'attraversamento di una catena: i pacchetti che matchano una regola di (U)LOG vengono loggati e continuano ad essere processati venendo gestiti da netfilter secondo le regole successive.
In un firewall, che di default blocca tutto, la regola di logging dovrebbe essere l'ultima prima del DROP di default.
Il target LOG
Il target LOG (-j LOG
) permette di definire diverse opzioni:
--log-level #
- Livello di logging, secondo le logiche di syslog, utile, insieme alla configurazione di syslog.conf, per loggare i dati sui pacchetti su file separato.
--log-prefix stringa
- Una stringa, lunga fino a 29 caratteri, che viene messa come prefisso alla riga di log, per renderlo più leggibile e associarlo ad un dato tipo di traffico
--log-tcp-sequence
- Logga il TCP sequence naumber. Dato sensibile, se accessibile ad altri utenti locali.
--log-tcp-options
- Logga le opzioni presenti nell'intestazione TCP
--log-ip-options
- Logga le opzioni presenti nell'intestazione IP (come il precedente può essere utile per strumenti di analisi dei log, altrimenti, se le informazioni aggiuntive non si reputano interessanti, è meglio disattivare)
--log-uid
- Logga lo UserID del processo che ha generato il pacchetto (in OUTPUT).
Il target ULOG
Meno diffuso e usato rispetto a LOG, ULOG fornisce maggiore flessibilità ed estende notevolmente il campo di applicazioni possibili.
Redireziona infatti in multicast il pacchetto che ha matchato la regola su una netlink socket a cui possono legarsi uno o più processi in userspace ricevendo i pacchetti senza che un loro eventuale malfunzionamento interrompa la gestione del traffico da parte di netfilter.
I programmi che ricevono i pacchetti li possono quindi trattare per molteplici scopi:
- Logging su database o in formati diversi da quello standard via syslog del target LOG
- Ispezioni dei pacchetti per matching su tipologie di traffico articolate, come le regole di un IDS quale SNORT
- Attivazione di meccanismi di Intrusion Prevention, interrompendo flussi di traffico indesiderati o pericolosi
Le applicazioni possono essere molte e modulari e possono essere sviluppate come componenti esterne al kernel.
Una di queste è ULogD che funziona come un servizio e utilizza diversi plugin per gestire i dati in vario modo, tra cui la possibilità di loggare su database MySQL o PostgreSQL
--ulog-nlgroup nlgroup
- Definisce il gruppo netlink (1-32) a cui è indirizzato il pacchetto. Di default è 1
--ulog-prefix prefix
- Come su LOG, imposta una stringa come prefisso alla riga di log (max 32 caratteri)
--ulog-cprange #
- Numero di byte da copiare in user space. Di default è 0 e l'intero pacchetto viene inviato
--ulog-qthreshold #
- Numero di pacchetti che il kernel deve avere in coda prima di inviarli al netlink. Default è 1
Esempi
Per loggare i pacchetti sulle catene di filter FORWARD, INPUT e OUTPUT aggiungendo in ogni riga di log adeguato prefisso.
iptables -A FORWARD -j LOG --log-prefix="FORWARD: "
iptables -A INPUT -j LOG --log-prefix="INPUT:"
iptables -A OUTPUT -j LOG --log-prefix="OUTPUT:"
Per loggare tutti i pacchetti UDP in INPUT con porta sorgente diversa da 137,138 e 139, inserendo come prefisso INPUT UDP:
iptables -A INPUT -p UDP --source-port ! 137:139 -j LOG --log-prefix="INPUT UDP:"
Per loggare tramite ULOG:
iptables -A INPUT -j ULOG --log-prefix="INPUT:"
In esecuzione sul sistema deve esserci us servizio come ulogd in grado di intercettare il multicast su netlink.
Un buona regola di log da appendere alla fine di una catena con policy di default DROP, può essere la seguente. Logga solo pacchetti di tipo unicast (comodo per evitare log di drop di multicast o broadcast inoffensivi) e con livello 7 di severity su sysylog (debug):
iptables -A INPUT -m pkttype --pkt-type unicast -j LOG --log-prefix "INPUT: " --log-level 7
Esempio di output di LOG su syslog
Feb 19 11:01:12 GIOVE kernel: FORWARD=eth1 OUT=eth0 SRC=192.168.0.98 DST=213.198.151.2 LEN=66 TOS=0x00 PREC=0x00 TTL=127 ID=165 PROTO=UDP SPT=1047 DPT=53 LEN=46