Depurador para Iptables

47

Estoy buscando una manera fácil de seguir un paquete a través de las reglas de iptables. No se trata tanto de iniciar sesión, porque no quiero registrar todo el tráfico (y solo quiero tener objetivos LOG para muy pocas reglas).

Algo así como Wireshark para Iptables. O tal vez incluso algo similar a un depurador para un lenguaje de programación.

Gracias Chris

Nota: No tiene que ser una herramienta GUI elegante. Pero debe hacer más que solo mostrar un contador de paquetes más o menos.

Actualización: casi parece que no podemos encontrar nada que proporcione la funcionalidad que se solicita. En ese caso: busquemos al menos una buena técnica que se base en el registro de iptables, que puede activarse y desactivarse fácilmente, y no requiere escribir reglas de iptables de forma redundante (tener que escribir la misma regla para -j LOGy -j ...)

ip iptables debugging packet-analyzer Chris Lercher
fuente

Respuestas:

10

No puedo pensar en una solución directa, pero puedo pensar en una ronda sobre la forma de rastrear un paquete.

  1. Registre cada regla con una directiva de prefijo de registro (--log-prefix "Rule 34")
  2. Genere un paquete de prueba o flujo de paquetes con scapy y configure el campo TOS en algo único
  3. grep la salida del archivo de registro para esa configuración de TOS y ver qué reglas lo registraron.
Haakon
fuente
Gracias por la idea Desafortunadamente, no puedo registrar todas las reglas (en un sistema, el disco probablemente no sería lo suficientemente rápido como para hacerlo. En otro, el registro de iptables no está disponible en el kernel).
Chris Lercher
1
Use una tubería con nombre como el archivo softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml Sin embargo, dado que no puede iniciar sesión en su núcleo, está un poco SOL
Haakon
Gracias, probablemente no resolverá mi problema, pero en general es bueno saber que el syslog de tuberías sería posible, ¡podría ser útil en otro momento!
Chris Lercher
Una pregunta relacionada con el registro: ¿iptables maneja múltiples paquetes al mismo tiempo (de modo que las entradas de registro puedan intercalarse)? En ese caso, creo que la idea de TOS sería imprescindible para muchos análisis de log de iptables.
Chris Lercher
No sé la respuesta a eso. Sin embargo, espero que cada interfaz sea manejada simultáneamente por iptables como mínimo.
Haakon
82

Si tiene un kernel y una versión de iptables lo suficientemente recientes, puede usar el objetivo TRACE (parece estar integrado al menos en Debian 5.0). Debe establecer las condiciones de su rastreo para que sean lo más específicas posible y deshabilitar las reglas de RASTREO cuando no esté depurando, ya que arroja mucha información a los registros.

RASTREO
Este objetivo marca los paquetes para que el núcleo registre cada regla que coincida con los paquetes a medida que atraviesan las tablas, cadenas y reglas. (El módulo ipt_LOG o ip6t_LOG es necesario para el registro). Los paquetes se registran con el prefijo de cadena: "TRACE: tablename: chainname: type: rulenum" donde type puede ser "rule" para una regla simple, "return" para una regla implícita al final de una cadena definida por el usuario y "política" para la política de las cadenas integradas. Solo se puede usar en la tabla sin formato.

Si agregaste reglas como esta

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

Se le proporcionará una salida similar a esta.

# 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
fuente
8
Gracias, esto es genial! En realidad es la mejor respuesta, desearía poder aceptarla (era una pregunta de recompensa, por lo que la respuesta aceptada es definitiva). Si bien no puedo usarlo en todos mis sistemas (debido a las limitaciones del kernel), en algunos sistemas sí puedo. Esta respuesta merece un voto positivo, porque está muy cerca de lo que estaba buscando.
Chris Lercher
Anoche encontré esta característica cuando estaba releyendo la página de manual de iptables para poder responder una pregunta diferente. Parece ser una característica relativamente nueva. No se preocupe por no poder marcarlo como aceptado. Tal vez esto se votará lo suficiente con el tiempo como para ganarme otra insignia populista.
Zoredache
Esta es realmente la respuesta canónica para rastrear paquetes en iptables. Es una pena que algunos núcleos recientes no lo habiliten por defecto.
Peter Grace
¿Hace cuánto tiempo el kernel soporta TRACE? Lo he usado con éxito en CentOS 6.4 pero no en CentOS 6.2
sebelk
6

Tres respuestas en una publicación:

1) Depuración por 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) Depuración por syslog

Desde este sitio 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) Sin depuración, agradable edición de iptables:

También esto puede ser útil: http://www.fwbuilder.org/

Marc Riera
fuente
1
Gracias. Los puntos 1) y 3) no tienen mucho que ver con los siguientes paquetes a través de las reglas de iptables, pero el punto sobre la redirección de las entradas de registro basadas en "--log-level" puede ser útil, si finalmente tengo que recurrir a registro (en caso de que no haya absolutamente ninguna otra solución).
Chris Lercher
2

tenía la misma pregunta y descubrí que Zoredache apuntando a TRACE / ipt_LOG era la solución.

Además, encontré un script que inserta / elimina las reglas de LOG que preceden a todas las reglas de iptables actualmente activas. Lo probé y descubrí que es una herramienta realmente agradable. - La salida es similar a la solución TRACE - Ventaja: funciona en la configuración activa de iptables, sin importar desde dónde se cargó. ¡Puede activar / desactivar el inicio de sesión sobre la marcha! No necesita modificar ningún script de firewall que pueda haber generado Firewall Builder o cualquier herramienta que utilice ... - Desventaja: sin modificación, el script crea reglas de LOG para TODAS las reglas activas. En cambio, cuando use las reglas de TRACE, probablemente restringirá el registro a las direcciones / servicios / conexiones para los que desea investigar el procesamiento de iptables ahora.

De todos modos, me gusta el enfoque :) Felicitaciones a Tony Clayton, eche un vistazo: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

Saludos, Chris

Chris
fuente
0

Usualmente uso paquetes y contadores de bytes para ver cómo funcionan las reglas y para encontrar lo que falta o está mal.

Puede verlos con "iptables -nvL".

Vi.
fuente
2
Sin embargo, puedo ver lo que quiere el autor; Si está tratando de probar sus reglas de iptables en una interfaz ocupada, simplemente mirar los contadores no será de mucha ayuda, especialmente si es probable que el paquete coincida con varias reglas y salte alrededor de las cadenas definidas por el usuario en el proceso (como es típico cuando filtrar direcciones IP no deseadas y reglas de protección contra inundaciones).
PP.
@PP: Exactamente, estás leyendo mi mente. @ Vi: Gracias, esto puede ser útil en algunas circunstancias, y lo he usado a veces. Ahora necesito algo más poderoso.
Chris Lercher
-2

AFAIK un paquete IP atraviesa la cadena de reglas hasta la primera coincidencia. Así que realmente no veo cuál es el problema aquí. Si usted tiene:

  1. regla 1
  2. regla 2
  3. regla 3 REGISTRO

Y un paquete llega al registro, significa que la regla 3 es la primera regla coincidente.

Anónimo
fuente
No es verdad. Los paquetes pueden coincidir con múltiples reglas, y lo hacen. A menos que una regla tenga una acción (como -j DROPo -j ACCEPT), continuará coincidiendo más adelante en la cadena.
PP.