¿Cuándo rastrea el módulo conntrack de iptable los estados de los paquetes?
Primero necesita almacenar estados. Con un antiguo cortafuegos BSD que usé, supongo que se llamaba IPFW, solía poner una regla que decía "realizar un seguimiento del estado del paquete saliente", y esto se colocaba en la dirección de salida de las interfaces. Luego, otra regla en la dirección de entrada que los comparó con los estados que fueron creados por la regla en la dirección de salida. Entonces solía haber 2 reglas: (1) para completar la tabla de estados, esto estaba en la dirección de salida, y (2) para buscar la tabla de estados, esto estaba en la dirección de entrada.
Pero con connntrack, veo que se aplica en la cadena INPUT, como esta regla:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
Esto me hace preguntarme, ¿qué está haciendo realmente esa declaración?
- ¿Está diciendo que comenzará a rastrear los paquetes que coincidan con esa regla al poner su información en la tabla de estados?
- ¿O está diciendo que ya tiene la información de los estados y actuará contra los mensajes entrantes basados en ella? (por ejemplo, ¿aceptar si pertenecían a una conexión previamente aceptada?). Pero, en este caso, ¿dónde se llenó la tabla de estados? ¿Qué regla lo hace? ¿O es implícito y sin reglas?
Respuestas
Presentación introductoria de Netfilter y conntrack
Primero, el esquema obligatorio sobre el flujo de paquetes en Netfilter y redes generales:
Netfilter es el marco de filtrado de paquetes que se inserta sobre el resto de la pila de la red (representado por la "decisión de enrutamiento" y otras partes de la caja blanca con bordes redondeados). Netfilter proporciona enlaces y API para otros subsistemas y "clientes". Entre estas partes se encuentran conntrack (el rastreador de conexiones) e iptables (o nftables ). La separación entre Netfilter y conntrack es bastante confusa. Puede considerar conntrack como una parte integrada de Netfilter.
En el esquema que describe los distintos pasos que atraviesa un paquete, puede ver que en algún punto (entre raw / PREROUTING y mangle / PREROUTING, o entre raw / OUTPUT y mangle / OUTPUT) el paquete atraviesa conntrack .
En este punto, conntrack buscará en sus propias tablas de búsqueda (una mini base de datos de búsqueda guardada en la memoria del kernel):
- si no se encuentran las características de este paquete (y si no se declaran SIN SEGUIMIENTO en la tabla sin procesar), una nueva entrada de tupla bidireccional de Conntrack (protocolo, luego información específica de familia y protocolo: fuente y puerto iniciales, puerto y destino inicial, fuente y puerto de respuesta, destino de respuesta y puerto (esos dos últimos suelen ser inversos, a menos que haya NAT o algunos protocolos extraños, como respuesta de eco que coincida con la solicitud de eco para ICMP)) que describe el flujo se crea con el estado NEW.
- si coincide (en cualquier dirección) con una entrada anterior y es compatible con el estado de este flujo, el estado del flujo puede verse alterado (por ejemplo: cambiar de NUEVO a ESTABLECIDO si ese no era el caso antes).
- si por alguna razón específica el paquete no puede coincidir con un flujo existente a pesar de tener sus características (por ejemplo: un paquete TCP tardío recibido después de que una retransmisión ya se activó con éxito, por lo que está fuera de la ventana con respecto a la secuencia y los valores SACK) el el paquete se etiquetará como INVALIDO.
- Hay algunos otros casos como RELATED: se trata de paquetes que no forman parte del flujo en sí, sino que están relacionados con un nuevo flujo que se puede asociar con otro flujo existente (es decir, en la base de datos). Dos ejemplos son un error de ICMP creado al recibir un paquete (por ejemplo: puerto UDP inalcanzable) o cuando un asistente de protocolo especial como el módulo del kernel
nf_conntrack_ftp, que es un complemento del subsistema conntrack , detecta que un paquete es parte del flujo de datos separado asociado con los comandos FTP PASV / EPSV o PORT / EPRT realizados en el flujo de comandos (en el puerto 21).
Abordar la pregunta
Dicho todo esto, aquí están las respuestas a sus dos balas:
en el espacio de nombres de la red principal, conntrack comienza a rastrear conexiones tan pronto como se cargan sus módulos (incluidos los posibles submódulos relevantes específicos del protocolo). Para espacios de nombres de red no iniciales (contenedores ...), esto también requiere que algún otro subsistema haga referencia a él (como el módulo conntrack de iptables de OP o usar una vez el comando que se
conntrackdescribe más adelante). Este es el valor predeterminado y un paquete debe marcarse específicamente como SIN SEGUIMIENTO antes de que el subsistema conntrack lo vea para que este paquete no sea rastreado. En Linux, solo hay unos pocos casos en los que no se necesitaría el seguimiento, pero luego, por supuesto, el cortafuegos con estado y la NAT con estado / dinámica ya no estarán disponibles (la NAT sin stent que incluso podría requerir el uso de UNTRACKED en primer lugar, todavía puede estar disponible hecho, pero no con iptables . tc o nftables pueden). Para evitar que conntrack maneje algunos paquetes, se puede usar este tipo de regla de iptables (por ejemplo: puerto 80 / tcp):iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrackCuando el paquete atraviesa el filtro / ENTRADA y alcanza esta regla:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTEl módulo del kernel específico de iptables
xt_conntrackconsulta el subsistema conntrack (manejado por los diversos módulos del kernel relevantesnf_conntrack*) y pregunta sobre el estado de este paquete en su base de datos de búsqueda. Si la respuesta esRELATEDoESTABLISHEDel paquete coincide y procede al veredicto ACEPTAR. En realidad, el resultado ya está almacenado en caché en el paquete la primera vez que se realizó la búsqueda (generalmente mediante conntrack ), por lo que esta es una "búsqueda" barata. Por tanto, esta es una regla genérica para manejar flujos ya aceptados anteriormente. Esos flujos pueden aceptarse inicialmente en reglas que lo mencionen explícitamente-m conntrack --ctstate NEWo simplemente en reglas que no lo mencionen, pero que se coloquen después de esta regla genérica (pero tenga en cuenta el estado INVÁLIDO, que normalmente debe eliminarse antes de hacerlo).agregando una viñeta: el manejo de los paquetes entrantes y salientes es bastante simétrico entre PREROUTING y OUTPUT (incluso si no parecen simétricos): interfaces de conntrack en PREROUTING así como en OUTPUT (y en algunos otros lugares, considerando que NAT es trabajando con conntrack , excepto por su primer paquete en estado NEW atravesando la tabla nat de iptables ). Esto puede ser ligeramente diferente de la descripción que escribió sobre IPFW. Si un servidor que ejecuta aplicaciones también restringe los flujos salientes, lo más probable es que necesite esta misma regla de iptables genérica tanto en filtro / SALIDA como en filtro / ENTRADA, para permitir que pasen los paquetes de respuesta salientes del tráfico entrante ya aceptado.
Información adicional
Hay herramientas específicas para interactuar con el conntrack tablas de búsqueda del subsistema de conntrack-herramientas .
conntrack: para consultar, eliminar o actualizar el contenido de las tablas de búsqueda manejadas por conntrack .
Algunos ejemplos.
Puede enumerar todas las entradas rastreadas (que pueden ser grandes sin un filtro adicional) con:
conntrack -LSi su sistema está haciendo NAT (por ejemplo, un enrutador frente a una LAN privada o ejecutando VM y contenedores), puede usar
--any-nat,--src-nato--dst-natsolo mostrar resp. todo NAT, todo NAT de origen (enmascaramiento) o todo NAT de destino (normalmente para puertos reenviados):Monitoreo en tiempo real de eventos conntrack :
conntrack -Econntrackd: un demonio cuyos dos propósitos principales son (conntrack) contabilidad y estadísticas de flujo, o sincronización de estado de clúster de firewall con estado de alta disponibilidad .
El seguimiento de la conexión es una función independiente de Netfilter y no está configurado con IPTables.
En la imagen, hay dos conntrackpasos en la ruta de ENTRADA y uno en la ruta de SALIDA. Estos pasos asocian paquetes individuales con conexiones existentes rastreadas en la tabla de rastreo de conexiones, o crean nuevas entradas de rastreo de conexiones en la tabla.
La funcionalidad de Conntrack es un módulo del kernel de Linux y, a menudo, se incluye en el kernel en la configuración predeterminada.
El funcionamiento de Conntrack se puede ajustar ajustando los net.netfilter.nf_conntrackvalores de sysctl.
Tu segunda alternativa es lo que sucede. La información de estado es registrada por la función Conntrack y la regla IPTables simplemente consulta la tabla Conntrack para obtener información.