¿La configuración de una política DROP predeterminada realmente mejora la seguridad?

El uso de una regla DROP predeterminada para todos los puertos, excepto los destinados originalmente (para un sitio web, son 80/443) reduce la superficie de ataque de las estaciones en la red. Es mucho más conveniente (y más barato) descartar paquetes en lugar de configurar un servicio para que esté seguro con respecto a una política determinada.

Hay un par de giros diferentes que se pueden poner en su pregunta, pero voy a abordar ¿Es mejor DROP para los puertos no permitidos que para RECHAZAR?

Eliminar paquetes: en silencio, sin TCP RST o ICMP Prohibited - es preferible por al menos dos razones.

1. ralentiza los escáneres que intentan llegar a un gran número de puertos porque no obtienen comentarios positivos.
2. Reduce los falsos positivos en las exploraciones: los exploradores que ven mensajes RST / Prohibidos llegan a esperarlos, y cuando se realiza una exploración grande a veces estos paquetes se pierden. Si nunca envía las respuestas, no se pierden los paquetes descartados en un escaneo, y los cierra.

Si usted mismo está escaneando (por ejemplo, para verificar el cumplimiento), reducir esos falsos positivos es una mejora notable. Y si está reduciendo los falsos positivos de los escáneres malintencionados, bueno, preferiría que no se entusiasmen con los puertos que están cerrados; Prefiero que tengan un escaneo preciso y, mirándolo, deciden ir a pescar a otro lugar.

Lo pondría a la defensa en profundidad. Sí, puede configurar sus servicios para escuchar solo a localhost o su red interna. Incluso cuando se configura correctamente, todavía existe la posibilidad de que debido a un error en el código, acepte erróneamente todo el tráfico. Los servicios que aceptan paquetes UDP también pueden ser vulnerables a un ataque de suplantación de IP. TCP es resistente a tal ataque ya que la configuración de la conexión nunca se lleva a cabo, pero puede terminar con muchas conexiones TCP abiertas a medias, lo que puede hacer DOS en su servicio. Esto se puede llevar a cabo porque el atacante puede falsificar una dirección IP interna que tiene acceso al servicio. Este ataque se conoce comúnmente como un ataque de inundación SYN. Más información: enlace

Al final del día, tener precauciones adicionales aumenta la cantidad de trabajo que un atacante tiene que hacer para comprometer su sistema. Los safegaurds adicionales también reducen la posibilidad de que un solo error cause una infracción.

Entiendes la situación correctamente; Hay un beneficio mínimo en dejar caer el tráfico a puertos cerrados. Sin embargo, todavía se considera "mejor práctica".

Creo que la razón por la que ShieldsUP informaría esto es que podría indicar un error de configuración. Si un administrador de firewall intenta bloquear todos los puertos cerrados y pierde uno por algún motivo, esto es algo que ShieldsUP puede detectar en un análisis. ¿Pusieron una calificación de riesgo en el hallazgo? Si es algo más alto que "bajo", entonces seriamente cuestionaría eso.

La tecnología de firewall de red no ha cambiado mucho desde finales de los años 90, y muchos consejos provienen de una era en la que "más bloqueo es bueno" sin una gran comprensión de lo que realmente ayudan los cierres. La mayor parte del progreso que ha ocurrido con los cortafuegos se está moviendo más allá de la capa de red y está realizando una "inspección profunda". Pero en un puerto cerrado, no hay absolutamente ninguna inspección profunda por hacer.

Desde la parte superior de mi cabeza, una razón obvia es que obliga al escáner a tomar más tiempo para determinar si un servicio está presente en un puerto determinado o no. No sabe si los paquetes se eliminaron en la ruta, o si la ruta al servidor al que está accediendo solo tiene un RTT largo, o si existe una política predeterminada de firewall DROP. Y todo lo que ralentiza a los atacantes, y solo le causa inconvenientes a las personas que trazan un mapa de Internet, sin afectar a los usuarios legítimos a los que realmente quiere conectarse, es Good Thing (TM).

Luego está el hecho de que esta declaración de su parte "en lugar de tomarse el tiempo para configurar correctamente estos servicios, los administradores simplemente lanzan un firewall frente a él". no tiene en cuenta el hecho de que estos servicios pueden estar tan bien configurados como sea posible , y aún contienen un 0 días. Es posible que desee que el servicio se ejecute, e incluso sea visible para (algunos) usuarios externos, pero oculto detrás de una detonación de puertos / SPA solución, o simplemente filtrado por dirección IP (al colocar una regla que acepta intentos de TCP de las direcciones de la lista blanca).

Si está usando SPA, no importa cuántos servicios estén detrás del firewall, o cuántos de ellos tienen configuraciones erróneas o días ocultos, los únicos que deben preocuparse son el firewall en sí, la solución SPA. , y los servicios explícitamente incluidos en la lista blanca en el servidor de seguridad. Por supuesto, también debe preocuparse por quién tiene las teclas de SPA, pero esa es una discusión diferente.

Y si filtra por IP, es la misma idea; excepto que ahora solo tiene que confiar en esos hosts, confiar en el firewall, confiar en su ISP (hasta cierto punto) y confiar en que un solo paquete falso y falsificado por sí solo no podrá interrumpir el servicio.

Esto tiene sentido por la misma razón que todas las listas blancas tienen sentido; la seguridad nunca se ve perjudicada, y generalmente se ayuda, cuando las capacidades se dispensan de forma estrictamente necesaria, y la información se dispensa sobre la base de la necesidad de saber.

Para las cadenas OUTPUT y FORWARDING, el razonamiento detrás de una política DROP predeterminada debería ser bastante obvio; Las políticas de DROP predeterminadas en esas cadenas son la parte más fundamental de cualquier política de filtrado de egreso.