Ejemplos de instalación

El mismo instalador en los hosts con los que suele encontrarse: un despliegue con Ansible o cloud-init, una imagen base, un servidor con panel de control, un host de correo o de base de datos, un contenedor LXC y un VPS tras un cortafuegos en la nube. Cada ejemplo usa las opciones y las variables que documenta la página de instalación, nada de lo que hay aquí es una segunda vía de entrada.

Desatendida, en muchos hosts

Tres cosas hacen que una instalación desatendida funcione, y todos los ejemplos de abajo se apoyan en ellas. Las condiciones de uso se aceptan por adelantado con REPORTEDIP_ACCEPT_TERMS=1, porque no hay nadie que escriba yes. La clave viaja en el entorno y nunca como argumento, porque /proc/<pid>/cmdline lo puede leer cualquier usuario local y el entorno no. Y las respuestas a las preguntas que haría un terminal se dan como variables, así que ningún host se queda esperando una respuesta: REPORTEDIP_MODE, REPORTEDIP_BAN y REPORTEDIP_NOTIFY_EMAIL. Omite una y se aplica el valor por omisión de una configuración nueva, que es drop, bloqueos locales activados y ningún correo.

La ejecución es idempotente. En un host que ya tiene /etc/reportedip-agent/config.yaml el script coloca el binario y se detiene, y la configuración se deja tal cual. Las actualizaciones no necesitan el despliegue para nada: el agente se actualiza solo cada seis horas con una versión firmada. Lo único que hay que hacer después de cada instalación es la lista blanca: el instalador mete en ella la dirección desde la que vino la sesión, y el rango desde el que administras no está hasta que lo añades.

Ansible

Una lista de tareas, no un rol, porque no hay nada que plantillar: el instalador sondea el host por su cuenta. La clave sale del vault, la tarea se omite en un host que tiene configuración, y la tarea de la lista blanca trata una dirección que ya está como sin cambios, que es como la indica el agente.

- name: Install the ReportedIP Agent
  ansible.builtin.shell: curl -fsSL https://reportedip.com/agent/install.sh | sh
  args:
    creates: /etc/reportedip-agent/config.yaml
  environment:
    REPORTEDIP_ACCEPT_TERMS: "1"
    REPORTEDIP_KEY: "{{ reportedip_api_key }}"
    REPORTEDIP_MODE: "drop"
    REPORTEDIP_BAN: "true"
    REPORTEDIP_NOTIFY_EMAIL: "ops@example.org"
  no_log: true

- name: Whitelist the management range
  ansible.builtin.command:
    argv: [reportedip-agent, whitelist, add, "{{ management_range }}", "management"]
  register: rip_whitelist
  changed_when: rip_whitelist.rc == 0
  failed_when: rip_whitelist.rc != 0 and "already in" not in (rip_whitelist.stderr ~ rip_whitelist.stdout)

- name: Confirm the host is healthy
  ansible.builtin.command: reportedip-agent status
  changed_when: false

no_log mantiene la clave fuera de la salida de Ansible y de sus registros; el propio instalador la mantiene fuera de la lista de procesos. Un host de salto que no es desde donde administras necesita --admin-ip, que solo existe como argumento: REPORTEDIP_ADMIN_IP no existe, y install.sh no pasa argumentos a la configuración. Ejecuta el script con REPORTEDIP_NO_SETUP=1 y después reportedip-agent install --admin-ip 203.0.113.0/24 en una segunda tarea, con el mismo bloque de entorno.

cloud-init

La misma línea en runcmd. Lo que cambia es dónde vive la clave: los datos de usuario los puede leer desde dentro de la instancia cualquier proceso que alcance el servicio de metadatos, así que una clave colocada ahí es una clave que puede leer cualquier aplicación del host. Donde eso importe, recógela en el arranque desde un almacén de secretos y pásala en el entorno de ese único comando.

#cloud-config
runcmd:
  - [sh, -c, "curl -fsSL https://reportedip.com/agent/install.sh | REPORTEDIP_ACCEPT_TERMS=1 REPORTEDIP_KEY=YOUR_API_KEY REPORTEDIP_NOTIFY_EMAIL=ops@example.org sh"]
  - [reportedip-agent, whitelist, add, "203.0.113.0/24", "management"]
  - [reportedip-agent, sync]

Una imagen base

Coloca el binario en la imagen y nada más. REPORTEDIP_NO_SETUP=1 descarga, verifica e instala el binario y se detiene ahí: ni configuración, ni unidades, ni alta del host. La configuración se hace una vez en el primer arranque, en el host real, porque dos cosas que escribe no deben clonarse: el ID de instalación, que es como el servicio distingue un servidor de otro, y la lista blanca automática, que lleva la dirección de la sesión que la ejecutó. Una imagen que lleva un ID de instalación convierte cada clon en el mismo servidor dentro del registro de hosts, y una licencia se cuenta entonces una vez para todos ellos y no se asigna de forma fiable a ninguno.

# In the image build:
curl -fsSL https://reportedip.com/agent/install.sh | REPORTEDIP_ACCEPT_TERMS=1 REPORTEDIP_KEY=YOUR_API_KEY REPORTEDIP_NO_SETUP=1 sh

# At first boot of the clone, once:
REPORTEDIP_ACCEPT_TERMS=1 REPORTEDIP_KEY=YOUR_API_KEY reportedip-agent install --notify-email ops@example.org
reportedip-agent sync

Paneles de control

reportedip-agent doctor nombra el panel que encuentra bajo /usr/local: ISPConfig, Plesk, cPanel o DirectAdmin. Lo que el instalador configura más allá del nombre depende de si se ha medido la disposición de los registros por sitio de ese panel. Hoy eso es ISPConfig; para los demás se nombra el panel, se encuentran los registros estándar, y los registros por dominio te toca añadirlos a ti. También lista las fuentes configuradas con los archivos a los que apuntan, y reportedip-agent test <log> muestra qué produciría un registro antes de añadirlo.

ISPConfig

Medido en hosts de producción. El instalador encuentra los registros por sitio bajo /var/log/ispconfig/httpd/*/access.log y error.log como glob, así que un sitio añadido más tarde queda cubierto sin ningún cambio, el registro de acceso al panel /var/log/ispconfig/auth.log como fuente panel, y el registro de correo, pure-ftpd (que ISPConfig instala como pure-ftpd-mysql) y fail2ban cuando están en marcha. En un host de alojamiento eso dio 196 archivos de registro a partir de 62 líneas de configuración. Las listas mail, web y ftp siguen a los servicios activos y a los puertos que no escuchan solo en loopback; ssh y edge están siempre activas.

Plesk

Se reconoce por /usr/local/psa. El registro de correo estándar se encuentra; los registros web por dominio no se configuran, porque su disposición no se ha medido. Suelen vivir bajo /var/www/vhosts/system/<domain>/logs/ como access_log, más proxy_access_log donde nginx está delante de Apache. Compruébalo con ls y después añade una fuente web con un glob y una fuente web-error para los registros de errores. Un cortafuegos del panel que reescribe las tablas al aplicar sus reglas no elimina el agente de forma definitiva: la siguiente sincronización nota que la cadena ha desaparecido y la reconstruye, y reportedip-agent sync lo hace ahora mismo.

sources:
  - type: sshd
  - type: postfix
    path: /var/log/maillog
  - type: dovecot
    path: /var/log/maillog
  - type: web
    glob: "/var/www/vhosts/system/*/logs/access_log"
  - type: web
    glob: "/var/www/vhosts/system/*/logs/proxy_access_log"
  - type: web-error
    glob: "/var/www/vhosts/system/*/logs/error_log"

cPanel

Se reconoce por /usr/local/cpanel. Tres cosas difieren de un host normal. Los registros por dominio son los domlogs, normalmente /var/log/apache2/domlogs/ con /usr/local/apache/domlogs apuntando ahí; una fuente web con un glob los cubre. El servidor de correo es Exim y su registro es /var/log/exim_mainlog, que no es una de las rutas que busca el instalador, así que la fuente exim se añade a mano. Y donde corre csf, /var/log/lfd.log es una fuente propia, csf, y cada bloqueo que hace lfd se notifica a través de ella; Imunify360 tiene una fuente de sondeo, marcada como experimental. Ejecuta test primero con cada registro: un domlog con un formato personalizado no produce nada, y eso se aprende mejor en un terminal que con un contador vacío una semana después.

sources:
  - type: sshd
  - type: web
    glob: "/var/log/apache2/domlogs/*"
    exclude: ["*-ssl_log", "*.bkup*"]
  - type: exim
    path: /var/log/exim_mainlog
  - type: csf
    path: /var/log/lfd.log

DirectAdmin

Se reconoce por /usr/local/directadmin. Los registros por dominio suelen estar bajo /var/log/httpd/domains/, un <domain>.log y un <domain>.error.log por cada uno, y Exim escribe /var/log/exim/mainlog, que de nuevo no es una ruta que el instalador pruebe. Dos globs y una ruta cubren el host.

Un servidor de correo, un servidor de base de datos

Correo

Un host que ejecuta Postfix y Dovecot no necesita que se añada nada. El instalador ve los servicios o los puertos a la escucha y configura las dos fuentes sobre el único registro de correo, y la lista de correo cae en los puertos de correo fijos 25, 465, 587, 110, 995, 143 y 993. Los umbrales son por fuente de evento y bajos a propósito, porque un servidor de correo ve pocos fallos legítimos: tres fallos SASL en una hora, cinco destinatarios rechazados, tres rechazos de amavis, diez fallos de Dovecot. Un host que ejecuta Exim en su lugar recibe la fuente exim cuando el registro está en una de las rutas de Debian o de Red Hat. Lo que sale de la máquina es lo mismo que en todas partes: la dirección, los identificadores de categoría, una frase generada, y ninguna línea del registro.

Base de datos

Un host de base de datos que no escucha en nada más que SSH y el puerto de la base de datos recibe una fuente, sshd, y dos listas que importan: ssh en el puerto SSH y edge, que coincide con todos los puertos y por tanto también con el de la base de datos. El agente no lee ningún registro de base de datos, así que no verá una fuerza bruta contra la propia base de datos; la respuesta a eso no está en esta página, es una regla de cortafuegos que mantenga el puerto fuera de internet. Lo que añade el agente es que una dirección que la red ya conoce como atacante se descarta antes de su primer intento de conexión, en todos los puertos.

Contenedores LXC y cortafuegos en la nube

LXC en Proxmox

El agente necesita dos cosas de un contenedor: systemd, que un contenedor LXC con una distribución basada en systemd tiene, y un backend de cortafuegos que pueda usar, que es la pregunta abierta. Que nft o ipset puedan crear un conjunto dentro del contenedor depende de qué privilegios tenga el contenedor, y en uno sin privilegios normalmente no pueden. El instalador no adivina: el bloque de requisitos nombra el backend que encontró, y una instalación sin ninguno sigue adelante en modo solo notificar, cosa que doctor dice con todas las letras. Ejecuta un sync después de la instalación y lee status: una cadena que está ahí es la respuesta. Donde no está, el bloqueo corresponde al host Proxmox, y el contenedor sigue detectando y notificando.

Un VPS tras un cortafuegos en la nube

Un cortafuegos del proveedor filtra antes de que el paquete llegue al host. Lo que descarta nunca aparece en un registro, así que los contadores y los conjuntos del agente solo ven lo que el proveedor dejó pasar; no es un fallo, es el orden de las capas. En un VPS merece la pena hacer dos cosas. Mete el rango desde el que administras en la lista blanca justo después de la instalación, porque la lista blanca automática solo guarda la dirección desde la que vino la sesión. Y conoce el camino de vuelta antes de necesitarlo: la consola del proveedor va fuera de banda, no pasa por los conjuntos del núcleo, así que una dirección de administración bloqueada está a un reportedip-agent unban <address> desde la consola, y de todos modos cada bloqueo local caduca por sí solo.

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