☰

La política NAT de iptables ¿Acepta un agujero de seguridad?

tag-icon • tag-icon linux security iptables firewall nat
La política NAT de iptables ¿Acepta un agujero de seguridad?

Estoy fortaleciendo mi servidor vps y recientemente vi que todas las políticas están abiertas (ACEPTAR) en la Mesa Nat. Estoy buscando en Internet y no encontré nada sobre cómo asegurar la tabla nat. ¿Es eso un agujero de seguridad o no? Aquí la SALIDA:

Chain PREROUTING (policy ACCEPT 21038 packets, 1097K bytes)
 pkts bytes target     prot opt in     out     source               destination                                                 

Chain INPUT (policy ACCEPT 9 packets, 1088 bytes)
 pkts bytes target     prot opt in     out     source               destination                                                 

Chain OUTPUT (policy ACCEPT 187 packets, 14396 bytes)
 pkts bytes target     prot opt in     out     source               destination                                                 

Chain POSTROUTING (policy ACCEPT 48 packets, 3767 bytes)
 pkts bytes target     prot opt in     out     source               destination                                                 
  523  140K MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

Por cada ayuda estoy agradecido

Un cordial saludo Barbanegra

Respuesta1

No, está perfectamente bien utilizar una política ACEPTAR para elnatmesa. Usar una política DROP sería una anomalía.

Un paquete atraviesa varias cadenas en varias tablas siguiendo este esquema:

Flujo de paquetes en Netfilter y General Networking

Ser aceptado simplemente significa que el paquete tiene otra oportunidad de ser aceptado o descartado en la siguiente ronda (es decir, la siguiente cadena y sus reglas para recibir este paquete). La eliminación tiene un efecto instantáneo: el paquete desaparece y no se procesa ninguna otra regla para este paquete. Entonces, a medida que el paquete atraviesa las distintas cadenas en las distintas tablas, hay muchos lugares donde se puede dejar caer. Una GOTA en cualquier lugar eliminará el paquete. Un ACEPTAR adicional (por ejemplo: si nunca se usa NAT, no haynattabla creada) no cambiará este resultado.

como elnatLa tabla está destinada a hacer NAT y no a filtrar el tráfico (para esto hay una tabla dedicada:filtrar), no hay ninguna razón para que NAT alguna vez corte el tráfico. Todavía es técnicamente posible hacerlo, pero de todos modos también hay que considerar que NAT no se maneja como otras tablas porque en realidad es parte deconectar: solo se ve el primer paquete de cada nuevo flujo eniptables'nattabla, con el fin de establecer reglas NAT para el flujo. Otros no, su manejo lo hace directamenteconectarque sigue las reglas NAT (incluidas en la correspondienteconectartabla que se puede consultar con elconntrackdominio).

En resumen, nunca debes CAER en elnattabla: debe ACEPTAR o REGRESAR para crear excepciones a las siguientes reglas que realmente realizan NAT (dejando así el paquete intacto para que continúe en la siguiente ronda), o usar los diversos objetivos NAT disponibles (por ejemplo: DNAT, REDIRECT, SNAT, MASQUERADE). ..) para establecer las reglas NAT para este flujo (que también harán que el paquete continúe a la siguiente ronda). Deje la política predeterminada DROP para cadenas en elfiltrarmesa. ElmutilarLa tabla también se puede usar para eliminar el tráfico, pero generalmente tampoco está configurada con una política DROP predeterminada para sus cadenas. En cuanto a lo poco conocidoseguridadmesa No lo sé, rara vez se usa, por lo que rara vez existe.

información relacionada