2 votos

¿Debería iptables hacer NAT de origen en paquetes TCP inválidos?

Me tropecé con un peculiar problema:

He configurado un servidor OpenVPN en Ubuntu 16.04, en mi red de casa, para que mi teléfono Android y basadas en Debian notebook para enviar todo el tráfico de internet a través de mi red de casa. Para ello he configurado un MASQUERADE iptables regla para suplantar la dirección IP de origen de mis clientes OpenVPN tun0 interfaces de túnel. Yo todo funciona muy bien desde una perspectiva del usuario final. Sin embargo, mi router/firewall a veces se quejan de "marciano" origen de los paquetes, habiendo de origen dirección IP de la interfaz tun0 de mi cliente - en este caso el teléfono Android. Yo estaba perplejo acerca de estos mensajes y se preguntó si podría suponer un riesgo de seguridad - no es probable, ya que marciano paquetes normalmente se cayó en los routers. Pero la curiosidad toook más y he investigado más a fondo. Para hacer corta una larga historia, esto es lo que he encontrado:

  1. Cuando se apaga el teléfono (sólo la pantalla) es de OpenVPN cliente realiza una suave salida, que rompe algunas de las conexiones TCP sobre el tun0 interfaz de túnel para el servidor OpenVPN.

  2. Cuando encienda el teléfono de nuevo la conexión OpenVPN se reinicia automáticamente. Cuando esto sucede, el firewall de Ubuntu normalmente detectar un número de paquetes no válidos desde el teléfono a direcciones IP de internet - por ejemplo, google.com. Estos mensajes son los paquetes TCP de tipo RST/ACK, fin/ACK, y la PRIMERA, y la mayoría de ellos no son válidos en el sentido de iptables firewall de conexión de seguimiento.

  3. Ahora desconcertante parte: El cortafuegos iptables felizmente ruta de estos paquetes no válidos en adelante a los servidores de Ubuntu saliente de la interfaz Ethernet del router, donde el resultado es que el marciano de la fuente de paquetes de advertencias, pero su IP las direcciones de origen son los originales teléfono android interfaz tun0, direcciones IP, NO el de Ubuntu servidores dirección IP saliente. Todos los no-válida paquetes de obtener la correcta MAAQUERADE source NAT procesamiento.

Conclusiones anteriores se basaron en el uso de wireshark para capturar el tráfico, y iptables estadísticas de la siguiente regla para la captura de paquetes no válidos en la cadena forward.

Me las he arreglado para colocar estos paquetes mediante la siguiente regla:

-A FORWARD -s xxx.xxx.169.0/24 -o p2p1 -p tcp -m state --state INVALID -j DROP

Después de la introducción de esta regla ya no hay marcianos en el router, y wireshark ya no vea los paquetes en Ubuntu saliente interfaz Ethernet con la dirección de origen del teléfono.

Debo mencionar que durante las pruebas, el teléfono no está conectado a la LAN doméstica a través de wi-fi, así que todo el tráfico es OpenVPN protocolo UDP, que pasa a través de mi router/firewall para el servidor de OpenVPN en el servidor de Ubuntu.

Espero que alguien sepa si el comportamiento descrito está en línea con el diseño de Linux netfilter/iptables, o es un bug? Sospecho que el problema es de alguna manera relacionados con iptables seguimiento de conexión donde el roto conexiones TCP han perdido su conexión de las entradas de seguimiento en iptables, que a su vez evitar de alguna manera que la fuente de NAT lógica de la MASQUERAD regla para hacer su cosa.

Yo estaría feliz ff alguien podría ofrecer una visión más profunda sobre este y tal vez también podría comentar sobre cualquiera de los aspectos de seguridad - puede ser explotado de alguna manera?

0voto

Doug Smythies Puntos 1897

Su análisis es exhaustiva y completa. Muy bien hecho. Me fui a través de la misma investigación hace 8 años.

No es un error, aunque se mantiene llegar reportado como bug. De mis notas en el tiempo:

El NAT motor simplemente no saben qué hacer con un paquete no VÁLIDO, por lo que es aprobada sin la dirección de la traducción. De modo tal que los paquetes deben ser identificados y se dejó caer. Este requisito es increíblemente NO es evidente en la mayoría de la documentación.

Por favor vea también este informe de error, especialmente comentario 11.

Yo no soy consciente de que cualquier particular preocupaciones de seguridad con este. Soy consciente de que algunos Isp puede enojarse con los que no se puede enrutar los paquetes enviados. En mi regla iptables conjunto que tengo muchas normas, además de que el INVÁLIDO cheques, para asegurarse de que los paquetes nunca salir de mi LAN con no enrutable de origen o de destino IPs (es decir, 192.168.X.X, 10.X.X.X, 172.16.X.X, ...)

2,5 años después de la aplicación de la regla como usted tiene:

-A FORWARD -s xxx.xxx.169.0/24 -o p2p1 -p tcp -m state --state INVALID -j DROP

Hubo un caso de un NAT no había paquete de escapar de mi LAN.La causa fue un mal formada de paquetes ICMP desde un teléfono inteligente (algo que nunca debe ocurrir, pero lo hizo. Se trataba de un falso longitud de encabezado). Por lo que la especificación del protocolo se ha caído:

-A FORWARD -s xxx.xxx.169.0/24 -o p2p1 -m state --state INVALID -j DROP

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: