Página principal 
Introducción 

Seguridad Física 

Seguridad Local 

Seguridad del Sistema de Archivos 

Seguridad del Núcleo 

Seguridad de Red 

Seguridad del Root 

Preparación para la Seguridad 

¿Qué hacer en caso de Ruptura? 

Recursos 

¿Qué hacer en caso de Ruptura?

Ahora vamos a ver qué se puede hacer en caso de haber sufrido o estar sufriendo un ataque.

No es una situación agradable, y aunque siempre sería preferible que no hubiera sucedido, conviene tener en mente una serie de normas que nos permitan una actuación rápida y certera que disminuya las consecuencias del incidente. Como norma general hay que conservar la calma. No conviene tomar medidas apresuradas que puedan aumentar el impacto del ataque.

Vamos a distinguir una serie de situaciones posibles y cómo se debe actuar. Una vez visto esto nos queda aplicar el sentido común.

Detección de un ataque activo

Nos ponemos en situación: acabamos de detectar un ataque que está actualmente en curso.

El ataque puede ser de diversa naturaleza. Dejaremos aparte los casos genéricos como detectar alguien manipulando físicamente el ordenador.

Ataque local

Cuando detectamos un ataque local tendremos que verificar la identidad del atacante. No conviene sacar conclusiones precipitadas y culpar a alguien de atacar el sistema cuando sólo puede que sea una negligencia a la hora de seleccionar una clave o abandonar abierta una consola.

Hay que verificar el origen de la conexión, los registros del sistema y los procesos que tiene activos. Tendremos que comprobar si son los habituales y qué es lo que se sale de lo normal. Después nos dirigiremos a esa persona, por teléfono o personalmente, para preguntar qué está haciendo y pedir que cese en la actividad. Si no tiene una conexión activa y no tiene idea de lo que le estamos diciendo, habrá que profundizar en la investigación porque cabe la posibilidad de que alguien haya utilizado esa cuenta de forma ilegítima. Si reconoce el incidente, que le informe de los mecanismos que ha utilizado, las acciones que ha realizado y actúe en consecuencia.

Nunca se precipite para hacer acusaciones. Recopile todas las pruebas que haya detectado en los registros, procesos, modificaciones de información, etc. Sea rápido, pero seguro. Está en juego su sistema y su prestigio.

Ataque en red

Si el ataque se produce a través de la red podemos tener distintas situaciones. En general puede ser conveniente espiar un poco al intruso para obtener más pruebas y después desconectar el interfaz de red si es posible. Si no fuera posible desconectar el interfaz, deberíamos usar algún filtro para las conexiones procedentes de la dirección del atacante. Programas como ipchains (o ipfwadm en su caso) pueden realizar esta labor. Si desconectamos el interfaz o denegamos (no rechazar) los paquetes procedentes de esa dirección el intruso lo podría interpretar como un error de red, más que una detección del ataque. Si no se pudiera limitar el acceso a las direcciones que usa el intruso, intente cerrar la cuenta del usuario. Observe que cerrar una cuenta no es una cosa simple. Tiene que tener en cuenta los ficheros .rhosts, el acceso FTP y otras posibles puertas traseras.

En general no es aconsejable apagar el sistema. Por supuesto, nunca apagarlo en caliente; esto podría hacernos perder la información que tenemos en memoria. En Linux podemos ver la lista de procesos que hay en ejecución y matar aquellos que puedan estar dañando al sistema.

¿Somos el destino del ataque o somos un punto intermedio?

Se puede dar la situación que nuestra máquina no sea el destino final del ataque. Puede que el intruso la haya utilizado como punto intermedio para atacar a otros sistemas e intentar dificultar el seguimiento de las pistas. En este caso, además de limitar las acciones del atacante deberíamos notificarlo al administrador del destino del ataque y conservar todas las pruebas existentes por si se pudieran reclamar judicialmente.

En cualquier caso, si queremos dar validez legal a las pruebas obtenidas, sería conveniente la intervención judicial.

Es habitual que durante los próximos minutos el atacante vuelva a intentar continuar con sus acciones, tal vez usando una cuenta diferente y/o una dirección de red distinta.

El ataque ha concluido

Ha detectado un compromiso que ya ha ocurrido o bien lo ha detectado mientras ocurría y ha echado al atacante fuera de su sistema.

Ahora viene la parte más dura del incidente: tratar de dejar el sistema mejor que estaba antes de que ocurriera.

Tapar el agujero

Determine los medios que usó el atacante para acceder a su sistema. Deberá analizar cuidadosamente los ficheros de registro del sistema. En ellos debería haber una información valiosa para seguir la pista de las actividades del intruso en nuestra máquina. Las causas más habituales son una mala configuración de algún servicio, un programa defectuoso o la negligencia de algún usuario con respecto a su clave de acceso.

Compruebe por los cauces más conocidos, que se pueden consultar en la página sobre recursos de seguridad bajo Linux, la existencia de algún nuevo «exploit» que pueda ser la causa u otros fallos que tenga que corregir.

Si no elimina al atacante, probablemente volverá. No sólo a su máquina, sino a cualquiera otra de la red. Durante sus incursiones ha podido utilizar algún «sniffer», y disponer de información suficiente para tener acceso a otras máquinas locales.

Si sospecha que el atacante ha obtenido copias de los ficheros /etc/passwd, /etc/shadow, /etc/ppp/pap-secrets, /etc/ppp/chap-secrets o cualquier otro fichero que contenga datos de usuarios y claves, sería conveniente modificarlas todas. Si tiene distintos usuarios en su máquína, oblígueles a cambir su clave. En general es preferible cambiar siempre las claves despues de un incidente, una vez que sepamos que lo hacemos de una forma segura.

Verifique si se han modificado las limitaciones al acceso a distintas herramientas de administración remota como linuxconf. Puede que el atacante trate de abrir alguna puerta trasera para continuar aprovechándose de nuestras máquinas.

En algunos casos puede interesar antes de nada, hacer alguna copia de todo el disco duro para seguir investigando el incidente en otra máquina distinta que no esté conectada a la red y no perder una información que puede ser valiosa.

Evaluación de los efectos del ataque

El siguiente paso que hay que realizar es la evaluación de los efectos que ha tenido el ataque. Tiene que tener en mente la naturaleza del ataque para evaluar los efectos. Si ha sido una denegación de servicio es probable que el atacante no haya tenido acceso a la información local. Si tenía instalado algún programa, estilo Tripwire, que verifica la integridad, su trabajo ahora sería más cómodo. En caso contrario tendrá que verificar todos sus datos importantes. Verifique las fechas de creación de los ficheros binarios y si detecta alguna incongruencia con la fecha de instalación puede empezar a sospechar. Si tiene la posibilidad, compare los tamaños de los ficheros con otro sistema «limpio» y por supuesto, no trate de verificar los programas ejecutándolos como root.

Unas buena alternativa es volver a instalar el sistema. Guarde los ficheros de configuración para tener una funcionalidad idéntica a la previa al ataque. En Linux, los ficheros de configuración se almacenan en modo texto por lo que no son susceptibles de contener caballos de Troya. Eso sí, debería verificar que las configuraciones son las originales y no han sido manipuladas por el atacante. Reinstale el sistema y utilice las copias de seguridad para reponer los datos de los usuarios.

Hay que tener especial cuidado con las copias de seguridad. Tiene que estar seguro de que las copias de seguridad que está utilizando son previas a cualquier ataque. No se arriesgue a restaurar unas copias de seguridad que pudieran tener algún caballo de Troya; tenga un cuidado especial con los ficheros binarios que restaura.

Avisar

Si cree que ha sido objeto de un ataque que no está documentado, debería notificarlo a alguna organización de seguridad como CERT o similar para que se pueda solucionar lo antes posible y evitar que otros sistemas lo puedan padecer.

Y aunque sea un hecho documentado con anterioridad, no dude en pedir consulta a alguna de la múltiples lista de correo que tratan temas de seguridad en general y de Linux en particular. En España resulta especialmente recomendada la lista CERT-ES de RedIris.

Si ha conseguido información sobre el atacante, se lo debería notificar al administrador del dominio del intruso. Puede buscar este contacto con whois, con la base de datos del Internic o en RedIris. Podría enviarles un mensaje de correo con todos los registros relacionados con el incidente, fechas y horas. Si conoce alguna otra información sobre su intruso, podría mencionarla también. En ciertas situaciones, tras enviar el correo podría llamar por teléfono al administrador del sistema que originó el incidente. Si el admininistrador localiza a su atacante, podría hacerle las cosas mucho más fáciles.

Los buenos hackers con frecuencia usan sistemas intermedios. Algunos (o muchos) puede que ni sepan que han sido comprometidos. Intentar seguir la pista de un cracker hasta su origen puede ser difícil. Siendo educado con los administradores, le puede facilitar la obtención de la ayuda necesaria.

De todas formas, esperamos que la lectura de este capítulo sea totalmente innecesaria, si ha seguido unas normas adecuadas de seguridad.

 

Copyright © 1997-1999 Gonzalo Álvarez Marañón y Pedro Pablo Fábrega Martínez. Todos los derechos reservados.

Criptonomicón es un servicio ofrecido libremente desde el Instituto de Física Aplicada del CSIC. Para información sobre privacidad, por favor consulte la declaración de política sobre privacidad. Para sugerencias, comentarios o quejas, acuda al libro de visitas. Para contribuir al Criptonomicón, lea la página de contribuciones.