¿Es una buena práctica la detección de rootkits mediante la comparación de listas de archivos, procesos y conexiones?

2

Actualmente estoy leyendo el Manual del Equipo Azul y uno de los Los métodos recomendados para detectar rootkits son comparar los datos técnicos obtenidos de varias fuentes. Como lo entendí, esto se practica así:

  1. Compare una lista de todos los archivos en un disco duro obtenido a través del sistema con una lista de todos los archivos obtenidos mediante un CD en vivo

  2. Compare una lista de todas las conexiones mostradas por el sistema con una lista de conexiones capturadas por un toque de red.

  3. Compare una lista de todos los procesos mostrados por el sistema con una lista de procesos extraídos de una imagen de memoria con una herramienta como volatilidad.

Las listas deben coincidir con la causa. Si no es así, el anfitrión podría verse comprometido. Como he dejado de tener experiencia en las secuencias de comandos, puedo hacer todas estas cosas, pero ¿es realmente un método de detección común y bueno?

Es bastante costoso y, para ser honesto, no conozco a una sola persona que haya hecho algo tan recargado como ese para detectar un rootkit. Cabe señalar que soy administrador y no un tipo de IR.

    
pregunta davidb 11.07.2016 - 10:47
fuente

1 respuesta

2

Es un buen método de detección, para repetir:

  • Verificación de memoria para procesos ocultos
  • Verificación de tráfico de red
  • Comprobación del sistema de archivos

La solución anterior es flexible, escalable y segura, sin embargo, no es su promedio de scripts si se trata de una gran escala, por lo que es la solución más adecuada. Pero esto no significa que no funcione en escalas más pequeñas, sin embargo, el esfuerzo puede ser demasiado alto. La posible implementación se podría hacer de la siguiente manera:

  • La memoria comprueba el host de virtualización incorporado
  • Supervisión del tráfico de red en la capa de red (por ejemplo, netflow)
  • Comprobaciones del sistema de archivos en la capa de almacenamiento de la red

Ahora el problema es que, dado que es un trabajo bastante personalizado, no podrá confiar realmente en los resultados antes de que se invierta suficiente tiempo y dinero en el desarrollo de dicha solución, por lo que funciona, pero a gran escala, por ejemplo. muchos servidores, digamos, 10.000 de ellos o más, eso tendría sentido. También si estos servidores ejecutan varias cosas y no son el mismo tipo de servidor. Sin embargo, se pueden hacer algunas concesiones, es posible que desee evaluar algunos programas para hacer algunos de ellos, y luego puede ser más fácil hacerlo, vea más abajo.

Si desea intentarlo por sí mismo, intente configurar la supervisión de Netflow (sflow) y solo con esto, puede detectar con éxito el tráfico malicioso cuando suceda. Usar software ya hecho sería más eficiente. Así, por ejemplo, puede seleccionar patrones para que los paquetes activen la alarma. Se puede detectar con éxito una gran cantidad de tráfico inusual, no solo relacionado con la piratería y eso ayuda mucho. Es barato, fácil, polivalente y eficaz. Lo único es que necesita inventar patrones adecuados (por ejemplo, qué paquetes desea capturar), estos podrían ser básicamente algo inusual pero permitido, por ejemplo. Conexiones tcp salientes, que en el momento de la detección inicial pueden incluirse en la lista blanca si no son maliciosas. Otra forma fácil sería ejecutar tcpdump , luego netstat y ejecutar la comparación. Pero esto es menos útil, solo detectaría conexiones de red ocultas, y si buscas en Internet, es posible que encuentres algunos scripts útiles ya.

Con respecto a los sistemas de archivos, también puede usar un script normal para verificar la consistencia de los binarios (por ejemplo, usando los comandos estándar rpm o dpkg ), y también verificar la consistencia de los archivos de configuración. Dicha secuencia de comandos se puede ejecutar desde un host externo que se conecta a través de ssh , carga la secuencia de comandos generada (por ejemplo, con las últimas sumas de comprobación calculadas a partir de git repo fueron configuraciones), ejecute la verificación y devuelva el resultado. Rundeck puede ser un software para ayudarte con esto. El comando de ejecución desde un host externo le asegura que se está ejecutando en primer lugar, y al final es un método simple y eficiente.

Con respecto a la RAM, esta es la parte más difícil, y puede omitir esta parte por el momento porque es más avanzada. Volcar y analizar la RAM no es nada fácil.

También busque chkrootkit y rkhunter scripts y similares. Hay un antivirus gratuito Clamav y soluciones de pago como Kaspersky . Sin embargo, estos comprueban las puertas traseras conocidas, sin embargo, en el entorno corporativo / de alojamiento promedio hay una probabilidad de 50/50 si es un parche personalizado sshd con una clave secreta o una puerta trasera conocida.

Y no se olvide de asegurarse de que el kernel no esté parchado o que no haya un módulo malicioso, pero ese es un tema diferente. Intentaría investigarlo y usar el mismo script para verificar tanto el kernel como los procesos ocultos. Puede que ya haya algunos scripts que lo hagan en Internet.

En resumen, Netflow (o Sflow, es lo mismo) lo ayudará mucho, no solo con seguridad sino también con la red. No tiene nada que ver con los servidores, funciona de la manera en que el conmutador envía cada n-ésimo paquete al receptor de flujo de red cuando se verifica con patrones predefinidos y cuenta las estadísticas. Debe proporcionarle informes también. Las comprobaciones del sistema de archivos son fáciles de hacer con rpm y dpkg , y el resto se puede verificar desde git o con el servidor de compilación. Tenga en cuenta que los gestores de paquetes están utilizando firmas cristalográficas, por lo que no necesita usar LiveCD. Finalmente, revisa el kernel y los procesos ocultos y estás ordenado. Y antes de implementar el software, escanéelo con "Kaspersky".

Tómese el tiempo, desarrolle un plan y, poco a poco, no es difícil hacerlo todo.

    
respondido por el Aria 11.07.2016 - 16:42
fuente

Lea otras preguntas en las etiquetas