Una configuración inadecuada sorprendentemente común, es confiar en el tráfico basándose únicamente en el número de puerto origen. Es fácil entender entonces como ocurre esto. Un administrador puede configurar un nuevo y brillante firewall, únicamente para ser inundado con reclamos de usuarios descontentos cuyas aplicaciones dejaron de funcionar. En particular DNS puede no funcionar, pues las respuestas UDP DNS desde servidores externos, no pueden ingresar hacia la red. FTP es otro ejemplo común. En las transferencias FTP, el servidor remoto intenta establecer una conexión de retorno hacia el cliente para transferir el archivo solicitado.

Las soluciones seguras a estos problemas existen, frecuentemente en la forma de un proxy a nivel de aplicación, o módulos del firewall para interpretar el protocolo. Desafortunadamente también existen soluciones más fáciles e inseguras de utilizar. Al notar una respuesta DNS proviene desde el puerto 53, y un FTP activo desde un puerto 20, muchos administrador caen en la trampa de simplemente permitir conexiones entrantes desde estos puertos. Pues frecuentemente asumen ningún atacante notará y explotará tal agujero en el firewall. En otros casos, los administradores consideran esto una medida provisional a corto plazo, hasta puedan implementar un solución más segura. Luego olvidan esta actualización de seguridad.

Administradores de red con exceso de trabajo no son los únicos quienes caen en esta trampa. Numerosos productos son entregados con estas reglas inseguras. Incluso Microsoft ha sido culpable. Los filtros IPsec entregados con Windows 2000 y Windows XP, contienen reglas explícitas permitiendo tráfico TCP y UDP desde un puerto 88 (kerberos). Los fanáticos de Apple no deberían sentirse demasiado satisfecho sobre esto, pues el firewall entregado con Mac OS X Tiger es igual de malo. Jay Beale descubrió incluso si no se tiene habilitado el recuadro “Block UDP Traffic” o Bloquear Tráfico UDP en la GUI del firewall, los paquetes proviniendo del puerto 67 (DHCP) y 5353 (Zeroconf) pasan correctamente. Otro ejemplo patético de esta configuración, es el firewall personal Zone Alarm (versiones hasta 2.1.25), permiten cualquier paquete UDP entrante con el puerto origen 53 (DNS) o 67 (DHCP).

Nmap ofrece las opciones “-g” y “--source-port” (son equivalentes) para explotar estas debilidades. Simplemente se debe proporcionar un número de puerto, y Nmap enviará los paquetes desde este puerto cuando sea posible. Nmap debe usar diferentes números de puertos, para las pruebas de detección del sistema operativo funcionen adecuadamente. La mayoría de escaneos TCP, incluyendo el escaneo SYN, soportan completamente la opción, así como el escaneo UDP.

Para el siguiente ejemplo se utiliza una máquina con Windows Server 2012 R2. Únicamente se utiliza por defecto el firewall de Windows.

En primera instancia se ejecuta un “SYN Scan” contra el host.

# nmap -n -Pn -v 192.168.0. 92

Notar como únicamente se reportan en estado abierto los puertos TCP, 80, 443, 49155, 49156, y 40159.

A continuación se realiza un “SYN Scan” contra el mismo host, pero definiendo al puerto TCP 53 como origen del escaneo.

# nmap -n -Pn -v --source-port 53 192.168.0. 92

En los resultados obtenidos ahora se incluye; además de los puertos descubiertos con el anterior escaneo realizado; al puerto TCP 53 descubierto en estado abierto.

Fuentes:

https://nmap.org/book/firewall-subversion.html