Proteger un clúster de servidores con ReportedIP
Un clúster de servidores multiplica la superficie de ataque: cada nodo web, servidor de retransmisión de correo y proxy perimetral es objeto de pruebas de forma independiente, pero la mayoría de las configuraciones asignan a cada nodo sus propias reglas de bloqueo a medio configurar. ReportedIP todo el clúster comparta una única fuente de información sobre amenazas de la comunidad; además, gracias a la zona DNS/RBL, cada nodo puede acceder a ella a través de DNS sin cifrar, sin necesidad de código de integración específico para cada nodo.
La zona DNS/RBL es un complemento de pago disponible en los planes PRO y superiores. Suscríbete desde tu panel de control y, a continuación, configura cada nodo para que apunte a una cadena de zona.
Por qué un clúster necesita una fuente de información sobre amenazas compartida
Cuando diez nodos mantienen cada uno su propia lista de bloqueados, 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 prosperan los ataques de «credential stuffing» y las campañas de spam: se propagan por los nodos más rápido de lo que tarda un solo nodo en actualizar sus reglas.
Un feed compartido acorta la distancia. ReportedIP las direcciones IP a partir de una red comunitaria en tiempo real (con un nivel de confianza ≥ 75 % antes de incluir una dirección en la lista, y un periodo de espera de 48 horas para falsos positivos), y todos los nodos de tu clúster reciben la misma respuesta. Un nuevo atacante detectado en cualquier punto de la red queda bloqueado en todo tu clúster en un solo ciclo de caché.
Consultar la lista de bloqueados a través de DNS desde cada nodo
La zona DNS/RBL convierte la lista negra de la comunidad en una lista negra de DNS estándar en bl.reportedip.de. Un nodo busca la dirección IP del cliente invertida en tu token y lee la respuesta —la misma convención que utilizan Spamhaus y todas las demás listas negras de DNS—, por lo que cualquier software compatible con RBL funciona sin necesidad de código personalizado. A continuación RFC 5782, admite tanto IPv4 como IPv6, 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 es necesario un token por cada nodo. Configura cada servidor de retransmisión de correo para que apunte a la misma cadena de zona. Cada token incluye 100 000 consultas DNS al día, y el uso se acumula como la suma de todos los nodos: si el nodo A atiende 40 000 consultas y el nodo B, 35 000, el total asciende a 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 almacenada se guarda en caché durante 30 minutos y una NXDOMAIN para 5, por lo que la mayoría de las consultas repetidas nunca salen de tu 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 límite de velocidad por token de aproximadamente 50 consultas por segundo protege contra picos repentinos; los picos sostenidos que superen ese límite se gestionan con REFUSED.
Relés de correo: 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_replyLos 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 anulación de la respuesta de rechazo que evita que tu token aparezca en los mensajes de rebote SMTP, se encuentra en la documentación de la zona DNS/RBL. El token es una credencial privada: trátalo como si fuera una contraseña y cámbialo desde el panel de control 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 bloquee únicamente lo que le sea relevante. Un nivel de aplicaciones con muchas sesiones de inicio de sesión puede consultar la lista de ataques de fuerza bruta; un nivel de correo electrónico puede dar prioridad a la lista de spam:
<reversed-ip>.<your-token>.brute-force.bl.reportedip.de
<reversed-ip>.<your-token>.spam.bl.reportedip.deEntre 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. Los proxies inversos, los cortafuegos y los servidores web funcionan mejor con el feed de la lista negra de la comunidad — una exportación actualizada en formato texto/JSON/CSV que se obtiene mediante una tarea programada y se carga en fail2ban, un iptables ipset o un mapa de denegación de Nginx. Cada nodo periférico del clúster ejecuta el mismo cron y bloquea las mismas direcciones.
En el caso de las aplicaciones y los backends de API que necesitan una respuesta en el momento de la solicitud, el API REST devuelve un desglose completo de la confianza por IP (añadir 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.
Una estructura de referencia para un clúster de tres niveles
| Nivel de clúster | Cómo lee el feed | ReportedIP |
|---|---|---|
| MX / servidores de retransmisión de correo saliente | Consulta de DNSBL en el momento de la conexión SMTP | Zona DNS / RBL |
| Proxies inversos / WAF / perímetro | Exportación de la lista de bloqueados a nginx / iptables / fail2ban | Canal de la lista negra |
| Servidores de aplicaciones y API | Comprobación de la puntuación por solicitud | API pública |
| Nodos señuelo / honeypot | Notificar las direcciones IP de los atacantes a la red | Servidor trampa |
Cada nivel lee datos de una base de datos comunitaria, por lo que un atacante detectado por un nodo trampa queda bloqueado en tus servidores de retransmisión de correo y proxies perimetrales en el siguiente ciclo de caché. Cerrar el círculo —es decir, comunicar lo que ven tus propios nodos— es lo que garantiza que la fuente compartida sea precisa para todos.
Lo que necesitas para empezar
- Suscríbete a la zona DNS/RBL desde tu panel de control y copia el token.
- Añade la línea
reject_rbl_client(o Rspamdrbls(bloque) a cada nodo de correo; véase el Documentación de RBL. - Recupera el feed de la lista negra en los nodos periféricos; llama a la API desde los servidores de la aplicación.
- Lee el anuncio de lanzamiento de la zona en «DNS RBL Zone»: consulta nuestra lista de bloqueados desde tu servidor de correo.
Preguntas frecuentes
¿Necesito un token diferente para cada servidor?
No. Un solo token cubre todo el clúster; las 100 000 consultas diarias se suman en todos los nodos que lo utilizan. Añade un segundo token solo cuando un clúster grande necesite más margen, y luego distribúyelo entre los grupos de nodos.
¿Funciona la zona DNS/RBL con servidores de correo IPv6?
Sí. La zona cumple con el RFC 5782 y responde por igual a las consultas 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 el límite diario?
Una vez que el total diario acumulado del token alcanza su límite, la zona vuelve a 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.