Senda Oscura

Hoy estaba revisando algunos logs y pensé: ojalá pudiera resaltar con colores algunos patrones, me ayudaría mucho. Por supuesto, la primera idea que se me vino a la cabeza fue usar el grep:

# grep –colour PATRON /var/log/messages

Pero el grep elimina todas las líneas que no contienen el patrón y eso tampoco me interesaba. Busqué en la web un rato y encontré varias utilidades que coloreaban ficheros de logs completos, pero tampoco era lo que quería.

Lo que necesitaba era una utilidad que me resaltara sólo ciertos patrones y que me devolviera el contenido íntegro del fichero de logs. Eso sí que estaría bien. Y diría que hace tiempo me encontré con una utilidad que hacía exactamente eso… pero como no daba con ella y tampoco quería pasarme toda la mañana buscándola, escribí un pequeño script en perl que hacía todo lo que yo necesitaba. No soporta expresiones regulares (de momento) pero es suficiente para lo que yo lo quiero. Os pongo un par de ejemplos de uso:

1. Si lo ejecutamos sin parámetros nos sale una ayuda muy cutre. Básicamente nos dice que necesita al menos un patrón que colorear. El script sólo admite cuatro patrones como máximo (pero es muy sencillo modificarlo para que admita más). Cada patrón será resaltado con un color distinto.

# highlight
ERROR: Necesito al menos un patrón que sobresaltar
Uso: /usr/local/bin/highlight patron [patron2] [patron3] [patron4]

2. Coloreamos el log del iptables para que resalte los patrones ‘SPT=’, ‘DPT=’ y ‘Output’.

# cat iptables.log | highlight SPT= DPT= Output

3. Similar al anterior pero usanto un tail:

# tail -f iptables.log | highlight Input SPT= DPT= src= DST=

Descargar Highlight Script

El año nuevo me trajo un bonito regalo: una máquina comprometida. Me pidieron lo que se suele pedir en estos casos, buscar como lograron acceso y que medidas tomar para evitar intrusiones futuras. La máquina en cuestión ofrecía servicios de webhosting y no podía desconectarse bajo ningún concepto, tampoco existía una máquina de respaldo para casos como estos. Las copias de seguridad se hacían rigurosamente, pero no es suficiente en esta situación, es necesario que exista una máquina de respaldo lista para entrar en funcionamiento con la última copia de seguridad limpia.

Pero esto es lo que te enseña la experiencia, las cosas no son como dicen en los manuales… ahí estaba mi máquina con signos evidentes de compromiso y yo no podía desconectarla para analizarla con calma. Tampoco podía obtener un volcado del disco para su posterior análisis, se trataba de una máquina remota y, además, la carga adicional del volcado a un medio externo afectaría notablemente al desempeño del sistema.

Bueno, hay que jugar la mano con las cartas que te tocan, así que me puse manos a la obra. Tras un primer vistazo al sistema descubrí un bouncer y varias instancias del eggdrop campando a sus anchas, además todo ejecutado por el usuario ‘www-data’. Aquello olía a script kiddie. Era evidente que la máquina había sido comprometido por el fallo de algún CMS, pero en aquel momento sentía más curiosidad por la personalidad del atacante que por el fallo que le permitió entrar. Escribí unas cuantas reglas IPTables para asegurar mínimamente la máquina y fui a la caza del intruso. Tras tracearle un poco la pista lo encontré en un IRC dejado de la mano de Dios, estaba en un canal rodeado de todos sus eggdrops. Os aseguro que había muchos y cada uno de ellos era señal inequívoca de que una máquina había sido comprometida en algún lado. El servidor IRC no ocultaba la IP, así que tenía todas las direcciones de todas las máquinas comprometidas, supongo que debería haber notificado a los afectados… pero lo que hice fue hablar con mi pequeño intruso. Era un chaval chino con ganas de impresionar a sus amigos y obtener privilegios de operador en algún canal hacker. Estaba conectado a través de un bouncer, así que localizar su IP real me iba a costar mucho trabajo y tiempo… y tediosas negociaciones con administradores negligentes.

Ya conocía al intruso, así que volví a la máquina. Primero había que ver el alcance del ataque. No había indicios de que hubiera conseguido privilegios de root, aunque claro, siendo root nada te impide borrar tus huellas. De todas formas no parecía probable (y sin desconectar la máquina no podía hacer análisis más concienzudos). Había varios bouncers instalados en el sistema, por su fecha y ubicación era más que posible que fueran creados por distintos scripts, así pues podríamos estar hablando de varias webs vulnerables. Eliminé bouncers, eggdrops y una bonita puerta trasera colocada en el cron y fui a por el fallo que permitió entrar al intruso. Identifiqué varias vulnerabilidades que presentaba el sistema y estudié con detenimiento los logs del servidor web. Vi muchos rastreos automáticos de bots bien conocidos y alguno que otro sin precedentes, no me extrañaba nada que la máquina hubiera sido comprometida. Lo que me sigue extrañando es no haber encontrado más malware.

Informé sobre los problemas y di por acabado el trabajo. Pero aún tengo al sistema bajo vigilancia, estoy seguro de que en esa máquina hay más de lo que veo (también es posible que esté paranoico, esa es una de las consecuencias de este trabajo).

Para acabar un dilema, debería lanzarme en una cruzada contra el chaval que ejecutó el bot o debería dejarlo pasar sin una colleja… ninguna de las dos opciones me parece adecuada, pero haré lo que se suele hacer en estos casos (así va el mundo), tomaré la alternativa fácil… lo dejaré pasar.

Felices Fiestas