DigitalOcean me informó hoy que mi Droplet allí se desconectó porque estaba realizando un ataque DDoS.
Me han pedido que investigue y averigüe qué lo estaba causando.
Este era Ubuntu 14 y tenía 6 Apache VirtualHosts allí. Todos estaban en vivo.
Uno de mis sitios era una instalación de WordPress con un par de complementos.
Otro sitio tenía algún código API de Google Maps.
El resto solo tenía mi código original.
Aún no he entrado al servidor. Una vez que lo haga, ¿cuál sería el proceso para encontrar correctamente el software que causa esto?
Sospecho que esto sucedió porque no estaba usando una clave SSH con mi contraseña.
Respuesta1
Primero, mi más sentido pésame por tener que lidiar con algo como esto. Pero puedes limpiar esto. Primero, sólo necesito abordar esto:
Sospecho que esto sucedió porque no estaba usando una clave SSH con mi contraseña.
99% seguro que ese no es el caso. Prácticamente todos los compromisos del servidor web con los que me he enfrentado personalmente (y limpiado) durante mis más de 20 años de experiencia provinieron de fallas a nivel de aplicación ynocualquier cosa conectada a SSH o SFTP. De hecho, la mayoría de los desarrolladores/administradores web nunca se enfrentarán a compromisos a nivel SSH/SFTP; Las fallas en el código frontal son el principal punto de entrada para muchos programas maliciosos e incursiones injustificadas en sistemas web públicos.
Y en tu caso afirmas lo siguiente:
Este era Ubuntu 14 y tenía 6 Apache VirtualHosts allí. Todos estaban en vivo.
Uno de mis sitios era una instalación de WordPress con un par de complementos.
Otro sitio tenía algún código API de Google Maps.
Supongo que, a menos que se mantenga actualizado sobre las actualizaciones/parches de WordPress, sus instalaciones de WordPress eran vulnerables. Y no sólo el núcleo de WordPress sino también los complementos.
Realice una copia de seguridad del código base, la base de datos y las configuraciones existentes.
Lo primero que haría es neutralizar los hosts virtuales de Apache quizás estableciendo un index.phpmensaje que diga "Inactivo por mantenimiento" en cada uno de los índices raíz de esos sitios. También haría una copia de cada instalación de host virtual a través de un archivo TAR/Gzip y la descargaría para posibles análisis forenses. Esto debe hacerse para todos los servidores virtuales Apache, incluidos los volcados de las bases de datos MySQL y los archivos de configuración relevantes.
Consulte el /tmp/directorio para detectar cualquier signo de infección; sóplelo si es necesario.
Lo siguiente que le recomendaría es volcar y volver a crear el /tmp/directorio en el servidor. La razón es que muchas infecciones de malware en servidores web Linux colocan una buena parte de su carga útil en el /tmp/directorio. voy a profundizar masen esta respuesta aquípero todo se reduce a hacer lo siguiente.
Entonces, primero, mire en el /tmp/directorio y vea si hay algo allí que no debería estar allí. 9 de cada 10 veces el malware en sistemas Linux podrá instalarse en formato /tmp/.
Si no está seguro de lo que debería o no debería estar allí, /tmp/hay algo fácil, pero extremo, que puede hacer para eliminar las cosas malas. Simplemente ejecute esto en línea en la línea de comando:
rm -rf /tmp && mkdir /tmp && chown root:root /tmp && chmod 1777 /tmp
O ejecute cada comando individualmente así:
sudo rm -rf /tmp
sudo mkdir /tmp
sudo chown root:root /tmp
sudo chmod 1777 /tmp
Luego reinicie el servidor para ver si eso aclara las cosas. Si es así, ¡felicidades! Pero aún no estás fuera de peligro, ya que cualquier cosa que haya causado el sistema original aún puede penetrar en tu sistema, es solo cuestión de tiempo antes de que te reinfecten nuevamente. Es decir, esto limpia el desorden causado por una debilidad en su sistema, pero necesita descubrir cuál podría ser ese punto débil y fortalecerlo.
Verificaciones de vulnerabilidad de Bash "shellshock".
Y en esa otra respuesta proporciono consejos sobre cómo comprobar la bashvulnerabilidad de "shock".Este sitio proporciona buenas herramientas de prueba.para ver si su servidor es vulnerable a bashexploits "shellshock". Honestamente, este ha sido uno de los agujeros de seguridad más comunes que he tenido que reparar desde que lo descubrí. Por lo tanto, es muy probable que esto también sea un punto débil en el servidor. En cuanto a cómo corregir bashvulnerabilidades si se encuentran, consulte la sección siguiente sobre cómo actualizar/parchear todos los componentes del nivel del sistema operativo. Haga eso y bashtambién debería actualizarse/parchearse.
Actualice/parchee todos los componentes a nivel del sistema operativo.
Ahora bien, eso puede parecer desalentador, pero la realidad es que se lanzan parches de seguridad todo el tiempo para los sistemas Linux. Y si está utilizando una instalación de Linux estandarizada como Ubuntu o CentOS, simplemente puede ejecutar una actualización/mejora a través del instalador de su paquete de esta manera. En Ubuntu simplemente haz esto:
sudo apt-get update
sudo apt-get upgrade
Ahora bien, si no ha actualizado el sistema por un tiempo, es posible que vea una gran cantidad de parches y actualizaciones que deben solucionarse. ¡No entrar en pánico! Eso es normal. Simplemente ejecuta updatey upgradeespera. Es posible que tengas que reiniciar después, pero cuando lo hagas, tu sistema operativo principal debería estar completamente parcheado y actualizado.
Evalúe la base de código de sus sistemas de código de servidor virtual Apache; Cosas de WordPress y API de Google.
Prepárate: esta es la parte más fea. Debes descargar y evaluar el código base que fuepotencialmenteinfectado. Con suerte, sólo uno o dos sitios se vieron comprometidos. La forma de hacerlo es idiosincrásica para cada configuración, pero generalmente lo que debe hacer es cargar cada sitio en un entorno de desarrollo, actualizar el núcleo de WordPress, actualizar los complementos, verificar si todo funciona bien y luego considerar que el código está limpio. /estable.
Ahora he simplificado enormemente este paso. Pero la realidad es que incluso después de realizar parches y actualizaciones, es posible que aún tenga código de malware en su núcleo de WordPress. Entonces, la otra cosa que puedes hacer es reconstruir cada sitio de WordPress desde cero. Mantenga las bases de datos, las plantillas y básicamente reconstruya el sitio a partir de un núcleo de WordPress nuevo y limpio.
Sí, eso parece mucho trabajo, pero si tiene tantos servidores virtuales con diferentes bases de código, no hay otra opción.
Asesoramiento post mortem.
Esto no funciona para todos, pero diré esto: las copias de seguridad y tal vez incluso un repositorio de GitHub para el código base limpio es el camino a seguir para limpiar el desorden sin el último paso de “evaluación” que he mencionado anteriormente.
Lo que hago es ejecutar volcados regulares de MySQL en cualquier sitio de unidad de base de datos en el que trabajo, y me aseguro de que haya una base de código central limpia en GitHub. Luego, si ocurre una infección de malware, puedo revisar las copias de seguridad de MySQL e incluso volver a implementar código limpio desde GitHub para asegurarme de que la base del código esté limpia. ¿Y si el servidor en sí está simplemente arruinado? Bueno, simplemente deshazte del sistema infectado, reconstruye un nuevo sistema Linux, implementa el código, importa las bases de datos, ajusta las configuraciones y termina el día.
Recuerde, el 99% de todos los sitios web son solo una base de datos, un código base y un conjunto de configuraciones. Si tiene alguna forma limpia de “congelar” o hacer una copia de seguridad del código no infectado y una copia de seguridad de las bases de datos MySQL, entonces todo lo que tiene que hacer es ocuparse de la configuración. Lo cual es un dolor menor en comparación con limpiar el código desde cero.