You are on page 1of 2

Preparación 1 Identificación 2 Identificación 2

• Al Investigador forense se le deberá de proporcionar # find / -name "*" -print Tareas automáticas inusuales
acceso físico al sistema sospechoso. # find / -name ".*" -print Busque trabajos inusuales programados por los usuarios
# find / -name "..*" -print mencionados en /etc/cron.allow . Preste especial atención
• Puede ser necesario contar con una copia física del disco • Busque archivos de gran tamaño (en este caso que a los trabajos de cron programado por cuentas con UID 0
duro con propósitos de forensia y de evidencia. superen los 10 MB) (root): # crontab -u root -l
Finalmente, puede ser necesario un acceso físico para # find / -size 10 MB -print Busque cron inusuales que tengan como alcance todo el
desconectar la máquina sospechosa de cualquier red. • Busque procesos que se ejecuten desde o hacia archivos sistema: # cat /etc/crontab y # ls -la /etc/cron.*
que no estén “linkeados”:
# lsof +L1 Entradas inusuales de log
• Se precisa de un buen conocimiento de la actividad usual
Busque eventos sospechosos, incluyendo las siguientes:
de la máquina/servidor en la red. Usted debe de tener un
Busque archivos inusuales en /proc y /tmp. Este último Gran número de errores de autenticación/login local o por
archivo en lugar seguro donde se describa la actividad
directorio es uno de los preferidos por los atacantes para herramientas de acceso remoto (sshd, ftpd, etc)
usual de puertos para poder comparar eficientemente con
almacenar datos o binarios maliciosos. Programas con Llamadas a Procedimiento Remoto (RPC)
el estado actual.
con entradas de log que incluyen gran número de caracteres
Servicios inusuales extraños
• Puede ser de gran ayuda tener un buen conocimiento de
(Sólo Linux) Ejecute chkconfig (si está instalado) para Un gran número de errores en el registro de Apache
los servicios que corren usualmente en la máquina. No
comprobar si todos los servicios están habilitados: - Reinicios (de hardware)
dude en pedir ayuda a un experto en Unix/Linux si lo
# chkconfig - list - Reinicio de aplicaciones (reinicio Software)
considera necesario.. Es una buena idea tener un mapa de
Casi todos los archivos de registro se encuentran en /var/log
los servicios y procesos que se ejecutan en la máquina.
Revise los procesos en ejecución (recuerde que un rootkit en la mayoría distribuciones de Linux. Estas son las
puede cambiar los resultados en todo este documento, principales:
• Tenga una lista actualizada de todos los archivos críticos /var/log/message: mensajes en general y otros relacionados
especialmente aquí!).
(especialmente archivos SUID y GUID) y guárdela en un con el sistema
# ps -aux
lugar seguro fuera de la red o incluso en papel. Con esta /var/log/auth.log: Registros de autenticación
lista, usted puede fácilmente separar los archivos SUID /var/log/kern.log: Registros del kernel
Utilice lsof -p [pid] sobre procesos desconocidos
habituales y detectar los inusuales. /var/log/cron.log: Registros de crond (cron)
Usted debe de reconocer los procesos habituales y ser capaz /var/log/maillog: Registros del servidor de correo
• Tenga un mapa de su actividad de puertos usual así como /var/log/httpd/: Registro de acceso y errores de Apache
de deducir cuáles podrían haber sido añadidos por el
las reglas de tráfico. /var/log/boot.log: Registro de arranque del sistema
atacante.
Preste especial atención a los procesos que se ejecutan bajo /var/log/mysqld.log : Registro del servidor de base de
Identificación 2 el UID 0. datos MySQL
/var/log/secure: Entrada de autenticación
Actividad inusual de red /var/log/utmp o /var/log/wtmp : Registro de login
Cuent as inusuales Trate de detectar sniffers en la red mediante varias formas: Para ver los logs, las herramientas como cat y grep pueden
Busque cualquier entrada sospechosa en /etc/passwd , Busque en los archivos de log del kernel si hay interfaces que ser útiles:
especialmente con UID 0. También vea en /etc/group y hayan entrado en modo promíscuo, algo así como "kernel: cat /var/log/httpd/access.log | grep "GET /
/etc/shadow . device eth0 entered promiscuous mode" signup.jsp"
Busque los archivos huérfanos que podrían haber sido
dejados al borrar una cuenta utilizada en el ataque: Use # ip link para detectar el flag "PROMISC". Prefiera este Entradas inusuales en el log del kernel
# find / \ ( -nouser -o -nogroup \) -print método sobre ifconfig, puesto que ifconfig no funciona en
todos los kernels. • Busque eventos sospechosos en el log del kernel usando:
Archivos inusuales Busque actividad en los puertos: # netstat -nap y # lsof -i # dmesg
• Busque todos los archivos SUID y GUID: para obtener más información sobre los procesos que estén • Liste toda la información importante del kernel y del
# find / -uid 0 \ ( -perm -4000 -o -perm 2000 \) escuchando en los puertos. sistema:
-print Busque entradas MAC inusuales en su LAN: # lsmod
• Busque los nombres de archivos extraños, comenzando # arp -a # lspci
con ".", " .. " o " ". Busque direcciones IP inesperadas en la red. • Busque rootkits conocidos (use rkhunter o similares)
Hashes de archivos •Si es posible, aplique parches, para evitar el mismo tipo de
Verifique que todos los binarios en /bin, /sbin, /usr/bin, intrusión, en caso que el atacante hubiera utilizado una
/usr/sbin o cualquier otro lugar de almacenamiento vulnerabilidad ya arreglada.
correspondan con sus MD5 respectivos. (use AIDE o similar)
Remedio 4
ATENCIÓN: esta operación podría cambiar todas las
marcas de tiempo de los archivos. Esto sólo debe hacerse Temporalmente elimine todos los accesos a las cuentas
después que se hayan llevado a cabo todas las demás implicadas en el incidente, y elimine todos los archivos
investigaciones y que sepa que puede alterar estos datos. maliciosos. IRM #3
En los sistemas con RPM, utilice:
# rpm -Va | sort Detección de Intrusión en Unix/Linux
En algunos Linux, se puede utilizar un script llamado check-
packages .
Recuperación 5 Análisis en vivo sobre un sistema sospechoso
En Solaris: # pkg_chk-vn
No importa lo lejos que el hacker haya penetrado en el Autor IRM: CERT SG / Cedric Pernet
En Debian: debsums ac-
sistema y el conocimiento que usted pueda tener sobre el
Versión IRM: 1.3
compromiso, si el sistema ha sido penetrado, lo mejor es
Contención 3 reinstalar el sistema completamente y aplicar todos los
parches de seguridad.
email: cert.sg@socgen.com
web: http://cert.societegenerale.com
En caso que esta solución no pueda aplicarse, usted deberá: Traducción: Francisco Neira
•Respalde todos los datos importantes de la máquina ■ Cambiar todas las contraseñas del sistema, cuentas, y email: neira.francisco@gmail.com
comprometida, si es posible con una copia física bit a bit hacer que los usuarios lo hagan de manera segura: se deben Twitter: @neirafrancisco
del disco duro entero en un soporte externo. Sin cree usar contraseñas con mayúsculas/minúsculas, caracteres
necesario haga también una copia de la memoria (RAM) especiales, números, y por lo menos 7 caracteres.
del sistema investigado.. ■ Comprobar la integridad de todos los datos almacenados
Si la máquina no se considera crítica para la organización
en el sistema, utilizando hashes MD5. Extracto
■ Restaurar todos los archivos binarios que podrían haber
y se puede desconectar, apague la máquina bruscamente: sido cambiados (ejemplo: /bin/su) Esta “Metodología de Respuesta a Incidentes” (IRM, por sus
desenchufe. Si se trata de una computadora portátil con siglas en inglés) es una hoja resumen dedicada a los
una batería, sólo presione el botón "off" durante unos manejadores de incidentes que investigan un asunto de
segundos hasta que el equipo apague. Repercusiones 6 seguridad específico. Quién debe de usar estas hojas IRM?
• Administradores
Las investigaciones “offline” deben iniciarse Informe • Centro de Operaciones de Seguridad (SOC)
inmediatamente si el paso de identificación no dio ningún Deberá de redactarse un informe de crisis que será • CISOs y sus delegados
resultado pero el sistema es todavía sospechoso de estar distribuído entre todos los actores de la célula de manejo de • CSIRT (equipos de respuesta a incidentes
comprometido. crisis. informáticos)
Recuerde: Si usted afronta un incidente, siga el
Trat e de encont rar evidencias de todas las Deben de describirse los siguientes temas: IRM, tome notas y no pierda el control. Contacte
acciones del hacker: (usando como herramientas Causa inicial de la infección su CSIRT inmediamente si es necesario.
forenses Sleut h Kit / Autopsy por ejemplo) Acciones y líneas de tiempo de cada evento importante
Qué salió bien
•Busque todos los archivos utilizados por el atacante,
incluyendo archivos borrados y vea lo que se ha hecho con
Qué salió mal Pasos del manejo de incidentes
Costo del incidente
ellos o al menos su funcionalidad, para evaluar la Se definen 6 pasos para manejar los incidentes de seguridad:
amenaza. Capitalice • Preparación: Alistarse para manejar el incidente
•Revise todos los archivos accedidos recientemente. Deberán de definirse las acciones para mejorar los procesos • Identificación: Detectar el incidente
•Revise los logs. de manejo de infecciones de gusanos para capitalizar esta • Contención: Limitar el impacto del incidente
•De manera más general, trate de encontrar cómo entró al • Remedio: Remover la amenaza
experiencia.
sistema el atacante. Deben considerarse todas las pistas. • Recuperación: Recobrar a una etapa normal
Si no hay una prueba de la intrusión, no olvide que podría • Repercusiones: Delinear y mejorar el proceso
venir de un “insider”.