Mi servidor Linux fue pirateado. ¿Cómo puedo saber cómo y cuándo se hizo?

11

Tengo un servidor doméstico que ejecuta una distribución ubuntu de escritorio. Encontré esto en mi crontab

* * * * * /home/username/ /.access.log/y2kupdate >/dev/null 2>&1

y cuando busqué en ese directorio (el espacio después del nombre de usuario / es un nombre de directorio) encontré muchos scripts que obviamente están haciendo algo que no deberían.

Antes de limpiar esa computadora y reinstalar cosas, me gustaría saber qué causó la violación de seguridad y cuándo se hizo. Entonces no abro el mismo agujero otra vez.

¿Qué archivos de registro debo buscar? Los únicos servidores que conozco que se ejecutan en la computadora son sshd y lighttpd.

¿Qué debo hacer para detectar si vuelven a ocurrir cosas como esta?

Jonatan Kallus
fuente
@Person que votó para mudarse a SU: ¿Cómo crees que el análisis forense de virus / piratería se relaciona con el Superusuario más que con la Falla del servidor?
Chris S
3
Me alegra saber que el plan es borrar la computadora y reinstalar cosas. Eso es absolutamente lo que debe hacer sin importar lo que encuentre, porque siempre hay una buena posibilidad de que haya algo peor que no haya encontrado.
mattdm
¡Sí, realmente debería votar para pasar a Seguridad de TI ( security.stackexchange.com ), no a SU o Serverfault!
Rory Alsop

Respuestas:

4

Primero, asegúrese de que la computadora esté desconectada de cualquier red.
En segundo lugar, asegúrese de obtener datos importantes de las unidades antes de reiniciar el sistema operativo pirateado nuevamente.

Comience revisando las marcas de tiempo en los archivos en cuestión. A menudo son precisos.
Haga referencia cruzada con aquellos con el registro httpd y el registro de autenticación si no se borraron. Si el otro fue eliminado, puedes apostar que ese era el medio de entrada. Si todavía están en contacto, es posible que pueda obtener más información sobre cómo llegaron desde el registro.

Si están todos borrados, estás bastante jodido. Probablemente llevaría más tiempo averiguar qué sucedió de lo que vale.

Usted mencionó que esos dos servicios se estaban ejecutando, ¿había un buen firewall instalado para evitar el acceso a todo lo demás? ¿Permitió SSH en el puerto 22; es su inicio de sesión razonablemente fácil de adivinar; ¿permitiste iniciar sesión con contraseña? ¿Tuviste algún tipo de límite de velocidad real para los inicios de sesión con contraseña? ¿Tenía algún software adicional instalado con lighttpd; perl php; cgi; un CMS o similar? ¿Estaba ejecutando una versión actualizada de todo el software; ¿se suscribe a las notificaciones de seguridad de todo el software que ejecuta y evalúa cuidadosamente todas las notificaciones para ver si se aplican al software que ejecuta / expone al público?

Chris S
fuente
La instalación fue un Ubuntu Desktop Edition 10.x estándar, no se hizo nada en particular por seguridad. Asumí que había un buen firewall por defecto. ¿Eso no es correcto? Permití el inicio de sesión con contraseña en el puerto 22, pero la contraseña era una cadena aleatoria de 8 caracteres. ¿Debería ser lo suficientemente bueno?
Jonatan Kallus
Creo que el firewall predeterminado es "Abierto de par en par - Sin firewall". A menos que lo haya configurado cuidadosamente, no está haciendo nada.
Chris S
La pregunta es qué servicios estaba ejecutando más que qué firewall. A menos que el firewall esté configurado para configurar IP particulares para el acceso, el mejor firewall es no ejecutar servicios innecesarios en primer lugar. ¿Y cuál fue su configuración de red? Abierto a Internet? ¿Dentro de una red privada? ¿No tenía un firewall en el punto donde su red interna entró a Internet, o su servidor estaba en una DMZ?
Bart Silverstrim
El servidor estaba conectado directamente a internet. También lo usé como enrutador. Si el firewall predeterminado está completamente abierto, entonces creo que tengo suficiente explicación sobre cómo podría suceder esto ...
Jonatan Kallus
4

Este es un tema en sí mismo; puedes buscar en google forenses de linux para obtener más información. Básicamente, primero tendría que hacer una imagen de sus unidades para el análisis fuera de línea, luego limpiar la computadora e instalarla desde cero.

Y recuerda todos los imprevistos. Cualquiera que use la computadora podría tener sus contraseñas comprometidas. Cambie las contraseñas, manténgalas fuera de línea, etc. hasta que las obtenga en una "sala limpia" (VM aislada).

De lo contrario, se trata de una gran cantidad de registros de verificación (que pueden ser falsificados) y de sus aplicaciones (¿scripts php? ¿Bases de datos? ¿Actualizadas para las últimas soluciones?

Literalmente, no hay una manera fácil de responder a su pregunta, ya que necesitaría hacer un trabajo forense en el servidor y verificar si hay agujeros. Podrías usar algunas herramientas automatizadas, pero ten en cuenta que si el atacante tenía privilegios de root, ya no puedes confiar en los binarios del sistema, y ​​no puedes confiar en los registros.

En cuanto a futuros ataques, dependiendo de qué tan seguro quiera hacerlo, puede comenzar redirigiendo sus registros a un sistema que solo se utiliza para guardar registros del sistema. Ningún otro acceso, para reducir la huella del ataque.

También ejecutaría un software de suma de verificación en su sistema como Tripwire para verificar la integridad de sus archivos.

Y, por supuesto, manténgase actualizado con las actualizaciones y ejecute el software de escaneo que verifica los rootkits.

Nuevamente, la seguridad no es una cosa de tirar el interruptor. También puede ser una especialidad en sí misma. La seguridad en capas puede ser tan estricta como verificar hosts / IP que no pertenecen a su red, encriptar todos los accesos al sistema, recibir registros diarios de los cambios encontrados en su sistema y configurar un honeypot en su red para busque actividad extraña (¿por qué mi servidor intenta conectarse al puerto 25 en la computadora honeypot?)

En primer lugar, si desea verificar la actividad, obtenga la imagen del disco y vuelva a instalar el software del servidor. Desde cero Ya no se puede confiar en los binarios del servidor.

EDITAR - algunas otras cosas que se me ocurren desde que está ejecutando SSH - instale denyhosts. Se puede configurar para que los ataques automáticos contra su sistema en SSHD se bloqueen después de X número de intentos. También se puede configurar para actualizar desde otros servidores de host denegado en una "nube" para compartir IP bloqueadas para ayudar a minimizar los ataques automáticos. También puede mover el puerto en el que está escuchando; muchas personas señalan que es solo seguridad a través de la oscuridad, pero dada la cantidad de escaneos de bots, esto reduce significativamente los intentos aleatorios de entrar.

Bart Silverstrim
fuente
¡Gracias! Realmente respondiste la mitad de la pregunta cada una, desearía poder marcar ambas como la respuesta aceptada.
Jonatan Kallus