💾 Archived View for gemini.elbinario.net › monitorizacion.gmi captured on 2024-06-16 at 12:23:11. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
Es una creencia (errónea) que las personas que utilizan Linux están seguras frente a todo tipo de amenazas digitales. La realidad es que, pese a que la mayor parte de los ataques dirigidos y automatizados se diseñan para Windows (por estadística de uso), existen amenazas muy graves en Linux. De hecho, están aumentando cada vez más.
Con esto en mente y saliéndome de mi línea habitual de artículos, quiero dedicar un hueco a explicar monitorización básica de eventos en Linux (concretamente funcionaré con Debian, pero podríamos aplicar lo mismo en un CentOS o un Fedora con ligeros cambios), sin irnos a configuraciones complejas como Velociraptor (aunque lo recomiendo un montón), y trabajando directamente desde la terminal con auditd. Quiero incidir en un poquito de saneamiento en este sentido por amenazas como:
Los cryptominers (que hay mogollón) para Linux
Ransomware (como AvosLocker )
Los payloads dirigidos a Linux (payloads son pequeños programas, scripts y recursos pensados para lanzar un ataque, como por ejemplo una reverse shell) en forma de scripts o de binarios ELF.
Y otras muchas. A las máquinas individuales no le suelen llegar payloads o ransomware (eso suele estar mucho más enfocado a servers empresariales o de asociaciones, en definitiva algo más alcance y peso) pero un cryptominer si puede ser una amenaza común.
En cualquier caso, nunca está demás dedicar una tarde aburrida a sanear y monitorizar tus sistemas. Así que allá que vamos.
Por un lado, no nos hace falta auditd para hacer un hardening básico. Nos basta con seguir algunas pautas para restringir usuarios, crear reglas de contraseñas de sistema (para que tengan caducidad),o restringir el uso de USB y otros dispositivos externos. En este artículo me quiero centrar en monitorizar un sistema que ya se supone de algún modo seguro (o no) pero en cualquier caso, un sistema ya configurado. La monitorización es una actividad importante no sólo para enterarse de lo que ocurre en directo, si no para perfilar que ha ocurrido durante un ataque que ya ha sucedido y estudiar prevenciones en el futuro. Ese trabajo en si, en el mundo real se llama “Threat Hunting”, y en general se usan herramientas “muy tochas”. En este caso vamos a hacer las veces de hunting versión zapatillas de andar por casa un domingo, pero suficiente para tener un poco más de control sobre nuestro sistema.
Para empezar vamos a installar auditd:
sudo apt install auditd
Y comenzar el servicio:
sudo service auditd start
Ahora comienza la monitorización pero tenemos que definir reglas para ello. Para comenzar necesitamos: el archivo que queremos monitorizar (luego indicaré una lista de algunos interesantes y por qué), un filtro de permisos (lectura, escritura, append, ejecución) y una clave para buscar en el log posteriormente.
sudoauditctl -w /etc/passwd -p war -kmipass
Mediante este comando (que podemos ver aquí https://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-a-file.html ) estamos creando una regla de monitorización sobre /etc/passwd de escritura, append y lectura con la clave mipass.
Tras un rato si hacemos algo como consultar con grep o cat /etc/passwd, esto se quedará en el log y lo podemos consultar con:
sudo autosearch <comando>
Podemos crear varias reglas, y consultar varias cosas, por ejemplo una que viene de ejemplo en la misma página me parece súper útil:
sudo auditctl
-w /tmp -p e -k webserver-watch-tmp
Que monitoriza ejecuciones desde tmp (es decir, localización temporal). Esta es útil porque gran cantidad de malware “droppea” (disculpad los anglicismos) partes del ataque en esta dirección, y ejecuta cosas desde ahí (también ocurre en Windows).
Vale, una vez sabemos esto, imaginad que sois un malware que está intentando mandarse a sí mismo a cuantos más sitios mejor. Una técnica que suele utilizarse es comprobar claves ssh. De modo que podemos poner una regla:
sudoauditctl -w ~/.ssh/mi_clave-p war -kmipass
Para vigilar. Del mismo modo podríamos consultar quién ha hecho cat o cp de ese archivo con:
sudo autosearch –f ~/.ssh/mi_clave -i | grep comm | grep cat >> use of cat
sudo autosearch -f ~/.ssh/mi_clave -i | grep comm | grep cp >> use of cd
En este caso, autosearch -f nos permite filtrar por ese archivo en particular, en el log nos quedamos solo con comm, que es el comando usado, y buscamos en particular el uso de cat o de cd respectivamente. El filtro -i nos permite ver el usuario por nombre en lugar de por UID, lo cual es útil para que sea más amigable para un humano.
Ahora imaginemos que queremos crear una alerta para cuando el usuario 2000 usa cp sobre ~/.ssh/mi_clave, podríamos hacer:
USUARIO=»2000″
sudo autosearch -f /etc/passwd -ui $USUARIO -i | grep cp >> alerta_copiar
if [ -s alerta_copiar ]; then
notify-send «alerta, intento de copiar passwd por UID $USUARIO»
fi
Y programar la tarea para que se repita el tiempo que deseemos. Puede quedarse en paralelo añadiendo un while true y ejecutando con & en esa sesión o utilizar crontab para despreocuparse.
Otra cosa importante es la entropía de archivos. Con la siguiente línea (me vais a disculpar de que sea tan cutre, es la que uso) checkeo la entropía Chi Square de un archivo llamado test. El contenido del archivo es “prueba prueba prueba”.
cat test | ent -t > myent.csv | csvtool format ‘%(4)\n’ myent.csv | sed ‘1d’ ; rm myent.csv
El resultado en este caso sería 698.238095. Este número es el resultado de calcular la distribución de cada byte (un análisis de frecuencia), y nos ayuda a decidir si un documento está siendo comprimido, cifrado, modificado en general en relación a valores aleatorios. ¿Por qué es esto importante? Porque es lo que se utiliza para detectar si un ransomware está modificando (cifrando) un archivo. Algunos ransomware cifran de forma intermitente (en lugar de cifrar todo el archivo, solo trozos) para que la entropía no ascienda mucho (cuanta más entropía, más sospechoso de ataque de cifrado), pero no son la mayoría. De modo que podemos crear un archivo que guarde está información sobre un archivo que llamaremos “beacon”, y con monitorizar un cambio de ese archivo que puede ser de cifrado.
cat test | ent -t > myent.csv | csvtool format ‘%(4)\n’ myent.csv | sed ‘1d’ > beacon
rm myent.csv
valor=$(cat beacon)
int=$(echo «${valor%%.*}»)
valor_n=$(($int))
if [ $valor_n -gt 800 ]; then
notify-send «ALERTA, el beacon parace que se está cifrando»
fi
Si colocamos monitorización sobre ese archivo…
sudoauditctl -w beacon-p war -k mipass
Podemos comprobar quién, cuándo y cómo se ha cifrado el archivo.
sudo autosearch –f beacon-i >> beaconlog
El log de beacon también contiene nuestros cambios con el string, así que podemos comprobar todos los comm (comandos) del log:
sudo ausearch -f beacon | grep comm
Y después investigar los comandos que te parezcan más sospechosos (concretamente los que no sean del cron si usas cron o del script).
sudo autosearch -f beacon -c <micomando>
Aquí os dejo algunas ideas sobre qué monitorizar, ahora que sabemos cómo:
Entropia: si tienes dudas puedes comparar la entropía entre tu beacon normal y un beacon cifrado de diferentes maneras para ajustar la comparativa del script con tu propio benchmark. Estoy trabajando en un paper sobre un beacon minimal en Raku, por si os es de utilidad en el futuro, lo apsaré.
Contraseñas: cualquier archivo de contraseñas debería estar monitorizado dentro de este contexto, incluyendo los de keys de keepass, si es que están en local. Para un plus, investiga como funciona mimipengin, un programa para dumpear contraseñas y claves en Linux que utilizan varios cibercriminales (como Mimikatz en Windows), por ejemplo observa como se fija en “~/.local/share/keyrings/” o “/etc/vsftpd.conf”.
La mayoría de los ataques utilizan algo llamado C2 (command and control) un sistema para comunicar el servidor atacante con la víctima. Y con mucha frecuencia usa algo tan simple como wget o curl. Pero para asegurar que está comprueban que existe o lo intentan descargar de nuevo. Encuentra dónde están situados en tu sistema (si es que están) y monitoriza también esto.
Cada sistema es un mundo así que podéis probar a monitorizar diferentes situaciones en base a vuestras necesidades. Espero haber dado algunas pistas.
https://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-a-file.html
https://www.tecmint.com/linux-server-hardening-security-tips/