Un servidor ha sido atacado, ¿y ahora qué?
Responder a un incidente es seguir unos pasos fijos cuando alguien ha entrado en un sistema sin permiso. Primero se frena el daño, después se investiga y al final se cuenta lo ocurrido.
Hoy aprenderás a ordenar los hechos en una línea de tiempo y a escribir un informe que otra persona entienda.
Al terminar esta lección
Nota
Puedo ordenar los hechos de un ataque en una línea de tiempo.
La regla de este laboratorio
Importante
Trabaja solo con tu copia del laboratorio y solo con permiso. Los datos del caso son texto y no hay nada que ejecutar. Aprendes a investigar para poder defender un sistema de verdad.
Palabras clave
| Palabra | Qué significa | Ejemplo |
|---|---|---|
| Incidente | un hecho que daña o pone en riesgo la seguridad de un sistema | |
| Contener | frenar el daño para que no siga creciendo | |
| Evidencia | los datos que prueban lo que ocurrió | un registro |
| Línea de tiempo | los hechos ordenados por la hora en que ocurrieron | |
| Persistencia | lo que deja un intruso para volver a entrar | |
| Informe | un texto que cuenta qué pasó, cuándo y qué hacer |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.
Los cinco pasos de una respuesta a incidentes
Primero se detecta que algo va mal. Después se contiene el daño, por ejemplo cortando la cuenta atacada. Luego se investiga qué pasó y cómo entraron.
Con eso se recupera el sistema, y al final se escribe el informe para que no se repita.
Antes de empezar
Nota
Pulsa Iniciar el laboratorio y espera a que la máquina diga que está en marcha. Cada botón Ejecutar escribe su comando en el terminal. Estos Runs solo leen y no cambian nada.
Ve a tu carpeta personal
cd ~Se muestra aquí y no se ejecuta. Crea una cuenta gratuita para pulsar Ejecutar y escribirlo en el terminal de tu propio laboratorio.
Mira qué registros hay en el caso
ls case/var/logSe muestra aquí y no se ejecuta. Crea una cuenta gratuita para pulsar Ejecutar y escribirlo en el terminal de tu propio laboratorio.
Cuenta las líneas del archivo de fechas
wc -l case/mtimes.txtSe muestra aquí y no se ejecuta. Crea una cuenta gratuita para pulsar Ejecutar y escribirlo en el terminal de tu propio laboratorio.
Mira las tres primeras líneas de ese archivo
head -n 3 case/mtimes.txtSe muestra aquí y no se ejecuta. Crea una cuenta gratuita para pulsar Ejecutar y escribirlo en el terminal de tu propio laboratorio.
Cada archivo cuenta una parte de la historia
El primer Run enseña auth.log, quién entró por SSH, y la carpeta nginx, quién pidió páginas. El segundo escribe 21 case/mtimes.txt: una cabecera y veinte archivos.
El tercero enseña la cabecera, date time owner path, y dos cambios del 11 de agosto. Cada línea dice cuándo cambió un archivo y quién lo cambió.
Qué cuenta cada fuente de evidencia
| Fuente | Qué cuenta | Un dato que da |
|---|---|---|
| Registro de acceso (auth.log) | Quién intentó entrar y quién lo logró | La hora de un inicio de sesión |
| Registro de la web | Qué páginas se pidieron | La dirección de quien las pidió |
| Lista de cuentas (passwd) | Qué usuarios existen | Una cuenta nueva |
| Fechas de cambio | Cuándo cambió cada archivo | Un archivo que no debería existir |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.
La línea de tiempo ordena los hechos
Los registros están en archivos distintos y cada uno cuenta una parte. Para entender el ataque, se apuntan los hechos de todos ellos y se ordenan por la hora.
Así se ve qué fue antes y qué fue después. Un cambio que ocurrió antes de que llegara el intruso no puede ser suyo.
Ejemplo inventado de una línea de tiempo
| Hora | Fuente | Hecho |
|---|---|---|
| 09:02 | Registro de acceso | Cinco intentos fallidos desde una dirección nueva |
| 09:03 | Registro de acceso | Un intento correcto desde esa dirección |
| 09:07 | Fechas de cambio | Aparece un archivo nuevo en una carpeta de programas |
| 09:09 | Fechas de cambio | Se programa una tarea que lo ejecuta cada cinco minutos |
Las celdas que rellenan los estudiantes quedan en blanco en esta vista previa.
Cuenta las líneas que crean un usuario
grep -c useradd case/var/log/auth.logSe muestra aquí y no se ejecuta. Crea una cuenta gratuita para pulsar Ejecutar y escribirlo en el terminal de tu propio laboratorio.
No todo cambio raro es del atacante
El Run da 2: una persona con permisos creó una cuenta nueva y el sistema lo anotó dos veces. Eso es trabajo normal de una administradora.
Por eso se pregunta siempre quién hizo el cambio y a qué hora. La hora te dice si pudo ser del intruso.
Un error frecuente
Advertencia
Mucha gente cree que basta con borrar el archivo malo para acabar con el ataque. Un intruso suele dejar algo para volver, la persistencia. Hay que buscar cómo entró y qué dejó, o volverá.
Un buen informe separa hechos y suposiciones
Un informe responde a cuatro preguntas: qué pasó, cuándo, cómo y qué hay que hacer. Cada afirmación dice de qué evidencia sale.
Lo que se sabe va en el informe como hecho. Lo que se sospecha se escribe como suposición, y se dice cómo comprobarla.
Para ir más lejos: la investigación del laboratorio
En el laboratorio tendrás que hallar cuatro datos. Son la dirección del ataque, la cuenta, la hora de la primera entrada y lo que dejó el intruso. Los apuntas en answers.txt.
Antes de empezar, escribe qué fuente miraría primero para cada pregunta y por qué. Trabaja siempre sobre una copia de case, y deja las originales como están.