/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\ \|/ \|/ /|\ /|\ \|/ \|/ /|\ Asegurando nuestro Linux ! /|\ \|/ -------------------------- \|/ /|\ /|\ \|/ por CAOS - Ezkracho Team \|/ /|\ /|\ \|/ \|/ /|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\/|\ \|/ \|/ /|\ mail: caos@ezkracho.com.ar /|\ \|/ \|/ /|\ web: www.ezkracho.com.ar /|\ \|/ \|/ /|\ /|\ \|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/\|/ ----------------------------------------------- Este texto esta escrito dentro de los primeros "127" caracteres del codigo ASCII para evitar posibles errores al visualizarlo; por lo que no se usaran acentos y la "enie" se pondra como ~. ----------------------------------------------- T E M A R I O 0. Introduccion. 1. Consejos a la hora de la instalacion. 2. Archivo de contrase~as. 3. Sistema de archivos y SUID. 4. Deshabilitando y restringiendo servicios. 5. Usando un firewall. 6. Rastreando un intruso. 7. Auditando nuestro sistema. 8. Comentario final. 9. Acerca del autor. 10. Contacto. 11. Agradecimientos y despedida. 0. Introduccion. "Lo unico seguro es la inseguridad", no cabe duda de la veracidad de esta frase; podemos tener el hardware mas caro, el sistema operativo mas seguro y desarrollado, pero si no lo sabemos configurar adecuadamente puede ser tan peligroso como su parte mas debil. Esta guia esta dirigida a todos los que recien comienzan en el mundo de Linux y aparte de tener un sistema operativo estable y potente, quieren que tambien sea seguro. Vamos a ver todas las cosas a tener en cuenta a la hora de asegurar y defender nuestro Linux; hay que tener en cuenta que esta es solo una guia basica ya que es imposible abarcar todos los temas relacionados a la seguridad, pero tengan la certeza que al final de esta quien se atreva a "hackearnos" va a tener mas que un fuerte dolor de cabeza... Espero que disfruten de la lectura de esta guia, y que cualquier duda o critica constructiva me la hagan saber. 1. Consejos a la hora de la instalacion. Cuando comenzamos la instalacion de nuestro Linux ya tenemos que estar seguros que uso le vamos a dar, como ser el de un servidor o como ser el de uso hogare~o; si lo pensamos usar como una estacion de trabajo en nuestras casas sin brindar ningun servicio a ninguna otra PC, obviamente no tendria sentido instalar los paquetes del servidor web. A la hora de la instalacion tenemos que tener bien claro que vamos a instalar segun nuestras necesidades y que no, no nos conviene instalar cosas que no vamos a usar y mucho menos que no sabemos que son; de ultima luego de la instalacion podemos agregar cualquier cosa. Otra cosa a tener en cuenta es la distribucion que vamos a usar, es sabido que hay algunas distribuciones a las que se le suelen encontrar mas fallas de seguridad que a otras, estas generalmente son las orientadas al usuario comun pero en nuestro caso si es de nuestras primeras incursiones en Linux no nos detendremos mucho en esto, y hasta les recomendaria que empiesen con una distribucion como RedHat o Mandrake. Mas alla de la distribucion que hayamos elegido siempre tenemos que instalar las ultimas versiones de estas, porque mas halla de que tendremos la ventaja de tener el ultimo software tambien vamos a saber que cualquier problema de seguridad encontrado anteriormente ya fue patcheado. Por ultimo durante la instalacion en las ultimas distribuciones que he visto se pregunta que nivel de seguridad se desea, bajo - medio - alto y si se hace la instalacion en modo experto nos puede preguntar cosas como, puertas abiertas para todos - bajo - medio - alto - paranoico; siempre tenemos que tener en cuenta nuestras necesidades de seguridad, ya que si nos emocionamos y elegimos el nivel de seguridad paranoico despues en el uso diario del sistema se nos va a hacer un poco molesto tener que estar logueandonos con un pass de minimo 10 caracteres que no sea facil de adivinar, que es lo que nos pide este nivel de seguridad. 2. Archivo de contrase~as. El archivo de contrase~as lo podemos encontrar en /etc/passwd y sin duda este es el archivo que mas puede comprometer nuestro sistema, aqui se guarda no solo el password de todos los usuario sino tambien el del muy ansiado "root". Veamos como es la entrada del root en el archivo /etc/passwd : root:hvnsdcf:0:0:root:/root:/bin/bash Ahora veamos que significa cada uno de los campos que aparecen: root = nombre del usuario (en este caso el administrador) hvnsdcf = password encriptado 0 = numero de grupo de usuario 0 = numero de usuario (recordemos que 0 solo corresponde al root) /root = directorio del usuario /bin/bash = shell que utiliza (en este caso bash) Esta seria una entrada del archivo /etc/passwd claro que solo como ejemplo, ya que hoy dia la mayoria de los sistemas utiliza lo que se llama password shadowing. Lo que sucede cuando una contrase~a esta "shadow" es que en el archivo de passwords no estaria la contrase~a encritada como en el ejemplo, sino que la verdadera contrase~a encritada estaria en otro archivo que generalmente lo podemos encontrar en /etc/shadow pero tambien puede estar en otro directorio. Se usa este sistema porque si alguien llega a obtener el archivo de passwd lo puede desencriptar con un crackeador como ser John the Ripper, en cambio si esta shadow ya para poder crackearlo necesitariamos el archivo passwd y el archivo shadow. Una entrada de un archivo que esta shadow puede ser esta: root:x:0:0:root:/root:/bin/bash donde vemos que ya no aparece la contrase~a encriptada y aparece una "x" que tambien puede ser un "*" segun el sistema. La mayoria de los sistemas aparte de usar el password shadowing, utilizan MD5 que es un potente algoritmo de encriptacion. Si durante la instalacion les preguntan si quieren utilizar MD5 no duden en aceptarlo. No quiero recaer en la insistencia de proponer como muchos textos que elijamos una contrase~a que no sea facil de adivinar y que tenga cierto sentido de complejidad, pero tengan en cuenta que hoy dia hay muy potentes herramientas para crackear passwords. Traten de elejir un password que tenga caracteres en minuscula y mayuscula, numeros y caracters raros como $%&!?.. etc. 3. Sistema de archivos y SUID. Dentro del sistema de archivos de Linux ext2 (extension version 2) todos los archivos tienen permisos y su respectivo due~o, veamos por ejemplo el siguiente listado: [root@caos textos]# ls -l -rw-r--r-- 1 caos caos 7415 Dec 26 01:36 Historia-EkoTm.txt -rw-r--r-- 1 caos caos 7107 Jan 26 17:28 argenhack.zip -rw-r--r-- 1 caos caos 1428 Aug 16 1999 blackboxie.txt -rw-r--r-- 1 caos caos 2079 Dec 1 18:39 bohelp.zip -rw-r--r-- 1 root root 9267 Mar 17 10:00 buscar-ip.txt -rw-rw-rw- 1 root root 114992 Oct 8 00:31 caos-mrh.txt drwxr-xr-x 2 caos caos 4096 Mar 28 17:33 colaboraciones/ -rw-r--r-- 1 caos caos 4268 Dec 1 18:39 crack-nt.zip -rw-r--r-- 1 caos caos 4916 Dec 1 18:39 crackwinzip.zip -rw-r--r-- 1 caos caos 4460 Jan 24 17:17 crimenperfecto.zip -rw-r--r-- 1 caos caos 2493 Dec 12 16:16 empaquetado.zip -rw-r--r-- 1 caos caos 14739 Jan 12 17:47 encript.zip -rw-r--r-- 1 root root 19521 Jan 13 19:07 encript2.txt -rw-r--r-- 1 caos caos 6018 Dec 16 19:35 filtradoicmp.txt -rw-r--r-- 1 caos caos 6805 Dec 14 18:23 floodeterno.txt -rw-r--r-- 1 caos caos 2591 Aug 21 1999 guia-hack-1.txt -rw-r--r-- 1 caos caos 3132 Aug 21 1999 puertos.txt -rw-r--r-- 1 caos caos 23323 Feb 7 07:45 scanning.txt -rw-r--r-- 1 caos caos 13108 Dec 27 20:52 spoof-facil.txt -rw-r--r-- 1 root root 6184 Dec 1 18:11 spoof.txt En este listado vemos que el usuario "caos" que pertenece al grupo "caos" (la segunda columna es el grupo) es el due~o de la mayoria de los archivos; a su vez hay algunos archivos que solo pertenecen al root, pero pueden ser leidos por otros usuarios. Aparte de ver el tama~o, fecha y hora de creaci~n en la primer columna nos aparecen los permisos de los archivos. Los permisos de los archivos estan divididos en 3 campos: due~o, grupo y otros, analisemos el siguiente ejemplo: -rwxr--r-- 1 root root 6184 Dec 1 18:11 spoof.sh r = lectura w = escritura x = ejecucion Aqui vemos que el archivo "spoof.txt" tiene permisos de lectura, escritura y ejecucion para el due~o (que es el root), permisos de lectura para el grupo y permisos de lectura para otros, que seria el resto de los usuarios. Para cambiar los permisos de un archivo usamos el comando "chmod", se puede usar las letras "rwx" para hacer los cambios pero nos conviene acostumbrarnos a usar el valor en numeros: r = 4 --> lectura w = 2 --> escritura x = 1 --> ejecucion -rwxr--r-- 1 root root 6184 Dec 1 18:11 spoof.sh Lo que hacemos es sumar el valor de los diferentes permisos que tiene en cada campo, osea que si en el campo del due~o tenemos permisos de lectura, escritura y ejecucion la suma de estos permisos seria 7; y el valor de los permisos de todo el archivo seria 744 ya que grupo y otros solo tiene permisos de lectura. Por ejemplo si queremos que el archivo tenga solo permisos de lectura, escritura y ejecucion para el due~o tendriamos que hacer esto: [root@caos textos]# chmod 700 spoof.sh y nos quedaria lo siguiente: -rwx------ 1 root root 6184 Dec 1 18:11 spoof.sh Ahora pensemos que queremos cambiar este archivo de due~o, que deje de pertenecer al root y que pertenezca al usuario caos, para esto utilizamos el comando "chown". Lo que hacemos es especificarle cual es el nuevo due~o y cual es el nuevo grupo, veamos el ejemplo: [root@caos textos]# chown caos:caos spoof.sh y nos quedaria lo siguiente: -rwx------ 1 caos caos 6184 Dec 1 18:11 spoof.sh Bueno, dentro del sistema de archivos de Linux estan los que se llaman archivos SUID que solo pertenecen al root. Estos archivos los podemos encontrar con el comando find y nos conviene guardarlos en un archivo de texto la primera vez que instalamos Linux, para estar seguros que despues no aparezcan archivos SUID misteriosamente... [root@caos textos]# find / -perm +4000 >> suid.txt Lo que nos conviene es examinar esta lista y cambiarles el permiso para que solo puedan ser usados por el root (osea chmod 700), y dejar los que creamos estrictamente necesarios para el uso del resto de los usuarios, por ejemplo podriamos dejar: passwd, ping, su, etc. depende de cada administrador que archivos dejar. 4. Deshabilitando y restringiendo servicios. Lo primero que van a hacer en el supuesto de cualquier ataque es un escaneo de puertos para ver que se puede explotar; por lo que es muy recomendable cerrar todos los puertos de los servicios que no utilisemos. Al instalar Linux, y mas si instalamos todos los paquetes o cosas que no sabemos que son, vamos a tener muchos puertos abiertos; antes de intentar conectarnos a Internet o a cualquier red tenemos que hacernos un escaneo de puertos para ver que cosas estan de mas. Por ejemplo no tiene sentido tener abierto el puerto 21 de FTP si sabemos que no vamos a dar servicio de FTP a nadie, o el puerto 80 si no vamos funcionar como un servidor web. Podemos bajar el NMAP que es un excelente escaneador de puertos de http://www.insecure.org/nmap/ y una vez instalado escanearnos a nosotros mismos de la siguiente forma: [root@caos nmap]# nmap localhost Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) Interesting ports on localhost.localdomain (127.0.0.1): Port State Protocol Service 21 open tcp ftp 23 open tcp telnet 6000 open tcp X11 Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds Como vemos aqui solo tenemos abierto el puerto 21 correspondiente al FTP, el 23 correspondiente al Telnet y el 6000 que aparece cuando estamos usando el X-Window. Para alguien que solo usa Linux como un workstation, con tener solo estos puertos abiertos nos alcanza. Pero suponiendo que queremos cerrar todos los puertos o algunos en particular tenemos que editar el archivo /etc/inetd.conf (esto seria en RedHat); en este archivo hay una lista de la mayoria de los puertos y para cerrar los que estan abiertos solo tenemos que comentarlos poniendo un "#" adelante, veamos como seria parte de este archivo: #time stream tcp nowait root internal #time dgram udp wait root internal # # These are standard services. # ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # # Shell, login, exec, comsat and talk are BSD protocols. # #shell stream tcp nowait root /usr/sbin/tcpd in.rshd #login stream tcp nowait root /usr/sbin/tcpd in.rlogind #exec stream tcp nowait root /usr/sbin/tcpd in.rexecd Como vemos el ftp y el telnet estan sin comentar por lo que estos servicios estan accesibles para todo el mundo suponiendo que estamos conectados a Internet. Para cerrar estos puertos solo los comentamos y grabamos el archivo: #time stream tcp nowait root internal #time dgram udp wait root internal # # These are standard services. # #ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a #telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # # Shell, login, exec, comsat and talk are BSD protocols. # #shell stream tcp nowait root /usr/sbin/tcpd in.rshd #login stream tcp nowait root /usr/sbin/tcpd in.rlogind #exec stream tcp nowait root /usr/sbin/tcpd in.rexecd Pero supongamos que necesitamos los servicios de ftp y telnet para una red local por lo que no podemos desabilitarlos, y tampoco queremos que se acceda a estos servicios desde Internet mas alla de que se necesite un user y pass, entonces lo que podemos hacer es filtrar desde que lugar esta permitida la conexion. Para hacer esto tenemos dos archivos /etc/hosts.allow y /etc/hosts.deny, en uno ponemos desde donde esta permitido conectarse y en el otro desde donde no. La regla de verificacion es primero chequear en hosts.allow si hay alguna regla que te permita la entrada, si no encuentra ninguna va a buscar en hosts.deny si hay alguna regla que te deniegue la entrada, y si tampoco encuentra ninguna por defecto nos va a dejar entrar. Si son tan paranoicos como yo van a poner en hosts.deny la siguiente regla que deniega el acceso a cualquier servicio desde cualquier lugar, salvo que indiquemos especificamente lo contrario en hosts.allow, la regla seria asi: ALL: 0.0.0.0/0.0.0.0 Ahora si no queremos denegar la entrada a todos los servicios, sino a algunos especificos como ser el telnet, la regla seria asi: in.telnetd: 0.0.0.0/0.0.0.0 Bueno, ahora veamos como habilitamos la entrada a los servicios pero unicamente desde la red local, recordemos que en hosts.deny tenemos que haber denegado el acceso a todos para aclarar desde donde si esta permitido, las reglas en hosts.allow serian asi: in.telnetd: 192.168.0.0/255.255.255.0 Aqui estamos permitiendo el acceso al telnet pero solo desde nuestra red interna 192.168.0.*, ya que en hosts.deny denegamos el aceso a todos los servicios desde cualquier lugar . Y ahora veamos como habilitamos solo el servicio de ftp para el resto del mundo, lo hacemos asi: in.ftpd: 0.0.0.0/0.0.0.0 O el servicio de POP3: ipop3d: 0.0.0.0/0.0.0.0 Para aprender mas sobre las reglas simplemente tipeen en la consola: man hosts.deny o man hosts.allow. Por ultimo, otra cosa a tener en cuenta es que algunos servicios como ser el sendmail no lo podemos deshabilitar simplemente comentando el puerto en el archivo inetd.conf, para hacerlo ya tenemos que hacerlo con algunos programas que vienen para configurar el sistema o usando otros metodos, pero eso se los dejo para que lo investiguen ustedes :P 5. Usando un firewall. Vamos a usar un firewall por dos motivos, uno en contra de intrusos que deseen ingresar a nuestro sistema, y otro en contra de un supuesto ataque de DoS (Denegacion de Servicio). Por supuesto nos vamos a referir al IP Chains que viene con Linux, que en realidad no es un firewall sino un programa que filtra paquetes con reglas especificas. Veamos el siguiente ejemplo en el que estamos denegando el acceso de todos los paquetes icmp a nuestra maquina desde la IP 127.0.0.1 que somos nosotros mismos: [root@caos /]# ipchains -A input -s 127.0.0.1 -p icmp -j DENY Si despues de hacer esto nos hacemos un PING (ping localhost) veremos que no obtendremos respuesta. Ahora probemos volver a hacernos un PING pero luego de ejecutar la siguiente regla: [root@caos /]# ipchains -D input -s 127.0.0.1 -p icmp -j DENY Ahora vemos que si obtenemos respuesta del PING, esto es porque acabamos de deshabilitar la regla anterior. Veamos paso a paso los diferentes campos de la siguiente regla: # ipchains -A input -s 127.0.0.1 -p icmp -j DENY -A input: -A significa agregar cadena (Add chain) e input es un subfijo que complementa a -A y termina de decir que estamos agregando una regla nueva. Si dejamos la regla tal cual esta y en vez de poner -A ponemos -D (Delete chain) lo que hacemos es borrar la regla que anteriormente pusimos. -s 127.0.0.1: -s es el parametro que indica que la siguiente IP es a la que se le va a asignar una regla, y 127.0.0.1 es obviamente la IP que estamos filtrando. -p icmp: -p es el parametro que indica que protocolo vamos a filtrar, e icmp es el protocolo mismo que elejimos filtrar. Aparte de icmp tambien podemos filtrar el protocolo tcp, udp o all para filtrar los paquetes de cualquier protocolo. Solo debemos poner: -p xxxx (donde xxx puede ser tcp, udp, icmp o all). -j DENY: -j indica que hacer cuando un paquete entrante concuerda con la regla, y DENY lo que dice es que el paquete debe ser desechado. Aparte de DENY tambien tenemos ACCEPT que deja pasar el paquete y REJECT, MASQ, REDIRECT y RETURN que no vienen al caso explicarlos para el objetivo de esta guia. Pero supongamos que nuestra unica necesidad al usar un firewall es la de que ningun lammersillo nos haga un ataque de DoS cuando nos conectamos a Internet; entonces pasandole la siguiente regla al IP Chains ya estariamos a salvo: # ipchains -A input -s 0.0.0.0/0.0.0.0 -p all -j DENY Aqui lo que estamos diciendo es que absolutamente nadie nos puede enviar absolutamente nada, todo lo que nos envien sera rechazado. Obviamente esto es lo mas util cuando estamos bajo un ataque de DoS; pero si esta es nuestra unica necesidad les recomiendo que se bajen el Kfirewall que es un frontend del IP Chains para el X-Window y tiene estas opciones basicas. Ahora si nos encontramos bajo el ataque de una persona pero no queremos filtrar a todo el mundo ya que supongamos que le dimos una shell a un amigo para que se telnetee y haga "algo", entonces lo que hacemos es simplemente especificar la IP del molesto: # ipchains -A input -s 200.20.10.137 -p all -j DENY Pero resulta que esta persona es muy molesta y al descubrir que le filtramos la IP se desconecta y se vuelve a conectar para que su ISP (Proveedor de Servicio de Internet) le asigne otra direccion IP, entonces suponiendo que el ISP le asigna IP's en el rango de 200.20.10.1 a 200.20.10.255 lo que podemos hacer es directamente filtrarle toda la subnet, osea que cualquier IP que le asigne su ISP va a estar filtrado, esto lo hacemos asi: # ipchains -A input -s 200.20.10.0/24 -p all -j DENY Seguramente se preguntaran por que el 24 ? bueno es porque dentro del TCP/IP cada uno de los campos es una transformacion de ocho cifras en binario a una en decimal, osea que si nosotros queremos filtrar cualquiera de los 3 digitos del cuarto campo de la IP 200.20.10.137 lo que hacemos es decirle al IP Chains cuantas cifras debe tener en cuenta y cuantas debe barrer de punta a punta, por lo que 3 x 8 es igual a 24, con lo que estamos filtrando todo el cuarto octeto (de 0 a 255) de la IP y dejando intacto los 3 primeros octetos (200.20.10). Bueno, ahora supongamos que de una misteriosa forma hemos obtenido el "root" de toda la red de computadoras de nuestra universidad, y ahora nosotros somos los administradores de la red ;) Supongamos que en nuestra universidad hay dos laboratorios, uno perteneciente a los que estudian la carrera de sistemas (lab1.universidad.com.ar) y el otro laboratorio perteneciente a los que estudian otras carreras (lab2.universidad.com.ar); como los que no estudian sistemas nos caen muy mal hemos decidido que visitar www.playboy.com nos le hace bien y por lo tanto aplicaremos la siguiente regla: # ipchains -A input -s lab2.universidad.com.ar -d www.playboy.com -p www -j DENY Aqui vemos que todo el laboratorio 2 perteneciente a la gente que no estudia sistemas es el origen que marcamos como "-s lab2.universidad.com.ar", y que "-d www.playboy.com" es el destino por eso el -d, hasta aqui estamos diciendo que todos los pedidos que vengan del laborotorio 2 hacia www.playboy.com estan rechazados, pero tambien vemos que al final le agregamos un "-p www" con esto lo que decimos es como que tambien deniegue cualquier pedido de web hecho a esa direccion. Despues de ver el efecto productivo que tuvo en nuestros compa~eros del laboratorio 2 no entrar a www.playboy.com, pensamos que tambien seria muy conveniente que nadie en toda la universidad tampoco lo pueda hacer, obviamente exceptuandonos a nosotros que estamos en el laboratorio 1, esto lo hacemos con la siguiente regla en la que usamos un operador logico de negacion ! para decir que deniegue todas las direcciones exceptuando a una: # ipchains -A input -s !lab1.universidad.com.ar -d www.playboy.com -p www -j DENY Ya antes habiamos dicho que con -p podiamos especificar un protocolo, pero como vemos en el ejemplo anterior tambien se puede especificar un puerto ya que -p www es lo mismo que -p 80. Ahora veamos como denegar un acceso dentro del protocolo TCP a una IP pero con un rango especifico de puertos: -p TCP -d 200.40.0.41 5000:7000 Aqui vemos que denegamos todo el acceso a 200.40.0.41 dentro del protocolo TCP entre los puertos 5000 al 7000. Y que pasa si queremos filtrar paquetes ICMP que no utiliza puertos.. bueno en ese caso tenemos otros parametros que podemos especificar: -p ICMP -s 200.40.0.41 0 El parametro 0 que vemos al final corresponde a echo-reply que es usado por el ping, tambien tenemos el 3 que es de destination-unreachable, usado por cualquier trafico TCP/UDP que no nos conviene tocar, el 5 que es el redirect si estamos corriendo el demonio de ruteo, etc. Para mas info sobre estos parametros hacer: ipchains -h icmp Dentro de esta seccion de firewalls hemos dejado muchos temas sin revisar, pero seria muy extenso explicarlos a todos y no es el objetivo de este texto; para mas informacion hagan: man ipchains o bajense los howto del ipchains que pueden encontrar cosas interesantes. 6. Rastreando un intruso. La unica forma que existe de rastrear a un intruso y de probar que nuestro sistema fue atacado es mediante los log's del sistema. Un log es un registro de las actividades que un usuario o un programa hacen en nuestro sistema; hay varios programas que se encargan de realizar todo el logging del sistema lo cual se puede configurar desde "/etc/syslog.conf" y generalmente el lugar por defecto donde podemos encontrar los logs es en "/var/log/". Hay algunos programas que manejan sus propios loggins por lo que los guardan en directorios diferentes, pero generalmente los podemos encontrar en "/var/log/nombredelprograma/". Los archivos de log mas clasicos que generalmente vienen definidos por syslog.conf, y a los que mas deberiamos prestarle atencion son: /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler El primero por lo general es el que captura la mayoria de toda la informacion, como ser todos lo que los TCP_WRAPPERS nos devuelven, informacion del firewall, cuando un usuario se loguea, etc. Veamos un ejemplo de este archivo: Apr 3 23:13:04 raxr kernel: Kernel logging (proc) stopped. Apr 3 23:13:04 raxr kernel: Kernel log daemon terminating. Apr 3 23:13:05 raxr syslog: klogd shutdown succeeded Apr 3 23:13:05 raxr exiting on signal 15 Apr 3 23:15:22 raxr syslogd 1.3-3: restart. Apr 3 23:15:22 raxr syslog: syslogd startup succeeded Apr 3 23:15:22 raxr syslog: klogd startup succeeded Apr 3 23:15:22 raxr kernel: klogd 1.3-3, log source = /proc/kmsg started. Apr 3 23:15:22 raxr kernel: Inspecting /boot/System.map-2.2.14-15mdksecure Apr 3 23:15:22 raxr kernel: Loaded from /boot/System.map-2.2.14-15mdksecure. Apr 3 23:15:22 raxr kernel: Symbols match kernel version 2.2.14. El segundo es tambien muy interesante ya que nos va a loguear cosas tales como usuarios cambiando de UID/GID, intentos fallidos cuando se requieren contrase~as, intentos de coneccion sin finalizar, etc. Veamos un fragmento de este archivo: Apr 2 22:31:40 raxr login: ROOT LOGIN ON tty1 Apr 2 22:44:56 raxr login: ROOT LOGIN ON tty2 Apr 3 01:10:51 raxr in.telnetd[2196]: refused connect from 192.168.0.1 Apr 3 02:51:01 raxr in.ftpd[2831]: refused connect from 192.168.0.1 Apr 3 02:52:00 raxr in.ftpd[2856]: refused connect from 127.0.0.1 Apr 3 02:52:35 raxr in.ftpd[2885]: connect from 127.0.0.1 Apr 3 03:00:41 raxr in.ftpd[2954]: connect from 127.0.0.1 Apr 3 03:24:32 raxr in.telnetd[3158]: connect from 192.168.0.1 Apr 3 23:08:51 raxr login: ROOT LOGIN ON tty1 Apr 3 23:15:36 raxr login: ROOT LOGIN ON tty1 Apr 3 23:21:43 raxr login: ROOT LOGIN ON tty2 El tercer archivo maillog guarda generalmente entradas de conexiones pop/imap (nombre de usuario y logout), y el encabezamiento de cada uno de los correos que entran o salen del sistema pero si no tenemos servicios de este tipo no va a loguear nada. Y el cuarto archivo spooler ya no se suele usar y generalmente este en blanco, ya que ya nadie utiliza usenet o uucp, y la mayoria de las personas no va a estar ejecutando un servidor de usenet en su casa. Mas alla de que estos sean los archivos de log's mas representativos es muy saludable revisarlos todos cada tanto, ya que a veces podemos encontrar cosas muy interesantes. Otra cosa a tener en cuenta son los logs que la shell bash nos deja, ya que esta shell suele ser la que viene por defecto en todos los Linux y tiene un gran poder para loguear por ejemplo todos los comandos utilizados por un usuario. Esto es muy util ya que podemos ver que tipo de actividades hace generalmente un usuario, y cuando un dia vemos que en el historial se la paso un dia entero compilando cosas como exploit.c es que algo raro paso .. Veamos un ejemplo del archivo .bash_history que podemos encuentrar en nuestra home: cd xploit ls gcc smurf.c -o smurf ls rm smurf ping caos cd .. rm .bash_history Todas las configuraciones del logueo de la bash lo podemos configurar desde el archivo .bash_profile, por lo que seria conveniente investigar este archivo tambien. Tenemos que tener en cuenta que todos los archivos de log generados por la bash pueden ser modificados o borrados por el usuario, por lo que tenemos que tomar los recaudos necesarios con respecto a esto. Y siempre chequear los log's del sistema ya que esta es la "unica" forma en la que nos enteraremos si un intruso alcanzo nuestro sistema. 7. Auditando nuestro sistema. Las politicas de seguridad a seguir que apliquemos a nuestro sistema estan directamente relacionadas al nivel de paranoia que tengamos. Recuerdo que uno de los miembros de HBO siempre citaba "que sea paranoico no significa que no nos esten persiguiendo"; y esto lamentablemente es muy cierto, nunca creamos que nuestro sistema se encuentra seguro ya que en ese momento dejo de serlo. El lapso de tiempo que dejemos pasar para la proxima vez en que auditemos nuestro sistema depende de cada administrador y las necesidades de seguridad que tengamos, pero nunca dejemos pasar mucho tiempo. Las tareas basicas a la hora de auditar nuestro sistema serian comenzar investigando los log's para ver que no haya nada raro, el history de los usuarios que deja la shell bash, revisar el archivo de password para constatar que no haya aparecido ningun usuario nuevo con UID 0, chequear los archivos SUID y por supuesto nunca esta de mas hacernos un escaneo de puertos para constatar que no se haya abierto algun puerto misteriosamente. Basicamente estos serian las politicas a seguir a la hora de auditar nuestro sistema, que tenemos que intentar sea seguido y si es posible que se nos haga costumbre hacerlas. 8. Comentario final. "La seguridad no es una solucion, es un modo de vida" Nunca creamos que nuestro sistema es seguro, desconfiemos y estemos siempre alerta; les voy a contar una anecdota que les va a ilustrar mejor lo que les digo. Yo particularmente soy bastante paranoico con respecto a la seguridad de mi sistema, y por lo tanto no me gusta que absolutamente nadie toque mi maquina, eso a veces es molesto cuando invito a alguien a trabajar con la computadora. Bueno, estaba con un amigo que no voy a nombrar, creo que estabamos probando un exploit en la red local y en eso llama por telefono una novia que no podia dejar colgada, por lo que inmediatamente bloqueo la consola y me dispongo a entablar una amena charla ;), obviamente mi amigo se puso un poco molesto despues de estar media hora frente al monitor cruzado de brazos, y luego de performar una actuacion de "que no confias en mi ?" lo loguee como root bajo la promesa de que no iba a hacer nada raro para que no se aburra.. Esa noche entro al IRC un rato como lo hago habitualmente y me encuentro con mi "amigo", y despues de un rato veo como entra al canal alguien con el mismo nick que el pero con un "2" al final, inmediatamente me entra la curiosidad de ver quien es y le hago un "who" y veo que esta persona tiene el mismo host que yo, y se lo comento a mi amigo como algo muy raro el cual me responde con un "hace ps -x", sin perder un segundo veo como hay un usuario que yo no cree logueado en mi sistema y que ensima estaba chateando... Este es un ejemplo por el cual no hay que confiar en nadie y nunca hay creer que nuestro sistema esta seguro; para los que quieren saber como termina la anecdota les comento que mi dichoso amigo fue escarmentado bajo un duro ataque de DoS a causa del cual tuvo que desistir de chatear esa noche.., creo que los dos aprendimos una leccion ;) 9. Acerca del autor. Yo soy CAOS y soy el autor de este texto como de muchos otros, mi principal objetivo al realizar este tipo de documentaciones es promover el conocimiento llegando al lector de una forma mas amena, o con un lenguaje mas contemporaneo a los tiempos que corren hoy. Siendo uno de mis objetivos el aprender y compartir lo aprendido, junto con un grupo de amigos que tienen los mismos ideales, decidimos formar un grupo de investigacion y desarrollo al cual llamamos Ezkracho Team. Actualmente junto a los demas miembros de Ezkracho me encuentro trabajando en proyectos en comun como tambien personales; los cuales pueden encontrar en nuestra pagina web. Mis siguientes proyectos como metas personales son tantos que no los podria mencionar a todos, pero siempre me impongo cosas muy ambiciosas que me cuesta creer que las pueda lograr, hasta que lo hago. 10. Contacto. Si queres escribirme por alguna duda o critica constructiva sobre este texto hacelo a las siguientes direcciones de mail: caos@ezkracho.com.ar ezkracho@hotmail.com Para encontrar mas obras realizadas por mi o por mis compa~eros del Ezkracho Team, la URL de nuestra web es esta: www.ezkracho.com.ar Si queres saber todas las novedades de Ezkracho o todos los nuevos textos o programas que hacemos, suscribite a nuestro mailing list enviando un mail a la siguiente direccion: ezkracho-subscribe@onelist.com Muy pronto va a estar on-line el Ezkracho BBS asi que visiten la web o suscribanse al mailing para saber las novedades. 11. Agradecimientos y despedida. Principalmente quiero agradecer a todo el Ezkracho Team cuyo negro sentido del humor me hace preocuparme cada vez mas por la seguridad de mi sistema; pero no me puedo quejar de que no hemos aprendido mucho juntos y de que no se han acordado de mi familia en algun momento ;) Tambien quiero agradecer a toda la gente que dedica su tiempo y esfuerzo para hacer cosas que nos sirven a todos sin esperar nada a cambio. Espero que cada vez seamos mas los que nos dediquemos a difundir el conocimiento por un bien comun. Como ya lo he dicho alguna vez me gusta escribir porque cuando uno le puede explicar algo a otra persona es recien cuando realmente lo comprende. Espero que hayan disfrutado de la lectura de este texto tanto como yo en escribirlo y nos vemos en el proximo! Saludos, %%%%%%%%%%% %%%%%%%%%%% %%%%%%%%%%% %%%%%%%%%% %%%% %%% %%%% %%%% %%%% %%%% %%%%%%%%%%%% %%%% %%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%%%%%%%%%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%% %%%% %%%% %%%% %%%% %%%% %%%% %%%% %%% %%%% %%%% %%%% %%%% %%%%%%%%%%%% %%%%%%%%%%% %%%%%% %%%%%% %%%%%%%%%%% %%%%%%%%%% - = E z k r a c h o T e a m = -