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