¿Cómo puedo probar que los ataques SSH no son de mi aplicación?

Linode usa Xen , lo que significa que no solo tienes una aplicación; tienes todo un sistema operativo, completo con el kernel y las bibliotecas base. El ataque proviene de su sistema, por lo que está completamente en su jurisdicción. El atacante ingresó en su sistema de alguna manera, pero una vez allí, si es al menos medio competente, usó un rootkit para Transformar su robo en una instalación permanente. La desventaja es que un sistema rootkit no se mostrará desde el interior del sistema: el núcleo se habría infectado y no mostrará el proceso de ataque de los atacantes.

(Estoy utilizando aquí la suposición de que una vez que el atacante ingresó, él podría escalar sus derechos hasta el nivel raíz; esa es la suposición prudente, porque los sistemas operativos rara vez son tan sólidos como los atacantes locales).

Esto implica que su sistema debe ser eliminado y reinstalado desde cero; Se ha comprometido y ya no se puede confiar. En ese momento, tendría dos objetivos:

1. Comprenda cómo entró el atacante, para que no vuelva a hacerlo en el sistema que se acaba de reinstalar.
2. Convenza a la gente de Linode de que usted es una víctima, no un cómplice.

Para el primer punto, esto es una cuestión de análisis de todos los registros y otros rastros que se pueden encontrar en su sistema. Entonces, antes de rasparlo, tome una copia completa (preferiblemente, una copia byte a byte de su disco duro virtual) para un análisis posterior. Pero recuerda que si el atacante es razonablemente bueno, cubrió sus huellas (para eso son los rootkits). Además, algunas auditorías del código de su aplicación estarían en orden: el atacante ingresó de alguna manera a través de uno de los servicios de acceso externo de su servidor, que incluye su aplicación. Otra posibilidad es que el atacante haya adivinado la contraseña de su cuenta de SSH (después de todo, sabe que este atacante ejecuta ataques de fuerza bruta en los inicios de sesión de SSH): en su nuevo sistema , use una contraseña nueva, más grande y más aleatoria (¡no la escriba en su sistema actual! Está comprometida, por lo tanto, posiblemente se hagan cambios de contraseña al vuelo).

Para el segundo punto, esta es una cuestión de confianza y relaciones humanas. No puedes probar que no eres el atacante; pero la gente de Linode sabe que los sistemas secuestrados son una realidad común desafortunadamente. Solo ejerza la diligencia debida, como reinstalar el sistema desde cero: pasar por esa tarea tediosa ayudará en gran medida a establecer su buena fe en ese asunto.

Necesitas estudiar el tráfico que viene de tu servidor. Revelará si su servidor se está conectando a servicios SSH en otras redes.

Si no encuentra pruebas del tráfico generado desde su servidor, ofrézcalo a Linode y pídale que lo refute o lo acepte.

Si encuentra pruebas, debe pasar por el tráfico de la red, los registros, los procesos en ejecución y los archivos locales para determinar qué hace que su servidor se comporte de esta manera.

Cuando se haga esto, debe atacar al servidor y reinstalarlo desde una fuente confiable al mismo tiempo que implementa la solución antes de que se exponga al mismo vector de ataque que lo comprometió en primer lugar.

Puede probarlo, si puede encontrar un sistema comprometido de cualquier forma, forma o forma en su servidor. Tienes una parte de la prueba. Tener una sola línea de un archivo de registro no es una prueba. Por lo tanto, esto es realmente difícil de "probar". La seguridad de TI tiene mucho que ver con la WOT (Web of Trust). Debe dejar que "confíen" en usted de alguna manera. La forma más fácil de hacerlo es entregar el código fuente. Pero esto no es posible en la mayoría de los casos.

Pero aún así, si tienen pruebas sólidas de que su servidor ha intentado varios inicios de sesión en los servidores con SSH, es posible que tenga algo en marcha. Me gustaría hacer una imagen (disco duro, RAM) reiniciar y contratar a un pentester.

Acerca de detectar el ataque a ti mismo. Coloque un Sniffer en el puerto Ethernet de su servidor. La mejor manera de hacer esto es usar un puerto SPAN. No huela el propio sistema.

Muy buena suerte :)