La respuesta estándar es que no lo hace, lo borra e instala un sistema operativo nuevo, luego restaura los datos de los usuarios de las copias de seguridad que son anteriores a la infección o, al menos, verifica que todos los cambios sean legítimos.
Yo prefiero entender lo que pasó y arreglarlo. Un nuevo sistema instalado, parcheado a un estado de actualización reciente, podría contener exactamente las mismas vulnerabilidades que fueron explotadas en primer lugar, y además, eso lleva años a menos que esté lo suficientemente organizado como para que este sea solo uno de los muchos servidores bien administrados que puede volver a crear imágenes de medios confiables.
Esto se aplicaría a cualquier sistema operativo, pero solo estoy muy familiarizado con Linux. En primer lugar, desea preservar el estado de lo que hay en la memoria: procesos en ejecución, sockets abiertos y archivos. Ejecuto “lsof -n> lsof.log” y “ps axw> psaxw.log”. Idealmente, usaría versiones estáticamente vinculadas de ps y lsof de medios confiables (una memoria USB) y escribiría los resultados en medios externos. Si un intruso ha dejado procesos en ejecución, o está controlando una máquina en tiempo real, eso puede aparecer. Si encuentra tráfico sospechoso, puede ejecutar “tcpdump -w xx.cap -s 0” por un momento, idealmente también en un enrutador ascendente. A menudo, ciertamente en el pasado, el tráfico de hackers (IRC, etc.) no está encriptado. Si deshabilita la red desconectando Ethernet o desconectando las interfaces, los sockets abiertos permanecerán abiertos durante un tiempo para el análisis, pero un intruso remoto se desconectará.
- ¿Qué es la seguridad en Internet?
- ¿Cuál es el significado de captcha?
- ¿El seguro cibernético se convertirá alguna vez en un requisito legal para las empresas?
- ¿Cuáles son las reglas para una buena contraseña?
- ¿Para qué se utiliza el cifrado de datos en bases de datos?
Si desea tratar de preservar los datos para la cadena de custodia para posibles procedimientos legales, o para dar a un tercero, apague la máquina tirando del enchufe (no apague) y luego cree una imagen del disco, creando un hash de la imagen del disco, imprimiéndola y firmando con la fecha. Luego puede montar la imagen de disco de solo lectura y analizarla como si fuera un disco real, clonarla, etc.
Yo uso sistemas basados en RedHat. En eso, el administrador de paquetes RPM mantiene una base de datos del contenido del paquete con hashes de archivos. Ejecutar “rpm -Va” le dirá qué archivos de los paquetes instalados han cambiado desde la instalación. Una “c” en la primera columna significa un archivo de configuración que se espera que cambie, mientras que “5” significa que el hash ha cambiado. Eso no debería suceder: si un objeto ejecutable o de biblioteca ha cambiado, se ha alterado. “Stat ” le indicará un cambio y una hora de modificación que indica cuándo ocurrió. Si analiza una imagen de disco, usaría “rpm -Va —root / media / ” para acceder a las bases de datos correctas.
Por lo general, tiene alguna idea de cuándo ocurrió una intrusión. Ejecutaría “find / -ctime +3 -ctime -7 -type f” para encontrar todos los archivos que cambiaron entre 3 y 7 días atrás (o -mtime para el tiempo de modificación del archivo, que puede ser falso pero persiste durante la copia de seguridad / restauración ciclos). Buscaría en los registros del sistema como / var / log / secure para inicios de sesión sospechosos, / var / log / httpd para solicitudes web sospechosas, y los uniría para crear una línea de tiempo para la intrusión. Por lo general, también tengo registros de red ascendentes para un enrutador, y los registros del sistema de la máquina se envían a un sistema seguro para que no puedan ser manipulados; si lo son, eso es más evidencia. En algunos casos, puedo ver en los registros de la red que un intruso descargó algo de Internet. Podría encontrar que dejaron un archivo intermedio en / tmp o / var que coincide con la descarga. Si un archivo legítimo cambió al mismo tiempo, parece que descargaron un troyano y luego lo instalaron, tal vez algo para darse acceso o registrar contraseñas.
Los hackers no son superhombres. Si explotaron una vulnerabilidad el lunes, y desconectó la máquina el jueves, han tenido 4 días, y probablemente tenían una agenda que incluía docenas de máquinas en otras partes del mundo, y un objeto particular en mente. Desfigurar una página web, construir una botnet, enviar mensajes de phishing, crear un repositorio de warez. Probablemente hayan pasado menos de una hora en su máquina, y solo hay mucho que pueden haber logrado. A veces cometen errores o no son particularmente hábiles. He visto el historial de bash sin modificar: puedo leer lo que escribieron, con marcas de tiempo (configuré “HISTTIMEFORMAT = ‘% s’”).
Si puede hacerse una buena idea de lo que hicieron, puede deshacerlo: elimine los programas, puertas traseras, credenciales, trabajos cron, etc. que no deberían estar allí y restaure los originales. Luego debe averiguar cómo entraron. Si iniciaron sesión con una cuenta de usuario, el usuario “joe” inicia sesión todos los días entre las 9 a.m. y las 5 p.m. desde Chicago, y de repente inicia sesión desde Hong Kong a las 3 a.m. y hay un montón de aparecieron archivos extraños: luego se comunicaría con Joe, se aseguraría de que no estuviera de vacaciones en Asia y cambiaría su contraseña en todas partes (tal vez en un servicio externo como Kerberos o Active Directory). Luego pídale que ejecute un análisis de malware en sus escritorios y pregúntele sobre sus prácticas de reutilización de contraseñas. Si encuentra solicitudes web sospechosas para cosas como php.cgi que parecen haber funcionado, buscaría vulnerabilidades web: asegúrese de que sus aplicaciones estén parcheadas, o que los arneses de prueba no utilizados estén deshabilitados, o la entrada del usuario se desinfecte correctamente para la inyección de SQL etc. No todo se repara, especialmente si tiene software personalizado o errores de configuración, por lo que simplemente mantener el software actualizado no es lo suficientemente bueno. Si al final del día no tiene idea de cómo obtuvieron acceso, todo lo que puede hacer es restaurar las cosas, cruzar los dedos y esperar que no lo intenten nuevamente. Y encienda más registros; establecer modos detallados, capturar el tráfico de red. Una vez pirateé bash para registrar el historial en otro lugar; cuando hicieron “history -c”, no funcionó y pude ver todos sus comandos.
Normalmente supondría que un intruso con acceso raíz copió el archivo local / etc / shadow, a menos que pueda probar que no lo hizo. Lo mismo se aplicaría a las claves SSL privadas locales, las claves SSH privadas, etc. Por lo tanto, debe cambiarlas: cambiar todas las contraseñas locales. Todos los entienden, aunque las claves son un poco más complejas de explotar. Si se comparten contraseñas locales, deberá cambiarlas en todos los lugares donde se usen. Si un intruso tuviera acceso a contraseñas NIS sin procesar, desearía cambiarlas en el servidor. Si copiaron un archivo oculto, eso no significa que tengan contraseñas, pero la identificación sí significa que tienen la posibilidad de intentar un ataque de diccionario fuera de línea. Las contraseñas comunes como “12345” y “qazwsxedc” caerán en segundos, mientras que las verdaderamente aleatorias tomarán años. Pero una contraseña aleatoria solo es aleatoria si nadie sabe lo que es; las contraseñas descifradas se comparten. La mejor práctica es asumir lo peor.
