Debugger per Iptables

47

Sto cercando un modo semplice per seguire un pacchetto attraverso le regole di iptables. Non si tratta tanto di registrazione, perché non voglio registrare tutto il traffico (e voglio avere target LOG solo per pochissime regole).

Qualcosa come Wireshark per Iptables. O forse qualcosa di simile a un debugger per un linguaggio di programmazione.

Grazie Chris

Nota: non deve essere uno strumento GUI di fantasia. Ma deve fare di più che mostrare un contatore di pacchetti o giù di lì.

Aggiornamento: sembra quasi che non riusciamo a trovare nulla che fornisca la funzionalità richiesta. In tal caso: troviamo almeno una buona tecnica basata sulla registrazione di iptables, che può essere facilmente attivata e disattivata e non richiede di scrivere in modo ridondante le regole di iptables (dovendo scrivere la stessa regola per -j LOGe -j ...)

ip  iptables  debugging  packet-analyzer 
— Chris Lercher
fonte

Risposte:

10

Non riesco a pensare a una soluzione diretta, ma mi viene in mente un modo per rintracciare un pacchetto.

  1. Registra ogni regola con una direttiva prefisso log (--log-prefix "Rule 34")
  2. Genera un pacchetto di test o un flusso di pacchetti con scapy e imposta il campo TOS su qualcosa di unico
  3. grep l'output del file di registro per quell'impostazione TOS e vedere quali regole lo hanno registrato.
— Haakon
fonte
Grazie per l'idea Sfortunatamente, non posso registrare tutte le regole (su un sistema, il disco probabilmente non sarebbe abbastanza veloce per farlo. Su un altro, la registrazione di iptables non è disponibile nel kernel.)
— Chris Lercher
1
Usa una pipe con nome come file softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml Tuttavia, dato che non riesci ad accedere al tuo kernel sei un po 'SOL
— Haakon
Grazie, probabilmente non risolverà il mio problema, ma è generalmente bello sapere che il syslog delle tubazioni sarebbe possibile - potrebbe tornare utile in un altro momento!
— Chris Lercher,
Una domanda correlata sulla registrazione: iptables gestisce contemporaneamente più pacchetti (in modo che le voci di registro possano essere intercalate)? In tal caso, penso che l'idea di TOS sarebbe un must assoluto per molte analisi di LOG di iptables!
— Chris Lercher,
Non conosco la risposta a questo. Mi aspetto che ogni interfaccia sia gestita contemporaneamente da iptables come minimo.
— Haakon,
82

Se hai un kernel abbastanza recente e una versione di iptables puoi usare il target TRACE (sembra essere integrato almeno su Debian 5.0). È necessario impostare le condizioni della traccia in modo che siano quanto più specifiche possibili e disabilitare qualsiasi regola TRACE quando non si esegue il debug perché genera molte informazioni nei registri.

TRACE
Questo target contrassegna i pacchetti in modo che il kernel registri tutte le regole che corrispondono ai pacchetti mentre attraversano le tabelle, le catene, le regole. (Per la registrazione è necessario il modulo ipt_LOG o ip6t_LOG.) I pacchetti vengono registrati con il prefisso stringa: "TRACE: tablename: chainname: type: rulenum" dove type può essere "rule" per la regola normale, "return" per la regola implicita alla fine di una catena definita dall'utente e "politica" per la politica delle catene integrate. Può essere utilizzato solo nella tabella non elaborata.

Se hai aggiunto regole come questa

iptables -t raw -A PREROUTING -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE
iptables -t raw -A OUTPUT -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE

Ti verrà fornito un output simile al seguente.

# cat /var/log/kern.log | grep 'TRACE:'
Mar 24 22:41:52 enterprise kernel: [885386.325658] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325689] TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325713] TRACE: nat:PREROUTING:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: nat:nat.1:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:INPUT:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_all_c1:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_irc_c2:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
— Zoredache
fonte
8
Grazie, è fantastico! In realtà è la risposta migliore, vorrei poterlo accettare (era una domanda generosa, quindi la risposta accettata è definita). Anche se non posso usarlo su tutti i miei sistemi (a causa delle limitazioni del kernel), su alcuni sistemi posso. Questa risposta merita il voto, perché è molto vicino a quello che stavo cercando.
— Chris Lercher,
Ho trovato questa funzione ieri sera mentre rileggevo la pagina man di iptables in modo da poter rispondere a una domanda diversa. Sembra essere una funzionalità relativamente nuova. Non preoccuparti di non essere in grado di contrassegnarlo come accettato. Forse questo verrà votato abbastanza nel tempo per guadagnarmi un altro badge populista.
— Zoredache,
Questa è davvero la risposta canonica per tracciare i pacchetti in iptables. È un peccato che alcuni kernel recenti non lo abilitino per impostazione predefinita.
— Peter Grace,
Quanto tempo fa il kernel supporta TRACE? Ho usato con successo su CentOS 6.4 ma non su CentOS 6.2
— sebelk
6

Tre risposte su un post:

1) Debug per script:

#!/bin/bash
debug() {
    if [ -n "$debug" ]; then
        $@ || echo -e "The command which launched the error:\n$@"
    else
        $@
    fi
}
debug=1
IPTABLES="debug /sbin/iptables"

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
....

2) Debug tramite syslog

Da questo sito Web: http://www.brandonhutchinson.com/iptables_fw.html

If you want to make a syslog entry of dropped packets, change:

# Drop all other traffic
/sbin/iptables -A INPUT -j DROP

To:

# Create a LOGDROP chain to log and drop packets
/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP


You may also want to configure the --log-level to log dropped packets to a separate file instead of /var/log/messages:

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP --log-level debug


/etc/syslog.conf change:

# Send iptables LOGDROPs to /var/log/iptables
kern.=debug                                             /var/log/iptables

Reload the syslogd service for the change to take effect.
/sbin/service syslog reload

3) Nessun debug, bella modifica di iptables:

Anche questo può essere utile: http://www.fwbuilder.org/

— Marc Riera
fonte
1
Grazie. I punti 1) e 3) non hanno molto a che fare con i seguenti pacchetti attraverso le regole di iptables, ma il punto sul reindirizzamento delle voci di registro basate su "--log-level" può essere utile, se finalmente dovessi davvero tornare a registrazione (nel caso in cui non ci sia assolutamente altra soluzione).
— Chris Lercher,
2

aveva la stessa domanda e ha trovato Zoredache che puntava a TRACE / ipt_LOG era la soluzione!

Inoltre ho trovato uno script che inserisce / rimuove le regole LOG che precedono tutte le regole iptables attualmente attive. L'ho provato e l'ho trovato uno strumento davvero carino. - L'output è simile alla soluzione TRACE - Vantaggio: funziona sulla configurazione di iptables attiva, indipendentemente da dove è stato caricato. Puoi attivare / disattivare la registrazione al volo! Non è necessario modificare gli script firewall che potrebbero essere stati generati da Firewall Builder o dallo strumento, qualunque cosa tu usi ... - Svantaggio: senza modifiche, lo script crea le regole LOG per TUTTE le regole attive. Invece, quando si usano le regole TRACE, probabilmente si limiterà la registrazione agli indirizzi / servizi / connessioni per i quali si desidera esaminare subito l'elaborazione di iptables.

Ad ogni modo, mi piace l'approccio :) Complimenti a Tony Clayton, dai un'occhiata: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

Saluti, Chris

— Chris
fonte
0

Di solito uso pacchetti e contatori di byte per vedere come funzionano le regole e per trovare ciò che manca o che non va.

Puoi visualizzarli con "iptables -nvL".

— Vi.
fonte
2
Riesco a vedere cosa vuole l'autore; se stai provando a testare le tue regole di iptables su un'interfaccia occupata, semplicemente guardare i contatori non sarà di grande aiuto in particolare se il pacchetto è probabile che corrisponda a più regole e salti attorno a catene definite dall'utente nel processo (come è tipico quando filtraggio di indirizzi IP indesiderati e regole di protezione dalle inondazioni).
— PP.
@PP: Esatto, mi stai leggendo nella mente. @Vi: Grazie, questo può essere utile in alcune circostanze, e l'ho usato a volte. Ora ho bisogno di qualcosa di più potente.
— Chris Lercher,
-2

AFAIK un pacchetto IP attraversa la catena di regole fino alla prima corrispondenza. Quindi non vedo davvero qual è il problema qui. Se hai:

  1. regola 1
  2. regola 2
  3. regola 3 LOG

E un pacchetto lo inserisce nel registro, significa che la regola 3 è la prima regola corrispondente.

— Anonimo
fonte
Non vero. I pacchetti possono abbinare più regole e lo fanno. A meno che una regola non abbia un'azione (come -j DROPo -j ACCEPT) continuerà ad abbinarsi ulteriormente lungo la catena.
— PP.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.