Busqué en Google algunos y revisé dos primeros enlaces que encontró:
- http://www.skullbox.net/rkhunter.php
- http://www.techerator.com/2011/07/how-to-detect-rootkits-in-linux-with-rkhunter/
No mencionan qué debo hacer en caso de tales advertencias:
Warning: The command '/bin/which' has been replaced by a script: /bin/which: POSIX shell script text executable
Warning: The command '/usr/sbin/adduser' has been replaced by a script: /usr/sbin/adduser: a /usr/bin/perl script text executable
Warning: The command '/usr/bin/ldd' has been replaced by a script: /usr/bin/ldd: Bourne-Again shell script text executable
Warning: The file properties have changed:
File: /usr/bin/lynx
Current hash: 95e81c36428c9d955e8915a7b551b1ffed2c3f28
Stored hash : a46af7e4154a96d926a0f32790181eabf02c60a4
P1: ¿Hay HowTos más extendidos que expliquen cómo lidiar con advertencias de diferentes tipos?
Y la segunda pregunta. ¿Fueron mis acciones suficientes para resolver estas advertencias?
a) Para encontrar el paquete que contiene el archivo sospechoso, por ejemplo, es debianutils para el archivo / bin / which
~ > dpkg -S /bin/which
debianutils: /bin/which
b) Para verificar las sumas de verificación del paquete debianutils:
~ > debsums debianutils
/bin/run-parts OK
/bin/tempfile OK
/bin/which OK
/sbin/installkernel OK
/usr/bin/savelog OK
/usr/sbin/add-shell OK
/usr/sbin/remove-shell OK
/usr/share/man/man1/which.1.gz OK
/usr/share/man/man1/tempfile.1.gz OK
/usr/share/man/man8/savelog.8.gz OK
/usr/share/man/man8/add-shell.8.gz OK
/usr/share/man/man8/remove-shell.8.gz OK
/usr/share/man/man8/run-parts.8.gz OK
/usr/share/man/man8/installkernel.8.gz OK
/usr/share/man/fr/man1/which.1.gz OK
/usr/share/man/fr/man1/tempfile.1.gz OK
/usr/share/man/fr/man8/remove-shell.8.gz OK
/usr/share/man/fr/man8/run-parts.8.gz OK
/usr/share/man/fr/man8/savelog.8.gz OK
/usr/share/man/fr/man8/add-shell.8.gz OK
/usr/share/man/fr/man8/installkernel.8.gz OK
/usr/share/doc/debianutils/copyright OK
/usr/share/doc/debianutils/changelog.gz OK
/usr/share/doc/debianutils/README.shells.gz OK
/usr/share/debianutils/shells OK
c) Relajarse /bin/whichcomo veo bien
/bin/which OK
d) Para poner el archivo /bin/whicha /etc/rkhunter.confloSCRIPTWHITELIST="/bin/which"
e) Para advertencias en cuanto al archivo /usr/bin/lynx, actualizo la suma de comprobación conrkhunter --propupd /usr/bin/lynx.cur
P2: ¿Resuelvo esas advertencias correctamente?
In general, the only way to trust that a machine is free from backdoors and intruder modifications is to reinstall the operating system from the distribution media and install all of the security patches before connecting back to the network. We encourage you to restore your system using known clean binaries.Respuestas:
El uso
debsumses una idea muy inteligente con un defecto importante: si algo sobrescribiera un archivo propiedad de root como/bin/which, también podría reescribirse/var/lib/dpkg/info/*.md5sumscon una suma de verificación actualizada. No hay una cadena de custodia de vuelta a una firma Debian / Ubuntu, por lo que puedo ver. Lo cual es una verdadera lástima porque sería una forma muy simple y rápida de verificar la autenticidad de un archivo en vivo.En lugar de verificar realmente un archivo, debe descargar una copia nueva de esa deb, extraer el
control.tar.gzarchivo interno y luego mirar su archivo md5sums para compararlo con un archivo realmd5sum /bin/which. Es un proceso doloroso.Lo que probablemente ha sucedido aquí es que ha tenido algunas actualizaciones del sistema (incluso una actualización de distribución) y no le ha pedido a rkhunter que actualice sus perfiles. rkhunter necesita saber cómo deberían ser los archivos para que cualquier actualización del sistema lo altere.
Una vez que sepa que algo es seguro, puede ejecutarlo
sudo rkhunter --propupd /bin/whichpara actualizar su referencia del archivo.Este es uno de los problemas con rkhunter. Necesita una integración profunda en el proceso de deb para que cuando se instalen paquetes firmados y de confianza, rkhunter actualice sus referencias a los archivos.
Y no, no pondría en la lista blanca cosas como esta porque este es exactamente el tipo de cosas que un rootkit buscaría.
fuente
zuba, la idea de la lista blanca es mala; es desasignar un archivo para verificar que debería ser visible para usted y su anti-malware, aunque la idea se usa y ver el mensaje es inofensivo. ¿Podríamos crear una escritura en su lugar sería mejor? en algún lugar a lo largo de las líneas de \ líneas que comienzan con \ serán ignoradas; pero eso requiere algo de experiencia en codificación y conocimiento íntimo del funcionamiento de rkhunter.
El contenedor / que se reescribirá cuando sea necesario para acomodar los cambios de programación; En general, un archivo puede ser reemplazado o los archivos pueden crearse temporalmente y cambiar o desaparecer después de un reinicio, y eso puede engañar al software rkhunter.
Hay una línea donde el software / las actualizaciones o el antimalware se asemejan a un rootkit, y creo que estos son uno de esos.
El método que emplea es peligroso solo si cambia un programa o archivo que afectará (de alguna manera) el funcionamiento de las computadoras. A veces somos peores que nuestras máquinas a ese respecto. Probar esto para su computadora es realmente injusto, ya que podría hacerlo si fuera mío. Lo sabría, documentaría las advertencias y sumas de verificación y anotaría cada vez que hubiera un cambio.
fuente