Un ataque de denegación de servicio (DoS, o DDoS si viene de muchas máquinas a la vez) busca una sola cosa: que tu sitio deje de responder. No roba datos ni instala nada; simplemente lo satura con peticiones hasta que el servidor no da abasto.
En WordPress, los ataques más comunes no son los gigantescos que salen en las noticias, sino otros más modestos pero muy efectivos: miles de peticiones a las páginas que más le cuestan al servidor.
Las páginas que más duelen
Una página en caché le cuesta casi nada a tu servidor. Las que lo hacen trabajar de verdad son las que no se pueden cachear:
- El buscador (
/?s=...): cada búsqueda consulta la base de datos. - El login (
wp-login.php) y XML-RPC (xmlrpc.php). - El carrito y el pago de WooCommerce.
admin-ajax.phpy la API REST.- Los filtros de productos, que generan combinaciones casi infinitas.
Cómo reconocerlo
- El hosting te avisa de uso excesivo de CPU o de «procesos de entrada» (en cPanel con CloudLinux aparece como límite de EP o NPROC alcanzado).
- El sitio responde lento o con error 503 o 508.
- En los registros de acceso aparecen miles de peticiones parecidas en pocos minutos.
Por SSH, para ver qué está pasando en el registro de hoy:
# Las 10 IPs que más peticiones hicieron
awk '{print $1}' ~/access-logs/tudominio.cl-ssl_log | sort | uniq -c | sort -rn | head -10
# Las 10 URLs más pedidas
awk '{print $7}' ~/access-logs/tudominio.cl-ssl_log | sort | uniq -c | sort -rn | head -10Si una sola URL (como el buscador) o unas pocas IPs concentran la mayor parte del tráfico, ahí está el ataque.
Qué hacer en el momento
- Si tienes Cloudflare, activa el modo Under Attack (Bajo ataque) en el panel. Muestra un desafío de pocos segundos a cada visitante nuevo y detiene a casi todos los robots. Desactívalo cuando pase.
- Si el ataque va a una URL concreta, bloquéala o desafíala con una regla (ver más abajo).
- Si viene de pocas IPs, bloquéalas en el cortafuegos del servidor o en Cloudflare.
- Avisa a tu hosting. Muchos tienen protección a nivel de red y pueden ayudarte.
Si no tienes Cloudflare ni nada parecido delante del sitio, durante un ataque grande tu margen de acción es muy pequeño: todo el tráfico llega directo a tu servidor. Es la principal razón para prepararse antes.
Prepararte: reglas en Cloudflare
En Seguridad → Reglas de WAF → Reglas personalizadas, estas tres cubren la mayoría de los ataques a WordPress:
# 1. Desafío al login y a XML-RPC (acción: Desafío administrado)
(http.request.uri.path eq "/wp-login.php") or (http.request.uri.path eq "/xmlrpc.php")
# 2. Bloqueo de XML-RPC si no lo usas (acción: Bloquear)
(http.request.uri.path eq "/xmlrpc.php")
# 3. Desafío a búsquedas desde fuera de tu país (acción: Desafío administrado)
(any(http.request.uri.args.names[*] == "s")) and (ip.geoip.country ne "CL")Y en Reglas de limitación de velocidad, una para el buscador: por ejemplo, más de 20 búsquedas por minuto desde la misma IP recibe un desafío.
Prepararte: en WordPress
- Caché de página para todo lo que se pueda: lo cacheado aguanta mucho más.
- Desactiva XML-RPC si no usas la app móvil ni Jetpack.
- Limita la longitud de las búsquedas para frenar búsquedas basura que fuerzan consultas pesadas:
add_action( 'pre_get_posts', function ( $query ) {
if ( ! is_admin() && $query->is_main_query() && $query->is_search() ) {
$termino = (string) $query->get( 's' );
if ( mb_strlen( $termino ) > 60 ) {
wp_die( 'Búsqueda demasiado larga.', '', array( 'response' => 400 ) );
}
}
} );Prepararte: en tu VPS
Si administras tu propio servidor con cPanel, revisa que CSF (el cortafuegos) tenga activa la protección de conexiones por IP (CT_LIMIT) y que cPHulk esté encendido. No reemplazan a Cloudflare ante un ataque grande, pero detienen los pequeños sin que tengas que intervenir.
¿Tu sitio se cayó y sospechas un ataque? Comparte en el foro el resultado de los dos comandos de arriba (puedes ocultar las IPs) y te ayudamos a interpretarlo.
