it-swarm-es.com

¿Hay algún significado en solo permitir el puerto 80 y 443 hoy?

Se ha convertido en una tarifa estándar para las organizaciones con mentalidad de seguridad para bloquear todo lo que no sea 80 y 443. Como resultado, más y más aplicaciones (aparte de los navegadores web) están aprendiendo a usar estos puertos también para sus necesidades.

Los programas naturalmente maliciosos también lo hacen, lo que significa que para tener seguridad real, los firewalls deben examinar el flujo de datos y bloquearlos en función de los datos de la aplicación en lugar de solo puertos ...

Esto parece indicar que el bloqueo basado en puertos era un enfoque miope para empezar, algo así como la validación de entrada únicamente en el cliente ...

En ese caso, ¿no deberíamos detener el bloqueo general de los puertos no estándar e intentar un filtrado más fino en primer lugar ...? ¿O hay otras razones para mantener el enfoque de la lista blanca de puertos?

36
Milind R

Bloquear todos los puertos, excepto 80 y 443, puede ser parte de una buena estrategia de defensa en profundidad. Si es su única estrategia, entonces está en lo correcto, será defectuosa.

Un posible enfoque estratificado por ejemplo puede ser

  1. Bloquee todos los puertos en el firewall externo menos 80/443
  2. Tener un inline IPS (o como parte de su firewall) hacer análisis de paquetes
  3. Desinfecte la entrada de la aplicación web con un firewall de aplicación web
  4. Desinfecte la entrada db con un firewall db
  5. Registre todo y aliméntelo en un sistema de gestión de registros (con alertas)
  6. Copias de seguridad de todo (cualquiera que sea su estrategia de disponibilidad)
  7. Endurezca cada sistema operativo de acuerdo con la línea de base/puntos de referencia que elija (por ejemplo, Org SOP, CIS/DISA STIGS, etc.)

Este es solo un ejemplo muy simple. Una buena estrategia de defensa en profundidad tiene muchas capas que juntas crean un sistema seguro.

30
KDEx

Estás absolutamente en lo correcto. No hay nada mágico en el puerto 80 ni en el puerto 443. No hay nada intrínsecamente seguro en un puerto u otro, ni siquiera en un protocolo u otro. Si bloquea todo menos HTTP, todos simplemente comenzarán a usar HTTP. Los atacantes pueden y siempre se mueven más rápido que todo lo demás. No están limitados por el mantenimiento de infraestructura antigua.

En esencia, los protocolos y puertos no son seguros o inseguros. Bloquearlos es solo otra forma de teatro de seguridad.

25
Steve Sether

La lista blanca es generalmente preferible a la lista negra. Si solo abre los puertos que realmente necesita, y si limita esos puertos en la medida de lo posible, entonces ha reducido su área de superficie de ataque y ha limitado el tráfico que necesita mirar.

Sí, todavía se puede abusar de 80 y 443 por tráfico malicioso. Pero también está elevando el listón para los ataques (al menos un poco) al forzarlos a través de una ventana mucho más pequeña, y una que puede vigilar más fácilmente.

11
Xander

Los números de puerto no importan. Las aplicaciones que escuchan o se conectan en cualquier puerto son importantes. Use redes para limitar los vectores de ataque de aplicaciones.

Algunas sugerencias:

  • Los nodos de aplicación deben ser accesibles en múltiples redes con diferentes propósitos y perfiles de tráfico: una red de aplicaciones y una red de administración.
  • Evite aplicaciones en puertos <1024, p. use 8080 o algún otro puerto aleatorio. NAT a los puertos de la aplicación en los límites de la red de la aplicación (en el LB).
  • Use iptables para permitir solo el tráfico de la aplicación (80, 443) desde direcciones IP de equilibrador de carga específicas (si no está utilizando la ruta directa LB) o hacia servicios internos (su base de datos).
  • Limite SSH (22) y otro tráfico (registro) a una red de administración.
  • Físicamente segregar redes, si es posible.
  • No confíe en DNS para la configuración del nodo de la aplicación.
  • Separe las redes corporativas y de desarrollo de las redes de producción.
  • Monitoree redes segregadas para detectar tráfico no aprobado. por ejemplo: el tráfico SSH en la red de su aplicación indica un problema.
3
Kurt Stephens