Herramientas de usuario
tecnica:emergenciasprocedimiento
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anterior Revisión previa Próxima revisión | Revisión previa | ||
|
tecnica:emergenciasprocedimiento [2025/11/10 12:02] fmolinuevo |
tecnica:emergenciasprocedimiento [2025/11/10 12:11] (actual) fmolinuevo [Otras ideas] |
||
|---|---|---|---|
| Línea 36: | Línea 36: | ||
| * **Regla:** Toda la comunicación técnica pasa por aquí | * **Regla:** Toda la comunicación técnica pasa por aquí | ||
| - | ===== Fase 2: Evaluación y Contención ===== | + | ===== Fase 2: Evaluación y contención ===== |
| El objetivo es entender el "radio de explosión" (blast radius) y **detener el sangrado** inmediatamente. | El objetivo es entender el "radio de explosión" (blast radius) y **detener el sangrado** inmediatamente. | ||
| Línea 76: | Línea 76: | ||
| * Realizar el //rollback// del parche defectuoso | * Realizar el //rollback// del parche defectuoso | ||
| - | ===== Fase 4: Recuperación y Verificación ===== | + | ===== Fase 4: Recuperación y verificación ===== |
| El objetivo es restaurar los servicios de forma segura y ordenada, activando el Plan de Recuperación ante Desastres (DRP) si es necesario. | El objetivo es restaurar los servicios de forma segura y ordenada, activando el Plan de Recuperación ante Desastres (DRP) si es necesario. | ||
| Línea 120: | Línea 120: | ||
| - **Actualizar la documentación:** Los aprendizajes se usan para mejorar //este mismo procedimiento// | - **Actualizar la documentación:** Los aprendizajes se usan para mejorar //este mismo procedimiento// | ||
| - | ==== Puntos Clave para el Sysadmin/Infosec ==== | + | ===== Puntos Clave para el Sysadmin/Infosec ===== |
| * **Linux:** En un ataque, no olvides revisar crontab, /tmp, ~/.ssh/authorized_keys y las conexiones de red (netstat -antp) para contención y erradicación | * **Linux:** En un ataque, no olvides revisar crontab, /tmp, ~/.ssh/authorized_keys y las conexiones de red (netstat -antp) para contención y erradicación | ||
| Línea 126: | Línea 126: | ||
| * **Segmentación:** Tu mejor arma de contención es una red bien segmentada (VLANs, ACLs, microsegmentación). Si todo está en la misma red "plana", estás perdido | * **Segmentación:** Tu mejor arma de contención es una red bien segmentada (VLANs, ACLs, microsegmentación). Si todo está en la misma red "plana", estás perdido | ||
| * **Backups:** Sigue la regla **3-2-1-1-0**: 3 copias, 2 medios distintos, 1 //offline// (o //air-gapped//), 1 inmutable, y 0 errores de verificación | * **Backups:** Sigue la regla **3-2-1-1-0**: 3 copias, 2 medios distintos, 1 //offline// (o //air-gapped//), 1 inmutable, y 0 errores de verificación | ||
| + | |||
| + | ===== Otras ideas ===== | ||
| + | |||
| + | - 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 | ||
| + | - 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 geográficamente alejados, especialmente de datos críticos para la operación de la empresa | ||
| + | - Servidores de backup sin acceso desde los servidores de origen | ||
| + | - 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 | ||
| + | - 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 | ||
| + | - 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 | ||
| + | - Considerar la posibilidad de que el atacante aún tenga acceso, y tomar todas las precauciones necesarias | ||
| + | - El acceso al dominio, y los usuarios administrador deben ser extremadamente limitados, preferentemente configurarles acceso exclusivo desde algunas IPs consideradas "seguras", y dejar registrado en una knowledge base (KB) cualquier cambio (altas, bajas y modificaciones) para referencia posterior | ||
| + | - 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 | ||
| + | - 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 | ||
| + | - 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 | ||
| + | - Básicamente, considerar que si algo es "demasiado fácil", quizá sea inseguro | ||
| + | - El concepto de seguridad es dinámico, y las políticas de seguridad deben ser integrales, revisadas periódicamente como un todo, evitando nichos y "corralitos" de poder o prejuicios | ||
| + | - Realizar periódicamente auditorías de seguridad | ||
| + | - Considerar el acceso por VPN como un potencial vector de acceso muy agresivo. Usuarios y accesos deben ser registrados, y revisados los accesos periódicamente, dando de baja aquellos que sean necesarios. Es recomendable tener una política de vencimiento de los certificados, para obligar a todos los que necesiten acceder a que tengan que renovarlos | ||
| + | - El acceso desde afuera a puertos internos debe ser registrado y evaluado en cada caso, para lo cual se debe identificar un responsable del/los firewalls, quien llevará a cambio los cambios, documentando y realizando el correspondiente backup previo y posterior | ||
| + | - Educar al personal técnico y no técnico sobre mejores prácticas tanto de seguridad como de trabajo. Y hacerlo periódicamente, repasando conocimientos y mejorando cada vez, agregando aquellas nuevas consideraciones que sean necesarias | ||
| + | - Documentar todo lo posible y mejorar la documentación de manera permanente, educando y obligando a los responsables a hacerlo, y mantenerlo actualizado | ||
| + | - Educar y estimular a los equipos que funcionen como uno solo, colaborando entre sí, y/o cambiando roles para evitar dependencias críticas de alguno de ellos | ||
tecnica/emergenciasprocedimiento.1762786953.txt.gz · Última modificación: 2025/11/10 12:02 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
