Ya hace rato no publicaba sobre los logs de mi server. No es que falte material, pero lo que sucede parece rutinario ahora.
El Evento y los logs
Esta vez es curioso. Hoy al entrar en mi blog, no noté nada raro. De hecho, parecía estar mas fluido que de costumbre. Pero entré a mi server por SSH y… pos nada. Por pura coincidencia me llamó la atención un viejo Script que no recuerdo de donde lo saqué y que permitía ver la lista de los procesos que mas ocupan y lo ejecuté. PHP suele tener un alto consumo de RAM, pero no de CPU y hoy se marcaba un 23.9% en 3 procesos distintos.
Consumo de Recursos por PHP y MariadbRevise el monitor del sistema de mi server y efectivamente había un alto consumo de CPU, así que fui directo a los logs.
Alto consumo de CPU en el servidorEfectivamente había alguien haciendo travesuras con mi servidor.
IP 34.83.37.113 atacandoDecidí disparar primero y preguntar después así que le mande un bloqueo por IP
fail2ban-client set wordpress banip 34.83.37.113
Y visitar la pagina ipabusedb para consultar que novedades tenia.
IPAbusedb 34.83.37.113Por cierto, comparto el código. Admito que debí conservar su origen, pero si lo encuentro de nuevo, lo citaré.
1 2 3 4 5 6 7 8 910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061
#!/bin/bashexport LC_ALL=C bashtHost="$(hostname)"tTime="$(date +"%d/%m/%Y a las %H:%M:%S")"tMemTotal="$(free -mh | grep "Mem:" | awk '{print $2}')"tMemUsed="$(free -mh | grep "Mem:" | awk '{print $3}')"tMemFree="$(free -mh | grep "Mem:" | awk '{print $4}')"tLoadAverage="$(uptime | rev | cut -d ":" -f 1 | rev | cut -d " " -f 2-10)"columna_CPU=57columnas_total=$(tput cols)# Si la terminal es grande lo ponemos en dos columnas, si no en una solaif [ $columnas_total -gt 99 ] then fila_CPU=5 else fila_CPU=19 columna_CPU=0fitput clear # Borrado pantalla# Mostrar info printf "\n$tHost - $tTime"printf "\nRAM: $tMemUsed usados de $tMemTotal totales ($tMemFree M libres)\nCarga media de la CPU: $tLoadAverage\n"# Mostrar procesos que consumen RAMecho -e "\n[+] Listado de Procesos top10 consumo de RAM:\n"# Encabezadops -A --sort=-rss --format pid,user,pmem,rss,comm | head -n 1# Procesostput setaf 1 # Rojops -A --sort=-rss --format pid,user,pmem,rss,comm | sed -n '2,6p'tput setaf 3 # Amarillops -A --sort=-rss --format pid,user,pmem,rss,comm | sed -n '7,9p'tput setaf 2 # Verdeps -A --sort=-rss --format pid,user,pmem,rss,comm | sed -n '10,11p'tput sgr0 # Volver al color normal# Columna CPUtput cup $fila_CPU $columna_CPU; echo -e "[+] Listado de Procesos top10 consumo CPU:\n"# Encabezadotput cup $(($fila_CPU + 2)) $columna_CPU; ps -A --sort=-pcpu --format pid,user,pcpu,rss,comm | head -n 1# Procesostput setaf 1 # Rojofor (( i=2; i<=6; i++ ))do tput cup $(($i + $fila_CPU + 1)) $columna_CPU; ps -A --sort=-pcpu --format pid,user,pcpu,rss,comm | sed -n "$i,$i p"donetput setaf 3 # Amarillofor (( i=7; i<=9; i++ ))do tput cup $(($i + $fila_CPU + 1)) $columna_CPU; ps -A --sort=-pcpu --format pid,user,pcpu,rss,comm | sed -n "$i,$i p"donetput setaf 2 # Verdefor (( i=10; i<=11; i++ ))do tput cup $(($i + $fila_CPU + 1)) $columna_CPU; ps -A --sort=-pcpu --format pid,user,pcpu,rss,comm | sed -n "$i,$i p"donetput sgr0
Sobre lo sucedido
Claramente es un ataque de fuerza bruta contra xmlrpc.php por parte de esa IP que molestaba. No estoy muy seguro de que quería y al ver que abuseipdb decía que pertenecía a Google, lo obvio era concluir que era culpa de Google, pero le di la oportunidad de defenderse. Esto es lo que responde:
La IPAquí tienes un desglose de los puntos clave para entender por qué ves esta actividad:
113.37.83.34.bc.googleusercontent.comno significa que Google te esté atacando directamente, sino que alguien está utilizando los servicios de alojamiento en la nube de Google, como Google Cloud o Compute Engine, para atacar tu sitio. Es una práctica habitual que los atacantes utilicen servidores virtuales privados (VPS) o instancias de computación de grandes proveedores para enmascarar su origen.1.
googleusercontent.comy los servicios de Google Cloud2. ¿Por qué se utiliza Google Cloud para atacar?
- El dominio
googleusercontent.comes utilizado por los clientes de Google para alojar contenido, no por los propios servicios internos de Google.- La subsección
bc.googleusercontent.comen el nombre de host es una convención para las instancias de Compute Engine de Google que tienen una dirección IP pública.- Esto significa que la IP
113.37.83.34pertenece a un servidor virtual alquilado por un cliente de Google, no a la infraestructura principal de Google.
- Anonimato: Alquilar un servidor en un servicio de nube como Google Cloud permite a los atacantes ocultar su propia dirección IP real detrás de la IP del proveedor de servicios.
- Facilidad de uso: Las plataformas de nube ofrecen un acceso fácil y rápido para lanzar ataques, como los escaneos XML-RPC que has experimentado.
- Infraestructura robusta: Los atacantes aprovechan la sólida infraestructura de red de los proveedores de nube para asegurar que sus ataques sean efectivos.
3. ¿Por qué AbuseIPDB la asocia con Google?
- AbuseIPDB identifica a Google como el propietario del rango de IP, lo cual es correcto desde una perspectiva de registro. Google es el dueño de la infraestructura, pero no el responsable del uso malicioso.
- Las denuncias leves pueden deberse a que el atacante solo ha usado la IP por un corto período antes de ser detectado, o porque AbuseIPDB solo tiene reportes limitados de la actividad.
4. Qué puedes hacer:
- Bloquea la IP: Bloquea la dirección IP
113.37.83.34en tu cortafuegos o en la configuración de seguridad de tu sitio web para detener el escaneo inmediato.- Denuncia el abuso: Presenta una denuncia por abuso a Google Cloud Platform (GCP) para que tomen medidas contra el cliente que está utilizando su infraestructura para atacar tu sitio. Ellos tienen políticas estrictas contra el uso indebido.
- Protege la API XML-RPC: La API XML-RPC es conocida por ser un vector de ataque frecuente. Si no la utilizas, desactívala completamente. Si la necesitas, usa un Plugin que la proteja, la limite o la restrinja para evitar futuros ataques.
Conclusiones
Se mandó casi 2 horas de ataque hasta que me di cuenta y aun así algo sigue ocupando el CPU de mi servidor. Creo que no uso XMLRPC en nada, así que voy a deshabilitarlo. Por otro lado, me parece súper curioso como es que tengo al menos 1 llamada por segundo a mi servidor y aun así, el trafico orgánico es bajísimo. Le tengo dudas hasta a lo que mis estadísticas dicen que es trafico orgánico.
https://interlan.ec/2025/10/15/revisando-los-logs-de-mi-server-xmlrpc-php/
#Blog #devops #seguridad #seguridadInformática #servidores #vps #wordpress
