Auditoría integral del firewall: ¿no se puede acceder realmente a Internet?

Por lo que está describiendo, diría que la única forma de lograr su objetivo es una auditoría con credenciales del servidor y el firewall, en lugar de la exploración de la red desde el servidor.

La razón de esto es que el tráfico saliente solo se permite a un solo puerto alto en un solo host, no hay forma de que el método de escaneo de puertos encuentre eso.

Recomiendo hacer una revisión manual del conjunto de reglas del cortafuegos para asegurarse de que las reglas funcionen como se pretende. Dependiendo de lo que se use / de cuán familiarizado esté con ese tipo de cosas, puede hacerlo manualmente o usar algo como nipper para ayudar .

Para explicar lo que está viendo en el escaneo del puerto.

Todos los puertos responden como cerrados en lugar de filtrados. Esto es algo inusual para una conexión con firewall, ya que la mayoría de los firewalls eliminarán el tráfico bloqueado en lugar de rechazarlo explícitamente.

Sin embargo, eso explica por qué nmap piensa que el host está activo. Nmap utiliza un par de mecanismos para determinar que un host está activo y uno de ellos es un ping TCP (consulte la sección -sP de esta página) ). Si obtiene una respuesta a eso, se supone que el host está activo. Como su servidor de seguridad parece estar respondiendo con RST / ACK (el mensaje cerrado), esto causaría que nmap piense que todo está funcionando, ya sea que esté o no.

En una vida anterior usamos una herramienta llamada Firemon para hacer esto. Firemon no realiza pruebas físicas "reales / en vivo" basadas en el host, como las que se describen anteriormente, sino que analiza las reglas del firewall y luego determina qué puertos pueden estar abiertos.

Uno de los informes que pudimos ejecutar sería determinar qué puertos / protocolos están permitidos entre dos hosts. Incluso podría expandir eso para comparar puertos / protocolos entre dos redes.

Por supuesto, esto solo le daría resultados válidos si sabe que no hay forma de que el tráfico de su servidor pase por alto su firewall. Esto podría requerir una revisión de la arquitectura de la red y luego una prueba de tráfico básica para determinar la ruta de los paquetes, etc.

Si reúne algunas de esas pruebas, probablemente pueda lograr lo que desea hacer sin tener que escanear a Internet. No es una prueba física real, pero le daría cierto nivel de confianza. (es decir: no está probando que el firewall no tenga fugas). Luego, puede combinar esto con el registro de sus enrutadores e interruptores y listas de observación en una solución de tipo SIEM. IE: alerta si el host de ShouldNotHitInternetList se comunica con una ip no local.

Puede comenzar a organizar una serie de controles que le darán la confianza que necesita.

Por lo tanto, un escaneo SYN no le mostrará ninguna conexión basada en UDP, puertos abiertos, etc., ni hará nada en contra de, digamos, túneles ICMP. Pero volvamos a lo básico aquí. Tiene un objetivo, evitar conexiones o, más bien, auditar esas conexiones. Para eso, solo debes auditar las reglas de FW para los principiantes. Por ejemplo,

iptables -L -n 

Lo que le mostrará qué reglas se están ejecutando actualmente en una máquina. Si fuera yo, lo diagramaría todo (Visio). Qué servidores realizan qué tareas y qué reglas de firewall se implementan actualmente en esos servidores. ¿Coinciden con lo que necesitas / quieres hacer / se está haciendo?

Yo: Instalaría syslog remoto (syslog-ng) con TODOS los paquetes / conexiones que se están registrando, a los que puedo poner en algo como Splunk para análisis y alertas. Tal vez incluso lanzando AlienVault para alertarme de anomalías, etc. No me molestaría en escanear una vez que lo haga. auditado las reglas de fw, mi objetivo sería saber / entender lo que está llegando y dejar mis servidores. Para eso, tendría un análisis de archivo de registro (syslog remoto) y preferiblemente un SIEM.

Si fuera yo, entonces mi primera línea de defensa para un servidor coubicado estaría en el mismo servidor. No tengo acceso a todos los otros dispositivos involucrados en mover datos alrededor del centro de datos. No tengo tiempo para probar todos los cambios aplicados en el centro de datos (incluso si los operadores me lo han dicho).

Lo que describe puede implementarse en unas pocas reglas de iptables sin estado, que ofrecen una prueba por inducción de que el sistema se comportará como se define. Estaría tentado de ir un paso más lejos y asegurarme de que no haya una ruta predeterminada configurada en los dispositivos, solo para los puntos finales definidos explícitamente.