Agente ReportedIP para Linux

El agente es un único binario estático que hace dos trabajos en un servidor Linux: mantiene la lista negra comunitaria en el cortafuegos del núcleo y notifica a los atacantes que encuentra en los registros de ese servidor. De forma opcional también bloquea él mismo esos hallazgos locales. Sustituye al script de sincronización escrito a mano que documenta este sitio, y asume el trabajo que hacía fail2ban.

Qué hace

Por dónde seguir

• Instalación: las condiciones de uso, las comprobaciones, cada pregunta, las opciones y las variables de un despliegue, un host sin systemd.
• Ejemplos de instalación: Ansible y cloud-init, una imagen base, paneles de control, un host de correo o de base de datos, contenedores LXC y cortafuegos en la nube.
• Configuración: cada clave de config.yaml, los umbrales, la escalada de bloqueos, el correo y cuándo tiene efecto un cambio.
• Detección y reglas: los tipos de fuente, los escaneos de puertos desde el registro del núcleo, añadir un registro que el instalador pasó por alto, qué sale de la máquina y los archivos de reglas.
• Bloqueo: las dos clases de conjunto, cómo empieza y termina un bloqueo, la cadena en el núcleo y cómo levantar un bloqueo.
• Grupos: bloqueos compartidos entre tus servidores y tus sitios WordPress, los límites por plan, la lista blanca y el webhook.
• Funcionamiento: comandos, códigos de salida, las unidades, la monitorización, la reputación de la propia dirección del host y la tabla de resolución de problemas.
• Licencias: una licencia por servidor, el presupuesto de informes, los grupos a partir de Professional y qué sigue funcionando sin ella.
• Sustituir fail2ban: la migración en tres pasos, y el camino de vuelta.

Requisitos

Nada más. El binario está enlazado estáticamente y construido sin cgo, así que no trae intérprete, ni biblioteca compartida, ni repositorio de paquetes, ni ayudante de cron propio. Se desarrolló y se midió en Debian 12 (bookworm) en arm64 con ISPConfig, nginx, Postfix, pure-ftpd y bind.

ipset o nftables, y qué decide auto

Los dos backends hacen el mismo trabajo. Lo que importa es cuál usa ya el host, porque dos filtros de paquetes escribiendo la misma cadena INPUT es la forma en que desaparece una tarde.

Solo cuenta un binario que exista, nunca una cadena de versión: iptables --version en un host con el backend nft dice algo que parece correcto y no significa nada. En cuanto un host ha sincronizado, el backend elegido queda registrado, y un cambio posterior necesita reportedip-agent sync --migrate-backend en vez de construir en silencio un segundo juego de reglas.

Comprobar primero el host

doctor es el comando que se ejecuta antes de instalar. No cambia absolutamente nada: ningún archivo, ningún directorio, ninguna regla, ningún conjunto. Todo lo que informa lo ha leído.

reportedip-agent doctor

Leer el veredicto

Vuelve a ejecutar doctor después de la instalación. Con una configuración en su sitio informa de las fuentes configuradas en vez de las detectadas, y añade la desviación de reloj por fuente que midió el demonio. Una fuente cuyo registro sella cada línea a más de un minuto del reloj del sistema tiene una ventana de recuento que nunca se llena, y ese es el único fallo que se parece exactamente a «el detector no funciona».

Instalación rápida

Tres comandos en un host que todavía no tiene nada de esto. Ejecútalos en este orden y el agente notifica, las listas de la comunidad están en el núcleo y no se ha descartado nada que no hayas aceptado.

# 1. Install, as root. At a terminal it shows the terms of use and
#    takes a yes, then asks for your key, then three short questions;
#    an Enter answers drop and local bans on.
curl -fsSL https://reportedip.com/agent/install.sh | sh

#    For automation, and for fifty hosts, nothing is asked: the terms
#    are accepted up front and the key comes from the environment.
curl -fsSL https://reportedip.com/agent/install.sh | REPORTEDIP_ACCEPT_TERMS=1 REPORTEDIP_KEY="YOUR_API_KEY" sh

# 2. The first sync builds the chain and the sets. The installation
#    itself touches no firewall rule.
reportedip-agent sync

# 3. See that it ran, and read what would be dropped before it is.
reportedip-agent status
reportedip-agent doctor
reportedip-agent test /var/log/auth.log

Qué deja cada uno: el primero coloca el binario en /usr/local/bin, escribe /etc/reportedip-agent/config.yaml a partir de lo que ha encontrado en este host e instala las tres unidades de systemd. El segundo crea la cadena del cortafuegos y los conjuntos, que la instalación no toca a propósito, y los llena. El tercero es la prueba: status muestra un recuento de entradas por lista y el estado de licencia de este host, doctor nombra todo lo que falta, y test vuelve a pasar tu propio registro para mostrar qué dirección habría superado qué umbral. Las reglas descartan desde la primera sincronización, porque eso es lo que escribe la instalación, así que la lista blanca va antes de esa sincronización y no dos días después. Responde log en su lugar para un host en el que quieras leer primero un diario. La página de instalación es la misma instalación explicada por completo, y ese detalle es su razón de ser.

La primera hora, en orden

Cada paso responde a una pregunta de la que depende el siguiente. En otro orden, una instalación que funciona parece averiada.

1. reportedip-agent doctor. Antes que nada, porque es el único comando que no cambia nada.
2. reportedip-agent sync. La primera ejecución construye la cadena, crea los conjuntos y descarga las listas configuradas, una tras otra con una pausa corta entre ellas.
3. reportedip-agent status. Comprueba que cada lista configurada tiene un número de IPv4 plausible, que la cadena dice ok, que la lista blanca contiene las direcciones que esperas, y que account muestra tu rol y el estado de licencia de este host.
4. Arregla la lista blanca. El instalador añadió a la lista blanca la dirección desde la que llegó tu sesión SSH, que es una suposición. Sustitúyela por el rango desde el que administras de verdad, y añade tu monitorización, tu host de copias y el rango de tu oficina.
5. Vuelve a leer status al cabo de un día. Los contadores de paquetes de la cadena dicen cuánto han parado de verdad las reglas, y ban list dice qué direcciones ha detectado este host en sus propios registros.
6. Solo en un host para el que hayas respondido log: las reglas están del todo construidas y coinciden, solo registran en vez de descartar, así que el registro del núcleo te muestra exactamente qué habría cortado drop. Lee un diario, luego pon mode: drop y ejecuta sync, que reconstruye las reglas.

reportedip-agent doctor
reportedip-agent sync
reportedip-agent status
reportedip-agent whitelist add 203.0.113.0/24 "management"
reportedip-agent whitelist add 198.51.100.7   "monitoring"
reportedip-agent whitelist list

Actualizaciones y notas de versión

El agente busca una versión nueva cada seis horas, durante la sincronización. Verifica la descarga contra una firma Ed25519 con la clave pública integrada en el binario, devuelve a su sitio el binario en ejecución si el cambio falla y reinicia él mismo el servicio watch. reportedip-agent update hace lo mismo a petición, y update --check solo informa de lo que está publicado.

Volver a ejecutar el comando de instalación también actualiza un host. Un host por debajo de la versión mínima que admite el servicio se sigue actualizando solo; hasta que lo hace, el agente lo advierte en su registro, en status (exit 1) y en update --check. Las vueltas a una versión anterior se rechazan en general, así que un host que ha descargado una versión más reciente no retrocede por sí solo.

Lo que ha cambiado la versión actual es público y no necesita ninguna clave:

curl -s https://reportedip.com/agent/whats-new
reportedip-agent update --check

Los cambios en la propia REST API, o sea los campos de respuesta y los códigos de estado que afectan a una integración, están en cambio en el Changelog de la API.

Últimas versiones

• 0.3.41: --admin-ip acepta ahora de verdad un rango CIDR. Hasta 0.3.40 un rango se recortaba a su dirección de red, así que en la lista blanca automática solo acababa esa dirección. Con backend: auto el agente prefiere ipset, y las indicaciones del instalador ya lo dicen.
• 0.3.40: status --json para la monitorización: un documento con esquema 1 y el mismo veredicto y código de salida que el texto, sin petición a la API, y una configuración rota (exit 2) también entrega un documento. status informa ahora de un demonio watch parado con exit 1: el demonio deja una señal de vida cada 30 segundos, y una de más de dos minutos cuenta como parado. La configuración para los sistemas de monitorización habituales está en Monitorización.
• 0.3.39: la regla de escaneo de puertos ya no banea clientes FTP en modo pasivo. Cada conexión de datos va a un puerto que el servidor abre solo para esa transferencia, la regla conocía los puertos en escucha solo por la última sincronización, y por eso subir una carpeta parecía un escaneo en pocos segundos. La regla consulta ahora al núcleo si en ese momento escucha un socket en el puerto (-m socket --nowildcard con iptables, socket transparent con nftables), y el rango pasivo de un pure-ftpd, proftpd o vsftpd en marcha se lee de su configuración y queda fuera de la regla. En un servidor sin rango configurado queda fuera en su lugar el rango de puertos efímeros del núcleo. La cadena se reconstruye una vez en la siguiente sincronización.
• 0.3.38: install acepta el nivel de registro, como --log-level debug|info|warn|error o como REPORTEDIP_LOG_LEVEL. El valor por defecto sigue siendo warn. Un despliegue que quiere leerlo todo en cada host dice info una sola vez en lugar de editar después la configuración de cada host, y un nivel que el analizador rechazaría se rechaza antes de escribir nada.
• 0.3.37: un servicio que solo escucha en la interfaz loopback ya no cuenta como alcanzable. El sondeo de puertos contaba cada escucha de la tabla del núcleo sin importar a qué dirección estuviera vinculada, así que el resolvedor local que ocupa 127.0.0.53:53 en un host Debian corriente parecía un servidor de nombres, y un servidor de correo que solo acepta correo de su propia máquina parecía uno abierto a Internet. Un puerto que tiene un socket en loopback junto a uno real sigue contando. Esto decide también qué puertos trata como abiertos la regla de escaneo de puertos.
• 0.3.35: doctor nombra un registro que este host escribe y que no lee ninguna fuente, y dice dónde añadir la fuente. La detección se ejecuta una sola vez, en la instalación, y eso se queda así, porque un servicio detenido por mantenimiento nunca debe apagar una fuente. La dirección contraria no tenía a nadie que la vigilara: un servidor de correo instalado en un host que antes no tenía ninguno pasaba desapercibido, y el host parecía sano mientras ese servicio quedaba sin vigilancia. El hallazgo produce el código de salida 1.
• 0.3.34: install lee los registros web de la propia configuración del servidor web, incluidos los archivos de host virtual bajo conf.d y sites-enabled, en lugar de una lista de nombres por defecto. Un alojamiento real nombra sus registros según el sitio, así que las rutas por defecto encontraban el registro por defecto y se perdían el resto: en un host medido, otros dos registros, uno de ellos un registro de acceso con direcciones reales, se habrían quedado sin leer. Un registro cuyo formato oculta la dirección del cliente se sigue dejando fuera, y cada registro tomado así se nombra en una línea durante la instalación.
• 0.3.32: status ya no llama degraded a un host porque su lista de grupo esté vacía, que es el estado normal de una clave que no está en ningún grupo, y doctor ya no afirma que no haya ninguna fuente de registro en un host cuyo sshd escribe en el diario de systemd en lugar de en un archivo.
• 0.3.29: una instalación nueva escribe log_level: warn en lugar de info, así que un host nuevo se queda callado en el diario de systemd hasta que algo pide atención. Las líneas de rutina, una lista actualizada, una notificación en cola, un bloqueo local puesto, no cambian y están a una palabra de distancia. Un host que ya está instalado conserva lo que dice su archivo de configuración.
• 0.3.27: la lista blanca del grupo: las direcciones y prefijos que nombra un grupo de tu cuenta no los bloquea ni notifica nunca ningún miembro. La sincronización la lee con la lista de grupo, la escribe en group-whitelist bajo el directorio de estado y la aplica en la misma pasada al conjunto de lista blanca del núcleo, al filtro de las listas y a la puerta de notificación; whitelist list y status muestran las entradas con sus notas. La lista blanca de este host, la lista blanca automática y las capas integradas se quedan como están.
• 0.3.26: un escaneo de puertos rápido se quedaba por debajo de su propio umbral: la regla de escaneo registraba diez SYN por minuto con la ráfaga por defecto del núcleo de cinco, así que un escáner que sondea mil puertos en pocos segundos dejaba cinco líneas, y la regla necesita diez. La regla admite ahora una ráfaga de veinte, los veinte primeros sondeos de un escaneo se registran de golpe, y después la tasa mantiene el registro en silencio. La cadena se reconstruye una vez.
• 0.3.25: un host cuya clave no está en ningún grupo perdía su cadena con 0.3.24, porque el conjunto de grupo solo lo crea su primer feed y la regla que lo nombra era rechazada. Ahora cada conjunto de lista se crea antes de que una regla lo nombre. 0.3.24 fue retirada.
• 0.3.24: la lista de grupo group en el conjunto rip-group en todos los puertos; la reputación de la dirección desde la que este host notifica, como condición de salud reputation; la detección de escaneos de puertos desde el registro del núcleo con la fuente scan. La cadena se reconstruye una vez tras esta actualización y sus contadores de paquetes empiezan de cero.

Consumo de recursos

Medido en un host Debian 12 arm64 con siete archivos de registro seguidos por el agente: 16,6 MB de memoria residente. No hay intérprete que arrancar, ni base de datos, ni directorio de caché que calentar, y eso es la mayor parte de la explicación de esa cifra tan pequeña.

Qué no es el agente

No es un antivirus, ni un cortafuegos de aplicaciones web, ni un sustituto de Imunify360. No lee tus archivos, no examina cuerpos de peticiones y no pone nada en cuarentena. Bloquea y notifica direcciones, y lo hace sobre una superficie pequeña y auditable. Para protección a nivel de una sola petición en un sitio WordPress, usa en su lugar el plugin Hive. Los dos se ejecutan en la misma máquina sin estorbarse.

Última actualización: 30. septiembre 2026 · Mantenido por el equipo de ReportedIP