¿Cómo sé si mi servidor Linux ha sido pirateado?

Solución 1:

1. Guarde una copia prístina de archivos críticos del sistema (como ls, ps, netstat, md5sum) en algún lugar, con un md5sum de ellos, y compárelos con las versiones en vivo regularmente. Los rootkits modificarán invariablemente estos archivos. Utilice estas copias si sospecha que los originales se han visto comprometidos.
2. asistente o cable trampa le informará de cualquier archivo que haya sido modificado, suponiendo que sus bases de datos no hayan sido alteradas.
3. Configure syslog para enviar sus archivos de registro a un servidor de registro remoto donde no puedan ser manipulados por un intruso. Observe estos archivos de registro remotos en busca de actividad sospechosa
4. leer sus registros Regularmente:use logwatch o logcheck para sintetizar la información crítica.
5. Conoce tus servidores . Sepa qué tipos de actividades y registros son normales.

Solución 2:

Tú no.

Lo sé, lo sé, pero es la triste y paranoica verdad, de verdad;) Hay muchos indicios, por supuesto, pero si el sistema fue dirigido específicamente, podría ser imposible saberlo. Es bueno entender que nunca nada es completamente seguro. Pero necesitamos trabajar para una mayor seguridad, así que señalaré todas las otras respuestas en su lugar;)

Si su sistema se vio comprometido, no se puede confiar en ninguna de las herramientas de su sistema para revelar la verdad.

Solución 3:

Tripwire es una herramienta de uso común:le notifica cuando los archivos del sistema han cambiado, aunque obviamente debe tenerlo instalado de antemano. De lo contrario, los signos habituales son elementos como nuevas cuentas de usuario que no conoce, procesos y archivos extraños que no reconoce o un mayor uso de ancho de banda sin razón aparente.

Se pueden configurar otros sistemas de monitoreo como Zabbix para que le avise cuando se cambien archivos como /etc/passwd.

Solución 4:

Algunas cosas que me han avisado en el pasado:

• Alta carga en un sistema que debería estar inactivo
• Fallos de segmentación extraños, p. de utilidades estándar como ls (esto puede suceder con rootkits rotos)
• Directorios ocultos en / o /var/ (la mayoría de los script kiddies son demasiado estúpidos o flojos para cubrir sus huellas)
• netstat muestra puertos abiertos que no deberían estar ahí
• Los demonios en la lista de procesos de los que normalmente usa diferentes versiones (p. ej., bind , pero siempre usas djbdns )

Además, descubrí que hay una señal confiable de que una caja está comprometida:si tiene un mal presentimiento sobre la diligencia (con actualizaciones, etc.) del administrador del que heredó un sistema, ¡vigile de cerca! /P>

Solución 5:

Hay un método para verificar servidores pirateados a través de kill -

Esencialmente, cuando ejecuta "kill -0 $PID" está enviando una señal nop al identificador de proceso $PID. Si el proceso se está ejecutando, el comando de eliminación se cerrará normalmente. (FWIW, ya que está pasando una señal de muerte nop, no pasará nada en el proceso). Si un proceso no se está ejecutando, el comando de eliminación fallará (estado de salida inferior a cero).

Cuando su servidor es pirateado/se instala un rootkit, una de las primeras cosas que hace es decirle al kernel que oculte los procesos afectados de las tablas de procesos, etc. Sin embargo, puede hacer todo tipo de cosas geniales en el espacio del kernel para jugar con el procesos. Y entonces esto significa que

a) Esta verificación no es una verificación exhaustiva, ya que los rootkits bien codificados/inteligentes garantizarán que el kernel responda con un "proceso no existe" respondiendo haciendo que esta verificación sea redundante. b) De cualquier manera, cuando un servidor pirateado tiene un proceso "malo" en ejecución, su PID generalmente no se mostrará en /proc.

Entonces , si está aquí hasta ahora, el método es eliminar -0 todos los procesos disponibles en el sistema (cualquier cosa desde 1 -> /proc/sys/kernel/pid_max) y ver si hay procesos que se están ejecutando pero no informados en /proc.

Si algunos procesos aparecen como en ejecución, pero no se informan en /proc, probablemente tenga un problema de cualquier forma que lo mire.

Aquí hay un script bash que implementa todo eso:https://gist.github.com/1032229. Guárdelo en algún archivo y ejecútelo, si encuentra un proceso que no se informa en proc, debería tener alguna pista para comenzar a investigar.

HH.