ReportedIP Linux Agent 0.3.48: monitorización, control de reglas y menos bloqueos erróneos
ReportedIP Linux Agent 0.3.48 ofrece a los sistemas de monitorización una comprobación de estado en JSON, te permite fijar una duración de bloqueo por regla, simular una regla y descartar líneas de registro que sabes inofensivas, y deja de bloquear a clientes FTP, administradores de WordPress y relés de correo con filtrado. Esta versión cierra 21 versiones publicadas entre el 28 de septiembre y el 9 de octubre de 2026, la mayoría a partir de mediciones en los servidores donde el agente ya se ejecuta.
Un servidor con las actualizaciones automáticas activadas recibe la 0.3.48 en su siguiente comprobación, que la sincronización realiza cada seis horas. Todo lo demás sobre el agente está en la página de producto del Linux Agent y en la documentación del agente.
¿Qué cambió entre Linux Agent 0.3.27 y 0.3.48?
| Área | Versiones | Cambio principal |
|---|---|---|
| Monitorización | 0.3.31, 0.3.32, 0.3.40 | status --json, señal de vida del demonio, sin falsas alarmas en servidores sin grupo |
| Control de reglas | 0.3.43, 0.3.45 | Duración del bloqueo por regla, simulación, patrones a ignorar, reglas propias primero |
| Avalanchas de bots | 0.3.44, 0.3.46 | Alarma de volumen por registro web, regla de rastreo incluida en simulación |
| Menos bloqueos erróneos | 0.3.39, 0.3.42, 0.3.47, 0.3.48 | FTP en modo pasivo, recursos de página rechazados, admin-ajax de WordPress, relés de correo con filtrado |
| Instalación y diagnóstico | 0.3.29, 0.3.30, 0.3.34 a 0.3.38, 0.3.41 | Registros web leídos de la configuración del servidor, niveles de registro, doctor encuentra servicios sin vigilar |
La lista de grupo y la lista blanca de grupo llegaron justo antes de esta serie, con las versiones 0.3.24 y 0.3.27; se explican en Compartir bloqueos de IP entre servidores Linux.
¿Cómo monitorizo el Linux Agent con Zabbix, Nagios o Prometheus?
Desde la 0.3.40, reportedip-agent status --json imprime un documento JSON con el mismo veredicto y el mismo código de salida que la salida de texto: status es ok, degraded o error, y problems enumera cada motivo detrás del código 1. También incluye los valores que merece la pena graficar: tamaño de las listas, antigüedad de la última sincronización, bloqueos activos, longitud de la cola y el estado de cada fuente de registros.
- Ninguna petición a la API. La parte de la cuenta es la respuesta que guardó la última sincronización, así que una comprobación cada pocos minutos no cuesta nada.
- Un contrato estable. El documento lleva
schema: 1, y bajo ese número los campos solo se añaden. - Un demonio detenido es un error. El demonio de vigilancia deja una señal de vida, y
statussale con código 1 si falta o tiene más de dos minutos. Antes, las listas seguían en el núcleo y nada parecía fallar mientras ya no se detectaba nada. - Sin falsas alarmas. Un servidor cuya clave no está en ningún grupo ya no se considera degradado (0.3.32), y la reputación de la dirección propia del servidor solo avisa a partir de una confianza de 75, el nivel más bajo que sirve un feed (0.3.31).
Las configuraciones listas para Zabbix, Nagios e Icinga, Checkmk y Prometheus están en la página de monitorización; los códigos de salida aparecen en operación.
¿Cómo controlo una sola regla de detección?
La 0.3.43 añadió cuatro controles que antes requerían sobrescribir una regla o cambiar la configuración de todo el servidor:
| Control | Cómo | Qué hace |
|---|---|---|
| Duración del bloqueo por regla | action.time_minutes en un archivo de regla | Fija el primer bloqueo de esa regla, de un minuto a un año |
| Simulación | reportedip-agent rules simulate <id> | La regla sigue detectando y notificando, el bloqueo se convierte en un aviso simulated ban en el journal |
| Patrones a ignorar | /etc/reportedip-agent/ignore.d/<source>.conf | Descarta las líneas coincidentes antes de que las vea un detector |
| Exportación de bloqueos | ban list --json o --plain | Entrega los bloqueos a nginx, HAProxy o un script |
Los patrones a ignorar están pensados para comprobaciones de estado, sondas de monitorización y rutas ACME. Se rechaza un patrón que se tragaría una línea que las reglas incluidas están probadas para detectar, y también uno que coincide con la cadena vacía. Desde la 0.3.45 tus propias reglas se ejecutan antes que los paquetes firmados y las reglas incluidas, así que una regla propia ya no puede quedar tapada por una incluida. Sobrescribir una política, como report: false, ya no pone una regla un día en observación (0.3.43).
El formato de los archivos de reglas y los comandos de reglas se describen en la página de detección; la duración del bloqueo, la simulación y la exportación están en bloqueo.
¿Qué hace el agente contra las avalanchas de bots?
Desde la 0.3.44 el demonio cuenta cada línea de cada registro que lee y mantiene, para cada registro web, una línea base de líneas por hora. Cuando la hora en curso supera con creces esa línea base, el estado volume pasa a aviso, uno de los 13 estados de salud. La alarma nombra el sitio más ruidoso y no bloquea ni notifica nada; una avalancha de rastreadores es una cuestión de capacidad, no un dato para la comunidad. Necesita 24 horas completas de línea base antes de poder dispararse, y volume_factor: 0 en config.yaml la desactiva.
La misma versión incluye la regla web-query-crawl en simulación. Busca clientes que piden muchas páginas con cadena de consulta sin un referer propio. Desde la 0.3.46 solo cuenta clientes que se hacen pasar por un navegador, así que un rastreador que se identifica por su nombre nunca queda bloqueado por ella. Antes de publicarla se midió en cinco servidores durante dos días: ningún visitante ni ninguna monitorización la superó, solo rastreadores y bots. La guía Detectar y frenar avalanchas de bots explica cuándo activarla.
¿Qué bloqueos erróneos ha eliminado el agente?
- Clientes FTP en modo pasivo (0.3.39). Cada conexión de datos pasiva parecía una sonda a un puerto cerrado, y un cliente de un servidor gestionado fue bloqueado tres veces en un día. La regla de escaneo de puertos pregunta ahora al núcleo si un socket escucha en ese momento, y el rango pasivo de pure-ftpd, proftpd y vsftpd se lee de su configuración.
- Visitantes de una página rota (0.3.42). Una fuente, imagen, hoja de estilo o script rechazado, y todo lo que está bajo
/.well-known/, ya no cuenta como petición bloqueada. Las sondas a/.envo/.git/siguen contando. - Administradores de WordPress con sesión iniciada (0.3.47).
admin-ajax.phpresponde 400 a toda acción sin manejador, y un escritorio activo lo produce muchas veces por hora. Esa respuesta ya no cuenta; cualquier otra ruta bajo/wp-admin/sí. - Relés de correo con filtrado (0.3.48). Un remitente de sobre rechazado se contaba contra el servidor que conecta, y detrás de un relé con filtrado ese es siempre el relé. Un solo bloqueo detuvo la entrada de correo durante doce horas. En 20 días de un servidor de correo de la flota, esto solo cambia el veredicto sobre el relé.
- Direcciones en la lista blanca en
test(0.3.33). La columna del veredicto ahora dice no para una dirección que protege la lista blanca.
¿Qué hay de nuevo en instalación y diagnóstico?
- Registros web desde la configuración del propio servidor web (0.3.34).
installlee los archivos vhost bajoconf.dysites-enabled, así encuentra los registros de acceso por sitio de un alojamiento y no solo las rutas por defecto. - Niveles de registro (0.3.29, 0.3.38).
log_leveladmitedebug,info,warnoerror; una instalación nueva escribewarn.install --log-levelyREPORTEDIP_LOG_LEVELlo fijan durante un despliegue. - Sustituir fail2ban (0.3.30).
REPORTEDIP_FAIL2BAN_SOURCE=0deja fail2ban fuera como fuente en un servidor del que se va a retirar. - Servicios sin vigilar (0.3.35 a 0.3.37).
doctornombra un servicio que escucha en un puerto o escribe un registro que ninguna fuente vigila, juzga el registro en lugar del nombre del servicio e ignora los sockets ligados solo a loopback. - Rangos de administración (0.3.41).
install --admin-ipguarda un rango CIDR completo en la lista blanca automática en lugar de solo su primera dirección.
Cada actualización que el agente instala por sí mismo se verifica con una firma Ed25519 (RFC 8032) sobre las sumas de comprobación publicadas y se arranca una vez antes de sustituir el binario en ejecución. Las variables de install.sh están en la página de instalación, la migración en sustituir fail2ban.
Preguntas sobre Linux Agent 0.3.48
¿Tengo que cambiar mi config.yaml después de actualizar?
Un config.yaml existente sigue funcionando sin cambios, y un servidor conserva el nivel de registro que indica su archivo. Dos cosas cambian solas: la alarma de volumen viene activada y emite un aviso, más un correo si notify.email está configurado, cuando un registro web se desborda; volume_factor: 0 la desactiva. Y desde la 0.3.43, sobrescribir solo la acción de una regla, como report: false, ya no pone la regla un día en observación. Hace falta un paso: un servidor instalado antes de la 0.3.41 con un rango CIDR para --admin-ip solo tiene su primera dirección y debe añadir el rango con whitelist add.
¿La alarma de volumen bloquea algo?
La alarma de volumen nunca bloquea y nunca notifica. Pone el estado volume en aviso, nombra el sitio más ruidoso y remite a reportedip-agent status para la lista completa. Se apaga tras una hora tranquila completa. Bloquear una avalancha sigue siendo tarea de las reglas de detección, por ejemplo de web-query-crawl cuando la actives.
¿Qué plan necesito para el Linux Agent?
El agente funciona en todos los planes, Free incluido: la detección local, los bloqueos locales y las notificaciones funcionan siempre. El feed de la comunidad necesita una licencia de servidor: Professional incluye un servidor, Business tres, Enterprise según contrato, y desde Professional se pueden añadir más servidores por host. Los detalles están en la página de licencias.
Sigue leyendo
- Instalar el Linux Agent
- Todas las claves de config.yaml
- Configuraciones de ejemplo
- Grupos y webhooks
¿Tienes WordPress junto a tus servidores? La versión Hive 2.1.72 cubre el lado de WordPress de los mismos grupos. Cómo funcionan las licencias de prueba se explica en licencias de prueba gratuitas para el Linux Agent.
Bloquea lo que la comunidad ya ha visto y notifica lo que encuentran tus propios registros, en cada servidor Linux.