Herramientas de usuario
tecnica:emergenciasprocedimiento
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anterior Revisión previa | |||
|
tecnica:emergenciasprocedimiento [2025/11/10 12:09] fmolinuevo [Otras ideas] |
tecnica:emergenciasprocedimiento [2025/11/10 12:11] (actual) fmolinuevo [Otras ideas] |
||
|---|---|---|---|
| Línea 137: | 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 145: | 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.1762787366.txt.gz · Última modificación: 2025/11/10 12:09 por fmolinuevo
Herramientas de la página
Excepto donde se indique lo contrario, el contenido de este wiki esta bajo la siguiente licencia: CC Attribution-Noncommercial-Share Alike 4.0 International
