Crónicas de DDoS: lidiar con XMLRPC Attack of WordPress Bots

Hace dos días enfrentamos dificultades con uno de nuestros clientes como un limitado nettted. Normalmente, no brindamos asistencia técnica a nuestros clientes, pero desafortunadamente, el servicio de alojamiento de nuestros clientes no brinda asistencia. Debido a que sentimos la responsabilidad de ayudarla, decidimos tomar medidas contra los ataques de botnet. Nos hemos enfrentado a extraños comportamientos de robot durante el ataque. Mencionaré lo que sucedió por hora en esta página y qué acciones hemos tomado para proteger el sitio web de nuestro cliente.
Contenido
El comienzo del ataque DDoS: el atacante identifica
Día 1-) Tomando la primera medida contra los ataques
Día 1-) Primera respuesta: Aproveche ser local
Día 1-) Servidores de nombres intercambiados y problemas con la configuración de CloudFlare
Día 2-) ¡Regresó! Omitido en la nube con botnet!
Día 2-) Bloquear el país en Cloudflare
Día 3-) La venganza es un plato mejor servido frío
El comienzo del ataque DDoS: el atacante se identifica porque soy el propietario de Nettted Limited, trabajo de 16 a 18 horas al día para apoyar a nuestros clientes. Tenemos diferentes clientes de todo el mundo, por lo que tengo que estar despierto diferentes momentos. El lunes más tarde, antes que nada, 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, solo una cosa invisible me golpeó y dijo “¡Oye! Tienes que mirar tu trabajo y luego dormir “. Y sí … esto es lo que pasó en mi ausencia de 5 horas en el trabajo:
Uno de mis clientes eliminó el complemento SEO, eliminó todas las descripciones y títulos del sitio.También rompió la estructura de los enlaces del sitio.La configuración de caché ha cambiado y todos los archivos .js y .css estaban rotos.
Uno de mis clientes estaba recibiendo un ataque DDoS y solo viendo cómo se derrumbó su sitio.
Cuando me uní a WhatsApp y Skype, vi muchas quejas en esas 5 horas.El 30% de las oraciones eran solo “¿Dónde estás?”.Mi cliente me dijo que tenía 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 atacaría.Suena estúpido, pero realmente lo hizo … cuando volví al trabajo, el ataque ya ha comenzado.
Día 1-) Tomar la primera medida contra los ataques son algunas revistas del ataque que recibí: 103.9.156.249 – – [07/abril/2019: 01: 19: 02 +0100] “get/http/1.0″ 200 73651 ” – “” WordPress/4.1.1 ;; verificación de pingback del 93.174.93.163 “199.223.214.148 – – [07/abril/2019: 01: 19: 03 +0100]” get/http/1.0 “200 13194” – “” “” WordPress/3.3.1; http://www.mentic.gr “216.240.176.141 – – [07/abr/2019: 01: 19: 02 +0100]” Get/http/1.0 “200 73651” – “” Word Press /4.0; 104.236.33.158 – – [07/abr/2019: 01: 19: 02 +0100] “get/http/1.0″ 200 73651 ” -” “WordPress/4.1.1; http://pmsearchpartners.com; Verificación de pingback desde 93.174.93.163 “149.210.236.96 – – [07/abr/2019: 01: 19: 02 +0100]” Get/http/1.0 “200 73651” – “” WordPress/3.9.27; http://imageconsultant.mu/; Verificación de pingback de 149.210.236.96 “185.87.249.33 – – [07/abr/2019: 01: 19: 02 +0100]” get/http/1.0 “200 73651” – “” WordPress/4.1; 158.69.26.84 – – [07/abr/2019: 01: 19: 02 +0100] “get/http/1.0″ 200 73651 ” -” “WordPress/3.9.2; http://teensystudios.com; verificar el retroceso de la vicebARA 93.174.93.163 “103.23.76.243 – – [07/abr/2019: 01: 19: 02 +0100]” get/http/1.0 “200 73651” – “” WordPress/4.1.26; http: //help.worldmart .in; verificar el pingback del 93.174.93.163 “203.175.180.254 – – [07/abril/2019: 01: 19: 02 +0100]” get/http/1.0 “200 73651” – “” WordPress/4.1; http ;: //www.cybertechriskcenter.com; verificación de pingback del 93.174.93.163 “199.223.214.148 – – [07/abr/2019: 01: 19: 03 +0100]” Get/http/1.0 “200 13194” – “”
“WordPress/3.3.1; http://www.mentalic.gr” 68.71.60.249 – – [07/abr/2019: 01: 19: 02 +0100] “get/http/1.0″ 200 73651 ” -” “” ” WordPress/4.1.26; http://www.itunesalternative.org; verificación de pingback del 93.174.93.163 “66.55.132.6 – – [07/abr/2019: 01: 19: 02 +0100]” get/http/1.0 ” 200 73651 ” -” “WordPress/3.8.16; 163.172.103.45 – – [07/abr/2019: 01: 19: 02 +0100]” Get/http/1.0 “200 73651” – “En los registros que puede ver que el ataque provino de los agentes de los usuarios de WordPress. Sin embargo, algunos de estos ataques también llegaron sin agentes. Verificamos todos esos sitios web mencionados y todos fueron sitios desactualizados y abandonados. Hay una IP que era casi la misma en todas las revistas y había aún 2. 93,174.93.163 fue una IP holandesa, pero creo que el servidor/alojamiento fue el que preparó el ataque de botnet. Otras 2 IP también fueron IP de los Países Bajos. Porque había demasiadas notificaciones para “verificar Pingback desde” On “On” On ” ataques, pensé para Derrotas pingbacks y xmlrpc.php por ataque.
Mi primera reacción a los ataques fue el cambio del nombre xmlrpc.php, luego eliminando en absoluto y eliminar Pingback de la configuración de WordPress.
Resultado: ni siquiera frenó los ataques. Debido a que no logré buenos resultados de los primeros movimientos, decidí eliminar el archivo xmlrpc.php al wordpress de los archivos. Sin embargo, no ha ayudado. Sin embargo, se ha demostrado que ayuda a una especie de ataques DDoS. Si también lo enfrentas, puedes probarlo. Día 1-) La primera respuesta: Aproveche ser local ahora me dirá por qué no usé CloudFlare. CF ha tomado tiempo para instalar y los cambios en el servidor de nombres a veces pueden ser muy dolorosos. Así que quería reducir la velocidad de los ataques, pero también configuré CloudFlare para el sitio. Los servidores de nombres han cambiado. El ataque fue grave y afectó seriamente el uso de E/S, el ancho, etc. Creo que hubo 2-3 personas atacando diferentes servidores. El sitio web de mi cliente gana $ 1000 diarios y fue un problema grave para él. El sitio se detuvo aproximadamente 6 horas. Como el sitio era local, decidí configurar un htaccess. Necesitaba todas las direcciones IP en Dinamarca. Con la ayuda de un sitio, logré encontrar todos los IP en Dinamarca. Cerraría temporalmente el sitio para todo el tráfico extranjero. Creé un archivo Htaccess y bloqueé todo el tráfico extranjero al sitio. Resultado: este es un buen resultado temporal. Todos los robots maliciosos ahora alcanzaron 403 páginas. De todos modos eres malo. Google Batti también tocó 403. Debido a que el tráfico de arranque era principalmente de los EE. UU., No establecí ninguna configuración para los IPS de EE. UU. O Google Bot. Debido a que esto fue temporal hasta que ocurren los cambios en el servidor de nombres, no fue un problema.
Durante todo el proceso hablé con mi cliente por teléfono y lo calmé. Estaba bastante molesta y molesta por la situación. Me dijo que recibió mensajes del atacante. ¡Tenía su número de teléfono! Día 1-) Servidores de nombres intercambiados y problemas con la configuración de flatización de la nube aproximadamente 2 horas después, cuando configuramos HTACcess, los servidores de nombre cambiaron y activaron CloudFlare. Se han eliminado las reglas de rechazo/permiso del archivo .htaccess. Sin embargo, hubo un problema con la configuración de WAF de CloudFlare. Le pedí a mi cliente que cambiara la IP del servidor y ella lo hizo. En algún lugar más tarde cambiaría los registros DNS de CloudFlare, porque la información de IP antigua todavía estaba allí. Sin embargo, si lo hiciera poco después de la compra de la IP, el sitio se habría detenido nuevamente. El “modo de ataque” ya estaba activo en el sitio. Resultado: después de activar CloudFlare, todos los ataques fueron detenidos. Después de las 6-7 horas de emoción, me levanté de la silla y dormí. Pensé que había ganado, pero aún no había terminado. Día 2-) ¡Regresó! Omitido en la nube con botnet! Cambié la IP por la mañana y como pensé que el sitio estaba asegurado, entré en el medio ambiente en el medio ambiente. Hice otros cambios en .htaccess. Compré Pro Cloudflare para mi cliente. Hemos configurado algunas configuraciones de WAF para que el sitio sea más seguro. Sin embargo, algún tiempo después, logró regresar con ataques más serios y se golpeó un número grave de ataques. Él pasó por alto Cloudflare.

Algunas configuraciones de WAF de Cloudflare prometieron detener los ataques BOT WordPress, el ataque XMLRPC, pero no lo fueron.Decidí configurar todas las configuraciones de WAF como implícitas en CloudFlare.Resultado: todos los ataques BOT que no tienen un agente de usuario comienzan a llegar a 403. El resultado ha dado un alivio por un tiempo, y el servidor se inició nuevamente.Sin embargo, estaba recibiendo demasiados ataques y estaba cerca de eso.Día 2-) Bloquear al país en la nube Finalmente, pensé que deberíamos invertir más en la nube para deshacerse de estos ataques.He eliminado casi el 50% de la amenaza con mis últimos cambios.Sin embargo, había otro 50%.Para un sitio web local, bloquear el país no sería un problema.Además, dado que solucionamos el 50% del tráfico BOT, los ataques estadounidenses no serían un problema grave para nosotros.Compré Cloudflala Enterprise y bloqueé todo el tráfico extranjero, excepto los Estados Unidos y Dinamarca.