Re: Traducción del manual de seguridad al español: nota a traductores
after-compromise.sgml
--
Manuel Parrilla Sánchez
<!-- CVS revision of original english document "1.14" -->
<chapt id="after-compromise">Tras el compromiso (respuesta ante un incidente)
<sect>Comportamiento general
<p>Si está físicamente presente cuando ocurre un ataque, su primera respuesta
debería ser quitar la máquina de la red, desconectando el cable de la tarjeta de
red (si esto no tiene efectos negativos sobre lo que esté
realizando). Deshabilitar la red en la capa 1 es la forma más segura de mantener
al atacante fuera del ordenador comprometido (consejo de experto de Phillip
Hofmeister).
<p>Sin embargo, algunas herramientas utilizadas para comprometer sistemas
(N. del T., «rootkits»), troyanos e incluso un usuario deshonesto conectado por
una puerta trasera, podrían ser capaces de detectar este evento y reaccionar
ante él. Ver una ejecución de <tt>rm -rf /</tt> cuando desconecte la red del
sistema no es realmente muy divertido. Si no está dispuesto a correr el riesgo,
y está seguro de que el sistema está comprometido, debería <em>desconectar el
cable de corriente eléctrica</em> (todos ellos si hay más de uno) y cruzar los
dedos. Esto puede ser excesivo pero, en realidad, evitará cualquier bomba lógica
que un intruso pudiera haber programado. En este caso, el sistema comprometido
<em>no debería reiniciarse</em>. Los discos duros deberían llevarse a otro
sistema para analizarlos, o debería usted utilizar otro medio (un CD-ROM) para
arrancar el sistema y analizarlo. <em>No</em> debería utilizar los discos de
rescate de Debian para arrancar el sistema, pero <em>puede</em> utilizar el
intérprete de órdenes proporcionado por los discos de instalación (recuerde,
Alt+F2 le llevará a él) para analizar <footnote>Si usted es aventurero, puede
ingresar en el sistema y guardar información sobre todos los procesos en
ejecución (obtendrá muchos de /proc/nnn/). Es posible obtener de la memoria el
código ejecutable completo, incluso si el atacante ha borrado del disco los
archivos ejecutables. Luego tire del cordón de la corriente. </footnote> el
sistema.
<p>El método más recomendable para recuperar un sistema comprometido es utilizar
un sistema de archivos autónomo (N. del T., «live-filesystem») en CDROM, con
todas las herramientas (y módulos del núcleo) que podría necesitar para acceder
al sistema comprometido. Puede utilizar el paquete
<package>mkinitrd-cd</package> para construir dicho CDROM<footnote>De hecho,
esta es la herramienta utilizada para construir los CDROMs para el proyecto <url
id="http://www.gibraltar.at/"; name="Gibraltar"> (un cortafuegos en un CDROM
autónomo basado en la distribución Debian).</footnote>. Podría encontrar también
útil aquí el CDROM <url id="http://biatchux.dmzs.com/"; name="FIRE"> (antes
llamado Biatchux), puesto que es un CDROM autónomo con herramientas forenses
útiles en estas situaciones. No hay (todavía) una herramienta como ésta basada
en Debian, ni una forma sencilla de construir el CDROM con nuestra propia
selección de paquetes de Debian y <package>mkinitrd-cd</package> (por tanto
tendrá que leer la documentación suministrada con él para fabricar sus propios
CDROMs).
<p>Si en realidad quiere arreglar rápidamente el compromiso, debería quitar de
la red el ordenador comprometido y reinstalar el sistema operativo desde
cero. Naturalmente, esto puede no ser efectivo porque usted no se enterará de
la forma en la que el intruso obtuvo los privilegios de superusuario en el
primer sitio. Para eso, tiene que comprobarlo todo: cortafuegos, integridad de
archivos, ordenador de registros, archivo de registros, etc. Para más
información sobre qué hacer tras una intrusión, véase <url name="Sans' Incident
Handling Guide" id="http://www.sans.org/y2k/DDoS.htm";> o <url
id="http://www.cert.org/tech_tips/root_compromise.html"; name="CERT's
Steps for Recovering from a UNIX or NT System Compromise">.
<p>En <ref id="vulnerable-system"> están disponibles también algunas preguntas
sobre cómo manejar un sistema Debian GNU/Linux comprometido.
<sect>Realizar copia de seguridad del sistema
<p>Recuerde que si está seguro de que el sistema ha estado comprometido, no
puede fiarse del software instalado ni de ninguna información que este le
devuelva. Las aplicaciones podrían contener un troyano, podrían instalarse
módulos del núcleo, etc.
<p>Lo mejor que puede hacer es una copia de seguridad del sistema de archivos
completo (utilizando <prgn>dd</prgn>) tras arrancar desde un medio seguro. Los
CDROMs de Debian GNU/Linux pueden venir bien para esto, puesto que proporcionan
una shell en consola cuando arranca la instalación (acceda a ella utilizando
Alt+2 y pulsando Enter). Desde esta shell, copie la información que quiera
salvar en otro ordenador, si es posible (quizás a un servidor de archivos de red
por medio de NFS/FTP). Luego puede llevar a cabo cualquier análisis del
compromiso o la reinstalación mientras el sistema afectado está desconectado.
<p>Si está seguro de que el único compromiso es un módulo troyano del núcleo,
puede intentar arrancar la imagen del núcleo desde el CDROM de Debian en modo
<em>rescue</em> (N. del T.: modo rescate). Asegúrese de arrancar en modo
<em>monousuario</em>, de modo que no se ejecute otro proceso troyano después del
núcleo.
<sect>Contactar con su CERT local
<p>El CERT (en inglés: Computer and Emergency Response Team) es una organización
que puede ayudarle a recuperar su sistema comprometido. Hay CERTs por todo el
mundo
<footnote>
La siguiente es una lista de algunos CERTs, puede obtener una lista completa en
<url id="http://www.first.org/about/organization/teams/index.html"; name="FIRST
Member Team information">
(FIRST viene de Forum of Incident Response and Security Teams):
<url id="http://www.auscert.org.au"; name="AusCERT"> (Australia),
<url id="http://www.unam-cert.unam.mx/"; name="UNAM-CERT"> (México)
<url id="http://www.cert.funet.fi"; name="CERT-Funet"> (Finlandia),
<url id="http://www.dfn-cert.de"; name="DFN-CERT"> (Alemania),
<url id="http://cert.uni-stuttgart.de/"; name="RUS-CERT"> (Alemania),
<!--FIXME URL -->
<url id="http://security.dico.unimi.it/"; name="CERT-IT"> (Italia),
<url id="http://www.jpcert.or.jp/"; name="JPCERT/CC"> (Japón),
<url id="http://cert.uninett.no"; name="UNINETT CERT"> (Noruega),
<url id="http://www.cert.hr"; name="HR-CERT"> (Croacia)
<url id="http://www.cert.pl"; name="CERT Polskay"> (Polonia),
<url id="http://www.cert.ru"; name="RU-CERT"> (Rusia),
<url id="http://www.arnes.si/si-cert/"; name="SI-CERT"> (Eslovenia)
<url id="http://www.rediris.es/cert/"; name="IRIS-CERT"> (España),
<url id="http://www.switch.ch/cert/"; name="SWITCH-CERT"> (Suiza),
<url id="http://www.cert.org.tw"; name="TWCERT/CC"> (Taiwán),
y
<url id="http://www.cert.org"; name="CERT/CC"> (EEUU).
</footnote>
y usted debería contactar con su CERT local en caso de un incidente de seguridad
que le lleve a comprometer su sistema. La gente de su CERT local puede ayudarle
a recuperarlo.
<p>Proporcionar información a su CERT local sobre el compromiso (o al centro de
coordinación de CERT), incluso aunque no busque asistencia, puede también ayudar
a otros, puesto que el conjunto de información de los incidentes comunicados se
utiliza para determinar si una vulnerabilidad dada se está utilizando
ampliamente, si hay un nuevo gusano en escena, o cuales son las nuevas
herramientas de ataque que se están empleando. Esta información se encuentra
disponible para la comunidad de Internet en <url
id="http://www.cert.org/current/"; name="actividad de incidentes de seguridad
actuales"> (en inglés), y para publicar <url
id="http://www.cert.org/incident_notes/"; name="notas de incidentes"> (en inglés)
e incluso <url id="http://www.cert.org/advisories/"; name="avisos de seguridad">
(en inglés). Para obtener más información lea sobre cómo (y por qué)
informar sobre un incidente en <url
id="http://www.cert.org/tech_tips/incident_reporting.html"; name="Directrices de
comunicación de incidentes de CERT"> (también en inglés).
<p>También puede utilizar mecanismos menos formales, si necesita ayuda para
recuperarse de un compromiso, o quiere discutir sobre información de
incidentes. Esto incluye la <url id="http://marc.theaimsgroup.com/?l=incidents";
name="lista de correo de incidentes"> y la
<url id="http://marc.theaimsgroup.com/?l=intrusions"; name="lista de correo de
intrusiones"> (ambas en inglés).
<sect>Análisis forense
<p>Si desea obtener más información, el paquete <package>tct</package> («The
Coroner's Toolkit», de Dan Farmer y Wietse Venema) contiene utilidades para
llevar a cabo un análisis <em>post mortem</em> de un
sistema. <package>tct</package> permite al usuario recoger información sobre
archivos borrados, procesos en ejecución, y más cosas. Véase la documentación
incluida para obtener más información. Estas mismas utilidades y algunas otras
pueden encontrarse en <url name="Sleuthkit and Autopsy"
id="http://www.sleuthkit.org/";> de Brian Carrier, que proporcionan una interfaz
web para análisis forense de imágenes de disco. En Debian puede encontrarlo en
los paquetes <package>sleuthkit</package> (las herramientas) y
<package>autopsy</package> (la interfaz gráfica).
<p>Algunas otras herramientas para análisis forense que pueden utilizarse,
proporcionadas en la distribución de Debian, son:
<list>
<item><package>fenris</package>.
<item><package>strace</package>.
<item><package>ltrace</package>.
</list>
<p>Algunos de estos paquetes pueden utilizarse para analizar binarios
deshonestos (como puertas traseras), con objeto de determinar cómo trabajan y
qué le hacen al sistema. Algunas otras herramientas comunes son <prgn>ldd</prgn>
(en <package>libc6</package>), <prgn>strings</prgn> y
<prgn>objdump</prgn> (ambos en <package>binutils</package>).
<p>Si intenta hacer análisis forense con puertas traseras o binarios
sospechosos, recuperados de sistemas comprometidos, debería hacerlo en un
entorno seguro (por ejemplo en una imagen de <package>bochs</package> o
<package>xen</package> o un entorno de <prgn>chroot</prgn> utilizando un usuario
con pocos privilegios). De lo contrario, ¡su sistema puede quedar comprometido
por un troyano!
<p>Recuerde también que los análisis forenses deberían hacerse siempre sobre una
copia de seguridad de los datos, <em>nunca</em> sobre los datos mismos, por si
se alteran los datos durante el análisis y se pierde la evidencia.
<p>Puede encontrar más información sobre análisis forense en el libro de Dan
Farmer y Wietse Venema <url
id="http://www.porcupine.org/forensics/forensic-discovery/"; name="Forensic
Discovery"> (disponible en línea, N. del T.: en inglés), así como en <url
id="http://www.porcupine.org/forensics/column.html"; name="Computer Forensics
Column"> y <url id="http://www.porcupine.org/forensics/column.html";
name="Computer Forensic Analysis Class handouts">. El boletín de noticias de
Brian Carrier <url id="http://www.sleuthkit.org/informer/index.php"; name="The
Sleuth Kit Informer"> es también una fuente muy buena de consejos sobre análisis
forense. Finalmente, los retos de <url
id="http://www.honeynet.org/misc/chall.html"; name="Honeynet Challenges"> son una
excelente forma de perfeccionar sus destrezas en análisis forense al incluir
ataques reales contra sistemas trampa («honeypot») y proporcionar desafíos que van
desde análisis forenses de discos hasta registros de cortafuegos y capturas de
paquetes.
<p>ARRÉGLEME: Esperamos que este párrafo proporcione en un futuro próximo más
información sobre análisis forense en un sistema Debian.
<p>ARRÉGLEME: Hable sobre cómo hacer «debsums» en un sistema estable con los
MD5sums en CD y con el sistema de archivos recuperado, restaurado otra
partición.
<p>ARRÉGLEME: Añada enlaces a artículos sobre análisis forenses (como los
desafíos de Honeynet o los or <url id="http://staff.washington.edu/dittrich/";
name="David Dittrich's papers">).
Reply to: