HolA!” Continuando con las configuraciones sobre CISCO ASA, hoy dejo #how to sobre ataques tcp syn-flood (algo bastante común).-
Antes que nada les dejo un link de wikipedia para los que no saben de que va esto de “tcp syn-flood”.
Topologia: Simulamos una salida Internet y un atacante que conoce la dirección de ip 200.68.122.3:80. En esa dirección nuestro ASA tiene configurado un “forwarding” del puerto 80 desde la publica hacia un servidor web que esta ubicado en una DMZ (10.10.50.100).
Nuestro objetivo es decirle al ASA que haga un seguimiento sobre las sesiones que van destinadas desde Internet hacia el “servidor web” en la DMZ con el fin de determinar si es una conexión valida o si es un ataque. Como lo hace? El ASA utiliza algo llamo “TCP Inspection” entonces cuando una usuario desde Internet inicia la comunicación hacia la 200.68.122.3:80 lo detecta y contesta el three-handshake simulando ser el servidor. Si lo puede realizar con éxito entonces reenvía ésta info al server y el usuario se conecta sin problemas. Si el three-handshake falla lo considera un atacante y lo bloquea. Uno podría pensar que lo único que estamos haciendo con ésto es mover el ataque DOS del servidor al ASA, pero no lo afecta tan significativamente como sí lo hace con el servidor, debido a que cuenta con “TCP Syn Cookies”. Por lo cual no se queda esperando el ack del cliente sino que lo recuerda y cuando éste vuelva, finaliza el three-handshake y considera la conexión como válida.
Dejo un link sobre “TCP Syn Cookies” (Esta en ingles)
Comenzamos a configurar indicando sobre que interfaz vamos a configurar la política y le asignamos un nombre…
Configuramos el “class-map”
Creamos el “policy-map”..
Maximum Embyonic Connection: Indicamos cuantas conexiones con handshakes no finalizamos permitimos. Ramdomize Sequence Number: Cada conexión TCP tiene 2 números iniciales de secuencia (ISN – initial sequence number). Uno generado por el cliente y otro generado por el server. Si no activamos ésta opción somos vulnerables a sufrir un ataque hijacking, ya el atacante podría predecir el siguiente ISN de una nueva sesión tomando control de ésta.
Dejo un link de CISCO donde se explica en detalle todas las opciones (inglés)
Listo!
ATACANDO AL FIREWALL!!!
Iniciamos el ataque al firewall vulnerable! Vemos como la cantidad de sesiones aumenta significativamente…
Luego de la configuración para prevenir éste tipo de ataques, podemos observar que el firewall solo permite 5 sesiones con handshakes no terminados.
Comments