¿Cómo comprometieron los piratas informáticos mi instancia de EC2?

7

Mi instancia de EC2 fue hackeada recientemente. Realmente no importa, ya que estoy iniciando mi sitio web y aún no había información confidencial en mi servidor, pero planeo que haya en el futuro. Voy a terminar el servidor comprometido y configurar otro para asegurar mi sitio web.

Mi problema es que quiero asegurarme de que esto nunca vuelva a suceder, y la única manera de convencerme de que mi nuevo servidor es seguro es saber cómo se comprometió el primer servidor y asegurarme de que el nuevo servidor no pueda ser comprometido por el mismo método. Sin embargo, estoy teniendo problemas para identificar / entender cómo se hackeó el primer servidor.

La pila utilizada es Rails 4.2.4 + Postgresql 9.3 + Puma + Nginx 1.4.6. El servidor que estoy ejecutando es Ubuntu 14.04.2 LTS en una instancia de AWS EC2 t2.micro. Mis claves de acceso de AWS no se han publicado en ninguna parte y soy el único que debería tener acceso SSH a mi servidor.

Ahora no soy un pirata informático, ni siquiera un buen administrador de sistemas (aunque estoy aprendiendo), así que tengo que mantener la mente abierta sobre cómo se infiltró el servidor, pero ya que la única forma de acceder a mi servidor es por SSH, asumo que así es como entraron los hackers. Dejé erróneamente una regla de grupo de seguridad entrante para que el puerto SSH 22 tuviera una fuente de 0.0.0.0/0, lo que también me hace pensar que es probable que así sea como entraron los piratas informáticos.

Accedo a mi servidor mediante ssh usando una clave privada con un comando similar a

ssh -vi "/home/me/.ssh/my_private_key.pem" ubuntu@my_aws_instance.com

Un correo electrónico [email protected] me notificó el compromiso de que mi servidor había estado realizando ataques DDOS. Aunque no pude verificar esto mirando alrededor de mis registros, encontré algunos scripts php ocultos en /var/tmp que parecían estar diseñados para enviar correos electrónicos de phishing que me convencieron de que el servidor había sido hackeado.

No hay una configuración de contraseña para ssh que fue confirmada por hydra cuando intenté atacar mi propio servidor. Esto me implica que el atacante debe haber adivinado mi clave privada RSA ... excepto que entiendo que esto es no es realista posible .

No conozco ninguna otra forma posible de que el servidor se haya visto comprometido. ¿Alguien tiene alguna idea? ¿Alguno de mis supuestos o pasos están equivocados?

Reglas del grupo de seguridad entrante (en el momento de la piratería):

HTTP               TCP    80      0.0.0.0/0
PostgreSQL         TCP    5432    0.0.0.0/0
SSH                TCP    22      0.0.0.0/0
Custom TCP Rule    TCP    9200    91.216.55.150/32

Gracias de antemano por su ayuda. Estoy seguro de que he omitido mucha información útil, de modo que si hay algo más que quisiera saber, simplemente pregunte.

EDITAR:

El sitio web contiene alguna funcionalidad de entrada de datos de Rails bastante estándar. Principalmente a través de formularios html y allí también permito la carga de imágenes usando una gema llamada carrierwave .

    
pregunta Dennis 09.03.2016 - 15:45
fuente

1 respuesta

6
  

La pila utilizada es Rails 4.2.4 + Postgresql 9.3 + Puma + Nginx 1.4.6.   El servidor que estoy ejecutando es Ubuntu 14.04.2 LTS en un t2.micro de AWS EC2   instancia.


  

Accedo a mi servidor mediante ssh usando una clave privada ...

A menos que haya editado la configuración sshd para permitir también el inicio de sesión con contraseña, esto es suficiente para garantizar que un atacante remoto no pueda forzar la entrada de SSH. Sin embargo, si alguna vez se compromete la computadora que usa como cliente SSH, también debe considerar las claves comprometidas.


  

¿Cómo comprometieron los piratas informáticos mi instancia de EC2?

Difícil de decir sin más información. Una lista de servicios en ejecución, reglas de firewall y una pila de archivos de registro ayudaría.

  

Mi problema es que quiero asegurarme de que esto nunca vuelva a suceder ...

Tough cookies . Mientras tengas un servidor web de cara al público, será atacado. El mejor enfoque a tomar es aceptar que esto puede volver a suceder en el futuro y prepararse para ello. Algunas cosas realistas que puede hacer son mantener el software totalmente parcheado, tune sus reglas de firewall (¿realmente necesita dar acceso al todo el mundo ? ), implemente un IDS / IPS en AWS local network y enrutar todo el tráfico a través de él, y finalmente registrar todo el tráfico y reenviarlo a un endurecido logueando servidor .

Este es quizás el paso más importante para entender cómo fue hackeado y cómo prevenirlo en el futuro. Ir a través de los archivos de registro es una opción, pero tener una representación visual clara de los registros de su servidor hace que sea mucho más fácil detectar anomalías y buscar más tarde cuando un servidor es atacado. Tener un servidor de registro independiente y reforzado es importante porque si su servidor web está comprometido, el atacante puede borrar los rastros del ataque localmente.

Si desea ir un paso más allá, puede automatizar el proceso de detección de anomalías y definir reacciones basadas en eso. .

    
respondido por el cremefraiche 10.03.2016 - 00:49
fuente

Lea otras preguntas en las etiquetas