  -=( 7A69#13 )=--=( art9 )=--=( Conoce tu enemigo II;      )=--=( Tahum )=-
                               ( Siguiendo los  movimientos )
			       ( del blackhat.              )
			       
	
 [ Documento traducido por Tahum@phreaker.net, ponte en contacto a esta
   direccion si encuentras imperfecciones en la traduccion. Gracias. ]



                            Conoce tu enemigo II

                    Siguiendo los movimientos del blackhat



 Honeynet Project
 Http://project.honeynet.org
 Ultima modificacion: 18 de Julio, 2001.


        Este articulo es el segundo de  una serie de articulos.  En el primer
 articulo,  Conoce tu enemigo,  tratamos las  herramientas y metodologias del
 Script Kiddie.  Especificamente,  como comprueban  las vulnerabilidades para
 entonces atacar.  El tercer  articulo cubre  lo que los script kiddies hacen
 una vez han conseguido root.  En concreto,  como cubren sus huellas y lo que
 hacen a continuacion. En este, el segundo articulo, trataremos como detectar
 sus movimientos. Simplemente como en una operacion militar, quieres rastrear
 a los chicos malos y saber que estan haciendo. Trataremos aquello que puedes
 hacer,  y no puedes estipular,  con tus logs de sistema. Puedes ser capaz de
 determinar si tu sistema esta siendo puesto a prueba,  en que se ha puesto a
 prueba,  que herramientas  fueron  usadas,  y  si el ataque tuvo exito.  Los
 ejemplos provistos  aqui se  centran en  Linux,  pero pueden ser aplicados a
 cualquier sabor  de Unix.  Recuerda,  no hay  ningun metodo garantizado para
 seguir el rastro a cada paso del enemigo.  Sin embargo,  este articulo es un
 buen lugar para empezar a hacerse una idea.


 - Asegurando tus logs

        Este articulo no se  centra en la  deteccion de intrusiones,  hay una
 gran variedad de excelentes documentos que cubren el tema de los IDS.  Si te
 interesa la deteccion  de intrusiones,  te recomiendo que eches un vistazo a
 aplicaciones como Network  Flight Recorder o snort.  Este articulo se centra
 en la recolecta inteligente. Especificamente, como darte cuenta de lo que el
 enemigo esta  haciendo  algo revisando  tus logs.  Te sorprenderas de cuanta
 informacion encontraras  en tus  archivos.  Sin embargo,  antes de hablar de
 revision de logs,  hemos de tratar como proteger estos.  Tus logs carecen de
 valor si no  puedes confiar  en su integridad.  Lo primero que la mayoria de
 black-hats hacen es alterar los logs en el sistema que han comprometido. Hay
 una gran  variedad  de rootkis  que limpian su  presencia de los logs  (como
 cloak),  o  alteran  definitivamente  el  modo  de  logueo  (como la version
 troyanizada del binario syslogd). Como consiguiente, lo primero a hacer sera
 proteger tus logs, antes de revisarlos.

        Esto significa que necesitaras es un  servidor  de  remoto de logueo.
 Independientemente de lo seguro que sea tu sistema, no puedes confiar en los
 logs de un sistema comprometido. Si nada lo impide, el black-hat puede hacer
 un simple rm -rf /* en tu sistema,  limpiando el disco duro. Con esto, seria
 algo dificil recuperar los logs.  Para protegerte  de esto,  querras loguear
 toda la  actividad de  todos tus sistemas  y  recolectarla en un servidor de
 logueo remoto.  Recomiendo  hacer  de  tu  servidor  de  logueo  un servidor
 dedicado, por ej. la unica cosa que se debe hacer en ese sistema seria la de
 recoger logs  de  otros  sistemas...  si  el  dinero es  un problema, puedes
 facilmente usar un terminal linux como tu servidor de logueo.  Este servidor
 debe ser altamente seguro,  con  todos los  servicios cerrados,  permitiendo
 solo el acceso por consola  (lee Blindando Linux para un ejemplo).  Tambien,
 asegurate de que el puerto UDP  514 esta cerrado o protegido por firewall en
 tu conexion a Internet,  este  protege  tu  servidor  de logueo  de  recibir
 informacion mala o no autorizada de logueo desde Internet.

        Para aquellos de vosotros que os guste engaar,  algo que me gusta es
 recompilar syslogd leyendo desde un archivo de configuracion distinto,  como
 /var/tmp/.conf.  De este modo  el black-hat  no hara limpieza del archivo de
 log real.   Esto  es   simple  y   puede   hacerse   cambiando   la  entrada
 "/etc/syslog.conf"  en el codigo fuente de cualquier archivo que encuentres.
 Entonces instalamos  nuestra  nuevo archivo de configuracion para loguear de
 forma local y el servidor de log (ver el ejemplo). Asegurate de mantener una
 copia de seguridad del archivo de configuracion,  /etc/syslog.conf,  el cual
 apunta a todo el  logueo local.  Aun  cuando esta  configuracion sea inutil,
 esto hara que  el  black-hat  lance sus  ataques sobre  nuestro  servidor de
 logueo.  Otra opcion para tus  sistemas es  usar un metodo seguro de logueo.
 Ona  opcion  es  reemplazar  tu binario  syslogs  con algo  que compruebe la
 integridad  de ficheros y  demas funciones.  Ona opcion es syslogd,  la cual
 puedes encontrar en http://www.balabit.hu/products/syslog-ng.html. 
        
        La mayoria de los logs que usaremos son  los unicos almacenados en el
 servidor remoto  de logueo.  Como se  menciono anteriormente,  podemos estar
 seguros de forma fiable de la  integridad de estos logs dado que ellos estan
 en un servidor remoto y seguro.  Tambien,  dado que todos los sistemas estan
 siendo  logueados  por  un  unico  sistema,  es mucha mas  facil identificar
 patrones en esos logs.  Podemos rapidamente hacer  una revision de lo que ha
 sucedido a todos los sistemas desde una sola fuente.  La unica vez en la que
 querras revisar los logs  almacenados  localmente  en  un  sistema sera para
 compararlos con la copia que  el servidor  remoto de  logueo posee.  De esta
 forma puedes determinar si los logs locales han sido alterados comparandolos
 con los logs remotos.


 - Comparacion de patrones

        Revisando las entradas de tus logs,  podras normalmente determinar si
 has sufrido algun escaneo de puertos.  La mayoria de Script Kiddies escanean
 una red en busca de una unica vulnerabilidad. Si tus logs muestran una serie
 de conexiones desde una maquina determinada a muchas maquinas de tu red,  en
 el mismo puerto, sera probablemente un escano en busca de una vulnerabilidad
 en concreto.  Basicamente,  el enemigo  tiene un exploit para un determinado
 fallo de seguridad,  y buscan en tu red maquinas con las que usarlo.  Cuando
 encuentren  alguna  maquina  vulnerable,  la explotaran.  Para la mayoria de
 sistemas  Linux,  los  TCP Wrappers  se instalan por defecto.  De este modo,
 encontraremos la mayoria de estas conexiones en /var/log/secure.  Para otros
 tipos de Unix,  podemos loguear todas las conexiones de inetd lanzando inetd
 con el argumento "-t".  Un  tipico escaneo de  exploits se parece a lo que a
 continuacion se muestra. Aqui tenemos una maquina unica que escanea 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

        Aqui vemos que la maquina 192.168.11.200 esta escaneando nuestra red.
 Notese el escaneo de IPs de forma secuencial (esto no es siempre asi).  Esta
 es la ventaja de tener un unico  servidor de logueo,  que puedes identificar
 mas facilmente determinados patrones dado que tus logs estan combinados. Las
 repetidas conexiones al puerto 21,  ftp,  indican  que se estaba buscando un
 wu-ftpd vulnerable. Simplemente hemos determinado lo que el black-hat busca.
 A menudo,  los escaneos se hacen en etapas.  Alguien publica codigo para una
 vulnerabilidad de imap, y de pronto ves un rapido crecimiento de escaneos de
 imap en tus logs.  Al siguiente mes iran en busca  de tu ftp.  Una excelente
 fuente para ver los exploits actuales es http://www.cert.org/advisories/.  A
 veces,  se hace uso  de herramientas que escanean  una variedad de fallos al
 mismo tiempo,  de forma  que puedes  ver que  una sola  maquina se conecta a
 diferentes puertos de tus maquinas.

        Ten en mente que si no estas  logueando el servicio,  no sabras si te
 estan escaneando ese servicio. Por ejemplo, la mayoria de las conexiones rpc
 no son logueadas. Sin embargo, muchos servicios pueden ser aadidos de forma
 sencilla a /etc/inetd.conf para ser logueados con TCP Wrappers. Por ejemplo,
 puedes aadir una entrada en /etc/inetd.conf para NetBus. Puedes definir TCP
 Wrappers  que  denieguen  de  forma  segura  y logueen  las conexiones  (lee
 Detecion de Intrusiones para mas informacion sobre esto).


 - Cual es la herramienta?

        Hay ocasiones en las que  puedes  determinar las herramientas que han
 sido usadas para escanear tu red. Algunas de las herramientas de escaneo mas
 basicas se centran un en determinado fallo, como ftp-scan.c. Si solo se esta
 poniendo a prueba un unico puerto  en tu red,  seran herramientas de  "unica
 mision" seguramente las que se esten usando.  Sin embargo, existen programas
 que prueban una serie de vulnerabilidades,  las dos mas populares son sscan,
 por jsbach y nmap,  por Fyodor.  Hemos elegido estas dos herramientas porque
 representan las dos  "categorias"  de herramientas de escaneo.  Recomendamos
 altamente  que  pruebes  estas  dos  herramientas contra  tu propia red,  te
 sorprenderas de los resultados :).

 NOTA: La herramienta  sscan esta muy desfasada.  sscan se trata solo como un
 ejemplo.  Para   escanear  tu  propia  red  en  busca  de  vulnerabilidades,
 recomendamos la herramienta de codigo abierto Nessus.
        
        sscan  representa  la  herramienta de  escaneo del Script Kiddie para
 todos los propositos.  Esta escanea una red en busca de un conjunto concreto
 de vulnerabilidades. Es configurable, permitiendote aadir nuevos fallos que
 buscar.  Simplemente proporcionas  a la herramienta una red y una mascara de
 red, y esta hace el resto por ti. Sin embargo, el usuario debe ser root para
 ejecutarla.  El resultado que produce la herramienta es extremadamente facil
 de interpretar  (de aqui que sea tan popular).  Te  da un sumario conciso de
 los servicios vulnerables.  Todo lo que  debes hacer es ejecutar ssan contra
 una red,  hacer un grep para la palabra "VULN" en la salida del programa,  y
 entonces ejecutar el  "exploit du jour".  A contunuacion un ejemplo de sscan
 corriendo 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 raw".  No te dice que fallos
 existen,  mas bien,  te dice que puertos estan abiertos,  para determinar el
 impacto en la seguridad de la maquina.  Nmap se ha convertido rapidamente en
 el escaner de facto,  y con una buena razon. Es el mejor de la gran variedad
 de escaners  y  pone  todas  las  funcionalidades  en  una sola herramienta,
 incluyendo deteccion  de  SO,  varias opciones  de  ensamblaje  de paquetes,
 escaneo  UDP  y  TCP,  aleatoriedad,  etc.  Sin  embargo,  necesitas ciertos
 conocimientos de redes para  usar la herramienta e interpretar los datos.  A
 continuacion se  muestra  un ejemplo  de nmap  ejecutandose 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 logs,  puedes  determinar que herramientas se han usado
 contra ti.  Para hacer esto, debes comprender como actuan esas herramientas.
 Primero,  sscan logueara  lo  siguiente  (este es un escaneo por defecto sin
 modificaciones a cualquier archivo de configuracion):

 /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 tambien escanea vulnerabilidades de  cgi-bin.  Estas pruebas no
 seran logueadas  por  syslogd,  encontraras  acceso  a  ellas en access_log.
 Decidi incluirlas de todas formas para tu formacion :)

 /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

        Hay que darse cuenta de  que  se efectuaron conexiones completas para
 todos los  puertos (SYN, SYN-ACK, ACK),  y luego se cierran.  Esto es porque
 sscan determina en la capa de  aplicacion que puertos estan abiertos.  sscan
 no solo busca saber si  tu puerto  de ftp esta abierto,  sino que demonio de
 ftp esta ejecutando. Lo mismo se puede decir para imap, pop, etc. Esto puede
 verse en los  rastreos de un sniffado usando sniffit,  una herramienta usada
 comunmente para sniffar contraseas.
 
 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 mas  arriba,  una conexion  completa ha determinado la
 version de wu-ftpd que estas ejecutando.  Cuando ves conexiones completas en
 tus logs, como se ha mostrado mas arriba, seguramente estas siendo escaneado
 por una herramienta de escaneo de vulnerabilidades. Estas herramientas hacen
 conexiones completas para determinar que estas ejecutando.

        Nmap, como las mayoria de los escaneadores de puertos, no se preocupa
 de que estas ejecutando, sino si estas ejecutando servicios especificos. Por
 eso,  nmap posee  una amplia gama de opciones,  permitiendote determinar que
 tipo de conexion deseas efectuar, incluyendo SYN, FIN, Xmas, Null, etc. Para
 una  descripcion   detallada   de   estas  opciones,   revisa  el  documento
 http://www.insecure.org/nmap/nmap_doc.html.  Dada estas  opciones,  tus logs
 pueden variar dependiendo de las  opciones  que el usuario haya elegido para
 escanear tu red. Una conexion hecha con el flag -sT es una conexion completa
 en toda regla,  de forma que los logs seran  similares a sscan,  sin embargo
 nmap por defecto escanea mas puertos.

 /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

        Una cosa que debes tener  en mente es la opcion -D (o seuelo).  Esta
 opcion de nmap permite al usuario cambiar la direccion IP de origen.  Puedes
 ver escaneos desde 15 fuentes  diferentes al mismo tiempo,  pero solo una es
 la real.  Es extremadamente  dificil  determiar cual de las 15 es la actual.
 A menudo,  se selecciona la  opcion -sS  para el escaneo de  puertos.  Es la
 opcion silenciosa,  ya  que solo un  paquete SYN  es enviado.  Si el sistema
 remoto responda, la conexion se cierra inmediatamente con un RST.

 /var/log/secure

        Dooh!  aqui no hay nada!  Esto es  porque los  logs del  sistema solo
 recuerdan conexiones  completas.  Dado que el scanner nmap al usar la opcion
 -sS no establece  una  conexion completa,  estos  escaneos no son logueados.
 Este es el porque este metodo de escaneao se considera silencioso,  los logs
 del sistema no recuerdan los escaneo. Para los kernels antiguos de Linux, en
 especial los 2.0.x,  las conexiones  TCP incompletas  se loguean,  pero como
 conexiones rotas.  Los logs de un escaneo -sS tienen la siguiente pinta para
 los kernels antiguos. (NOTA: Solo se incluyen 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

        Fijate en todos los errores en las conexiones.  Dado que la secuencia
 SYN-ACK se cerro antes de que se pudiera  completar la conexion,  el demonio
 no pudo determinar el  sistema de origen.  Los logs te muestran que has sido
 escaneado,  desafortunadamente no  sabras  por quienes.  Este comportamiento
 solo sucede con los kernels de linux mas antiguos que el 2.0.x. Decia Fyodor
 "...basados en todos los mensajes de 'connection reset by peer'.  Este es un
 pieza  de  museo,  un   Linux  2.0.XX  --  virtualmente  cada  otro  sistema
 (incluyendo  los  kernels 2.2 y  posteriores) no  mostrara  nada.  Este  bug
 (devolviendo  accept()  antes de  completar  el acuerdo a tres vias) ha sido
 parcheado."
        
        Nmap incluye otras opciones de anonimato, como -sF, -sX, -sN, donde
 varios argumentos son usados, esta es la apariencia que tendran los logs en
 este tipo de escaneos

 /var/log/secure

        De nuevo, no nay nada, no hay logs!  Espeluznante, eh?  sencillamente
 acabas de  ser escaneado  y nunca  lo sabras.  Estos  tres tipos de escaneos
 determinan los mismos resultados sin que sean logueados, similar a la opcion
 -sS. Para detectar estos escaneos silenciosos, necesitaras usar herramientas
 de logueo  diferentes como  tcplogd o  ippl.  La mayoria  de los cortafuegos
 tambien te detectaran y loguearan estos escaneos,  como IPFilter, SunScreen,
 o FireWall-1.


 - Han ganado acceso?

        Una vez has  determinado  que has  sido  escaneado,  y lo que estabas
 buscando,  la siguiente gran cuestion es  "Han entrado?".  La mayoria de los
 exploits remotos estan hoy en dia  estan basados en fallos de desbordamiento
 de buffer (de otra forma conocidos como destrozos de pila).  Simplemente, un
 desbordamiento  de  buffer se  producen cuando  un programa  (normalmente un
 demonio)  recibe mas datos de entrada de  los esperados,  de forma que estos
 sobreescriben zonas criticas en la memoria. Cierto codigo se ejecuta, por lo
 general dando  el  usuario acceso  de root.  Para  mas informacion sobre los
 desbordamientos de pila,  echa un vistazo al excelente articulo de Aleph1 en
 ftp://ftp.technotronic.com/rfc/phrack49-14.txt.

        Normalmente podras identificar ataques de desbordamiento de buffer en
 el archivo de log /var/log/messages  (o /var/adm/messages para otros sabores
 de Unix)  para ataques como  el  de mountd.  Tambien veras logs similares en
 maillog para ataques  contra imapd.  Un ataque  de  desbordamiento de buffer
 dejaria este rastro.

 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~P33^[~@33~Kڰ^F~@u1^B~@~Eubb^V<t^Ft^K0~HF^^B~
 I^F~IF^D^F~IF^Hf1~I~@~I^F^Bf~IF^L*f~IF^N~MF^L~IF^D1~IF^P^P~IF^H
 f~@^A~IF^Df^D~@^DLR1~IF^D~IF^Hf~@~Hð?1~@?~@?~@.bin@~
 I^F.sh!@~IF^D1~HF^G~Iv^H~IF^L^K~I~MN^H~MV^L~@1^A1~@EPrivet
 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 asi en tus  logs,  alguien  ha intentado explotar tu
 sistema.  Es dificil saber si tuvo exito.  Una forma de hacerlo es siguiendo
 la fecha desde la  cual  se intento  explotar tu sistema,  ver si hay alguna
 conexion remota a tu sistema.  Si hay  un inicio  de sesion satisfactorio de
 forma remota,  significa que tienen  acceso.  Otro sintoma es que encuentres
 cuentas de usuario  como  "moof",  "rewt",  "crak0",  o "w0rm" aadidas a tu
 archivo /etc/passwd.  Estas cuentas,  con uid 0,  son aadidas por alguno de
 los mas comunes exploits.  Una vez el black-hat gana acceso,  normalmente lo
 primero que hara es limpiar los logs y troyanizar el logueo (syslogd),  para
 mas informacion lee Conoce Tu Enemigo:  III.  Dado este punto,  no reciviras
 ningun log de tu  sistema en  el que  se  indique  que  tu  sistema  ha sido
 comprometido.  Lo  que a continuacion haras es tema  para otro  articulo :).
 Hasta entonces, te recomiendo ojear http://www.cert.org/nav/recovering.html.

        Para ayudar a encontrar anomalias en archivos de log,  puedes usar un
 shell script  para  escanear  logs  buscando  firmas  especificas.  Para una
 informacion mas detallada de como usar grep y sort con archivos de log, echa
 un  vistazo  a  este  post  de  Marcus  Ranum   (actualmente  disponible  en
 http://www.nfr.net/firewall-wizards/mail-archive/1997/Sep/0098.html).


 - Conclusion 
        
        Tus logs  pueden  contarte  grandes  verdades  sobre el enemigo.  Sin
 embargo,  el primer paso es garantizar la integridad de tus logs. Una de las
 mejores formas de hacer esto es  usando un  servidor de logueo remoto que se
 encargue  de  recivir  y almacenar  los logs de todos tus sistemas.  Una vez
 seguro, puedes identificar patrones en tus logs. Basandote en estos patrones
 y  entradas  de  log,  puedes  determinar  que  busca  el  black-hat,  y que
 herramientas esta usando.  Basado en  este  conocimiento,  puedes asegurar y
 proteger mejor tus sistemas.


*EOF*
