Strike 3 …

Si ya se que he andado un poco callado, pero parece que ya puedo volver a las andadas.

Desde el pasado jueves comencé a notar un comportamiento anormal tanto en la salida como en la entrada de datos provenientes del ancho de banda de la universidad, dicho comportamiento me hizo revisar un poco el olvidado router que tenemos aquí, para detectar la posible falla.
Mas o menos para que se den una idea los anchos de banda andaban así:

Como se puede apreciar, no es nada normal este comportamiento y mas cuando no se permite usar KaZaas, Torrents y esas cosas que comen ancho de banda a lo loco y mucho menos en un domingo por la tarde, lo único que se me ocurrió es que estábamos siendo víctimas de algún tipo de ataque.
Con el comando show processes cpu history desde la linea de comandos del router se puede apreciar los picos, en las últimas 72 hrs. que estaba teniendo el router. En días normales el procesador anda entre el 7% y 10% de utilización y como se puede ver hubo momentos en que se tuvo hasta el 100%.

100 * *
90 * *
80 * * *
70 * *#******** *
60 * *#**####*** *
50 * *##*######****
40 * *##*#######***
30 * **##########***
20 * **###########**
10 #################
0….5….1….1….2….2….3….3….4….4….5….5….6….6….7.

CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU%

Desgraciadamente CISCO por si solo no ofrece mucha información y la poca que ofrece es muy enredosa. Afortunadamente Google siempre será el mejor amigo del administrador de sistemas, pero aún y con esa herramienta, la información es muy escasa, genérica o muy técnica. ¿Qué es lo que buscaba? Bueno pues básicamente la manera de habilitar los logs para las interfaces seriales del router, que son las que reciben los E1, de tal manera que me dijeran los destinos, orígenes, protocolos y puertos del tráfico que se estaba generando. En mis primeros intentos por ahí del domingo en la noche, eran tantas las transacciones que estaba teniendo el router que al momento de habilitar estos logs en pantalla, el router simplemente dejó de responder.
Lo que me llevo a buscar la manera de arrojar esos logs pero hacia otro equipo, ya que querer visualizarlos en la consola era imposible. El servicio capaz de hacer esto, generalmente es un Syslog Server, toda distribución de Linux cuenta con uno, ya que es el que se encarga de archivar los logs del propio sistema, lo único que había que ajustar es que recibiera esos logs de un equipo (router) externo.
Una vez habilitado el Syslog server, es necesario indicar al router quien sera ese server, que es lo que “logeara” y de donde y hacia donde.

Inmediatamente al empezar a aparecer los primeros logs se podía apreciar claramente que varias redes o hosts estaban llegando a una misma red (SYN Attack o Flood Attack), la cual no estaba definida en el router. Mas tarde me daría cuenta que esa red si pertenecía a UNIVA, pero no se estaba utilizando.
Ya con el conocimiento de la red víctima, simplemente agregé algunas ACL (Access Control Lists o Listas de control de acceso) en las interfaces seriales del router y listo… ataque terminado, pero casi cinco días después.

Gracias a que el router es un equipo bastante pero bastante grande en cuanto a capacidad, el ataque no tuvo repercusiones hacia los usuarios directamente, de hecho el firewall ni se enteró que había un ataque en su perímetro. Sin embargo tardé mucho tiempo en bloquear el ataque, en parte por que mis conocimientos sobre el IOS (sistema operativo del router) de Cisco eran casi nulos, ahora ya aprendí varias cosas que espero me sirvan en un futuro. Sin embargo creo que la base para una buena detección es tener herramientas como los Syslogs o el MRTG, para conocer y detectar comportamientos anormales en nuestras redes o equipos.