Imagina una empresa cerrada durante la noche.
Las luces están apagadas. No hay empleados. Desde fuera parece que no ocurre absolutamente nada.
Pero, mientras tanto, alguien está intentando entrar.
Primero prueba la puerta principal.
Está cerrada.
Después camina hasta la parte trasera del edificio y mueve el picaporte de la puerta de servicio.
También está cerrada.
Prueba una ventana.
Después otra.
Encuentra un pequeño ventanuco del almacén y comprueba si puede abrirlo.
Finalmente llega hasta la entrada utilizada por proveedores y vuelve a intentarlo.
No rompe nada.
No dispara ninguna alarma.
No hace suficiente ruido como para que alguien llame a la policía.
Simplemente está buscando una entrada.
Y si pensamos en la seguridad de WordPress, esta analogía se aproxima bastante a lo que ocurre todos los días en Internet.
Los bots no siempre intentan entrar por la puerta principal
Cuando hablamos de ataques contra WordPress, muchas personas piensan inmediatamente en el login.
Y tiene sentido.
Podemos imaginar:
wp-login.php = la puerta principal de la empresa.
Es una entrada evidente.
El atacante sabe que existe y puede intentar diferentes nombres de usuario y contraseñas esperando encontrar una combinación válida.
Pero proteger únicamente esa puerta sería como instalar una cerradura extraordinaria en la recepción de una empresa y olvidarnos de todas las demás entradas del edificio.
Porque WordPress tiene muchas formas de comunicarse con el exterior.
Y los bots las conocen.
wp-login.php: la puerta principal
/wp-login.php es probablemente la entrada más fácil de comprender.
Es donde normalmente accedemos al área administrativa de WordPress.
Los bots también saben dónde está.
Por eso existen automatizaciones que recorren miles de sitios WordPress intentando combinaciones como:
- admin + contraseña;
- nombres de usuarios descubiertos previamente;
- contraseñas procedentes de filtraciones;
- variaciones de contraseñas comunes;
- credenciales utilizadas anteriormente en otros servicios.
Es como encontrar a alguien todas las noches probando diferentes llaves en la puerta principal.
Un intento aislado puede no significar absolutamente nada.
Miles de intentos ya cuentan otra historia.
XML-RPC: la antigua puerta de servicio
Ahora imaginemos que nuestro intruso descubre que la puerta principal está muy protegida.
Entonces rodea el edificio.
En la parte trasera encuentra otra puerta.
En WordPress podríamos utilizar xmlrpc.php como analogía.
XML-RPC permite determinadas comunicaciones remotas con WordPress y puede ser utilizado legítimamente por algunos servicios.
El problema es que los atacantes también conocen su existencia.
Si esa funcionalidad está disponible, un sistema automatizado puede probarla.
Es exactamente lo que haría alguien intentando entrar en una empresa:
si la entrada principal está protegida, busca otra entrada.
Por eso la pregunta de seguridad no debería ser solamente:
¿Mi login está protegido?
También deberíamos preguntarnos:
¿Qué otras formas de comunicación con el exterior tiene mi WordPress?
REST API: la entrada utilizada por proveedores
Una empresa moderna no puede funcionar completamente aislada.
Tiene empleados, proveedores, transportistas, técnicos y servicios externos que necesitan comunicarse con ella.
WordPress tampoco.
La REST API permite que WordPress intercambie información con aplicaciones, plugins y otros sistemas.
Podemos imaginarla como una entrada específica para proveedores autorizados.
El problema no es que esa puerta exista.
El problema aparece cuando nadie controla quién está llamando, con qué frecuencia y qué está intentando solicitar.
Un bot puede realizar peticiones repetitivas contra determinados endpoints de la REST API.
Eso no significa que debamos bloquear completamente /wp-json/.
Sería parecido a soldar la puerta de proveedores porque una persona sospechosa intentó utilizarla.
Probablemente terminaríamos perjudicando el funcionamiento normal de la empresa.
La estrategia correcta es entender qué actividad es legítima y cuál resulta anómala.
admin-ajax.php: la ventanilla que necesita permanecer funcionando
WordPress y muchos plugins utilizan admin-ajax.php para ejecutar acciones dinámicas.
Aunque su nombre incluya “admin”, puede intervenir también en funcionalidades utilizadas desde la parte pública de una web.
Filtros.
Buscadores.
Formularios.
Carritos.
Plugins.
Acciones dinámicas.
Podemos imaginarlo como una pequeña ventanilla de atención que necesita permanecer disponible porque determinados procesos de la empresa dependen de ella.
Ahora imaginemos a alguien pulsando el timbre de esa ventanilla cientos de veces por minuto.
No ha entrado en el edificio.
No ha robado nada.
Pero está obligando continuamente a alguien dentro de la empresa a responder.
En un servidor sucede algo parecido.
Cada solicitud puede implicar ejecución de PHP, consultas a la base de datos y consumo de CPU.
Por eso un ataque no necesita conseguir acceso administrativo para generar un problema.
A veces basta con obligar al servidor a trabajar continuamente.
El checkout de WooCommerce: la caja de la empresa
Si tenemos WooCommerce aparece otra entrada muy interesante para los bots.
El checkout.
Podemos imaginarlo como la caja de una tienda.
Está diseñada para recibir clientes y, necesariamente, debe permanecer disponible.
Pero ahora imaginemos a una persona que entra continuamente en la tienda, llena un carrito, llega hasta la caja, proporciona datos falsos y se marcha.
Después vuelve.
Y vuelve.
Y vuelve otra vez.
Con diferentes nombres.
Diferentes emails.
Diferentes teléfonos.
Eso puede ocurrir de forma automatizada en WooCommerce.
El resultado puede ser:
- pedidos falsos;
- intentos de pago;
- emails innecesarios;
- registros de clientes;
- carga sobre PHP y base de datos;
- logs llenos de eventos;
- ruido operacional.
Nadie ha “hackeado” necesariamente la tienda.
Pero alguien está abusando de una funcionalidad legítima.
Los formularios son como el buzón de la puerta
Hay otra posibilidad todavía más sencilla.
El formulario de contacto.
Es nuestro buzón.
Está precisamente ahí para que cualquier persona pueda dejarnos un mensaje.
Pero un bot puede empezar a introducir cientos de mensajes automáticamente.
Publicidad.
Enlaces.
Emails falsos.
Contenido generado automáticamente.
El problema vuelve a ser el mismo:
una funcionalidad legítima está siendo utilizada de una manera para la que no fue diseñada.
El registro de usuarios: recepción entregando acreditaciones
Imaginemos ahora una empresa donde los visitantes pueden solicitar una acreditación en recepción.
Una persona llega.
Se identifica.
Recibe su tarjeta.
Perfecto.
Pero de repente llegan 500 solicitudes durante la madrugada.
Juan123.
John8492.
Test92831.
Emails extraños.
Dominios desconocidos.
Usuarios que se registran y nunca vuelven.
Es bastante probable que no tengamos 500 nuevos clientes.
Tenemos automatización.
El registro de usuarios de WordPress y WooCommerce puede convertirse en otro objetivo porque está diseñado precisamente para aceptar información desde el exterior.
El atacante no necesita saber qué hay detrás de cada puerta
Aquí aparece una característica importante de los bots.
Muchas veces no existe una persona sentada delante de un ordenador analizando específicamente nuestra web.
Es software.
El programa encuentra un dominio.
Detecta WordPress.
Y empieza a probar.
¿Existe wp-login.php?
Prueba.
¿Responde xmlrpc.php?
Prueba.
¿Existe /wp-json/?
Consulta.
¿Hay formularios?
Los envía.
¿Existe registro?
Intenta crear usuarios.
¿Hay WooCommerce?
Busca endpoints relacionados con la tienda.
Todo puede ocurrir automáticamente.
Nuestra empresa imaginaria puede tener decenas de personas probando puertas y ventanas durante la noche sin que ninguna de ellas sepa siquiera qué empresa funciona dentro del edificio.
Solo están buscando una entrada abierta.
Y muchas veces nadie quiere entrar: simplemente quieren molestarte
Existe además otra diferencia importante.
No todo ataque busca conseguir acceso administrativo.
Volvamos al edificio.
Un grupo de personas podría no conseguir abrir ninguna puerta.
Pero podría colocar a cien personas delante de la recepción tocando el timbre continuamente.
La puerta permanece cerrada.
Nadie entra.
Pero el personal de seguridad necesita atender continuamente esos intentos.
En un servidor web ocurre algo similar con el flood.
Miles de peticiones pueden consumir:
- CPU;
- memoria;
- procesos PHP;
- conexiones;
- consultas a la base de datos;
- recursos de WooCommerce.
La web puede empezar a funcionar lentamente incluso sin existir una vulnerabilidad explotada.
Por eso seguridad y rendimiento están más relacionados de lo que parece.
Tener una buena cerradura no significa tener un edificio seguro
Esta es probablemente la parte más importante de la analogía.
Podemos tener:
- una contraseña extraordinaria;
- autenticación en dos pasos;
- el usuario “admin” eliminado;
- el login protegido.
Perfecto.
Tenemos una excelente puerta principal.
Pero todavía debemos mirar las ventanas.
La puerta trasera.
La entrada de proveedores.
El almacén.
La recepción.
El buzón.
Y quién está caminando alrededor del edificio todas las noches.
En WordPress eso significa analizar no solamente malware y contraseñas, sino también:
- login;
- XML-RPC;
- REST API;
- AJAX;
- formularios;
- registro de usuarios;
- checkout;
- comentarios;
- plugins instalados;
- usuarios;
- logs;
- actividad repetitiva.
Por eso un análisis de seguridad WordPress debería observar el edificio completo y no limitarse a comprobar si existe malware o si la puerta principal tiene una buena contraseña.
La solución tampoco consiste en tapiar todas las ventanas
Podríamos resolver el problema de seguridad de nuestra empresa tapiando todas las ventanas, eliminando la puerta trasera y prohibiendo la entrada a cualquier persona.
Sería muy segura.
También sería bastante difícil trabajar dentro de ella.
En WordPress ocurre exactamente lo mismo.
Bloquear indiscriminadamente REST API, AJAX, XML-RPC, formularios o determinadas peticiones puede romper funcionalidades legítimas.
WooCommerce necesita comunicarse.
Los plugins necesitan ejecutar procesos.
Los clientes necesitan comprar.
Los formularios necesitan recibir información.
Las APIs pueden necesitar conectarse con servicios externos.
Por eso una buena protección necesita distinguir entre:
alguien utilizando una puerta
y
alguien probando esa puerta 500 veces.
Un vigilante no mira solamente quién entra
Imaginemos ahora que contratamos seguridad para nuestra empresa.
Un buen vigilante no bloquea automáticamente a todas las personas que se acercan.
Observa comportamiento.
Una persona llega a recepción, habla con alguien y entra.
Normal.
Otra persona intenta abrir cinco ventanas, después prueba la puerta trasera y finalmente empieza a manipular la cerradura principal.
Sospechoso.
En seguridad informática podemos aplicar una lógica similar.
Podemos observar señales como:
- dirección IP;
- User-Agent;
- frecuencia de peticiones;
- número de intentos;
- usuarios inexistentes;
- emails sospechosos;
- dominios de email;
- teléfonos;
- acciones repetitivas;
- endpoints utilizados;
- reincidencia.
Una señal aislada puede no justificar un bloqueo.
Varias señales combinadas pueden contar una historia completamente diferente.
Huuguu Flood Blocker: vigilar el comportamiento alrededor del edificio
Esta idea de observar patrones de comportamiento es precisamente una de las bases de Huuguu Flood Blocker.
El objetivo no es convertir WordPress en una fortaleza donde nada funciona.
Es añadir una capa de control sobre áreas sensibles y detectar comportamientos repetitivos relacionados con flood, bots, spam y abuso automatizado.
Entre otros puntos, puede trabajar sobre login, XML-RPC, REST API, registros, checkout de WooCommerce, comentarios y diferentes señales relacionadas con usuarios o accesos sospechosos.
Porque el problema no siempre es una puerta abierta.
A veces el problema son cientos de manos probando continuamente todas las puertas del edificio.
Mientras tú duermes, Internet continúa probando las puertas
Tu empresa puede cerrar a las 19:00.
Internet no.
Un WordPress conectado a Internet está disponible las 24 horas del día.
También a las 02:17.
A las 03:42.
A las 05:11.
Mientras tú duermes, los buscadores continúan visitándolo.
Los clientes pueden continuar navegando.
Los servicios externos continúan comunicándose.
Y los bots también continúan trabajando.
Algunos son legítimos.
Otros buscan información.
Otros generan spam.
Otros buscan vulnerabilidades conocidas.
Y otros simplemente recorren millones de dominios probando puertas, ventanas y pequeños accesos.
Por eso la pregunta correcta no es:
“¿Alguien está intentando entrar en mi WordPress?”
En una web pública, probablemente alguien o algo lo intentará tarde o temprano.
La pregunta realmente importante es:
“Si alguien prueba todas las puertas de mi WordPress esta noche, ¿voy a saberlo y qué ocurrirá cuando lo haga?”
