En caso de que un servidor Linux haya estado expuesto a Internet con una política de seguridad extremadamente baja (carpetas Samba anónimas r / w, servidor de base de datos Firebird con contraseña de administrador predeterminada, sin firewall, etc.) durante una semana, entonces, ¿cómo me aseguro de que el sistema esté funcionando? no se ve comprometido sin formateo completo y reinstalación, ¿solo se accede de forma remota a través de SSH?
Respuestas:
Normalmente sugeriría un chequeo local con una herramienta como chkrootkit, pero si la única forma de ejecutar el cheque es hacerlo de forma remota, entonces recomendaría que intentes Rootkit Hunter .
Rookit Hunter busca rootkits y otras actividades similares ejecutando pruebas como las siguientes (consulte la Información del proyecto para obtener más detalles):
Quiero agregar que, como han dicho otros, la única forma segura de garantizar que no se haya alterado su servicio es reconstruirlo. Estas herramientas funcionan bien, pero no son una garantía de éxito del 100%.
Sé que esta respuesta no es lo que quieres escuchar, pero aquí vamos de todos modos. Existen algunas herramientas que pueden verificar el sistema. La mejor manera de garantizar que el sistema esté limpio es limpiar el servidor y reconstruirlo. Yo haría lo siguiente:
Aquí hay algunos recursos que comenzaría a leer si aún no lo ha hecho.
[texto del enlace] [1] texto del enlace texto del enlace texto del enlace
[1]: http://www.sans.org/reading_room/whitepapers/linux/linux-rootkits-beginners-prevention-removal_901 "Linux Rootkits Beginners"
Tampoco es la respuesta que desea, pero si existe la posibilidad de que un sistema haya sido rooteado, puede ser muy difícil estar 100% seguro de que el sistema está limpio. Los rootkits están diseñados para ser difíciles de detectar. Si ejecuta varios verificadores de raíz y sale limpio, "lo más probable" es que su sistema esté limpio.
Si la seguridad es una preocupación, consideraría reconstruirla como se indicó anteriormente en el póster o restaurarla a partir de buenas copias de seguridad.
Realmente necesitas ser proactivo aquí. No hay una forma confiable de detectar rootkits en las máquinas, por lo tanto, debe evitar que lleguen allí en primer lugar y encontrar formas de detectarlos al ingresar (por ejemplo, a través de interfaces triples y bloqueadas).
Si cree que una máquina ha sido explotada de alguna manera, realmente necesita reinstalarla; no hay forma garantizada de limpiarla antes de la reinstalación. Con mucho, la opción más segura.
RKhunter, Tripwire, etc. son geniales, pero en realidad solo son beneficiosos si se instalaron antes del incidente; esto se debe a que son excelentes para detectar si se han cambiado los archivos clave. Si instala RKHunter ahora y lo ejecuta, detectará la inclusión de muchos rootkits, pero no detectará las puertas traseras que un atacante abrió en el sistema operativo o las aplicaciones que utiliza.
Por ejemplo, podría colarse en una computadora, crear un nuevo usuario, otorgarles permisos SSH y sudo, y luego limpiar dejando una configuración legítima en su lugar y sin rootkits; luego regrese más tarde y haga su maldad.
Lo mejor que puede hacer es ver qué puertos tienen servicios que los escuchan, luego ver la configuración de todos esos servicios y asegurarse de que todos sean legítimos. Luego, mire la configuración de su firewall y bloquee los puertos que no necesita, tanto de entrada como de salida. Luego instale RKHunter, etc. para ver si algún script-kiddie dejó caer un kit de raíz allí desordenadamente.
Para ser sincero, probablemente sea menos trabajo hacer lo que JJ sugirió y reconstruir que asegurarse de que la computadora no se haya visto comprometida. Son los datos los que son valiosos, no el sistema operativo y la configuración (aparte de las horas de trabajo para configurarlo).
Nunca estarás seguro de que alguien más inteligente que tú no lo descifró.
El primer paso realmente debería ser rkhunter / chkrootkit, sin embargo, también he tenido buena suerte en el pasado con las características que vienen incorporadas en ciertos administradores de paquetes, por ejemplo, 'rpmverify' que revisará todos los paquetes en su sistema y verificará que Los MD5Sums de los archivos que incluyen no difieren de los archivos en el disco.
Los archivos binarios principales deberían tener MD5 idénticos a los especificados en las bases de datos RPM o DPKG, por lo que si son diferentes, sabe que está sucediendo algo extraño.
La forma más efectiva de determinar si su sistema en ejecución está comprometido es usar Second Look . Verificará el kernel y todo el software en ejecución en la memoria para asegurarse de que sean consistentes con lo que envió el proveedor de distribución. Este es un enfoque mucho mejor que rkhunter, chkrootkit, etc., que buscan artefactos de infecciones específicas conocidas . Second Look no hace suposiciones sobre la integridad del sistema operativo, por lo que no necesita haberlo usado o instalado antes de un incidente.
(Descargo de responsabilidad: soy el desarrollador principal de Second Look).