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.

Revise el monitor del sistema de mi server y efectivamente había un alto consumo de CPU, así que fui directo a los logs.

Efectivamente había alguien haciendo travesuras con mi servidor.

Decidí 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.

Por 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
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

#!/bin/bash
export LC_ALL=C bash

tHost="$(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=57
columnas_total=$(tput cols)

# Si la terminal es grande lo ponemos en dos columnas, si no en una sola
if [ $columnas_total -gt 99 ]
    then
        fila_CPU=5
    else
        fila_CPU=19
        columna_CPU=0
fi

tput 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 RAM
echo -e "\n[+] Listado de Procesos top10 consumo de RAM:\n"
# Encabezado
ps -A --sort=-rss --format pid,user,pmem,rss,comm | head -n 1
# Procesos
tput setaf 1 # Rojo
ps -A --sort=-rss --format pid,user,pmem,rss,comm | sed -n '2,6p'
tput setaf 3 # Amarillo
ps -A --sort=-rss --format pid,user,pmem,rss,comm | sed -n '7,9p'
tput setaf 2 # Verde
ps -A --sort=-rss --format pid,user,pmem,rss,comm | sed -n '10,11p'
tput sgr0 # Volver al color normal

# Columna CPU
tput cup $fila_CPU $columna_CPU; echo -e "[+] Listado de Procesos top10 consumo CPU:\n"
# Encabezado
tput cup $(($fila_CPU + 2)) $columna_CPU; ps -A --sort=-pcpu --format pid,user,pcpu,rss,comm | head -n 1
# Procesos
tput setaf 1 # Rojo
for (( 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"
done
tput setaf 3 # Amarillo
for (( 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"
done
tput setaf 2 # Verde
for (( 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"
done
tput 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 IP

113.37.83.34.bc.googleusercontent.com no 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.

Aquí tienes un desglose de los puntos clave para entender por qué ves esta actividad:

1. googleusercontent.com y los servicios de Google Cloud

• El dominio googleusercontent.com es utilizado por los clientes de Google para alojar contenido, no por los propios servicios internos de Google.
• La subsección bc.googleusercontent.com en 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.34 pertenece a un servidor virtual alquilado por un cliente de Google, no a la infraestructura principal de Google.

2. ¿Por qué se utiliza Google Cloud para atacar?

• 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.34 en 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.