Proteger un clúster de servidores con ReportedIP: agente, grupos y DNSBL
Para proteger un clúster de servidores con ReportedIP, ejecuta el ReportedIP Linux Agent en cada nodo Linux y pon sus claves API en un grupo: cada nodo mantiene entonces la blacklist de la comunidad en su cortafuegos del kernel y descarta cualquier dirección que otro nodo haya notificado. Los relés de correo pueden añadir la DNS / RBL Zone dentro del diálogo SMTP, y los hosts que no pueden ejecutar el agente obtienen los mismos datos como feed o a través de la API.
Cuando este artículo se publicó en mayo de 2026, una zona DNS era la única capa compartida para todo un clúster. Desde septiembre de 2026, el agente y los grupos cubren la mayoría de los nodos, y la zona sigue siendo la herramienta adecuada para filtros de correo y appliances.
¿Qué pieza de ReportedIP encaja en cada nivel de un clúster?
Un clúster rara vez tiene un solo tipo de máquina. La tabla asigna a los niveles habituales la parte de ReportedIP que les corresponde. Todos leen de la misma base de datos comunitaria de direcciones atacantes puntuadas.
| Nivel del clúster | Qué lo protege | Cómo lee los datos |
|---|---|---|
| Hosts Linux web, de aplicación y de base de datos | Linux Agent | Sets del kernel |
| Relés de correo | Linux Agent y DNS / RBL Zone | Sets del kernel y consultas DNSBL |
| Frontales WordPress | Plugin Hive | Bloqueos locales y la lista del grupo |
| Appliances y cortafuegos en la nube | Blacklist Feed | Exportación programada |
| Backends de aplicación y de API | API REST | Consulta de puntuación por petición |
| Nodos señuelo | Honeypot Server | Solo notificaciones |
Como cada nivel lee las mismas puntuaciones, un atacante notificado por un honeypot o un sitio WordPress queda descartado en tu borde y en tus relés de correo en cuanto su puntuación lo permite. Devolver lo que ven tus propios nodos es lo que mantiene exactos esos datos compartidos para todos.
¿Cómo protege el Linux Agent cada nodo?
El agente es un único binario estático para linux/amd64 y linux/arm64, en la versión 0.3.38 a 28 de septiembre de 2026. Hace tres trabajos en cada host:
- Carga la blacklist de la comunidad en ipset o nftables como cinco listas, una por servicio expuesto: ssh, mail, web, ftp y edge. Cada lista solo actúa en los puertos de su servicio, así que una entrada de la lista web nunca toca SSH.
- Lee los logs que el host ya escribe, catorce tipos de fuente desde sshd hasta Postfix, Dovecot y el servidor web, y notifica una dirección en cuanto supera el umbral de esa fuente. Ninguna línea de log, ningún nombre de usuario y ninguna URL salen de la máquina.
- Bloquea lo que ha encontrado por sí mismo, con una duración que crece para los reincidentes. Un host que solo debe notificar puede desactivar el bloqueo local.
En un servidor con licencia, el feed se actualiza cada 15 minutos a partir de Professional. Sin licencia solo se pausa la descarga del feed: la lista que ya está en el kernel se queda, y la detección, el bloqueo local y las notificaciones siguen funcionando. El agente sustituye al script de sincronización escrito a mano y toma el relevo de fail2ban; los requisitos y la instalación rápida están en la documentación del Linux Agent.
Cada servidor necesita una licencia, contada por instalación
Las licencias de servidor son un grupo propio y se cuentan aparte de los dominios de Hive. Un host se identifica por el ID de instalación aleatorio que crea el agente, nunca por su nombre de host ni por su clave. Rotar una clave o renombrar una máquina no gasta una segunda licencia. Cuando una cuenta tiene más agentes que licencias, los hosts más antiguos conservan la suya.
| Plan | Servidores incluidos | Grupos | Claves por grupo |
|---|---|---|---|
| Professional | 1 | 1 | 10 |
| Business | 3 | 3 | 50 |
| Enterprise | Según contrato | 100 | 500 |
Cada servidor adicional cuesta 4,90 € al mes con IVA incluido y baja a 1,40 € a partir de 50 licencias; la escala completa está en la página de licencias de servidor. Las cuentas Free y Contributor pueden ejecutar el agente como notificador con bloqueo local completo, pero no pueden contratar una licencia ni crear un grupo.
¿Cómo compartes un bloqueo entre todos los nodos?
Pon las claves API de tus nodos en un grupo de tu cuenta de reportedip.com. Cuando un miembro notifica una dirección, todos los demás miembros la bloquean durante la ventana de bloqueo del grupo, 24 horas por defecto, en todos los puertos. El agente guarda esa lista en un sexto set del kernel llamado group. Los sitios WordPress con Hive pueden unirse al mismo grupo y reflejar la lista como un tipo de bloqueo propio.
En un clúster importan dos detalles. La dirección desde la que notifica un miembro nunca está en la lista que recibe, así que un grupo no puede dejar a tus nodos fuera unos de otros. Además, un grupo puede llevar una lista blanca de hasta 200 direcciones y prefijos para los hosts de monitorización y administración que no deben bloquearse en ningún sitio. Cada nuevo bloqueo puede disparar también un webhook firmado hacia un chat o un sistema de tickets, descrito en la documentación de grupos. La configuración en cuatro pasos, con salida de ejemplo, está en Compartir bloqueos entre servidores Linux.
¿Cuándo es la DNS / RBL Zone la mejor opción?
El agente descarta una dirección listada en el kernel antes de que llegue a Postfix. Muchas configuraciones de correo prefieren decidir dentro del diálogo SMTP: rechazar con un motivo, o sumar una puntuación en Rspamd y aceptar el mensaje igualmente. Eso es lo que hace la DNS / RBL Zone. Sirve la blacklist de la comunidad como DNSBL con clave en bl.reportedip.de y sigue el RFC 5782 para IPv4 e IPv6. También encaja en máquinas donde no puedes ejecutar un servicio como root, como una pasarela de correo gestionada o un appliance antispam que acepta cualquier RBL.
Una dirección listada responde 127.0.0.2 con una confianza de 90 o más y 127.0.0.3 entre 75 y 89; una dirección limpia responde NXDOMAIN. En Postfix es una sola restricción, igual en cada nodo de correo:
# main.cf (same on every mail node)
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_rbl_client <your-token>.bl.reportedip.de=127.0.0.[2..3]
# keep the token out of bounces and logs:
rbl_reply_maps = texthash:/etc/postfix/rbl_replyLa plantilla de respuesta que mantiene el token fuera de los rebotes SMTP está detallada en la documentación. Las subzonas por categoría como brute-force o spam limitan la respuesta a un tipo de amenaza, de modo que un nivel de correo puede ponderar el spam de forma distinta a los ataques de inicio de sesión.
Una clave de zona para el clúster o una por servidor de correo
Cada clave incluye 100.000 consultas al día, que se reinician a las 00:00 UTC, y un límite de unas 50 consultas por segundo. El consumo se cuenta por clave, sea cual sea el nodo que pregunte: el nodo A con 40.000 consultas y el nodo B con 35.000 suman 75.000. La caché del resolvedor mantiene la mayoría de las consultas repetidas dentro de tu red, 30 minutos para una dirección listada y 5 minutos para NXDOMAIN.
Un clúster pequeño puede compartir una clave. Con relés muy cargados, una clave por servidor de correo es el reparto más limpio: un nodo no puede agotar a los demás, y una clave filtrada se rota sin tocar el resto. Cada clave es una suscripción propia a 7,90 € al mes o 79 € al año con IVA incluido, disponible a partir de Professional.
¿Y los hosts que no pueden ejecutar el agente?
Los cortafuegos en la nube, los balanceadores de carga y las máquinas sin Linux usan el Blacklist Feed: los mismos datos como exportación en texto, JSON o CSV, filtrados por confianza y categoría y descargados según un horario. El acceso empieza en el plan gratuito Contributor y no cuenta contra ninguna cuota diaria. La vía manual con scripts de ipset y notificaciones de fail2ban está en Proteger tu servidor web; en un host Linux, el agente hace el mismo trabajo con menos mantenimiento.
Los backends de aplicación y de API que necesitan un veredicto en el momento de la petición consultan la API REST. Una cuenta gratuita cubre 1.000 comprobaciones y 50 notificaciones al día, y las comprobaciones masivas empiezan en Professional.
¿Cómo despliegas ReportedIP en un clúster?
- Ejecuta
reportedip-agent doctoren un host de cada tipo. El comando no cambia nada y nombra todo lo que falta, como un backend de cortafuegos o un log sin leer. - Pon tus direcciones de administración y monitorización en la lista blanca antes de la primera sincronización, porque las reglas descartan tráfico desde esa sincronización.
- Instala de forma desatendida con
REPORTEDIP_ACCEPT_TERMS=1yREPORTEDIP_KEYdesde Ansible, cloud-init o una imagen base, como en los ejemplos de instalación. - Crea un grupo, añade las claves de todos los nodos y de cada sitio con Hive, y pasa las excepciones comunes a la lista blanca del grupo.
- Contrata la DNS / RBL Zone para los relés de correo y los appliances que deban decidir dentro del SMTP, y añade la restricción en cada uno.
- Coloca uno o dos nodos señuelo en direcciones sin uso con el Honeypot Server. Sus notificaciones suben la puntuación de cada atacante que capturan en toda la red.
Preguntas sobre la protección de un clúster de servidores
¿Necesita cada servidor del clúster su propia licencia?
Cada servidor que deba recibir el feed de la comunidad y la lista del grupo necesita una licencia. Professional incluye una y Business tres, y las siguientes cuestan de 4,90 € a 1,40 € por servidor y mes. Un servidor sin licencia sigue detectando, bloqueando en local y notificando, así que sigue aportando al clúster.
¿Puede una clave de la DNS / RBL Zone servir a todos los servidores de correo?
Una clave puede servir a todos los servidores de correo de un clúster pequeño, porque sus 100.000 consultas diarias se cuentan por clave, sea cual sea el nodo que las envíe. Con relés muy cargados es mejor una clave por servidor, para que un solo nodo no agote la cuota de los demás y una clave filtrada se pueda rotar por separado.
¿Debo mantener fail2ban junto al agente?
Solo durante el cambio. El agente toma el relevo de fail2ban: comprueba primero qué herramienta ocupa los nombres de los sets del cortafuegos, ejecuta ambos un tiempo y después apaga fail2ban definitivamente. Un host que mantiene fail2ban sigue notificando sus bloqueos, porque el agente lee fail2ban como una de sus fuentes.