Proteger un clúster de servidores con una lista DNSBL compartida

Un clúster de servidores multiplica tu superficie de ataque: cada nodo web, Mail Relay y proxy perimetral es objeto de pruebas de forma independiente; sin embargo, la mayoría de las configuraciones asignan a cada nodo sus propias reglas de bloqueo a medio configurar. ReportedIP permite que todo el clúster comparta una única Threat Feed sobre amenazas de la comunidad; además, gracias a la DNS / RBL Zone, cada nodo puede consultarla a través de DNS sin cifrar, sin necesidad de código de integración específico para cada nodo.

La DNS / RBL Zone es un Add-on de pago disponible en los planes PRO y superiores. Suscríbete desde tu Dashboard y, a continuación, configura cada nodo para que apunte a una cadena de zona.

Por qué un clúster necesita una Threat Feed compartida

Cuando diez nodos mantienen cada uno su propia lista de bloqueos, una dirección IP bloqueada en el nodo 1 sigue llegando a los nodos del 2 al 10 hasta que cada uno de ellos se entera de ello por su cuenta. Esa brecha es precisamente donde tienen éxito los ataques de «Credential Stuffing» y las campañas de spam: se van alternando entre tus nodos más rápido de lo que tarda cualquier nodo individual en actualizar sus reglas.

Un feed compartido acorta la brecha. ReportedIP puntúa las direcciones IP procedentes de una Community Network en tiempo real (con un nivel de confianza ≥ 75 % antes de que una dirección se incluya en la lista, y un periodo de espera de 48 horas para False Positives), y todos los nodos de tu clúster reciben la misma respuesta. Cualquier nuevo atacante detectado en cualquier punto de la red queda bloqueado en todo tu clúster en un solo ciclo de caché.

Consultar la Blocklist a través de DNS desde cada nodo

La DNS / RBL Zone convierte la Community Blacklist en una DNSBL estándar en bl.reportedip.de. Un nodo consulta la IP inversa del cliente asociada a tu token y lee la respuesta —la misma convención que utilizan Spamhaus y cualquier otra DNSBL—, por lo que cualquier software compatible con RBL funciona sin necesidad de código personalizado. Cumple con el RFC 5782, cubre tanto IPv4 como IPv6 por igual y devuelve 127.0.0.x códigos:

Respuesta	Significado	Acción
`127.0.0.2`	Incluido en la lista, alto nivel de confianza (≥ 90)	Rechazar
`127.0.0.3`	Incluido en la lista, nivel de confianza medio (75-89)	Rechazar o puntuar
`NXDOMAIN`	Limpio	Aceptar
`127.255.255.251`	Se ha alcanzado la cuota diaria	Añadir un token
`127.255.255.252`	Token no válido / inactivo	Comprobar la factura

Un único token para todo el clúster: el uso se suma, no se duplica

No necesitas un token por cada nodo. Configura todos los Mail Relays para que apunten a la misma cadena de zona. Cada token incluye 100 000 consultas DNS al día, y el uso se agrega como la suma de todos tus nodos: si el nodo A realiza 40 000 consultas y el nodo B, 35 000, el total cuenta como 75 000 dentro de la cuota diaria. En la práctica, el almacenamiento en caché del resolutor te permite mantenerte muy por debajo de ese límite: una respuesta listada se almacena en caché durante 30 minutos y una respuesta NXDOMAIN durante 5, por lo que la mayoría de las consultas repetidas nunca salen de su red.

Cuando un clúster con mucha actividad se acerque al límite, añade un segundo token y distribúyelo entre los grupos de nodos: las cuotas son independientes. Un Rate Limit por token de aproximadamente 50 consultas por segundo protege contra los picos repentinos; los picos sostenidos que superen dicho Rate Limit se responden con REFUSED.

Mail Relay: una línea en Postfix o Rspamd

En cada servidor MX y en cada servidor de retransmisión de salida del clúster, añade la zona a tus restricciones. Postfix genera automáticamente la consulta inversa para los remitentes IPv4 e IPv6 (versión 2.6 y posteriores):

# 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_reply

Los usuarios de Rspamd habilitan ambas familias de direcciones y asocian los códigos de retorno a símbolos:

# local.d/rbl.conf
rbls {
  reportedip {
    rbl = "<your-token>.bl.reportedip.de";
    ipv4 = true;
    ipv6 = true;
    returncodes {
      REPORTEDIP_HIGH   = "127.0.0.2";
      REPORTEDIP_MEDIUM = "127.0.0.3";
    }
  }
}

La configuración completa, incluida la opción de anulación de «reject-reply» que evita que tu token aparezca en los mensajes de rebote SMTP, se encuentra en los Docs de la DNS / RBL Zone. El token es una credencial privada: trátalo como si fuera una contraseña y cámbialo desde el Dashboard si se filtra.

Subzonas de categoría para el filtrado por servicio

Añade un slug de categoría para filtrar por tipo de amenaza, de modo que cada nodo solo bloquee lo que le sea relevante. Una capa de aplicaciones con muchas sesiones de Login puede consultar la lista de ataques Brute-Force; una capa de correo electrónico puede dar mayor peso a la lista de spam:

<reversed-ip>.<your-token>.brute-force.bl.reportedip.de
<reversed-ip>.<your-token>.spam.bl.reportedip.de

Entre las babosas se incluyen spam, brute-force, cms-login, web-attacks, malware, ddos, fraud, infrastructure, y apt. Solo se devuelve un resultado si la dirección IP figura en esa categoría.

Nodos periféricos y web: el feed y la API

No todos los niveles son compatibles con DNSBL. Para los proxies inversos, los cortafuegos y los servidores web, resulta más útil el Blacklist Feed de la comunidad: una exportación actualizada en formato texto/JSON/CSV que se puede obtener con una tarea cron y cargar en fail2ban, un iptables ipset o un mapa de rechazo de nginx. Cada nodo periférico del clúster ejecuta la misma tarea cron y rechaza las mismas direcciones.

Para las aplicaciones y los backends de API que necesitan un veredicto en el momento de la solicitud, la REST API devuelve un desglose completo de la confianza por IP (añade verbose=true para ver todos los componentes de la puntuación). Una cuenta gratuita incluye 1.000 comprobaciones y 50 informes al día; las operaciones masivas están disponibles en el plan PRO y superiores.

Un esquema de referencia para un clúster de tres capas

Nivel de clúster	Cómo lee el feed	Producto ReportedIP
MX / Mail Relay de correo saliente	Consulta de DNSBL en el momento de la conexión SMTP	DNS / RBL Zone
Proxies inversos / WAF / perímetro	Exportación de la Blocklist a nginx / iptables / fail2ban	Blacklist Feed
Backends de aplicaciones y API	Comprobación de la puntuación por solicitud	Public API
Nodos señuelo / Honeypots	Notificar las direcciones IP de los atacantes a la red	Honeypot Server

Cada nivel lee datos de una base de datos comunitaria, por lo que un atacante detectado por un nodo «Honeypot» queda bloqueado en tus Mail Relays y proxies periféricos en el siguiente ciclo de caché. Cerrar el ciclo —es decir, comunicar lo que ven tus propios nodos— es lo que garantiza que la fuente de información compartida sea precisa para todos.

Lo que necesitas para Getting Started

Suscríbete a la DNS / RBL Zone desde tu Dashboard y copia el token.
Añade la línea reject_rbl_client (o el bloque Rspamd rbls ) a cada nodo de correo; consulta la documentación de RBL.
Recupera el Blacklist Feed en los nodos periféricos; llama a la API desde los servidores de la aplicación.
Lee el comunicado de lanzamiento de la zona en «DNS / RBL Zone»: consulta nuestra Blocklist desde tu servidor de correo.

Preguntas frecuentes

¿Necesito un token distinto para cada servidor?

No. Un único token cubre todo el clúster; las 100 000 consultas diarias se suman entre todos los nodos que lo utilizan. Añade un segundo token solo cuando un clúster grande necesite más margen de capacidad y, a continuación, distribúyelo entre los grupos de nodos.

¿Funciona la DNS / RBL Zone con servidores de correo IPv6?

Sí. La zona cumple con el RFC 5782 y responde por igual a las consultas de IPv4 e IPv6. Postfix 2.6+ y Rspamd generan automáticamente la consulta inversa para cualquiera de las dos familias de direcciones; una misma directiva cubre ambas.

¿Qué ocurre si un nodo alcanza la cuota diaria?

Una vez que el total diario combinado del token alcanza su límite, la zona vuelve 127.255.255.251 y deja de resolver hasta el siguiente reinicio a medianoche (UTC). Añade otro token para aumentar la capacidad. Dado que las respuestas se almacenan en caché durante un máximo de 30 minutos en cada resolutor, la mayoría de los clústeres nunca se acercan al límite.

Proteger un clúster de servidores con ReportedIP