Puertos filtrados: ¿qué es exactamente lo que los filtra?

En general, existen múltiples dispositivos entre usted y su objetivo. En el camino, los firewalls, enrutadores, conmutadores y otros dispositivos de red pueden restringir que sus paquetes lleguen a su destino. También los cortafuegos basados en host o los controles de acceso a la aplicación pueden provocar una respuesta filtrada.

Algunas veces obtiene una respuesta del dispositivo de filtrado en la respuesta de un mensaje de error de ICMP pero en la mayoría de los casos, en algún lugar a lo largo de la ruta, los paquetes se eliminan.

Sus suposiciones:

• no Iptables puede configurarse para que no responda en absoluto a menos que esté en una lista aprobada. O iptables puede configurarse con una lista de hosts / redes para no responder en absoluto.
• Depende de cómo se define el dispositivo de seguridad. Un término mejor sería dispositivo de control de acceso, ya que podría ser algo así como ACL en un enrutador.
• Dependiendo de la aplicación y su pila de redes es posible. Una aplicación con una pila de red terrestre de usuario puede elegir qué hacer con las solicitudes en lugar del sistema operativo.

En la mayoría de los sistemas operativos, el manejo del protocolo de enlace de tres vías TCP es responsabilidad del código de red del sistema operativo. Las aplicaciones solo pueden declarar interés en recibir conexiones en un puerto determinado mediante la llamada al sistema listen (). El sistema operativo responderá a un SYN con un SYN / ACK si hay una aplicación escuchando en el puerto, y con un RST de lo contrario. Ninguna aplicación tiene nada que ver con eso.

Este es el comportamiento predeterminado. Puede ser modificado por muchas cosas, incluyendo pero no limitado a los mecanismos de filtrado de paquetes en el host. Además, la implementación especializada de TCP / IP puede comportarse de manera diferente a propósito.

Cuando NMAP no recibe un SYN / ACK ni un RST en respuesta a un paquete SYN, informa que ese puerto está "filtrado". No tiene forma de determinar la razón por la que no recibió una respuesta. A la inversa, si un firewall intermedio bloquea el puerto respondiendo con RST, NMAP informará que el puerto está cerrado aunque el paquete de la sonda nunca llegó a su destino.

En resumen, su cotización es al menos inexacta. NMAP también informa que los puertos están filtrados si no pueden determinarse como abiertos o cerrados por otras razones además del filtrado de paquetes. El filtrado de paquetes es solo una de las causas más comunes y, por lo tanto, se ha convertido en el epónimo de ese resultado. Además, NMAP puede incluso informar que un puerto está cerrado cuando no puede determinarlo como abierto o cerrado debido a un filtro de paquetes que interviene.

Al intentar ingresar la forma más simple de la red target :

Internet   ---  firewall  ---   target

cruzarás al menos 3 niveles de filtrado:

1. cortafuegos
2. en el nivel del sistema operativo del objetivo
3. en el nivel de aplicación del objetivo

En cada de estos niveles, un primer paquete IP (y cualquier otro paquete de protocolo como un paquete ESP o AH) podría recibir 4 tipos de tratamiento:

1. el paquete simplemente se elimina (no cualquier forma de respuesta)
2. el paquete se descarta y se devuelve un ICMP tipo 3, código 9 o 10,
3. recibir un paquete TCP RST
4. recibir un paquete TCP ACK

Las redes reales se construyen con este ladrillo básico.

Aquí hay varias preguntas, déjame intentar reformularlas para que se pueda dar una respuesta adecuada.

Pregunta 1. ¿Responden los sistemas con SYN / ACK o RST si el tráfico llega a un host?

Respuesta corta: no necesariamente, puede obtener un destino ICMP inalcanzable (puerto inalcanzable), que se considera una respuesta aceptable cuando no hay un proceso escuchando en ese puerto ( RFC 1122 , página 40 y RFC 792 , página 5). También es posible que no reciba ninguna respuesta; desafortunadamente, no todos cumplen con las especificaciones de RFC. Desafortunadamente, he visto implementaciones que responden a SYN con un FIN! Sí, puede ser tan malo.

Pregunta 2. ¿Se responderá correctamente a cada sonda que logre llegar al puerto?

Respuesta corta: no necesariamente, las implementaciones de la pila TCP en los sistemas operativos varían, por ejemplo, he visto sistemas integrados con recursos limitados a los que se ha cambiado el proceso de escucha, y en el momento en que el proceso se ha restaurado de nuevo en la memoria , la ventana de oportunidad para una respuesta se ha cerrado. Es una excepción y no la regla, pero debe tener en cuenta que no todos cumplirían con la norma; algunos pueden tener mecanismos de protección contra inundaciones SYN incorporados que pueden ver demasiados segmentos SYN del mismo host como un intento de DoS.

Pregunta 3. ¿Puede una aplicación ignorar las sondas?

Por lo general, no es responsabilidad de la aplicación hacer eso, es la pila del sistema operativo la que cuida estas cosas. No quiere decir que no pueda implementar su propio controlador de protocolo, pero rara vez es el caso. Pero diría que pocas aplicaciones tienen algo que ver con la parte de TCP de sus comunicaciones.

Espero que encuentre útiles estas respuestas :-)