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

¿Cuáles son las señales reveladoras de que un servidor Linux ha sido pirateado? ¿Hay alguna herramienta que pueda generar y enviar por correo electrónico un informe de auditoría de forma programada?

1. Mantenga una copia prístina de los 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 tripwire le informará sobre cualquier archivo que haya sido modificado, suponiendo que sus bases de datos no hayan sido manipuladas.
3. Configure syslog para enviar sus archivos de registro a un servidor de registro remoto donde un intruso no pueda manipularlos. Mire estos archivos de registro remotos para detectar actividades sospechosas
4. lea 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.

Usted no

Lo sé, lo sé, pero en realidad es la triste y paranoica verdad;) Hay muchas pistas, por supuesto, pero si el sistema fue dirigido específicamente, podría ser imposible saberlo. Es bueno entender que nada es completamente seguro. Pero tenemos que trabajar para obtener más seguridad, por lo que señalaré todas las otras respuestas en su lugar;)

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

Tripwire es una herramienta de uso común: le notifica cuando los archivos del sistema han cambiado, aunque obviamente necesita tenerlo instalado de antemano. De lo contrario, los signos habituales son elementos como nuevas cuentas de usuario que no conoce, procesos extraños y archivos 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 alertarlo cuando se cambian archivos como / etc / passwd.

Algunas cosas que me han avisado en el pasado:

• Alta carga en un sistema que debería estar inactivo
• Segfaults extraños, por ejemplo. de utilidades estándar como ls(esto puede suceder con kits de raíz 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 allí
• Demonios en la lista de procesos en los que normalmente usa diferentes sabores (por ejemplo bind, pero siempre usa 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, ¡vigílelo de cerca!

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

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

Cuando se piratea su servidor / 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 interesantes en el espacio del kernel para manipular el kernel. procesos. Y esto significa que

a) Esta comprobación no es exhaustiva, ya que los rootkits bien codificados / inteligentes asegurarán que el núcleo responderá con una respuesta de "proceso no existe", haciendo que esta comprobació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 ejecutan pero no se informan en / proc.

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

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

HTH

Secundaré las respuestas dadas aquí y agregaré una propia.

find /etc /var -mtime -2

Esto le dará una indicación rápida si alguno de sus archivos del servidor principal ha cambiado en los últimos 2 días.

Esto es de un artículo sobre detección de piratería Cómo detectar si su servidor ha sido pirateado.

De Cómo puedo detectar intrusiones no deseadas en mis servidores?

• Use un IDS

  SNORT® es un sistema de prevención y detección de intrusos de red de código abierto que utiliza un lenguaje basado en reglas, que combina los beneficios de los métodos de inspección basados ​​en firma, protocolo y anomalías. Con millones de descargas hasta la fecha, Snort es la tecnología de detección y prevención de intrusos más ampliamente implementada en todo el mundo y se ha convertido en el estándar de facto para la industria.

  Snort lee el tráfico de red y puede buscar cosas como "prueba de manejo con lápiz" donde alguien simplemente ejecuta un escaneo de metasploit completo contra sus servidores. Es bueno saber este tipo de cosas, en mi opinión.

• Usa los registros ...

  Dependiendo de su uso, puede configurarlo para que sepa cuándo un usuario inicia sesión, o inicia sesión desde una IP extraña, o cuando la raíz inicia sesión, o cuando alguien intenta iniciar sesión. De hecho, el servidor me envía un correo electrónico con cada mensaje de registro superior a Debug. Sí, incluso aviso. Filtrado algunos de ellos, por supuesto, pero cada mañana cuando recibo 10 correos electrónicos sobre cosas, me dan ganas de arreglarlo para que deje de suceder.

• Supervise su configuración: de hecho, mantengo todo mi / etc en subversion para poder seguir las revisiones.

• Ejecute escaneos. Herramientas como Lynis y Rootkit Hunter pueden brindarle alertas sobre posibles agujeros de seguridad en sus aplicaciones. Hay programas que mantienen un hash o un árbol de hash de todos sus contenedores y pueden alertarlo sobre los cambios.

• Supervise su servidor: al igual que mencionó el espacio en disco, los gráficos pueden darle una pista si algo es inusual. Uso Cacti para vigilar la CPU, el tráfico de red, el espacio en disco, las temperaturas, etc. Si algo parece extraño, es extraño y deberías averiguar por qué es extraño.

Solo me gustaría agregar a esto:

Verifique su historial de bash, si está vacío y no lo ha desarmado o vaciado, existe una buena posibilidad de que alguien haya comprometido su servidor.

Verifique el último. O verá direcciones IP desconocidas o se verá muy vacío.

Luego, como dice la respuesta aceptada, los archivos del sistema a menudo cambian, verifique la fecha de modificación. Sin embargo, a menudo alteran la fecha de modificación.

A menudo instalan otra versión de ssh que se ejecuta en un puerto aleatorio. Esto a menudo está oculto en algunos lugares realmente extraños. Tenga en cuenta que normalmente cambiará su nombre a algo diferente a ssh. Por lo tanto, verifique netstat (puede que no funcione, ya que a menudo lo reemplazan) y use iptables para bloquear cualquier puerto desconocido.

En cualquier caso, esta es una situación en la que es mejor prevenir que curar. Si se ha visto comprometido, es mejor simplemente formatear y comenzar de nuevo. Es casi imposible confirmar que ha limpiado con éxito el truco.

Tome nota de lo siguiente para evitar que su servidor se vea comprometido.

1. Cambiar puerto ssh
2. Evitar que root pueda iniciar sesión
3. solo permite ciertos usuarios
4. Evitar el inicio de sesión con contraseña
5. Utilice claves ssh, claves protegidas con contraseña preferibles
6. Siempre que sea posible, ponga en una lista negra todas las IP y ponga en la lista blanca los ips requeridos.
7. Instalar y configurar fail2ban
8. Use tripwire para detectar intrusiones
9. Controle la cantidad de usuarios que iniciaron sesión con Nagios o zabbix. Incluso si recibe una notificación cada vez que inicia sesión, al menos sabrá cuándo está jugando otra persona.
10. Si es posible, mantenga su servidor en un vpn y solo permita ssh a través de vpn ip. Asegure su VPN.

Vale la pena tener en cuenta que una vez que estén en un servidor, verificarán su historial de bash y buscarán otros servidores a los que se conectó a través de ssh desde ese servidor. Luego intentarán conectarse a esos servidores. Por lo tanto, si obtiene una fuerza bruta debido a una contraseña deficiente, es muy posible que puedan conectarse al otro servidor y comprometerlos también.

Es un mundo feo, reitero que prevenir es mejor que curar.

Después de buscar un poco, también está esto, hace lo que he enumerado anteriormente, entre otras cosas: http://www.chkrootkit.org/ y http://www.rootkit.nl/projects/rootkit_hunter.html

Deberías revisar GuardRail. Puede escanear su servidor diariamente y decirle qué ha cambiado de una manera visual agradable. No requiere un agente y puede conectarse a través de SSH, por lo que no necesita desechar su máquina y recursos con un agente.

Lo mejor de todo, es gratis para hasta 5 servidores.

Compruébalo aquí:

https://www.scriptrock.com/