Descubra cómo se está utilizando mi servidor para los ataques DDOS

Podría ser que alguien esté usando tu instancia, ya sea por rootkit o mediante algunos scripts de PHP maliciosos. Su sistema está comprometido ahora. Deténgalo desde la órbita y restaure desde un estado de confianza (copia de seguridad).

Asegúrese de mantener su servidor actualizado y use hashes de contraseña largos y complejos. No permitir el inicio de sesión de raíz (solo permitir el inicio de sesión por clave, por ejemplo). Instale un HIDS (sistema de detección de intrusos basado en host) y un rootkithunter. OSSEC es una buena opción en Linux.

Probablemente su servidor se vio afectado por una vulnerabilidad de la web y se cargó un script php que interactúa con las órdenes del atacante.

Debes seguir estos pasos para asegurarte de que no volverás a ser pirateado:

1. Verifique los registros del servidor e identifique el comportamiento del atacante y su vulnerabilidad.
2. Trate de encontrar el script php malicioso en su servidor, para hacer esto volcando todos sus archivos localmente y comparándolos con una copia de seguridad antigua. Debería mostrarte el archivo modificado / nuevo.
3. Guarde el script malicioso, que se usa para contener el Comand & Controle la dirección IP, para que pueda enviarla a la policía.
4. Restaure el sitio web desde cero, no use copias de seguridad recientes ni scripts reutilizados del sitio comprometido. Los atacantes podrían insertar una puerta trasera en él y estarías abriendo la puerta nuevamente.

Lo más importante es identificar cómo comprometieron su sitio, si lo restaura con la misma vulnerabilidad, el robot del atacante volverá a escanear su sitio y tendrá el mismo problema.

Además, mantenga sus servicios actualizados, use contraseñas largas y complejas, etc. ...

Saludos.

Intentaría establecer el alcance de la penetración. Puede estar limitado a algún tipo de script en su sitio que hayan podido utilizar para crear un ataque DDOS. No es eso, puede estar limitado a una secuencia de comandos que pudieron cargar que realiza alguna acción incorrecta.

Si tiene una buena configuración conocida y puede determinar que no escaparon de los límites de sus motores de secuencias de comandos (y que sus motores de secuencias de comandos se configuraron de manera segura para que no pudieran alterar el sistema en sí), entonces debería está bien para restaurar a una buena configuración conocida de cualquier cosa a la que tengan acceso los motores de secuencias de comandos.

Si no puede estar seguro de que sus motores de secuencias de comandos están configurados de forma segura o si parece que realmente han obtenido acceso directo al cuadro fuera del motor de secuencias de comandos, no hay medidas para contener lo que podrían tener. oculto y deberías disparar desde la órbita como se sugirió anteriormente.

El truco es que no quiere dejar ninguna posibilidad de una reinfección, lo cual es muy probable si han tenido un acceso de bajo nivel, ya que hace que sea fácil dejar atrás cosas aparentemente inocuas que permitirán una reinfección más fácilmente.

Lo más probable es explotar una debilidad en una aplicación local, tal vez junto con un exloit del núcleo raíz. Iría algo como esto.

1) Hacker explota una debilidad en una aplicación PHP que les permite crear archivos de propiedad del servidor web y luego ejecutar ese código.

2) Su código malicioso descargaría un script que permite un acceso más fácil para ejecutar comandos. Descargar un script en perl a / dev / shm usando wget es bastante común.

3) El script perl se conectaría a un servidor remoto para formar un túnel, o podría aceptar conexiones entrantes, para que se puedan ejecutar comandos arbitrarios con mayor facilidad.

4) El código fuente de C para un exploit de raíz se instalará, compilará y ejecutará.

5) Si tiene éxito, el usuario ahora tendría privilegios de root. En este punto, el servidor de seguridad puede estar deshabilitado, la configuración predeterminada de iptables ha cambiado y las puertas traseras, como un ssh modificado, podrían instalarse para dar acceso a pesar de la configuración de hosts.allow y similares.

Esto solo roza la superficie, pero hay herramientas que pueden ayudar con la detección de intrusos y los pasos que podría tomar para fortalecer su configuración, como evitar conexiones salientes a IPs arbitrarias en el firewall (iptables en lugar del firewall externo de EC2). no tener un compilador de C en el lugar habitual o en absoluto, y mover herramientas como wget, aunque un script podría lograr lo mismo, por lo que es simplemente una molestia para el pirata informático. Mantener un registro de los procesos en ejecución con frecuencia (cada 5 minutos o menos) puede ayudar en el análisis post mortem al igual que los registros web. Es muy probable que un hacker cree archivos o directorios en / dev / shm o / tmp, y una utilidad que esté monitoreando entradas inesperadas podría detectar las intrusiones antes. Bloquear el servidor para permitir el acceso solo a ti mismo si se encuentran elementos inesperados, especialmente en / dev / shm (donde normalmente no habría nada) no sería excesivo.

La implementación de las actualizaciones del kernel se recomienda fuertemente , ya que ha habido muchos exploits de escalamiento de privilegios en Linux.