PDF de programación - Detección de intrusiones en Sistemas Linux

Bisoños Usuarios de Linux de Mallorca y Alrededores | Bergantells Usuaris de Linux de Mallorca i Afegitons

Detección de intrusiones en Sistemas Linux.

Por carcoco (http://bulmalug.net/~carcoco/) creado el << 09/12/2001 18:20 >> y modificado por última vez el << 09/12/2001 18:20 >>

O ¿como saber si tu máquina Linux ha sido crakeada? ...

Intenet, con el consiguiente aumento en la probabilidad de sufrir un
Cada día, hay más y más máquina conectadas a
ataque por parte de crackers. El número de ataques reportados ha crecido espectacularmente con respecto a la cifra de
años anteriores.
¿Podemos estar tranquilos y seguros detrás de nuestro potente Firewall?

Linux es un sistema que potencialmente es muy seguro, pero necesita estar bien administrado, porque de otra forma
puede ser la causa de númerosos problemas relacionados con la seguridad.

Lo peor que puede pasar es que hayan entrado en tu máquina y que ni te enteres, intentaré desmenuzar algunos
consejos a seguir, para averiguar si nuestra máquina sigue siendo segura o no, al mismo tiempo que proporciono
interesantes enlaces a documentación relacionada con este tema.

Recomendaciones de Seguridad:

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Utilizar buenas contraseñas, para evitar los ataques a contraseña.
Utilizar encriptación en las comunicaciones: ssh, pgp, SSL, Ipsec ...
Habilitar únicamente los servicios necesarios.
Detectar puntos vulnerables del sistema: scanners.
Registro de sistema: logs.
Integridad del sistema: Tripwire, md5sum ...
Actualización del sistema debido a problemas de seguridad.
Utilización de Firewall.
Sistemas de detección de Instrusos (IDS): snort, LIDS, ...
Utilización de un sistema de archivos encriptado.

Aún siguiendo todas estas recomendaciones, no podremos estar seguros al 100% de que nuestro sistema no ha sido
crackeado, y que cuando ejecutamos, por ejemplo, ps -aux, no estemos realmente ejecutando un troyano que recoge
información sensible de nuestro sistema.
Lo que tendremos que hacer es descubrir indicios de la presencia de los crackers en nuestra máquina:

Verificar tamaños de archivos: ps suele medir 80 Kb, aunque podemos encontrar troyanos del comando ps de apenas
10Kb:

$ type ps
ps is /bin/ps
$ l /bin/ps
-r-xr-xr-x 1 root root 83096 Dec 5 23:11 /bin/ps

Una precaución adicional, es tener el almacenado el resultado del comando md5sum de los archivos más
importantes/vulnerables, de forma que podemos comprobar si estos han sido fraudulentamente modificados, esto se
debería de hacer, después de terminar la primera instalación del sistema.

$ md5sum /bin/ps
3fb65605d59a7c89206926c1a600d220 /bin/ps

Precisamente esta es la función principal del programa Tripwire (http://www.tripwire.org/), asegurar la integridad de los
archivos, de una forma más flexible y potente que lo que tendríamos que montar a través de scripts y md5sum. Tripwire
se distribuye con licencia GPL desde hace algun tiempo, siendo anteriormente comercial, este es el motivo por el que
encontrareís varios proyectos, que se autodenominan una alternativa al comercial tripwire. como aide (
http://www.cs.tut.fi/~rammer/aide.html)

Otro truco habitual de los script kiddie es enlazar el comando history de la shell, para que apunte a /dev/null, de forma
que no registre en el historico los comandos ejecutados:

$ l /home/carlos/.bash_history
-rw------- 1 carlos users 9434 Dec 8 19:44 .bash_history

Tendriamos que preocuparnos, si no topamos con algo como:

$ l /home/carlos/.bash_history
lrwxrwxrwx 1 carlos users 9 Dec 8 19:44 .bash_history ->
/dev/null

Suelen usar otro tipo de shells mucho mas simplistas, que no registren los comandos ejecutados, de forma que se evitan el
preocuparse de borrarlos. Por eso siempre es recomendable tener instalado únicamente lo que realmente se utiliza.

También suelen manipular los registros del sistema, quitando sus entradas, para que no quede constancia de sus actos en
sitios/programas como utmp, wtmp, lastlog, /var/log/messages ...
Más información en Anonymizing UNIX Systems : http://www.pimmel.com/articles/anonymous-unix.html.
Para evitarlo:

Mandar la parte más sensible del registro a un impresora, de forma que al cracker le seria imposible borrar estas
entradas. Aunque si se da cuenta del truco, puede colapsar la impresora mandandole imprimir basura.
Utilizar otra máquina como registro, necesitará crackear esta otro máquina para eliminar todas sus huellas.
Mandar los logs por correo electrónico.
Cualquier otra posibilidad que se os ocurra. Existen varios sistemas de registro de log, mucho más potentes y
seguros que el syslog típico de Linux, como por ejemplo Modular Syslog de la empresa Core (
http://sourceforge.net/projects/msyslog/), con licencia BSD.

Podemos usar varios programas que detectan el borrado de estos log, algunos de los más populares son el Antizap y el
Antizap2 (alguien sabe donde encontrarlos). (También podemos usar el chkrootkit, tal y como veremos más adelante)

Es interesante examinar si aparecen misteriosamente cuentas de usuarios desconidas en el sistema, para lo cual
examinaremos el fichero /etc/passwd: Sólo debería aparecer el usuario root, con todos los privilegios.

$ grep :x:0: /etc/passwd
root:x:0:0:root:/root:/bin/bash

Aqui tenemos la lista de todos los usuarios del sistema, si aparece alguno extraño, podemos empezar a sospechar:

$ cat /etc/passwd | awk -F’:’ ’{print $1}’

Buscaremos en el sistema ficheros ocultos o raros, que puede ser usados para ocultar troyanos, directorios, comandos,
etc...
Muchos piratas suelen crear directorios ocultos utilizando nombres como ’...’ (punto-punto-punto), ’..’ (punto-punto),
’..^g’ (punto-punto control+G), ’\ ’ (espacio en blanco), ’.\ ’ (punto-espacio en blanco). En algunos casos un pirata ha
utilizado nombres como ’.x’ o ’.hacker’ o incluso ’.mail’ .

Normalmente el script kiddie, habrá conseguido acceso como un usuario normal y explotando algún error/bug consigue
privilegios de root, los comandos/programas setuidados son los principales objetivos de los crackers, por lo que no es
mala idea tenerlos controlados.

find / -perm +4000 -print
o
find / -user root -perm -4000 -print

Revisar la configuración de programas como cron y at, de forma que el posible pirata, no haya añadido ninguna entrada
que le permita volver a entrar en el sistema posteriormente. Es interesante el averiguar realmente como ha entrado el
cracker en el sistema, porque es la única forma de evitar que pueda volver a entrar de la misma forma.

Examinar el fichero /etc/inetd.conf en busca de cambios o entradas extrañas, en especial la ejecuten un shell (por ejemplo:
/bin/sh o /bin/csh)

Revisar cuidadosamente ficheros relacionados con el acceso o ejecución remota de comandos, tales como,
/etc/hosts.equiv, /etc/hosts.lpd y todos los .rhost del sistema.

Examinar detalladamente los ficheros de logs, analizado especialmente los logs de ftp, samba, servidor http, telnet,
messages ... Nos fijaremos en entradas desde lugares extraños, verificaremos la fecha de los ficheros (es muy importante
tener correctamente configurada la hora y fecha en todos los servidores).

chkrootkit

Los crackers, suelen camuflar o sustituir en ficheros binarios del sistema su propios ficheros troyanos, algunos de los
ejemplos típicos son: login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync, asi como los binarios listados en
/etc/inetd.conf.
Nosotros tenemos que verificar que tenemos la versión original de estos ficheros y no la versión troyanizada, todo esto y
mucho más lo podemos hacer usando el potente programa chkrootkit, en la última versión disponible detecta troyanos en

todos estos ficheros:
aliens, asp, bindshell, lkm, rexedcs, sniffer, wted, z2, amd, basename, biff, chfn, chsh, cron, date, du, dirname, echo,
egrep, env, find, fingerd, gpm, grep, hdparm, su, ifconfig, inetd, inetdconf, identd, killall, login, ls, mail, mingetty, netstat,
named, passwd, pidof, pop2, pop3, ps, pstree, rpcinfo, rlogind, rshd, slogin, sendmail, sshd, syslogd, tar, tcpd, top, telnetd,
timed, traceroute, write.

Siendo capaz de detectar los siguientes RootKits:
Solaris rootkit, FreeBSD rootkit, lrk3, lrk4, lrk5, lrk6, t0rn (and t0rn v8), some lrk variants, Ambient’s Rootkit for Linux
(ARK), Ramen Worm, rh[67]-shaper, RSHA, Romanian rootkit, RK17, Lion Worm, Adore Worm, LPD Worm, kenny-rk,
Adore LKM, ShitC Worm, Omega Worm, Wormkit Worm, dsc-rootkit.

Una vez compilados los programas (chkwtmp, chklastlog, chkproc, chkwtmp, ifpromisc) que utiliza el chkrootkit para
realizar parte de sus trabajo (chkrootkit en sí mismo es un shell script), la utilización del mismo es bastante trivial.

# ./chkrootkit
ROOTDIR is ‘/’
Checking ‘amd’... not found
Checking ‘basename’... not infected
Checking ‘biff’... not infected
Checking ‘chfn’... not infected
Checking ‘chsh’... not infected
Checking ‘cron’... not infected
Checking ‘date’... not infected
Checking ‘du’... not infected
Checking ‘dirname’... not infected
Checking ‘echo’... not infected
Checking ‘egrep’... not infected
Checking ‘env’... not infected
Checking ‘find’... not infected
Checking ‘fingerd’... not found
Checking ‘gpm’... not infected
Checking ‘grep’... not infected
Checking ‘hdparm’... not infected
Checking ‘su’... not infected
Checking ‘ifconfig’... not infected
Checking ‘inetd’...

....

Solo puede darse un problema (de muy facil solución como vamos a ver), y que consiste en que chkrootkit, al ser un
shell script, se basa en las siguientes herramientas:
awk, cut, echo, egrep, find, head, id, ls, netstat, ps, strings, sed, uname.
que puede contener algun troyano, la solución nos la da el propio programa, por medio de un simple parametro, le
indicaremos donde debe de buscar y ejecutar esos programas que necesita:
Si los tenemos un CD-ROM:

./chkrootkit -p /cdrom/bin

En caso de tener los binarios originales de la distribución en un diskette:

./chkrootkit -p /floppy

En el caso que solo nos interese verificar alg