Crónicas de DDOS: cómo lidiar con el ataque XMLRPC de los bots de WordPress

Hace dos días nos enfrentamos a dificultades con el sitio web de uno de nuestros clientes como Nettsted Limited. Normalmente no brindamos soporte técnico a nuestros clientes, pero desafortunadamente el servicio de alojamiento de nuestro cliente no le brinda ningún soporte. Como sentimos la responsabilidad de ayudarla, decidimos tomar medidas contra los ataques de Botnet . Nos enfrentamos a comportamientos extraños de bots durante el ataque. Voy a comentar lo que pasó hora a hora en esta página y las acciones que hemos realizado para proteger el sitio web de nuestro cliente.

El comienzo del ataque DDOS: el atacante se identifica a sí mismo

Como soy propietario de Nettsted Limited, trabajo de 16 a 18 horas al día para brindar asistencia a nuestros clientes. Tenemos diferentes clientes de todo el mundo, por lo que necesito estar despierto en diferentes zonas horarias. Durante meses después, primero quería ver una película y divertirme con mi familia. Desafortunadamente, este fue uno de los peores días de mi carrera. Después de la película, decidimos descansar. Sin embargo, una cosa invisible me empujó y me dijo “¡oye! tienes que echar un vistazo a tus obras y luego dormir”. Y si… Esto fue lo que pasó en mis 5 horas de ausencia en el trabajo:

1. Uno de mis clientes eliminó el complemento SEO, eliminó todas las descripciones y títulos del sitio web. También rompió la estructura de enlaces del sitio web.
2. El otro cliente eliminó algunos complementos que instalamos que están relacionados con SEO. Cambió la configuración de los cachés y, de alguna manera, todos los archivos .js y .css se rompieron.
3. Uno de mis clientes estaba recibiendo un ataque DDOS y solo estaba viendo cómo se desmoronaba su sitio web.

Cuando me uní a WhatsApp y Skype, vi muchas quejas por esas 5 horas. El 30% de las oraciones fueron simplemente "¿Dónde estás?".

Mi cliente me ha dicho que le ha llegado un mensaje a través de WhatsApp. El atacante se identificó con el número de teléfono y le dijo a mi cliente que la iba a atacar. Esto realmente suena estúpido pero realmente lo hizo… Cuando regresé al trabajo, el ataque ya había comenzado.

Día 1-) Tomar la primera acción contra los ataques

Estos son algunos registros del ataque que recibimos:

103.9.156.249 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1.1; ; verifying pingback from 93.174.93.163"
199.223.214.148 - - [07/Apr/2019:01:19:03 +0100] "GET / HTTP/1.0" 200 13194 "-" "WordPress/3.3.1; http://www.mentalic.gr"
216.240.176.141 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.0;
104.236.33.158 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1.1; http://pmsearchpartners.com; verifying pingback from 93.174.93.163"
149.210.236.96 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/3.9.27; http://imageconsultant.mu/; verifying pingback from 149.210.236.96"
185.87.249.33 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1;
158.69.26.84 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/3.9.2; http://teensystudios.com; verifying pingback from 93.174.93.163"
103.233.76.243 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1.26; http://help.worldmart.in; verifying pingback from 93.174.93.163"
203.175.180.254 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1.1; http://www.cybertechriskcenter.com; verifying pingback from 93.174.93.163"
199.223.214.148 - - [07/Apr/2019:01:19:03 +0100] "GET / HTTP/1.0" 200 13194 "-" "WordPress/3.3.1; http://www.mentalic.gr"
68.71.60.249 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/4.1.26; http://www.itunesalternative.org; verifying pingback from 93.174.93.163"
66.55.132.6 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-" "WordPress/3.8.16;
163.172.103.45 - - [07/Apr/2019:01:19:02 +0100] "GET / HTTP/1.0" 200 73651 "-"


En los registros puede ver que el ataque provenía de los agentes de usuario de WordPress. Sin embargo, algunos de esos ataques también venían sin agentes. Revisé todos esos sitios web referidos y todos eran sitios web obsoletos y abandonados. Hay una IP que era casi la misma en todos los registros y había otras 2. 93.174.93.163 era una IP de los Países Bajos, pero creo que fue el servidor/alojamiento el que nos estaba preparando un ataque de botnet. Otros 2 IP también eran IP de los Países Bajos.

Dado que había demasiadas notificaciones de "verificación de pingback desde" en los ataques, pensé que estaba usando pingbacks y xmlrpc.php para atacar.

Mi primera reacción a los ataques fue cambiar el nombre de xmlrpc.php, luego eliminarlo y eliminar los pingbacks de la configuración de WordPress .

Resultado : ni siquiera ralentizó los ataques.

Como no obtuve buenos resultados con los primeros movimientos, decidí eliminar el archivo xmlrpc.php de WordPress de los archivos. Sin embargo, todavía no ayudó.

Sin embargo, ha demostrado que ayuda en algunos tipos de ataques DDOS. Si también te enfrentas a eso, también puedes probarlo.

Día 1-) Primera respuesta: Aproveche el hecho de ser local

Ahora me vas a decir por qué no usé cloudflare. CF estaba tomando tiempo para configurar y los cambios en el servidor de nombres pueden ser realmente molestos a veces. Así que quería ralentizar los ataques, pero también configuré cloudflare para el sitio web. Cambió los servidores de nombres. El ataque fue serio y dañó gravemente el uso de E/S, el ancho de banda, etc. Creo que eran 2-3 personas que atacaban desde diferentes servidores. El sitio web de mi cliente ganaba 1000 $ diarios y era un problema grave para él. El sitio estuvo inactivo alrededor de 6 horas.

Como el sitio era local, decidí configurar un htaccess. Necesitaba todas las direcciones IP de Dinamarca. con la ayuda de un sitio web me las arreglo para encontrar todas las direcciones IP de Dinamarca. Cerraría el sitio web a todo el tráfico extranjero temporalmente. Creé un archivo htaccess y bloqueé todo el tráfico extranjero al sitio web .

Resultado : este es un buen resultado temporal. Todos los bots maliciosos estaban llegando a 403 páginas ahora. Sin embargo, malas noticias. Los bots de Google también estaban llegando a 403. Dado que el tráfico de bots provenía principalmente de EE. UU., no hice ninguna configuración para EE. UU. o las IP de bots de Google. Dado que esto era temporal hasta que se realizaran cambios en el servidor de nombres, no fue un problema.

Durante todo el proceso estuve hablando con mi cliente por teléfono y calmándola. Estaba bastante enojada y molesta por la situación. Me dijo que recibió mensajes del atacante. ¡Ella tenía su número de teléfono!

Día 1-) Servidores de nombres cambiados y problemas con la configuración de Cloudflare

Aproximadamente 2 horas después de configurar htaccess, los servidores de nombres cambiaron y activé cloudflare. Se eliminaron las reglas de denegación/permisión del archivo .htaccess. Sin embargo, hubo un problema con la configuración WAF de Cloudflare. Le pedí a mi cliente que cambiara la IP del servidor y lo hizo. Algún tiempo después, cambiaría los registros DNS de cloudflare ya que la información IP antigua todavía estaba allí. Sin embargo, si lo hiciera poco después de comprar la IP, el sitio volvería a estar inactivo. El “Modo Bajo Ataque” ya estaba activo en el sitio web.

Resultado : después de que activamos Cloudflare, todos los ataques se detuvieron.

Después de 6-7 horas de emoción, me levanté de la silla y me fui a dormir. Pensamos que habíamos ganado, pero aún no ha terminado.

Día 2-) ¡Regresó! ¡Omitido a Cloudflare con Botnet!

Hemos cambiado la IP por la mañana y como pensé que el sitio web era seguro, cambié el modo de ataque a medio. Hice algunos otros cambios en .htaccess. Compré PRO cloudflare para mi cliente. Configuré algunas configuraciones de WAF para hacer que el sitio web sea más seguro. Sin embargo, algún tiempo después, logró regresar con ataques más serios y una gran cantidad de ataques estaban llegando al origen. Estaba pasando por encima de Cloudflare.

Algunas configuraciones WAF de Cloudflare prometían detener los ataques de bots de WordPress, XMLRPC Attack, pero no lo fueron . Decidí configurar todas las configuraciones de WAF como predeterminadas en Cloudflare.

Resultado : todos los ataques de bot que no tienen un agente de usuario comienzan a llegar a 403.

El resultado le dio un alivio al sitio web por un tiempo y el servidor estuvo activo una vez más. Sin embargo, estábamos recibiendo demasiados ataques y estuvo cerca.

Día 2-) Bloqueo de países en Cloudflare

Finalmente, pensé que deberíamos invertir más en Cloudflare para deshacernos de esos ataques. Casi hemos eliminado el 50% de la amenaza con mis últimos cambios. Sin embargo, todavía había otro 50%. Para un sitio web local, el bloqueo del país no sería un problema. Además, dado que hemos solucionado el 50% del tráfico de bots, los ataques desde EE. UU. no serían un problema grave para nosotros. Compramos la empresa Cloudflare y bloqueamos todo el tráfico extranjero excepto de EE. UU. y Dinamarca .

Resultado : esto arregló el 90% del tráfico de botnet.

Día 3-) La venganza es un plato que se sirve frío

Nuestro servidor podría gestionar el 90 % del tráfico de botnets. Sin embargo, no han detenido sus ataques. Entonces encontré un complemento interesante en WordPress. Sin embargo, tenía que probarlo primero. De lo contrario, el sitio web podría dejar de funcionar y eso arruinará las cosas. Le pedí a un amigo programador que atacara uno de mis sitios web. Estaba funcionando perfectamente. Entonces investigo sobre el atacante. Entiendo quién es y por qué nos ataca.

Me puse en contacto con el atacante primero. Le pedí que detuviera sus ataques. Sin embargo, me respondió con muchos insultos y palabrotas. Simplemente lo bloqueé de WhatsApp y ni siquiera le respondí. Mi cliente me pidió que pagara más por este servicio pero lo negué. Me lo estaba tomando como una cuestión de orgullo. Le pedí permiso a mi cliente y eliminé el modo de ataque. Configuré el complemento.

Empecé a enviar sus desagradables, malditos y viles bots de regreso a su sitio web. Su sitio web se derrumbó frente a mis ojos. Lo que sentí fue lo mismo con Cersei, que estaba viendo la destrucción del Sept de Baelor. Luego les envié su otro sitio web y luego otro y luego otro... Cuando detuvieron el ataque, el sistema se estaba deteniendo. Sin embargo, cuando comenzaron a atacar a los bots, los estaban redirigiendo a todos sus sitios web.