Conoce a tu enemigo: II - Siguiendo los movimientos

Conoce a tu enemigo: II
Siguiendo los movimientos del "blackhat"

Traducción del texto: Know Your Enemy: II, disponible en
Honeynet Project
http://www.honeynet.org/
Última modificación: 18 de junio, 2001

Licencia de la traducción

Se da permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia Libre de Documentación GNU, versión 1.2 o cualquier versión posterior publicada por la Free Software Foundation (Fundación para el Software Libre); este documento no tiene secciones invariantes, textos de portada ni de contraportada. Se incluye una copia de dicha licencia en la sección titulada "Licencia de Documentación Libre GNU".

Este artículo es el segundo de una serie de artículos. En el primer artículo, Conoce a tu enemigo, tratamos las herramientas y metodologías del script kiddie. Específicamente, como comprueban las vulnerabilidades y luego atacan. El tercer artículo cubre lo que los script kiddies hacen una vez han conseguido root. En concreto, como cubren sus huellas y qué hacen después. En este segundo artículo, explicaremos cómo detectar sus movimientos. Como en el ejército, quieres rastrear a los chicos malos y saber qué están haciendo. Explicaremos qué es lo que puedes y no puedes determinar con tus registros de sistema. Puedes ser capaz de determinar si tu sistema está siendo escaneado, para qué ha sido escaneado, qué herramientas fueron utilizadas, y si el ataque tuvo éxito. Los ejemplos proporcionados aquí se centran en Linux, pero se pueden aplicar a cualquier sistema Unix. Recuerda, no hay ningún método que garantice el seguimiento de cada paso del enemigo. Sin embargo, este artículo es un buen sitio para comenzar.

Asegurar tus registros
Este artículo no trata sobre Detección de Intrusiones, hay una gran variedad de excelentes fuentes que cubren los IDS. Si estás interesado en la detección de intrusiones, te recomiendo que compruebes aplicaciones como Network Flight Recorder o snort. Este artículo se centra en la recolección de inteligencia. Concretamente, cómo averiguar lo que está haciendo el enemigo mediante la revisión de tus registros de sistema. Te sorprenderás de la cantidad de información que encontrarás en tus propios ficheros de registro. Sin embargo, antes de que podamos hablar de revisar tus registros, tenemos que discutir cómo protegerlos. Tus registros carecen de valor si no puedes confiar en su integridad. Lo primero que la mayoría de black-hats hacen es alterar los registros del sistema comprometido. Hay una gran variedad de rootkits que eliminan su presencia de los registros (como cloak), o alteran todo el mecanismo de registro (como la versión infectada (trojaned) de los binarios syslogd). Así que el primer paso para poder revisar tus registros consiste en protegerlos.

Esto significa que necesitarás utilizar un servidor de registro remoto. Independientemente de lo seguro que sea tu sistema, no puedes confiar en los registros de un sistema comprometido. Si no hay protección, el black-hat puede hacer un simple "rm -rf /*" en tu sistema, borrando el disco duro. Esto dificulta la recuperación de tus registros. Para protegerse contra esto, puede que quieras registrar el tráfico tanto de forma local como en un servidor de registro remoto. Te recomiendo hacer de tu servidor de registro un servidor dedicado, que la única cosa que debería hacer sería recoger registros de otros sistemas. Si el dinero es un problema, puedes utilizar fácilmente un equipo linux como servidor de registro. Este servidor debería ser altamente seguro, con todos los servicios desactivados, permitiendo sólo el acceso por consola (lee Armoring Linux como ejemplo). También, asegúrate de que el puerto UDP 514 está bloqueado o protegido por cortafuegos en tu conexión a Internet. Esto protege tu servidor de registro de recibir información mala o información de registro no autorizada desde Internet.

Para aquellos que os guste engañar, algo que me gusta hacer es recompilar syslog para que lea un fichero de configuración distinto, como /var/tmp/.conf. De esta forma el black-hat no sabrá cuál es el verdadero fichero de configuración. Esto se hace simplemente cambiando la entrada "/etc/sysregistro.conf" en el código fuente a cualquier fichero que quieras. Entonces instalamos nuestro nuevo archivo de configuración para registrar tanto de forma local como mediante el servidor de registro remoto (ver ejemplo). Asegúrate de que mantienes una copia estándar del archivo de configuración, /etc/syslog.conf, que apunta a todo el sistema de registro local. Aunque este fichero de configuración sea ahora inútil, servirá para evitar que el black-hat se percate de cuál es el verdadero destino de nuestro registro remoto. Otra opción para tus sistemas es usar un método seguro de registro. Una opción consiste en reemplazar tu binario syslogd con algo que realice comprobación de integridad y posea más funciones. Una opción es syslog-nt, que puedes encontrar en http://www.balabit.hu/products/syslog-ng.html.

La mayoría de los registros que utilizaremos son los que almacenaremos en el servidor de registro remoto. Como se menciono antes, podemos fiarnos de la integridad de estos registros al estar en un servidor remoto y asegurado. Además, como todos los sistemas están siendo registrados por un sólo sistema, es mucho más fácil identificar patrones en esos registros. Podemos revisar rápidamente qué está sucediendo en todos los sistemas desde una sola fuente. La única vez en la que podrás querer revisar los registros almacenados localmente en un sistema será para compararlos con la copia que el servidor de registro remoto posee. Puedes determinar si los registros locales han sido alterados comparándolos con los registros remotos.

Comparación de patrones
Examinando tus entradas de registro, normalmente podrás determinar si estás siendo víctima de un escaneo de puertos. La mayoría de los script kiddies escanean una red en busca de una única vulnerabilidad. Si tus registros revelan que la mayoría de tus sistemas están siendo accedidos desde el mismo sistema remoto, desde el mismo puerto, será probablemente un escaneo en busca de una vulnerabilidad en concreto. Básicamente, el enemigo tiene un exploit para un determinado fallo de seguridad, y está escaneando tu red para poder utilizarlo. Cuando encuentren alguna maquina vulnerable, la explotaran. Para la mayoría de sistemas Linux, los TCP Wrappers se instalan por defecto. Así, podremos encontrar la mayoría de estas conexiones en /var/log/secure. Para otros tipos de Unix, podemos registrar todas las conexiones de inetd lanzándolo con el parámetro "-t". Un típico escaneo de exploits podría ser como el de abajo. Aquí tenemos un escaneo en busca de una vulnerabilidad de wu-ftpd.

/var/log/secure
Apr 10 13:43:48 mozart in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:51 bach in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:54 hadyen in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:57 vivaldi in.ftpd[6613]: connect from 192.168.11.200
Apr 10 13:43:58 brahms in.ftpd[6613]: connect from 192.168.11.200

Aquí vemos la maquina 192.168.11.200 escaneando nuestra red. Nótese cómo la fuente escanea de forma secuencial cada IP (esto no siempre es así). Esta es la ventaja de tener un servidor de registro, puedes identificar más fácilmente patrones en tu red ya que todos los registros están combinados. Las repetidas conexiones al puerto 21, ftp, indicaban que estaban buscando probablemente el exploit wu-ftpd. Tan sólo hemos determinado lo que el black-hat busca. A menudo, los escaneos suelen hacerse por etapas. Alguien publica código para una vulnerabilidad de imap, y de pronto ves un rápido crecimiento de escaneos de imap en tus registros. Al siguiente mes serás alcanzado por ftp. Una excelente fuente para ver los exploits actuales es http://www.cert.org/advisories/. A veces, las herramientas escanean varios exploits al mismo tiempo, de forma que puedes ver a una sola maquina conectándose a varios puertos.

Ten en cuenta que si no estás registrando el servicio, no sabrás si te escanean ese servicio. Por ejemplo, la mayoría de las conexiones rpc no son registradas. No obstante, muchos servicios pueden ser añadidos de forma sencilla a /etc/inetd.confpara ser registrados con TCP Wrappers. Por ejemplo, puedes añadir una entrada en /etc/inetd.conf para NetBus. Puedes definir TCP Wrappers que denieguen y registren de forma segura las conexiones (lee Detección de Intrusiones para más información sobre esto).

¿Cuál es la herramienta?
A veces puedes realmente determinar las herramientas utilizadas para escanear tu red. Algunas de las herramientas más básicas buscan un exploit específico, como ftp-scan.c. Si un único puerto en tu red se está poniendo a prueba, probablemente están utilizando herramientas de "misión única". No obstante, existen herramientas que escanean una serie de vulnerabilidades, las dos más populares son sscan, por jsbach y nmap, por Fyodor. Hemos seleccionado estas dos herramientas porque representan las dos "categorías" de herramientas de escaneo. Recomendamos encarecidamente que pruebes estas dos herramientas contra tu propia red, puede que te sorprendan los resultados :).
NOTA: La herramienta sscan está muy anticuada. sscan se menciona sólo como un ejemplo. Para escanear tu propia red en busca de vulnerabilidades, recomendamos la herramienta de código abierto Nessus.

sscan representa la herramienta de escaneo del script kiddie para "todos los propósitos". Escanea una red en busca de un conjunto concreto de vulnerabilidades. Es configurable, permitiéndote añadir nuevos exploits que buscar. Simplemente proporcionas a la herramienta una red y una mascara de red, y hace el resto por ti. Sin embargo, el usuario debe ser root para ejecutarla. Los datos de salida son muy fáciles de interpretar (por eso es tan popular). Da un resumen conciso de muchos servicios vulnerables. Todo lo que tienes que hacer es ejecutar sscan contra una red, hacer un grep para la palabra "VULN" a la salida, y entonces ejecutar el "exploit du jour". A continuación se expone un ejemplo de un sscan ejecutado contra el sistema mozart (172.17.6.30).

otto #./sscan -o 172.17.6.30

--------------------------<[ * report for host mozart *
<[ tcp port: 80 (http) ]>               <[ tcp port: 23 (telnet) ]>
<[ tcp port: 143 (imap) ]>              <[ tcp port: 110 (pop-3) ]>
<[ tcp port: 111 (sunrpc) ]>            <[ tcp port: 79 (finger) ]>
<[ tcp port: 53 (domain) ]>             <[ tcp port: 25 (smtp) ]>
<[ tcp port: 21 (ftp) ]>

--<[ *OS*: mozart: os detected: redhat linux 5.1
mozart: VULN: linux box vulnerable to named overflow.
<[ *CGI*: 172.17.6.30: tried to redirect a /cgi-bin/phf request.
<[ *FINGER*: mozart: root: account exists.
<[ *VULN*: mozart: sendmail will 'expn' accounts for us
<[ *VULN*: mozart: linux bind/iquery remote buffer overflow
<[ *VULN*: mozart: linux mountd remote buffer overflow
---------------------------<[ * scan of mozart completed *

Nmap representa la herramienta de "datos crudos" (raw data). No te dice que vulnerabilidades existen, sino que te dice qué puertos están abiertos, para que determines el impacto de seguridad. Nmap se ha convertido rápidamente en el escáner más popular, y con buenas razones. Toma lo mejor de gran variedad de escáneres y reúna todas las funcionalidades en una sola herramienta, incluyendo detección de SO, varias opciones de ensamblaje de paquetes, escaneo UDP y TCP, aleatoriedad, etc. No obstante, necesitas habilidades en redes para utilizar la herramienta e interpretar los datos. Abajo se muestra un ejemplo de nmap ejecutado contra el mismo sistema.

otto #nmap -sS -O 172.17.6.30 

          Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) 
          Interesting ports on mozart (172.17.6.30): 
          Port    State       Protocol  Service 
          21      open        tcp        ftp 
          23      open        tcp        telnet 
          25      open        tcp        smtp 
          37      open        tcp        time 
          53      open        tcp        domain 
          70      open        tcp        gopher 
          79      open        tcp        finger 
          80      open        tcp        http 
          109     open        tcp        pop-2 
          110     open        tcp        pop-3 
          111     open        tcp        sunrpc 
          143     open        tcp        imap2 
          513     open        tcp        login 
          514     open        tcp        shell 
          635     open        tcp        unknown 
          2049    open        tcp        nfs 

          TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) 
          Remote operating system guess: Linux 2.0.35-36 

          Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds

Revisando tus registros, puedes determinar cuál de estas herramientas fue utilizada contra ti. Para hacer esto, debes comprender como funcionan esas herramientas. Primero, sscan registrará de la forma siguiente (este es un escaneo por defecto sin modificaciones a cualquier fichero de configuración):

/var/log/secure
Apr 14 19:18:56 mozart in.telnetd[11634]: connect from 192.168.11.200
Apr 14 19:18:56 mozart imapd[11635]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.fingerd[11637]: connect from 192.168.11.200
Apr 14 19:18:56 mozart ipop3d[11638]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.telnetd[11639]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.ftpd[11640]: connect from 192.168.11.200
Apr 14 19:19:03 mozart ipop3d[11642]: connect from 192.168.11.200
Apr 14 19:19:03 mozart imapd[11643]: connect from 192.168.11.200
Apr 14 19:19:04 mozart in.fingerd[11646]: connect from 192.168.11.200
Apr 14 19:19:05 mozart in.fingerd[11648]: connect from 192.168.11.200

/var/log/maillog
Apr 14 21:01:58 mozart imapd[11667]: command stream end of file, while reading line user=??? host=[192.168.11.200]
Apr 14 21:01:58 mozart ipop3d[11668]: No such file or directory while reading line user=??? host=[192.168.11.200]
Apr 14 21:02:05 mozart sendmail[11675]: NOQUEUE: [192.168.11.200]: expn root

/var/log/messages
Apr 14 21:03:09 mozart telnetd[11682]: ttloop: peer died: Invalid or incomplete multibyte or wide character
Apr 14 21:03:12 mozart ftpd[11688]: FTP session closed

Sscan también escanea vulnerabilidades de cgi-bin. Estos escaneos no serán registrados por syslogd, los encontrarás en access_log. Decidí incluirlos de todas formas para tu formación :)

/var/log/httpd/access_log 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/phf HTTP/1.0" 302 192 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/Count.cgi HTTP/1.0" 404 170 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/test-cgi HTTP/1.0" 404 169 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/php.cgi HTTP/1.0" 404 168 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/handler HTTP/1.0" 404 168 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webgais HTTP/1.0" 404 168 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/websendmail HTTP/1.0" 404 172 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webdist.cgi HTTP/1.0" 404 172 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/faxsurvey HTTP/1.0" 404 170 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/htmlscript HTTP/1.0" 404 171 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/pfdisplay.cgi HTTP/1.0" 404 174 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/perl.exe HTTP/1.0" 404 169 
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/wwwboard.pl HTTP/1.0" 404 172 
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/ews/ews/architext_query.pl HTTP/1.0" 404 187 
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/jj HTTP/1.0" 404 163

Fíjate cómo se hicieron conexiones completas para todos los puertos (SYN, SYN-ACK, ACK), y luego se cerraron. Esto es porque sscan determina en la capa de aplicación qué puertos están abiertos. sscan no sólo quiere saber si tu puerto de ftp está abierto, sino qué demonio de ftp está ejecutando. Lo mismo se puede decir para imap, pop, etc. Esto puede verse en las trazas de rastreo utilizando sniffit, una herramienta usada comúnmente para rastrear contraseñas.

mozart $ cat 172.17.6.30.21-192.168.11.200.7238
220 mozart.example.net FTP server (Version wu-2.4.2-academ[BETA-17](1) Tue Jun 9 10:43:14 EDT 1998) ready.

Como has visto arriba, se hizo una conexión completa para determinar qué versión de wu-ftpd se estaba ejecutando. Cuando ves las conexiones completas en tus registros, como se muestra arriba, probablemente estas siendo escaneado por una herramienta de exploits. Estas herramientas hacen conexiones completas para determinar que estas ejecutando.

Nmap, como casi todos los escaneadores de puertos, no se preocupa de qué estas ejecutando, sino si estas ejecutando servicios específicos. Por esto, nmap posee un poderoso conjunto de opciones, permitiéndote determinar que tipo de conexión realizar, incluyendo SYN, FIN, Xmas, Null, etc. Para una descripción detallada de estas opciones, visita http://www.insecure.org/nmap/nmap_doc.html. Debido a estas opciones, tus registros pueden variar según de las opciones seleccionadas por el usuario remoto. Una conexión hecha con el indicador -sT es una conexión completa, de forma que los registros serán similares a sscan, no obstante, nmap por defecto escanea más puertos.

Una cosa que debes tener en cuenta es la opción -D (o señuelo). Esta opción de nmap permite al usuario falsear la dirección de origen. Puedes ver escaneos desde 15 fuentes diferentes al mismo tiempo, pero solo una es la verdadera. Es extremadamente difícil determinar cual de las 15 es la fuente real. A menudo, se selecciona la opción -sS para el escaneo de puertos. Esta es una opción más sigilosa, ya que sólo un paquete SYN es enviado. Si el sistema remoto responde, la conexión se cierra inmediatamente con un RST.

/var/log/secure

¡Ooh! ¡Fíjate que aquí no hay nada! Esto es porque los registros de sistema solo registran conexiones completas. Dado que el scanner nmap está utilizando la opción -sS, no establece una conexión TCP completa, por lo que los intentos de escaneo no están siendo registrados. Por eso este método de escaneo se considera sigiloso, los registros de sistema no registran los escaneos. Con los kernels más antiguos de Linux, específicamente 2.0.x, las conexiones TCP incompletas son registradas, pero como conexiones rotas. Los registros de un escaneo -sS son como los siguientes en los kernels más antiguos. (NOTA: Aquí sólo se han incluido las tres primeras entradas).

/var/log/secure
Apr 14 21:25:08 mozart in.rshd[11717]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:08 mozart in.rshd[11717]: connect from unknown
Apr 14 21:25:09 mozart in.timed[11718]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart in.timed[11718]: connect from unknown
Apr 14 21:25:09 mozart imapd[11719]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart imapd[11719]: connect from unknown

Fíjate en todos los errores en las conexiones. Como la secuencia SYN-ACK se cerró antes de completar la conexión, el demonio no puede determinar el sistema de origen. Los registros muestran que has sido escaneado, desafortunadamente no sabes por quién. Este comportamiento solo sucede con los kernels de linux más antiguos que el 2.0.x. Citando a Fyodor "...según todos los mensajes de 'connection reset by peer'. Esta es una singularidad de Linux 2.0.XX -- virtualmente cualquier otro sistema (incluyendo los kernels 2.2 y posteriores) no mostrara nada. Este bug (devolviendo accept() antes de completar el acuerdo de 3-vías) ha sido corregido."

Nmap incluye otras opciones de sigilo, como -sF, -sX, -sN, donde varios indicadores son utilizados. Este es el aspecto de los registros en este tipo de escaneos:

/var/log/secure

¡De nuevo, fíjate en algo aquí, no hay registros! Da miedo, ¿eh? Acabas de ser escaneado y ni siquiera lo sabes. Estos tres tipos de escaneos determinaron los mismos resultados sin ser registrados, como con la opción -sS. Para detectar estos escaneos sigilosos, necesitaras utilizar diferentes herramientas de registro diferentes como tcplogd o ippl. La mayoría de los cortafuegos también detectaran y registrarán todos estos escaneos, como IPFilter, SunScreen, o FireWall-1.

¿Obtuvieron acceso?
Una vez que has determinado que has sido escaneado, y qué estabas buscando, la siguiente gran pregunta es "¿Entraron?". La mayoría de los exploits remotos de hoy en día están basados en desbordamientos de búfer (conocidos también como romper la pila (stack smashing)). En líneas generales, un desbordamiento de búfer se produce cuando un programa (normalmente un demonio) recibe más datos de entrada de que espera, por lo que se sobrescriben zonas criticas en la memoria. Cierto código se ejecuta entonces, normalmente dando al usuario acceso de root. Para más información sobre desbordamientos de búfer, lee el excelente artículo de Aleph1 titulado Smashing the Stack for Fun and Profit.

Normalmente puedes identificar ataques de desbordamiento de búfer en el fichero de registro /var/log/messages (o /var/adm/messages para otros tipos de Unix) para ataques como el de mountd. También verás registros similares en maillog para dichos ataques contra imapd. Un ataque de desbordamiento de búfer tendría este aspecto:

Apr 14 04:20:51 mozart mountd[6688]: Unauthorized access by NFS client 192.168.11.200.
Apr 14 04:20:51 mozart syslogd: Cannot glue message parts together
Apr 14 04:20:51 mozart mountd[6688]: Blocked attempt of 192.168.11.200 to mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P3Û3À°^[Í~@3Ò3À~KÚ°^FÍ~@þÂuô1À°^BÍ~@~EÀubëb^V¬<ýt^FþÀt^Këõ°0þÈ~HFÿëì^°^B~
I^FþÈ~IF^D°^F~IF^H°f1ÛþÃ~IñÍ~@~I^F°^Bf~IF^L°*f~IF^N~MF^L~IF^D1À~IF^P°^P~IF^H°
fþÃÍ~@°^A~IF^D°f³^DÍ~@ë^DëLëR1À~IF^D~IF^H°fþÃÍ~@~HÃ°?1ÉÍ~@°?þÁÍ~@°?þÁÍ~@¸.bin@~
I^F¸.sh!@~IF^D1À~HF^G~Iv^H~IF^L°^K~Ió~MN^H~MV^LÍ~@1À°^A1ÛÍ~@èEÿÿÿÿýÿPrivet
ADMcrew~P(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(Apr 14 04:20:51
mozart ^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^
E^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^ H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H(-^E

Cuando veas algo así en tus registros, alguien ha intentado explotar tu sistema. Es difícil saber si el exploit tuvo éxito. Una forma de hacerlo es siguiendo el intento del exploit, ver si hay alguna conexión desde una fuente remota a tu sistema. Si hay un inicio de sesión con éxito de desde el sistema remoto, tienen acceso. Otra pista es que encuentres cuentas de usuario como "moof", "rewt", "crak0", o "w0rm" añadidas a tu fichero /etc/passwd. Estas cuentas, con uid (Identificador de Usuario) 0, son añadidas por alguno de los exploits más comunes. Una vez que un black-hat obtiene acceso, normalmente lo primero que hace es limpiar tus registros e infectar tu mecanismo de registro (syslogd), para más información lee Conoce a tu enemigo: III. A partir de aquí, no recibirás ningún registro de tu sistema ya que ha sido completamente comprometido. Qué debes hacer a continuación es tema para otro artículo :). Hasta entonces, te recomiendo leer http://www.cert.org/nav/recovering.html.

Para ayudar a encontrar anomalías en archivos de registro, puedes usar un shell script para escanear registros en busca firmas específicas. Para información más detallada de como usar grep y sort en ficheros de registro, visita este mensaje de Marcus Ranum.

Korn shell script

Conclusión
Tus registros de sistema pueden proporcionarte importante información sobre el enemigo. No obstante, el primer paso es garantizar la integridad de tus ficheros de registro. Una de las mejores formas de hacer esto es utilizando un servidor de registro remoto que reciba y almacene los registros de todos tus sistemas. Una vez asegurado, puedes identificar patrones en tus ficheros de registro. Basándote en estos patrones y entradas de registro, puedes determinar qué es lo que el black-hat busca, y potencialmente qué herramientas están usando. Según en este conocimiento, puedes asegurar y proteger mejor tus sistemas.