Monitorizar anuncios BGP con BGPalerter

Si anuncias tus propios prefijos por BGP, necesitas saber cuándo algo sale mal. Un hijack de prefijo, una fuga de ruta, un error de configuración RPKI: estos incidentes pueden dejar tu red fuera de servicio o desviar tu tráfico a través de un atacante. BGPalerter vigila datos públicos de route collectors y te alerta en tiempo real.

Este tutorial instala BGPalerter v2 en Ubuntu 24.04, configura la monitorización de prefijos y ASN, establece notificaciones Slack y email, y ejecuta todo como servicio systemd. Asume que ya tienes BGP funcionando con BIRD2 o FRR.

¿Qué monitoriza BGPalerter y cómo funciona?

BGPalerter monitoriza tus prefijos BGP en tiempo real usando datos públicos de route collectors de RIPE RIS. Se conecta por WebSocket a ris-live.ripe.net, que agrega feeds de más de 600 peers en todo el mundo. No requiere integración con tus routers. Funciona en cualquier servidor Linux con acceso a internet saliente.

BGPalerter incluye estos monitores:

Monitor	Qué detecta	Canal por defecto
monitorHijack	AS de origen incorrecto, hijacks de sub-prefijo	hijack
monitorVisibility	Prefijo retirado o visto por muy pocos peers	visibility
monitorNewPrefix	Sub-prefijo inesperado anunciado por tu AS	newprefix
monitorPath	El camino AS coincide con un patrón regex (scrubbing, cambio de tránsito)	path
monitorPathNeighbors	AS upstream/downstream inesperado en el camino	path
monitorAS	Tu ASN anuncia un prefijo no declarado	misconfiguration
monitorRPKI	Prefijo anunciado con estado RPKI inválido	rpki
monitorROAS	ROA añadido, editado, eliminado o por expirar	roa

Cada monitor tiene un parámetro thresholdMinPeers. Una alerta solo se dispara cuando la anomalía es confirmada por al menos ese número de peers del route collector, lo que reduce los falsos positivos.

¿Cómo instalo BGPalerter en Ubuntu 24.04?

Descarga el último binario de BGPalerter desde GitHub y hazlo ejecutable. No necesitas instalar Node.js al usar el binario precompilado. El binario autónomo incluye el runtime de Node.js; cuenta con al menos 1 GB de RAM libre en el servidor de monitorización.

Crear un usuario dedicado

Ejecuta BGPalerter bajo su propia cuenta sin privilegios. Nunca ejecutes herramientas de monitorización de red como root sin motivo.

sudo adduser --system --group --home /opt/bgpalerter --shell /usr/sbin/nologin bgpalerter

Descargar el binario

cd /opt/bgpalerter
sudo -u bgpalerter curl -Lo /opt/bgpalerter/bgpalerter-linux-x64 https://github.com/nttgin/BGPalerter/releases/latest/download/bgpalerter-linux-x64
sudo chmod +x /opt/bgpalerter/bgpalerter-linux-x64

ls -la /opt/bgpalerter/bgpalerter-linux-x64

El archivo debería pesar unos 140 MB. El binario es autónomo e incluye el runtime de Node.js. Sin dependencias externas.

Alternativa con Docker

Si prefieres contenedores:

docker run -d --name bgpalerter \
  -v /opt/bgpalerter/volume:/opt/bgpalerter/volume \
  --restart unless-stopped \
  nttgin/bgpalerter:latest run serve -- --d /opt/bgpalerter/volume/

Coloca tus archivos config.yml y prefixes.yml en /opt/bgpalerter/volume/ antes de iniciar el contenedor. El resto de este tutorial cubre el método del binario. Los archivos de configuración son idénticos en ambos casos.

¿Cómo configuro prefixes.yml para monitorizar mi ASN?

BGPalerter necesita saber qué prefijos y ASN te pertenecen. El comando generate consulta datos de enrutamiento públicos y construye prefixes.yml a partir de lo que tu AS anuncia actualmente.

sudo -u bgpalerter /opt/bgpalerter/bgpalerter-linux-x64 generate \
  -a YOUR_ASN \
  -o /opt/bgpalerter/prefixes.yml \
  -i -m

Sustituye YOUR_ASN por tu número de AS (solo dígitos, sin prefijo «AS»). Las opciones:

Opción	Propósito
`-a`	ASN(s) a monitorizar. Separados por comas para varios: `-a 64496,64497`
`-o`	Ruta del archivo de salida
`-i`	Ignorar prefijos delegados (originados por otros ASN)
`-m`	Detectar automáticamente todos los ASN de origen de tus prefijos

El comando produce un archivo como este:

198.51.100.0/24:
  description: Production network
  asn: 64496
  ignoreMorespecifics: false
  ignore: false

2001:db8::/32:
  description: IPv6 allocation
  asn: 64496
  ignoreMorespecifics: false
  ignore: false

options:
  monitorASns:
    64496:
      group: default

Campos principales

ignoreMorespecifics: Ponlo a true si desagregas intencionalmente (por ejemplo, anuncias tanto /24 como /25). En false, BGPalerter alerta ante cualquier anuncio más específico inesperado. Para la mayoría de operadores, false es el valor correcto. Los more-specifics inesperados son señal de hijack.

options.monitorASns: Activa monitorAS para tu ASN. BGPalerter alerta si tu ASN empieza a originar un prefijo no listado en el archivo.

group: Controla el enrutamiento de alertas. El grupo default se asocia a los canales de notificación. Puedes crear grupos separados (por ejemplo noc, engineering) y dirigirlos a diferentes canales Slack o listas de correo.

Edita el archivo generado para añadir descripciones, ajustar ignoreMorespecifics por prefijo o añadir prefijos que aún no se anuncian pero deben vigilarse contra originación no autorizada.

¿Cómo configuro config.yml?

El asistente de configuración automática crea un config.yml por defecto en el primer arranque. Para producción, quieres control explícito sobre cada parámetro.

Crea /opt/bgpalerter/config.yml:

connectors:
  - file: connectorRIS
    name: ris
    params:
      carefulSubscription: true
      url: ws://ris-live.ripe.net/v1/ws/
      perMessageDeflate: true

monitors:
  - file: monitorHijack
    channel: hijack
    name: basic-hijack-detection
    params:
      thresholdMinPeers: 3

  - file: monitorVisibility
    channel: visibility
    name: withdrawal-detection
    params:
      thresholdMinPeers: 40
      notificationIntervalSeconds: 3600

  - file: monitorNewPrefix
    channel: newprefix
    name: newprefix-detection
    params:
      thresholdMinPeers: 3

  - file: monitorAS
    channel: misconfiguration
    name: asn-monitor
    params:
      thresholdMinPeers: 3

  - file: monitorRPKI
    channel: rpki
    name: rpki-monitor
    params:
      thresholdMinPeers: 3
      checkUncovered: true
      checkDisappearing: true

  - file: monitorROAS
    channel: roa
    name: rpki-diff
    params:
      enableDiffAlerts: true
      enableExpirationAlerts: true
      roaExpirationAlertHours: 2
      checkOnlyASns: true

  - file: monitorPathNeighbors
    channel: path
    name: path-neighbors
    params:
      thresholdMinPeers: 3

reports:
  - file: reportFile
    channels:
      - hijack
      - newprefix
      - visibility
      - path
      - misconfiguration
      - rpki
      - roa
    params:
      persistAlertData: false
      alertDataDirectory: alertdata/

notificationIntervalSeconds: 86400
persistStatus: true
alertOnlyOnce: false
fadeOffSeconds: 360
checkFadeOffGroupsSeconds: 30

logging:
  directory: logs
  logRotatePattern: YYYY-MM-DD
  maxRetainedFiles: 30
  maxFileSizeMB: 15
  compressOnRotation: true
  useUTC: true

rest:
  host: localhost
  port: 8011

rpki:
  vrpProvider: rpkiclient
  refreshVrpListMinutes: 15

monitoredPrefixesFiles:
  - prefixes.yml

checkForUpdatesAtBoot: true
generatePrefixListEveryDays: 0
pidFile: bgpalerter.pid
maxMessagesPerSecond: 6000
multiProcess: false
environment: production
configVersion: 2

Notas sobre el conector

connectorRIS transmite actualizaciones BGP en directo desde RIPE RIS vía WebSocket. El parámetro carefulSubscription: true limita el flujo a tus prefijos monitorizados, reduciendo ancho de banda y CPU.

Tu firewall debe permitir conexiones WebSocket salientes a ris-live.ripe.net en el puerto 80 (ws://) o 443 (wss://). No se necesitan reglas de entrada.

La sección rest expone una API HTTP local en el puerto 8011 para comprobaciones de estado. Por defecto escucha en localhost, así que no está expuesta a la red.

Ajuste de monitores

thresholdMinPeers controla la sensibilidad. Un valor de 3 significa que al menos 3 peers del route collector deben confirmar una anomalía antes de generar una alerta. Valores más bajos capturan más eventos pero producen más falsos positivos. Para detección de hijacks, 3 es un buen punto de partida. Para visibilidad, 40 es apropiado ya que RIPE RIS tiene más de 600 peers.

notificationIntervalSeconds a nivel de monitor sobreescribe el parámetro global. Para visibilidad, 3600 (1 hora) previene la fatiga de alertas durante episodios de flapping.

¿Cómo monitorizo anuncios RPKI inválidos con BGPalerter?

BGPalerter comprueba la validez RPKI de cada anuncio BGP recibido para tus prefijos. Si tu prefijo aparece con estado RPKI inválido, recibes una alerta. Esto detecta errores de configuración ROA y ciertos tipos de hijacks que el filtrado basado en RPKI rechazaría.

La sección monitorRPKI en config.yml se encarga de esto:

checkUncovered: true alerta cuando tu prefijo no tiene ROA. Cada prefijo anunciado debería tener cobertura ROA.
checkDisappearing: true alerta cuando un ROA que cubría tu prefijo desaparece.

El módulo separado monitorROAS vigila cambios de ROA a nivel RPKI: nuevos ROA creados, ROA existentes editados o eliminados, y ROA próximos a expirar. El parámetro roaExpirationAlertHours: 2 te avisa 2 horas antes de que expire un ROA.

Un ejemplo de alerta RPKI:

The prefix 198.51.100.0/24 (AS64496) is announced with RPKI state Invalid.
Seen by 5 peers. Top 3 AS paths: 64496 174 3356, 64496 6939, 64496 1299

¿Cómo configuro alertas por email en BGPalerter?

Añade un bloque reportEmail a la sección reports de config.yml. BGPalerter usa SMTP directamente.

reports:
  # ... mantén reportFile de arriba ...

  - file: reportEmail
    channels:
      - hijack
      - newprefix
      - visibility
      - path
      - misconfiguration
      - rpki
      - roa
    params:
      showPaths: 5
      senderEmail: bgpalerter@example.com
      smtp:
        host: mail.example.com
        port: 587
        secure: false
        ignoreTLS: false
        auth:
          user: bgpalerter@example.com
          pass: your-smtp-password-here
          type: login
        tls:
          rejectUnauthorized: true
      notifiedEmails:
        default:
          - noc@example.com

Sustituye los valores SMTP por los de tu servidor de correo. El parámetro showPaths: 5 incluye hasta 5 caminos AS en el email de alerta para ver por dónde se propagó la ruta anómala.

Dado que config.yml contiene la contraseña SMTP en texto plano, restringe los permisos del archivo para que solo el usuario bgpalerter y root puedan leerlo:

sudo chown root:bgpalerter /opt/bgpalerter/config.yml
sudo chmod 640 /opt/bgpalerter/config.yml

La sección notifiedEmails asocia grupos a direcciones de correo. El grupo default recibe todas las alertas. Si definiste grupos personalizados en prefixes.yml, añade las entradas correspondientes:

      notifiedEmails:
        default:
          - noc@example.com
        noc:
          - oncall@example.com
          - sre@example.com

¿Cómo configuro notificaciones Slack en BGPalerter?

Añade un bloque reportSlack a la sección reports. Necesitas una URL de webhook entrante de Slack.

Crea el webhook en Slack: ve a la configuración de tu workspace, busca «Incoming Webhooks» en Apps y crea un webhook para el canal donde quieras recibir alertas.

reports:
  # ... mantén reportFile y reportEmail ...

  - file: reportSlack
    channels:
      - hijack
      - newprefix
      - visibility
      - path
      - misconfiguration
      - rpki
      - roa
    params:
      showPaths: 3
      colors:
        hijack: "#d60b1c"
        newprefix: "#fa9548"
        visibility: "#fad648"
        path: "#42cbf5"
        rpki: "#d892f0"
        roa: "#d892f0"
      hooks:
        default: https://hooks.slack.com/services/T00/B00/xxxx

El mapa colors asigna un color distinto a cada tipo de alerta en Slack. Rojo para hijacks, amarillo para pérdida de visibilidad, violeta para problemas RPKI.

Sustituye la URL del webhook por tu webhook real de Slack. Los permisos de config.yml establecidos antes (640, root:bgpalerter) mantienen la URL del webhook legible solo por el servicio.

¿Cómo ejecuto BGPalerter como servicio systemd?

Crear la unidad systemd

sudo tee /etc/systemd/system/bgpalerter.service > /dev/null << 'EOF'
[Unit]
Description=BGPalerter - BGP Monitoring
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=bgpalerter
Group=bgpalerter
WorkingDirectory=/opt/bgpalerter
ExecStart=/opt/bgpalerter/bgpalerter-linux-x64
Restart=on-failure
RestartSec=30s

# Hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/opt/bgpalerter
PrivateTmp=true

[Install]
WantedBy=multi-user.target
EOF

Las directivas ProtectSystem=strict y ProtectHome=true restringen el acceso al sistema de archivos. BGPalerter solo necesita escribir en su propio directorio.

Activar e iniciar

sudo systemctl daemon-reload
sudo systemctl enable --now bgpalerter

enable hace que el servicio arranque con el sistema. --now lo inicia de inmediato.

systemctl status bgpalerter

● bgpalerter.service - BGPalerter - BGP Monitoring
     Loaded: loaded (/etc/systemd/system/bgpalerter.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-03-20 10:20:00 UTC; 5s ago
   Main PID: 1373 (bgpalerter-linu)
      Tasks: 10 (limit: 9443)
     Memory: 724.3M
        CPU: 4.483s
     CGroup: /system.slice/bgpalerter.service
             └─1373 /opt/bgpalerter/bgpalerter-linux-x64

El binario autónomo incluye todo el runtime de Node.js, por lo que el consumo base de memoria ronda los 500-800 MB sin importar la cantidad de prefijos. Asegúrate de tener al menos 1 GB de RAM libre en el servidor de monitorización.

Consultar los logs

journalctl -u bgpalerter -f --no-pager

Al arrancar, BGPalerter carga la configuración y se conecta a RIPE RIS. Las primeras líneas en el journal son:

Loaded config: /opt/bgpalerter/config.yml
BGPalerter, version: 2.0.1 environment: production

BGPalerter también escribe logs en /opt/bgpalerter/logs/. El parámetro logRotatePattern: YYYY-MM-DD crea un archivo de log diario. Con maxRetainedFiles: 30 y compressOnRotation: true, conservas un mes de logs comprimidos sin intervención manual.

¿Cómo pruebo las alertas de BGPalerter?

Ejecuta BGPalerter con la opción -t para enviar alertas de prueba a través de todos los canales de notificación configurados. El conector de prueba integrado simula cada tipo de alerta sin esperar eventos BGP reales.

sudo -u bgpalerter /opt/bgpalerter/bgpalerter-linux-x64 -t

Esto envía mensajes de prueba a tu canal Slack y por email. Comprueba que las alertas lleguen con el formato y enrutamiento correctos. Si definiste varios grupos, cada uno debe recibir las alertas que le corresponden.

Para monitorización continua, consulta el journal:

journalctl -u bgpalerter --since "1 hour ago" --no-pager

¿Cómo se compara BGPalerter con las alternativas?

BGPalerter no es la única opción de monitorización BGP. Aquí tienes una comparación rápida:

Herramienta	Tipo	Caso de uso principal
BGPalerter	Autoalojado, open source	AS único, monitorización de prefijos, alertas en tiempo real
ARTEMIS	Autoalojado, open source	Redes grandes, módulos de detección personalizados, investigación
Cloudflare Radar	SaaS	Consulta rápida, sin autoalojamiento, alertas limitadas
BGPStream	Biblioteca/SaaS	Análisis programático, investigación con datos históricos
bgp.tools	SaaS	Exploración visual, datos comunitarios, comprobaciones rápidas

BGPalerter encaja bien en el caso de un AS único autoalojado. No requiere integración con routers y funciona en un VPS pequeño. ARTEMIS es más potente pero bastante más complejo de desplegar.

Para defensa en profundidad, combina BGPalerter con el despliegue de ROA RPKI y un filtrado de rutas adecuado en tus sesiones BGP.

¿Algo salió mal?

BGPalerter se cierra inmediatamente: Comprueba journalctl -u bgpalerter -e. Causas frecuentes: YAML mal formado en config.yml o prefixes.yml. Valida con python3 -c "import yaml; yaml.safe_load(open('config.yml'))".

Sin datos de RIPE RIS: Tu firewall debe permitir conexiones salientes a ris-live.ripe.net en el puerto 80 (WebSocket). Si estás detrás de un proxy restrictivo, usa la URL wss:// en el puerto 443. Actualiza la URL del conector en config.yml.

Las alertas no llegan (email): Ejecuta con -t para aislar el problema. Verifica las credenciales SMTP en config.yml. Comprueba que la dirección del remitente esté autorizada por tu servidor de correo (SPF, autenticación). Revisa journalctl -u bgpalerter en busca de mensajes de error SMTP.

Las alertas no llegan (Slack): Verifica que la URL del webhook sea válida. Slack desactiva los webhooks de apps sin uso. Prueba el webhook directamente: curl -X POST -H 'Content-type: application/json' --data '{"text":"test"}' "https://hooks.slack.com/services/T00/B00/xxxx".

Consumo de memoria alto: Las listas grandes de prefijos consumen más memoria. Si monitorizas muchos ASN, aumenta el swap o divide en varias instancias de BGPalerter con archivos de prefijos separados.

El servicio no se reinicia: RestartSec=30s en el archivo de unidad añade un retardo de 30 segundos entre intentos de reinicio. Para fallos persistentes, comprueba el código de salida en systemctl status bgpalerter.

Copyright 2026 Virtua.Cloud. Todos los derechos reservados. Este contenido es una obra original del equipo de Virtua.Cloud. La reproducción, republicación o redistribución sin permiso escrito está prohibida.

Monitorizar anuncios BGP con BGPalerter en Linux