Herramientas de usuario

Herramientas del sitio


tecnica:emergenciasprocedimiento

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anterior Revisión previa
Próxima revisión
Revisión previa
tecnica:emergenciasprocedimiento [2025/11/10 12:08]
fmolinuevo [Puntos Clave para el Sysadmin/Infosec]
tecnica:emergenciasprocedimiento [2025/11/10 12:11] (actual)
fmolinuevo [Otras ideas]
Línea 129: Línea 129:
 ===== Otras ideas ===== ===== Otras ideas =====
  
-  - La mayor parte de los backups funcionaron adecuadamente;​ alguien me comentó que algunos backups estaban también cifrados, pero que se pudo recuperar la mayoría de los datos de otras fuentes 
   - Desconectar la corriente de los switches/​gateways/​routers en vez de cables de red de servidores   - Desconectar la corriente de los switches/​gateways/​routers en vez de cables de red de servidores
   - Realizar un inventario preliminar de los servidores y servicios comprometidos,​ para informar y tomar acciones   - Realizar un inventario preliminar de los servidores y servicios comprometidos,​ para informar y tomar acciones
-  - Crear un equipo de War Room mínimo, con responsables técnicos de alto nivel. Serán los responsables de comunicar a los equipos directivos y de operaciones las tareas y decisiones 
   - Considerar que el acceso a los backups esté restringido,​ ya sea mediante el acceso a un puerto con credenciales,​ o bien en modo sólo lectura si es necesario accederlos mediantes CIFS   - Considerar que el acceso a los backups esté restringido,​ ya sea mediante el acceso a un puerto con credenciales,​ o bien en modo sólo lectura si es necesario accederlos mediantes CIFS
   - Realizar backups remotos, nunca en el propio equipo   - Realizar backups remotos, nunca en el propio equipo
Línea 139: Línea 137:
   - Identificar los servidores afectados por ejemplo con una simple etiqueta "​Infectado",​ tratando de evitar apagarlos para intentar preservar evidencia del ataque que pueda llevar a obtener información forense relevante   - Identificar los servidores afectados por ejemplo con una simple etiqueta "​Infectado",​ tratando de evitar apagarlos para intentar preservar evidencia del ataque que pueda llevar a obtener información forense relevante
   - Documentar el caso lo mejor posible, indicando qué ocurrió y qué se hizo, y mejorarlo poco a poco con el tiempo, con nuevos incidentes o simplemente revisando y registrando nuevas ideas   - Documentar el caso lo mejor posible, indicando qué ocurrió y qué se hizo, y mejorarlo poco a poco con el tiempo, con nuevos incidentes o simplemente revisando y registrando nuevas ideas
-  - En general se recomienda: * evitar pagar, ya que nada asegura que se obtenga la clave de descifrado, se financia a los desarrolladores del ransomware, e incluso si se obtiene la clave, el trabajo para descifrar todos los archivos es una tarea titánica, y además agrega a la empresa al listado de "​dispuestos a pagar" con lo cual se garantiza nuevos intentos de ataque; * evitar tomarse demasiado tiempo para identificar y buscar la cepa del ransomware pues es sumamente raro que exista una clave de descifrado preexistente;​ * tomar capturas e información de los mensajes, para documentar, denunciar, o aportar a investigadores,​ y si es posible del ejecutable o código que se encuentre, teniendo las precauciones del caso; * evitar intentar limpiar un servidor infectado, se debe blanquear los discos, y reinstalar de cero+  - En general se recomienda: 
 +    ​* evitar pagar, ya que nada asegura que se obtenga la clave de descifrado, se financia a los desarrolladores del ransomware, e incluso si se obtiene la clave, el trabajo para descifrar todos los archivos es una tarea titánica, y además agrega a la empresa al listado de "​dispuestos a pagar" con lo cual se garantiza nuevos intentos de ataque; 
 +    ​* evitar tomarse demasiado tiempo para identificar y buscar la cepa del ransomware pues es sumamente raro que exista una clave de descifrado preexistente; ​ 
 +    ​* tomar capturas e información de los mensajes, para documentar, denunciar, o aportar a investigadores,​ y si es posible del ejecutable o código que se encuentre, teniendo las precauciones del caso;  
 +    ​* evitar intentar limpiar un servidor infectado, se debe blanquear los discos, y reinstalar de cero
   - Cambiar la contraseña de todos los administradores antes de comenzar la reinstalación. Considerar la necesidad de forzar cambio de contraseña/​desactivar todos los usuarios si es necesario   - Cambiar la contraseña de todos los administradores antes de comenzar la reinstalación. Considerar la necesidad de forzar cambio de contraseña/​desactivar todos los usuarios si es necesario
-  - En dominios Windows: * asumir que todas las contraseñas del dominio están comprometidas;​ * forzar un reseteo de contraseña para todas las cuentas de usuario; * resetear todas las cuentas de servicio y de administrador;​ * si el domain controller ​quedó operativo, resetear el token KRBTGT dos veces para invalidar todos los tickets Kerberos existentes que los atacantes puedan haber robado+  - En dominios Windows: ​ 
 +    ​* asumir que todas las contraseñas del dominio están comprometidas; ​ 
 +    ​* forzar un reseteo de contraseña para todas las cuentas de usuario; ​ 
 +    ​* resetear todas las cuentas de servicio y de administrador;​ 
 +    ​* si el Domain Controller ​quedó operativo, resetear el token KRBTGT dos veces para invalidar todos los tickets Kerberos existentes que los atacantes puedan haber robado
   - Identificar si es posible, y erradicar, el vector de ingreso   - Identificar si es posible, y erradicar, el vector de ingreso
   - Considerar la posibilidad de que el atacante aún tenga acceso, y tomar todas las precauciones necesarias   - Considerar la posibilidad de que el atacante aún tenga acceso, y tomar todas las precauciones necesarias
Línea 147: Línea 153:
   - Dejar registrada alta/​baja/​modificaciones de usuarios en una KB   - Dejar registrada alta/​baja/​modificaciones de usuarios en una KB
   - Servidores Windows que no necesiten estar en el dominio, dejarlos fuera de él, por ejemplo réplicas de DBs, backups, etc   - Servidores Windows que no necesiten estar en el dominio, dejarlos fuera de él, por ejemplo réplicas de DBs, backups, etc
-  - Los servidores Linux, aunque sean internos sin acceso desde afuera, deberían tener: * root con diferentes contraseñas (evaluar si es suficiente crear una regla mnemotécnica para simplificar las diferencias entre ellas, y si algunos pueden tener contraseñas de root totalmente diferentes);​ * fail2ban configurado y activado+  - Los servidores Linux, aunque sean internos sin acceso desde afuera, deberían tener: ​ 
 +    ​* root con diferentes contraseñas (evaluar si es suficiente crear una regla mnemotécnica para simplificar las diferencias entre ellas, y si algunos pueden tener contraseñas de root totalmente diferentes);​ 
 +    ​* fail2ban configurado y activado
   - El servicio SSH en los servidores Linux debería estar configurado para permitir el acceso exclusivo de los usuarios especificados,​ con la regla AllowUser, lo cual evita que se cree algún usuario de prueba (como he visto en algunos servidores) y ese usuario ya por defecto tenga acceso por SSH   - El servicio SSH en los servidores Linux debería estar configurado para permitir el acceso exclusivo de los usuarios especificados,​ con la regla AllowUser, lo cual evita que se cree algún usuario de prueba (como he visto en algunos servidores) y ese usuario ya por defecto tenga acceso por SSH
   - Identificar servidores críticos (para operación de la empresa, por los datos almacenados,​ o los servicios prestados) y considerar endurecer las políticas de acceso a los mismos   - Identificar servidores críticos (para operación de la empresa, por los datos almacenados,​ o los servicios prestados) y considerar endurecer las políticas de acceso a los mismos
tecnica/emergenciasprocedimiento.1762787307.txt.gz · Última modificación: 2025/11/10 12:08 por fmolinuevo