Cuando algo sale mal

Módulo 10: Mantener la seguridad · Tiempo de lectura: 11 minutos

Objetivo de aprendizaje: Tras esta lección, sabrá reconocer las señales de un servidor hackeado, dará los primeros pasos sin destruir pruebas ni copias de seguridad, elegirá entre limpiar y reinstalar, y sabrá cuándo debe notificar una brecha de datos.

Conceptos clave: incidente, señales, aislar, snapshot como prueba, registro del incidente, reinstalar, sustituir claves y contraseñas, copia de seguridad limpia, obligación de notificar brechas de datos (72 horas), Agencia Española de Protección de Datos, plan de emergencia

Reconocer un incidente

Una intrusión rara vez se anuncia. Por lo general, usted nota algo "raro". Señales que debe tomarse en serio:

• Carga alta sin motivo: el procesador está continuamente al 100%, por ejemplo por un criptominero. Compruebe con top o htop de qué proceso se trata y con qué usuario se ejecuta.
• Procesos o servicios desconocidos: un programa con un nombre extraño, a menudo en /tmp, /dev/shm o /var/tmp, o un servicio o temporizador de systemd que usted no ha creado.
• Tráfico saliente que no cuadra: su proveedor le avisa de que su servidor envía spam o ataca a otros servidores, o los gráficos de red del panel muestran picos.
• Usuarios o claves nuevos: una línea en ~/.ssh/authorized_keys que no reconoce, un usuario en /etc/passwd con UID 0, una línea nueva en /etc/sudoers.d/.
• Archivos modificados: archivos PHP desconocidos en su sitio web, un crontab modificado.
• Registros que han desaparecido o están vacíos: a los atacantes les gusta borrar sus huellas.

Algunos comandos para echar un vistazo rápido:

anna@web1:~$ top -o %CPU
anna@web1:~$ sudo ss -tunap | grep ESTAB
anna@web1:~$ sudo last -n 20
anna@web1:~$ awk -F: '$3 == 0 {print $1}' /etc/passwd
anna@web1:~$ sudo find /etc/systemd/system /etc/cron* -newer /etc/hostname -type f
anna@web1:~$ for u in /root /home/*; do sudo cat $u/.ssh/authorized_keys 2>/dev/null; done

last muestra quién inició sesión y cuándo, la línea con awk muestra todas las cuentas con UID 0 (solo debería ser root), y la línea con find busca units y archivos cron más recientes que un archivo creado durante la instalación.

Atención: en un servidor realmente hackeado, estos comandos también pueden estar falsificados. Le ayudan a sospechar algo, no a demostrar que todo está limpio.

Los primeros pasos: calma, aislar, documentar

Lo más importante en los primeros minutos es no borrar cosas presa del pánico. Siga este orden.

1. Abra un registro. Anote en papel o en su portátil (no en el servidor) lo que ve, cuándo y lo que hace. Lo necesitará más adelante para encontrar la causa, para una notificación, una denuncia o su seguro. El NCSC neerlandés también lo recomienda.

2. Aísle el servidor. Evite que siga causando daños (spam, ataques, envío de datos) sin apagarlo:

• en el firewall de su proveedor (si lo hay), cierre todo excepto SSH desde su propia dirección; o
• haga lo mismo en el propio servidor, a través de la consola;
• si no hay otra opción: apague el servidor desde el panel. En ese caso, perderá el contenido de la memoria.

3. Cree un snapshot. Un snapshot en el panel guarda el estado tal como está ahora. Es su prueba y su fuente para averiguar más adelante cómo entró el atacante, incluso si después reinstala el servidor.

4. Ponga a salvo sus copias de seguridad. Compruebe que sus copias de seguridad fuera del servidor siguen intactas y asegúrese de que el servidor hackeado ya no tenga acceso a ellas (por ejemplo, revocando la clave de acceso del servidor al almacenamiento de copias). Los atacantes también intentan borrar o cifrar las copias de seguridad.

¿Limpiar o reinstalar?

La respuesta tentadora es: eliminar el archivo sospechoso, detener el criptominero y listo. Pero usted no sabe qué más ha hecho el atacante: una segunda puerta trasera, un programa modificado, una clave adicional, un temporizador que lo restaura todo. Un servidor en el que alguien ha tenido acceso root ya no es de fiar.

Por eso, el consejo de los administradores y también del NCSC neerlandés es: reinstale los sistemas afectados y restaure sus datos desde una copia de seguridad que no esté infectada. En concreto:

1. Una instalación nueva (reinstalar desde el panel, o un servidor nuevo).
2. De inmediato, la base de este curso: actualizaciones, usuario normal con sudo, SSH con claves nuevas, firewall (módulos 2 a 5).
3. Reinstalar sus aplicaciones desde fuentes oficiales, preferiblemente con sus archivos compose o sus notas (lección 10.4).
4. Restaurar los datos (base de datos, archivos subidos) desde una copia de seguridad anterior al incidente. No restaure código ni configuración a ciegas: pueden contener la puerta trasera. Revise también con espíritu crítico los datos restaurados; un atacante puede llevar dentro más tiempo del que usted cree.
5. Cerrar la vulnerabilidad por la que entró el atacante. Si no, volverá a ocurrir. El snapshot del paso 3 le ayuda a investigarlo.

Sustituir todo lo que pueda haberse filtrado

Parta de la base de que todo lo que había en el servidor está en manos del atacante:

• Claves SSH: elimine de todas partes las claves públicas que estaban en el servidor y cree pares de claves nuevos si había claves privadas en el servidor.
• Contraseñas de bases de datos, paneles de administración y usuarios de su aplicación.
• Claves de API y tokens (correo, pagos, almacenamiento en la nube, almacenamiento de copias) de archivos .env y de la configuración: revóquelos en el servicio correspondiente y sustitúyalos.
• Certificados: la clave privada de su certificado estaba en el servidor. Solicite la revocación del certificado y pida uno nuevo (con Let's Encrypt es rápido, lección 7.3).

Notificar: el RGPD y otros

Si en el servidor había datos personales (datos de clientes, cuentas, direcciones de correo), es posible que se trate de una brecha de datos. El RGPD (artículo 33) establece que el responsable del tratamiento debe notificar una brecha de datos a la autoridad de control sin dilación indebida y, a ser posible, en un plazo de 72 horas desde que tenga constancia de ella. En España, esa autoridad es la Agencia Española de Protección de Datos (AEPD). Algunos puntos importantes:

• no es necesario notificar si es improbable que la brecha suponga un riesgo para los afectados; si tiene dudas, notifique;
• si todavía no dispone de toda la información, notifique igualmente en un plazo de 72 horas y complete los datos más adelante;
• a las personas cuyos datos se han filtrado debe informarlas si existe un riesgo alto para ellas;
• toda brecha de datos debe documentarse en un registro propio, aunque no tenga que notificarla.

Si administra el servidor para un cliente, normalmente usted es encargado del tratamiento: en ese caso debe informar al cliente (el responsable del tratamiento) sin dilación indebida, para que este pueda notificar. Esta lección no constituye asesoramiento jurídico; en caso de duda, consulte el sitio web de la AEPD (https://www.aepd.es/). La notificación a la AEPD se realiza a través de su sede electrónica.

Además: comunique a su proveedor el uso indebido que se haya hecho desde su servidor (a menudo ya lo habrá detectado) y, en caso de un ataque grave, presente denuncia ante la Policía Nacional (https://www.policia.es/) o la Guardia Civil (https://www.guardiacivil.es/). Si su organización entra en el ámbito de NIS2, se aplican plazos de notificación propios y más cortos (la transposición española de NIS2 todavía no está en vigor a principios de noviembre de 2026).

Prepararse: el plan de emergencia

Un incidente siempre ocurre en mal momento. Lo que haya organizado de antemano le ahorrará horas:

• Sepa cómo acceder a la consola y al botón de snapshot de su proveedor, y guarde los datos de acceso al panel (con verificación en dos pasos) en algún lugar fuera del servidor.
• Sepa dónde están sus copias de seguridad, cómo restaurarlas y que funcionan (lección 8.2).
• Mantenga una lista de todos los secretos que hay en el servidor, para saber qué debe sustituir.
• Mantenga una lista de contactos: su proveedor, quién más debe estar informado sobre el servidor (cliente, compañero) y los datos de contacto para notificar una brecha de datos.

En la práctica

En la pantalla del VPS de WebOké encontrará la consola, los snapshots, las copias de seguridad y el botón para reinstalar; en otros proveedores se llaman de forma parecida (console o VNC, snapshot, rescue, reinstall). Este curso es de autoayuda: nadie vigila su servidor y nadie resolverá un incidente por usted. Precisamente por eso es tan importante tener un plan de emergencia que pueda ejecutar usted mismo.

Resumen

• Señales: carga inexplicable, procesos, servicios o claves desconocidos, tráfico saliente extraño, archivos y registros modificados o desaparecidos.
• Primeros pasos: llevar un registro, aislar el servidor, crear un snapshot como prueba, poner a salvo las copias de seguridad.
• Un servidor en el que alguien tuvo acceso root no se limpia, se reinstala; los datos se restauran desde una copia limpia y se cierra la vulnerabilidad.
• Sustituya todas las claves, contraseñas, tokens y certificados que había en el servidor.
• ¿Afecta a datos personales? Una brecha de datos se notifica a la AEPD, a ser posible en un plazo de 72 horas, y toda brecha se documenta.

Cuestionario

Ejercicio

Ejercicio O10.3: Su plan de emergencia en una sola página. Redacte para su propio servidor un plan de emergencia que ocupe como máximo una hoja A4: cómo accede al panel, a la consola y a los snapshots; dónde están sus copias de seguridad y cómo las restaura; qué secretos hay en el servidor; a quién debe informar (y si debe notificar en caso de brecha de datos); y qué cinco primeros pasos da si sospecha de una intrusión. Guarde el plan fuera del servidor.

Para saber más

• Sin acceso a su VPS: ¿qué hacer?
• Snapshots y copias de seguridad de su VPS
• Montar una ISO propia o reinstalar su VPS
• NCSC neerlandés, Gehackt, wat nu? (fuente neerlandesa, en neerlandés): https://www.ncsc.nl/incidenten-en-herstellen/gehackt-wat-nu
• Agencia Española de Protección de Datos (AEPD), brechas de datos personales: https://www.aepd.es/