Iptables: “-p udp --state ESTABLISHED”

Veamos estas dos reglas de iptables que a menudo se utilizan para permitir DNS saliente:

iptables -A OUTPUT -p udp --sport 1024:65535 --dport 53 
   -m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A INPUT -p udp --sport 53 --dport 1024:65535
   -m state --state ESTABLISHED -j ACCEPT

Mi pregunta es: ¿cómo debo entender exactamente el estado ESTABLECIDO en UDP? UDP no tiene estado.

Aquí está mi intuición: me gustaría saber si esto es incorrecto o no:

La página del manual me dice esto:

estado

Este módulo, cuando se combina con el seguimiento de conexión, permite el acceso a
estado de seguimiento de conexión para este paquete.

  --estado ...

Entonces, iptables básicamente recuerda el número de puerto que se usó para el paquete saliente (¿qué más podría recordar para un paquete UDP?) , Y luego permite que el primer paquete entrante se envíe en un corto período de tiempo. Un atacante tendría que adivinar el número de puerto (¿sería realmente demasiado difícil?)

Sobre evitar conflictos:

El kernel realiza un seguimiento de qué puertos están bloqueados (ya sea por otros servicios o por paquetes UDP salientes anteriores), de modo que estos puertos no se utilizarán para nuevos paquetes DNS salientes dentro del marco de tiempo. (¿Qué sucedería si accidentalmente intentara iniciar un servicio en ese puerto dentro del plazo? ¿Sería denegado / bloqueado ese intento?)

Encuentre todos los errores en el texto anterior :-) Gracias,

Chris

— Chris Lercher
fuente

Respuestas:

Entonces, iptables básicamente recuerda el número de puerto que se usó para el paquete saliente (¿qué más podría recordar para un paquete UDP?),

Estoy bastante seguro de que UDP almacena los puertos y direcciones de origen y destino.

Si desea inspeccionar las tablas de estado, instale conntrack y / o netstat-nat.

(¿Qué sucedería si accidentalmente intentara iniciar un servicio en ese puerto dentro del plazo? ¿Sería denegado / bloqueado ese intento?)

Como está utilizando OUTPUT e INPUT, está hablando de servicios locales. El puerto ya está en uso. No creo que su sistema le permita iniciar otro servicio ya que algo ya está escuchando en ese puerto. Sin embargo, supongo que podría detener el primer servicio y comenzar otro si realmente quisiera, en ese caso la respuesta probablemente llegaría a su servicio. Lo que el servicio hace con el paquete depende de cuál es el contenido del paquete y de qué servicio es.

— Zoredache
fuente

Entonces, si comencé a decir una instancia de Tomcat en el puerto 8080, tendré una probabilidad de 1: (65535-1023) de que el inicio falle, si accidentalmente se ejecuta una consulta DNS en el mismo puerto. ¿O simplemente esperará hasta que expire el plazo? ¿Cuánto dura el período de tiempo predeterminado?

— Chris Lercher

En Linux, creo que el rango de puertos efímero es comúnmente 32768-61000 (ver / proc / sys / net / ipv4 / ip_local_port_range), esto no incluiría su puerto de ejemplo de 8080. Tiende a ser muy poco común configurar servicios para escuchar en los puertos dentro del rango efímero. El tiempo que una entrada UDP indica en la tabla es típicamente de 30 segundos (consulte / proc / sys / net / netfilter / nf_conntrack_udp_timeout)

— Zoredache

+1 ¡Gracias, especialmente por las rutas / proc!

— Chris Lercher

En caso de que alguien desee extender el udp_timeout, useecho "net.netfilter.nf_conntrack_udp_timeout = 180" >> /etc/sysctl.conf

— Kiran

NB: esta respuesta ha sido editada.

A pesar de lo que dicen las páginas del manual, ESTABLISHEDparece significar "con estado". Para UDP, eso simplemente significa (como sugiere) recordar cada paquete UDP saliente (la "tupla src ip, src port dst ip, dst port") por un tiempo y reconocer sus respuestas.

FWIW, mis reglas normales para el tráfico DNS serían algo como esto:

# permit any outbound DNS request (NB: TCP required too)
iptables -A OUTPUT -p udp --sport 1024:65535 --dport 53  -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024:65535 --dport 53  -j ACCEPT

# accept any packet that's a response to anything we sent
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

es decir, controlar el tráfico en la OUTPUTcadena y luego dejar que los iptablesmódulos de estado manejen todo lo demás en la INPUTcadena.

Ver también esta pregunta relacionada .

— Alnitak
fuente

Soy consciente de que también debería permitir TCP. Pero, ¿qué significaría RELACIONADO para UDP? Página de manual: "RELACIONADO, lo que significa que el paquete está iniciando una nueva conexión, pero está asociado con una conexión existente, ..." ¿Conexiones para UDP? Tal vez realmente tenga más sentido que ESTABLECIDO, pero eso es lo que me gustaría descubrir.

— Chris Lercher

Cuando uso sus reglas, pero restringe udp INPUT a RELACIONADO, mis consultas DNS no funcionan. Parece que tengo que permitir ESTABLECIDO. ¿Hay alguna razón para permitir también RELACIONADO (para UDP)?

— Chris Lercher

ok, parece que ESTABLECIDO significa más de lo que dice la página del manual. En cualquier caso, si usa filtros de SALIDA como el mío y no acepta el tráfico inbonud, entonces esa regla de ENTRADA es la única que necesitará.

— Alnitak

Dado lo que hemos encontrado, los paquetes udp RELACIONADOS no existen AFAIK. Sin embargo (por ejemplo) si alguna vez hace FTP saliente desde ese cuadro, necesita una regla de estado RELACIONADA para el canal de datos. La única regla "ESTABLECIDA, RELACIONADA" es AFAIK, la regla única más óptima para el tráfico de entrada.

— Alnitak

en realidad, pueden existir RELATEDpaquetes UDP para RTP.

— Alnitak

Los desarrolladores de iptables han considerado que un estado "ESTABLECIDO" era la situación en la que los paquetes se veían en ambas direcciones, independientemente del protocolo entre dos clientes.

La extensión de estado es parte de Conntrack. El núcleo comprende el estado de la tabla

/proc/net/nf_conntrack

Ejemplo de estados iptable para UDP en la tabla nf_conntrack desde el punto de vista del remitente. Imaginemos que envía una consulta DNS en UDP

udp   17 20 src=192.168.1.2 dst=192.168.1.10 sport=35237 dport=53 \
 [UNREPLIED] src=192.168.1.10 dst=192.168.1.2 sport=53 \
 dport=35237 use=1

Se ha enviado un paquete. No respondió y, oh, la tabla tiene los datos de lo que se espera a cambio (el paquete para la respuesta DNS).

udp   17 20 src=192.168.1.2 dst=192.168.1.10 sport=35237 dport=53 \
  src=192.168.1.10 dst=192.168.1.2 sport=53 \
 dport=35237 use=1

La respuesta ha llegado, el indicador no respondido se ha ido, significa que esta conexión UDP está en estado ESTABLECIDO durante un pequeño período de tiempo definido en su sistema.

— Nicolas Guérinet
fuente