Una instancia a la deriva I: preparación y primeros logs

Hace hoy 12 días, haciendo uso de la Free tier de AWS, se me ocurrió (con fines educativos, obvio xD) lanzar una instancia y dejarla a la deriva, como quien dice a la buena de Dios.

La idea es poner en práctica algunas herramientas y ver qué se puede aprender de los logs y como segundo paso analizar una "intrusión" exitosa (si eventualmente la hay). Una suerte de honeypot pero mas rústico.

La instancia lanzada corre Ubuntu 14.04 con las siguientes características:

• Instancia t2.micro (es gratis xD)
• El servicio SSH se encuentra activo y permite autenticación por password (a los fines de permitir una intrusión "controlada" dejando un password sencillo). Es el único servicio de acceso público.
• Al usuario por defecto (ubuntu) le fueron removidos los permisos de sudo, de forma tal que no pueda convertirse en root tan fácilmente, ni ejecutar comandos como tal.
• Tanto el usuario ubuntu como root tienen passwords fuertes, de momento.
• Auditd está configurado y corriendo, con un subconjunto de reglas obtenidas del archivos lspp.rules (/usr/share/doc/auditd/examples/lspp.rules.gz). Labeled Security Protection Profile (LSPP).
• Fail2ban se encuentra corriendo y analizando los logs (/var/log/auth.log), pero solo a fines de reportar los accesos exitosos (en lugar de los fallidos). Esto es para ser consciente del momento en que la instancia sea accedida por un tercero.
• En background corre tcpdump capturando todo el tráfico que entra y sale de la instancia. Cada 5 MB de tráfico capturado el archivo es comprimido y copiado fuera de la instancia. Si por algún motivo esta captura es detenida, la instancia se apagará.
• Los archivos auth.log y mail.log son rotados  diariamente y copiados fuera de la instancia.
• Los logs de auditd son copiados a fuera de la instancia cada 2hs.
• Por si no lo saben la Free Tier es free hasta cierto consumo de recursos, en particular lo que mas me preocupa es el consumo de tráfico de red que está acotado a 15GB de tráfico saliente mensuales. En caso de que este límite se supere y se me generen gastos asociados, una alarma de Cloudwatch me lo avisará y podré tomar acciones (apagar la instancia xD).

Configuración de auditd

Dado que no pensaba ponerme a escribir todas las reglas desde cero se me ocurrió (sugerencia de Red Hat de hecho xD) utilizar uno de los archivos de ejemplos que vienen con el paquete en su instalación (/usr/share/doc/auditd/examples/). En particular elegí lspp.rules porque la mayoría de las reglas coincidían con lo que yo pretendía que audit registrara. Sin entrar en detalles:

• Se registraran eventos sobre archivos y directorios críticos del sistema, /etc/passwd, /etc/cron*, /etc/init.d/, /root/, /etc/audit/ entre otros.
• Se registraran las actividades del usuario ubuntu (usuario que será expuesto con contraseña débil). Procesos creados, archivos, etc.
• Ante eventos adversos auditd lanzará un kernel panic, lo que esencialmente detendrá el funcionamiento de la instancia. Es decir, si no hay logs no habrá instancia.
• Los logs son rotados por el mismo auditd y existe un cronjob que cada 2hs manda el archivo rotado por mail. De esta manera los logs son almacenados para analizar posteriormente.

Configuración de tcpdump

La idea de correr una captura de tráfico en background es para contar con los detalles de la actividad de red durante la potencial intrusión. Acá tampoco hay nada de magia, tcpdump es lanzado de la siguiente manera

tcpdump -n not port 25 -w sample -C 5M -z /sbin/reader 2>/dev/null & echo $! > /var/run/reader.pid

de tal forma que el tráfico al puerto 25 es ignorado (esto es para cortar el loop que se formaría al capturar el tráfico del mail), la captura es fraccionada cada 5MB y procesada por el script /sbin/reader, que sencillamente comprime el archivo le da un nombre mas mailfriendly y lo envía por correo. Como mencioné antes, hay un cronjob que a cada minuto controla la existencia del proceso señalado por el contenido del archivo reader.pid, si no encuentra un proceso con ese pid apaga el sistema. Claramente esto no es infalible, pero es una medida de protección mas.

En algún momento analicé la idea de mandar los logs y demás archivos a un bucket S3. El problema es que la free tier solo da 5GB de almacenamiento gratuito en S3 y limita el número de operaciones PUT a 2000, que podrían no ser suficientes, por eso me opté por envío por mail (rústico, I know xD).

Logs de autenticación

Dado que parte de la idea de esto es analizar los logs, había que ver qué analizar y cómo. De momento el análisis es completamente offline, los archivos /var/log/auth.log y /var/log/mail.log son rotados diariamente y el archivo rotado es enviado por mail. A ciencia cierta el único utilizado de momento es auth.log, que luego de obtenido es utilizado para poblar una BD con los registros de intentos fallidos de autenticación en el servidor.

Un script en perl recorre los logs e inserta cada autenticación fallida en una tabla, para que sea un poco mas sencillo el análisis.

Primeros resultados

Después de 12 días de logs, acá va un pequeño resumen de lo que encontré:

• Se registraron 46556 intentos de autenticación fallidos, provenientes de 664 direcciones diferentes.
• De las 664 direcciones, 
• 159 pertenecen a la India con 297 intentos. Los 3 usuarios mas probados fueron admin (46), user (10), support (5).
• 112 pertenecen a Rusia  con 246 intentos). Los 3 usuarios mas probados fueron admin (52), login (12) y MGR (12).
• 106 pertenecen a Bahrain (unas islas del Golfo Pérsico) con 195 intentos. Los 3 usuarios mas probados fueron admin (67), MGR (11), User (8)
• 105 pertenecen a Brasil con 200 intentos. Los 3 usuarios mas probados fueron admin (72), MANAGER (7), User (6)
• 70 pertenecen a Italia con 123 intentos. Los 3 usuarios mas probados fueron admin (22), MGR (11), FIELD (7) (seguido por MANAGER(6)).
• 43 pertenecen a China con 10884 intentos. Los 3 usuarios mas probados fueron root (10601), oracle (21), ubuntu (19).
• 21 pertenecen a Pakistan con 35 intentos. Los 3 usuarios mas probados fueron admin (6), MAIL (5), maint (4).
• 11 pertenecen a USA con 11732 intentos. Los 3 usuarios mas probados fueron root (11101), test (110), nagios (68).
• y el resto a otros países con un total de 22844 intentos (un número muy chico de IPs realizó muchos intentos).
• Del punto anterior hay una serie de similitudes a la vista, los intentos recibidos de Bahrain, Brasil, Italia y Rusia tienen usuarios en común como admin, MANAGER y MGR.
• Las IPs de China y USA apuntaron casi completamente al usuario root. De hecho:
• De USA 108.51.89.92 hizo 10409 intentos el 16 de Julio seguida por 198.154.62.59 con 539 el 7 de Julio.
• Del lado de China la cosa está mas distribuida, 
• 218.65.30.217 hizo 539 el 7 de Julio, 15 el 9, 90 el 11, 1065 el 12, 166 el 16 y 285 el 17. 
• 218.87.111.109 hizo 539 intentos el 8 de Julio, 539 el 10, 32 el 11 y 3 el 15. 
• 59.63.192.196 hizo 540 intentos el 10 de Julio, 539 el 12 y 10 el 13. 
• Reincidencia y coincidencia con el número de intentos, eso podría indicar el uso de las mismas herramientas, incluso muchos coinciden en la frecuencia de las pruebas entre 8 y 10 segundos.
• Los 3 usuarios mas probados son root (43428 veces, 93% de las veces), test (352 veces) y admin (348 veces). Claramente root es el usuario mas deseado, lo cual es lógico ya que ganar acceso de root de esta manera sería una manera MUY sencilla de obtener control total del sistema.
• Las 3 IPs con mas intentos son:
• 108.51.89.92 de USA con 10832 intentos durante el 16 de Julio, a razón de 1 intento cada 2-4 segundos.
• 180.250.223.10 de Indonesia con 10832 intentos durante el 16 de Julio, a razón de 1 intento cada 2-4 segundos.
• 77.222.137.46 de Ucrania con 10832 intentos durante el 13 de Julio, a razón de 1 intento cada 2-4 segundos.
• Seguidos por las IPs chinas del punto anterior.
• Las 3 IPs del punto anterior parecen haber utilizado el mismo diccionario, ya que además de coincidir el número de intentos coinciden los usuarios utilizados exactamente, incluso el orden en que fueron probados. Se probó:
• zhangyan 1 vez
• dff 1 vez
• root 10409 veces
• oracle 2 veces
• test 102 veces
• ubuntu 9 veces
• y a continuación usuarios como: git, boot, 123456, 123, apache, bash r00t, etc.
• 53 direcciones fueron identificadas al menos 2 días, 2 de las IPs registraron intentos 6 días diferentes.
• En cuanto a los clientes utilizados:
• El 77% utilizó libssh-0.5.2 .
• El 18% utilizó PUTTY . 
• El 3% utilizó libssh-0.1
• El 1,8% utilizó libssh2_1.4.3, libssh2_1.4.2 o libssh2_1.4.1
• Luego siguen algunos como: JSCH-0.1.51 y paramiko_1.14.0

A partir de este momento y para hacer las cosas mas interesantes, queda expuesto el usuario ubuntu con un password MUY sencillo. Veremos cuánto tiempo les toma lograr una autenticación exitosa y cómo se comportan.