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

36

¿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?

cowgod
fuente
1
Si el estado es desconocido, realmente no hay forma. Es por eso que es tan importante usar fuentes de instalación confiables y configurar herramientas como Tripwire antes de exponerlo a algo más que a sí mismo.
Oskar Duveborn
10
Te refieres a "agrietado". Hackear es cómo obtuvimos Linux en primer lugar.
gbarry
Un amigo mío, cuyo servidor estaba alojado con nosotros, una vez me pidió que mirara su servidor, ya que parecía haber algo extraño en él. Tan pronto como vi los registros, supe que algo estaba pasando. Intentaron cubrir sus huellas y creo que había instalado un kit de raíz, pero lo estropeó un poco. De todos modos, para abreviar una larga historia, tuvimos que reconstruir todo el servidor desde cero. Nos llevó toda la noche y luego configuramos algunas herramientas de auditoría de seguridad.
Matt
@Matt Mind nos dice qué herramientas? ¿Sigue siendo el mismo hoy?
Rodrigo

Respuestas:

34
  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.
Brent
fuente
8
md5 se ha debilitado severamente si no se ha descartado. Es posible que desee pasar a sha512.
Broam
12

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.

Oskar Duveborn
fuente
55
Asume que su atacante tiene alguna habilidad, quiere ser sigiloso de alguna manera y no está puramente interesado en eliminar el spam y agregar su OC3 a una botnet. En estos días, generalmente se da cuenta del hecho de que grandes cantidades de spam salen de su servidor, generalmente en un sistema sobrecargado que no debería estarlo. La mayoría de los "hackers" están motivados por el dinero en estos días.
Ernie
2
Las herramientas de ataque más avanzadas requieren cero habilidad en estos días y están fácilmente disponibles y algunas son extremadamente sigilosas por defecto y por diseño. Las redes de bots / zombies pueden estar inactivo mucho tiempo antes de ser utilizado por los daños, pero los errores en las herramientas de ataque puede provocar accidentes no deseados y el comportamiento extraño etc.
Oskar Duveborn
11

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.

Batidor
fuente
11

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!


fuente
10

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

Shai
fuente
Eso es realmente útil para mi servidor doméstico donde no tengo tiempo para mantener el sistema como un sistema de trabajo productivo. De todos modos, ¿podría usar esto en un entorno profesional y estar "relativo" seguro de los resultados? Y para que la respuesta tenga 3 años: ¿sigue siendo un método válido para verificar si hay una infección común hoy en día en 2014?
hub
7

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.

Ian Purton
fuente
1
Pienso -ctime en lugar de -mtime. No se puede manipular -ctime
Tillebeck
5

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.

Tom Ritter
fuente
2

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.

Robar
fuente
0

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/

Cheyne
fuente
¿Es este un servicio en la nube que inicia sesión en su máquina con derechos de root? ¿Qué sucede si el servicio se ve comprometido?
hub
No necesitas darle raíz. También puede optar por utilizar un agente, lo que significa que su máquina sondea en lugar de llamar a SSH. Las contraseñas para cosas como DB siempre se almacenan en su máquina, no en la nube también.
Cheyne