¿Podemos confiar en la información que muestran los comandos de la utilidad linux para una máquina vulnerable?

Como el sistema está comprometido, no se debe confiar en nada a través de herramientas. A menos que tenga las herramientas validadas (por ejemplo, Tripwire FIM ), su mejor apuesta es tomar un sistema similar, copiar lo que sea necesario, que debería ejecutarse si los sistemas son similares en arquitectura, etc. Sin embargo, este no es el método óptimo. Debido a que la máquina está comprometida, dependiendo de sus próximos pasos (legales, autoridades, etc.), crearía una imagen forense y luego lidiaría con lo que ocurrió cuando tiene su copia. Una vez que tenga su copia, debe determinar el riesgo asociado con volver a poner el sistema en línea, etc.

Si ha determinado cómo un atacante entró en el sistema, tendría que limpiar ese "agujero" (vulnerabilidad, configuración errónea) para asegurarse de que no vuelvan. A veces, esto puede llevar más tiempo que instalar un sistema limpio. Pero digamos que necesitas el sistema 'that'. Podría reinstalar ps con algo como: apt-get install --reinstall procps lo mismo se aplica para lsof. Querría asegurarse de que sus repositorios no hayan sido cambiados y su DNS no apunte a un repositorio que no sea de confianza.

En su mayor parte para responder a su pregunta: ¿Podemos confiar en la información que muestran los comandos de la utilidad linux ? La respuesta es que absolutamente no debería. Poco debe confiarse en ese sistema hasta que se realice un análisis exhaustivo.

Si su sistema ha sido comprometido, no debe confiar en nada .

Creo que, por lo general, las utilidades estándar funcionarán en su mayoría correctamente, pero dejarán de lado las cosas relacionadas con los procesos del atacante. Los rootkits están diseñados de esta manera, por lo que es menos probable que note que la máquina está comprometida. Entonces, creo que generalmente puedes confiar en ellos para ver tus propios procesos, pero no para asegurarte de que se haya eliminado un rootkit.

Si el atacante puede cargar módulos del kernel, o modificar el kernel, incluso las llamadas al sistema y /proc API pueden estar. Así que incluso una copia limpia de las utilidades del espacio de usuario como ps , o grep foo /proc/*/cmdline , no le dirá si hay un proceso malicioso en ejecución. Cualquier rootkit que valga la pena esconderá sus propios procesos.

Todos los archivos en todo el sistema son como desechos radioactivos , que pueden contaminar otras cosas si no tienes cuidado. p.ej. es posible que un atacante haya agregado algo a /home/*/.bashrc para volver a infectar su sistema en caso de que reinstale el sistema operativo pero no marque /home .

De manera similar, puede haber cosas desagradables en la configuración de su servidor web, o en sus scripts CGI, etc. Compare con las copias de seguridad, y no asuma que cualquier cosa es segura si el atacante podría haberlo tocado.

Definitivamente, realice todas y cada una de las comprobaciones de datos que no sean de confianza en una máquina de limpieza conocida. Siempre y cuando no ejecute nada del sistema comprometido, debería estar bien. (es decir, suponiendo que cmp y diff no tienen ninguna vulnerabilidad. Pero tenga en cuenta que strings no es seguro en archivos que no son de confianza, dependiendo de la versión de libbfd . Usa strings -a .

Saqué mi bola de cristal y, ¡Buenas noticias !, ¡ninguna de ps , netstat , top y lsof se han cambiado! De hecho, ninguno de los comandos en su sistema fueron modificados por el rootkit ... excepto por bash . Sin embargo, bash intercepta las llamadas a todas las demás utilidades para ocultar la presencia continua del rootkit modificando cualquier salida antes de que la veas; es posible que desee saber que las llamadas a cp , echo , sudo y apt-get también están siendo interceptadas.

¡Todo está bien, sin embargo! El rootkit también reemplazó a udev y al módulo usbcore , por lo que cualquier dispositivo USB conectado al sistema será infectado por BadUSB. De modo que el teclado que conectó al servidor para depurar desde la consola y el pendrive USB que usó para mover la base de datos crítica al servidor de conmutación por error ahora son vectores para el rootkit en el resto de su red. Solo deben pasar unas 48 horas antes de que todos sus sistemas sean Uno con el rootkit. Será un par de días dolorosos, pero puedes rendirte el fin de semana y disfrutar de la luz del sol sabiendo que ya no tienes que preocuparte por administrar tus sistemas por tu cuenta.

Sí, un poco exagerado. Pero realmente, si no sabes exactamente lo que hizo el rootkit, ¿entonces qué hizo el rootkit?

Probablemente, pero no necesariamente. El atacante siempre podría reemplazar los programas con versiones modificadas propias si tuvieran acceso de root.

Sorprendentemente, contra todas las leyes del universo, una analogía basada en automóviles es inútil aquí.

Cualquiera de los comandos de su sistema (o las bibliotecas de las que dependen) puede ser (y probablemente ha sido) reemplazado por una copia que se ve y actúa casi exactamente como la original, pero también tiene el propósito secreto de ocultar el compromiso existente y / o ayudar en cualquier intento de compromiso futuro.

En resumen, la respuesta es "No, no puedes confiar en ninguno de los programas de tu sistema comprometido".