Como el sistema está comprometido, no se puede confiar en nada a través de las herramientas. A menos que tenga las herramientas validadas (por ejemplo, Tripwire FIM), su mejor opción es tomar un sistema similar, copiar lo que sea necesario, que debería ejecutarse si los sistemas tienen una arquitectura similar, 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 se ocuparía de lo ocurrido cuando tenga 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 ingresó un atacante al sistema, necesitará limpiar ese 'agujero' (vulnerabilidad, mala configuración) para asegurarse de que no regrese. A veces, esto puede llevar más tiempo que instalar un sistema limpio. Pero digamos que necesita 'ese' sistema. Podrías 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 cambiado y que 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 de Linux la respuesta es absolutamente no deberías. Se debe confiar poco en ese sistema hasta que se realice un análisis exhaustivo.
Si su sistema se ha visto comprometido, no debe confiar en nada .
Creo que, por lo general, las utilidades estándar funcionarán correctamente en su mayoría, pero dejan de lado 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, en general, puede confiar en ellos para analizar sus propios procesos, pero no para asegurarse de que un rootkit haya desaparecido.
Si el atacante puede cargar módulos del kernel o modificar el kernel, incluso el sistema llama y /proc La API puede mentir. Entonces, 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 se precie ocultará sus propios procesos.
Cada archivo en todo el sistema es como desechos radiactivos , que potencialmente puede contaminar otras cosas si no tienes cuidado. p.ej. un atacante podría haber agregado algo a /home/*/.bashrc para volver a infectar su sistema en caso de que reinstale el sistema operativo pero no marque /home .
Del mismo modo, puede haber cosas desagradables en la configuración de su servidor web, o en sus secuencias de comandos CGI, etc. Compare con las copias de seguridad y no asuma que nada es seguro si el atacante podría haberlo tocado.
Definitivamente haga todas y cada una de las comprobaciones de datos que no sean de confianza en una máquina que se sepa que está limpia. Mientras no ejecute nada desde el sistema comprometido, debería estar bien. (es decir, asumiendo cmp y diff no tiene 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 .
Probablemente, pero no necesariamente. El atacante siempre podría reemplazar los programas con sus propias versiones modificadas si tuviera acceso de root.