Monitorare gli annunci BGP con BGPalerter su Linux

9 min di lettura·Matthieu·rpkinetworkingbgpalertermonitoringbgp|

Installa BGPalerter v2 su un VPS Linux per monitorare i tuoi prefissi contro hijack, route leak e stati RPKI non validi. Configura avvisi Slack e email, eseguilo come servizio systemd.

Se annunci i tuoi prefissi via BGP, devi sapere quando qualcosa va storto. Un hijack di prefisso, un route leak, un errore di configurazione RPKI: questi incidenti possono portare offline la tua rete o instradare il traffico attraverso un attaccante. BGPalerter controlla i dati pubblici dei route collector e ti avvisa in tempo reale.

Questo tutorial installa BGPalerter v2 su Ubuntu 24.04, configura il monitoraggio di prefissi e ASN, imposta le notifiche Slack e email, e fa girare il tutto come servizio systemd. Presuppone che BGP sia già in funzione con BIRD2 o FRR.

Cosa monitora BGPalerter e come funziona?

BGPalerter monitora i tuoi prefissi BGP in tempo reale usando i dati pubblici dei route collector di RIPE RIS. Si connette via WebSocket a ris-live.ripe.net, che aggrega feed da oltre 600 peer nel mondo. Non richiede integrazione con i tuoi router. Gira su qualsiasi server Linux con accesso internet in uscita.

BGPalerter include questi monitor:

Monitor Cosa rileva Canale predefinito
monitorHijack AS di origine errato, hijack di sotto-prefisso hijack
monitorVisibility Prefisso ritirato o visto da troppo pochi peer visibility
monitorNewPrefix Sotto-prefisso inatteso annunciato dal tuo AS newprefix
monitorPath Il percorso AS corrisponde a un pattern regex (scrubbing, cambio di transit) path
monitorPathNeighbors AS upstream/downstream inatteso nel percorso path
monitorAS Il tuo ASN annuncia un prefisso non dichiarato misconfiguration
monitorRPKI Prefisso annunciato con stato RPKI non valido rpki
monitorROAS ROA aggiunto, modificato, eliminato o in scadenza roa

Ogni monitor ha un parametro thresholdMinPeers. Un avviso scatta solo quando l'anomalia è confermata da almeno quel numero di peer del route collector, riducendo i falsi positivi.

Come installo BGPalerter su Ubuntu 24.04?

Scarica l'ultimo binario di BGPalerter da GitHub e rendilo eseguibile. Non serve installare Node.js con il binario precompilato. Il binario autonomo include il runtime Node.js; prevedi almeno 1 GB di RAM libera sul server di monitoraggio.

Creare un utente dedicato

Esegui BGPalerter con un account non privilegiato dedicato. Non eseguire mai strumenti di monitoraggio di rete come root senza motivo.

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

Scaricare il 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

Il file dovrebbe pesare circa 140 MB. Il binario è autonomo e include il runtime Node.js. Nessuna dipendenza esterna.

Alternativa Docker

Se preferisci i container:

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

Posiziona i file config.yml e prefixes.yml in /opt/bgpalerter/volume/ prima di avviare il container. Il resto di questo tutorial copre il metodo binario. I file di configurazione sono identici in entrambi i casi.

Come configuro prefixes.yml per monitorare il mio ASN?

BGPalerter deve sapere quali prefissi e ASN ti appartengono. Il comando generate interroga i dati di routing pubblici e costruisce prefixes.yml in base a ciò che il tuo AS annuncia attualmente.

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

Sostituisci YOUR_ASN con il tuo numero AS (solo cifre, senza il prefisso "AS"). Le opzioni:

Opzione Scopo
-a ASN da monitorare. Separati da virgola per più ASN: -a 64496,64497
-o Percorso del file di output
-i Ignora i prefissi delegati (originati da altri ASN)
-m Rileva automaticamente tutti gli ASN di origine dei tuoi prefissi

Il comando produce un file come questo:

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

Campi principali

ignoreMorespecifics: Imposta a true se deaggreghi intenzionalmente (ad esempio, annunci sia /24 che /25). Con false, BGPalerter avvisa per qualsiasi annuncio più specifico inatteso. Per la maggior parte degli operatori, false è il valore corretto. More-specific inattesi sono un segnale di hijack.

options.monitorASns: Abilita monitorAS per il tuo ASN. BGPalerter avvisa se il tuo ASN inizia a originare un prefisso non presente nel file.

group: Controlla l'instradamento degli avvisi. Il gruppo default è associato ai canali di notifica. Puoi creare gruppi separati (ad esempio noc, engineering) e indirizzarli a diversi canali Slack o mailing list.

Modifica il file generato per aggiungere descrizioni, regolare ignoreMorespecifics per prefisso, o aggiungere prefissi non ancora annunciati ma da monitorare contro l'originazione non autorizzata.

Come configuro config.yml?

L'assistente di configurazione automatica crea un config.yml predefinito al primo avvio. Per la produzione, serve un controllo esplicito su ogni parametro.

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

Note sul connettore

connectorRIS trasmette in streaming gli aggiornamenti BGP da RIPE RIS via WebSocket. L'impostazione carefulSubscription: true limita lo stream ai soli prefissi monitorati, riducendo banda e CPU.

Il firewall deve consentire connessioni WebSocket in uscita verso ris-live.ripe.net sulla porta 80 (ws://) o 443 (wss://). Non servono regole in ingresso.

La sezione rest espone un'API HTTP locale sulla porta 8011 per health check. È in ascolto su localhost per impostazione predefinita, quindi non è esposta alla rete.

Regolazione dei monitor

thresholdMinPeers controlla la sensibilità. Un valore di 3 significa che almeno 3 peer del route collector devono confermare un'anomalia prima di generare un avviso. Valori più bassi catturano più eventi ma producono più falsi positivi. Per il rilevamento hijack, 3 è un buon punto di partenza. Per la visibilità, 40 è appropriato dato che RIPE RIS ha oltre 600 peer.

notificationIntervalSeconds a livello di monitor sovrascrive l'impostazione globale. Per la visibilità, 3600 (1 ora) previene l'affaticamento da avvisi durante il flapping.

Come monitoro gli annunci RPKI non validi con BGPalerter?

BGPalerter verifica la validità RPKI di ogni annuncio BGP ricevuto per i tuoi prefissi. Se il tuo prefisso appare con stato RPKI non valido, ricevi un avviso. Questo rileva errori di configurazione ROA e certi tipi di hijack che il filtraggio basato su RPKI rifiuterebbe.

La sezione monitorRPKI in config.yml gestisce questo:

  • checkUncovered: true avvisa quando il tuo prefisso non ha ROA. Ogni prefisso annunciato dovrebbe avere copertura ROA.
  • checkDisappearing: true avvisa quando un ROA che copriva il tuo prefisso scompare.

Il modulo separato monitorROAS controlla i cambiamenti ROA a livello RPKI: nuovi ROA creati, ROA esistenti modificati o eliminati, e ROA in prossimità di scadenza. L'impostazione roaExpirationAlertHours: 2 ti avvisa 2 ore prima della scadenza di un ROA.

Un esempio di avviso 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

Come configuro gli avvisi email in BGPalerter?

Aggiungi un blocco reportEmail alla sezione reports di config.yml. BGPalerter usa SMTP direttamente.

reports:
  # ... mantieni reportFile di sopra ...

  - 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

Sostituisci i valori SMTP con quelli del tuo server di posta. L'impostazione showPaths: 5 include fino a 5 percorsi AS nell'email di avviso per vedere dove si è propagata la rotta anomala.

Poiché config.yml contiene la password SMTP in chiaro, limita i permessi del file in modo che solo l'utente bgpalerter e root possano leggerlo:

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

La sezione notifiedEmails mappa i gruppi agli indirizzi email. Il gruppo default riceve tutti gli avvisi. Se hai definito gruppi personalizzati in prefixes.yml, aggiungi le voci corrispondenti:

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

Come configuro le notifiche Slack in BGPalerter?

Aggiungi un blocco reportSlack alla sezione reports. Serve un URL webhook Slack in entrata.

Crea il webhook in Slack: vai nelle impostazioni del workspace, trova "Incoming Webhooks" sotto Apps, e crea un webhook per il canale dove vuoi ricevere gli avvisi.

reports:
  # ... mantieni reportFile e 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

La mappa colors assegna un colore distinto a ogni tipo di avviso in Slack. Rosso per gli hijack, giallo per la perdita di visibilità, viola per i problemi RPKI.

Sostituisci l'URL placeholder del webhook con il tuo webhook Slack reale. I permessi di config.yml impostati in precedenza (640, root:bgpalerter) mantengono l'URL del webhook leggibile solo dal servizio.

Come eseguo BGPalerter come servizio systemd?

Creare l'unità 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

Le direttive ProtectSystem=strict e ProtectHome=true limitano l'accesso al filesystem. BGPalerter deve scrivere solo nella propria directory.

Abilitare e avviare

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

enable fa partire il servizio all'avvio. --now lo avvia subito.

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

Il binario autonomo include l'intero runtime Node.js, quindi il consumo di memoria base è circa 500-800 MB indipendentemente dal numero di prefissi. Assicurati di avere almeno 1 GB di RAM libera sul server di monitoraggio.

Controllare i log

journalctl -u bgpalerter -f --no-pager

All'avvio, BGPalerter carica la configurazione e si connette a RIPE RIS. Le prime righe nel journal sono:

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

BGPalerter scrive anche log in /opt/bgpalerter/logs/. L'impostazione logRotatePattern: YYYY-MM-DD crea un nuovo file di log ogni giorno. Con maxRetainedFiles: 30 e compressOnRotation: true, mantieni un mese di log compressi senza intervento manuale.

Come testo gli avvisi di BGPalerter?

Avvia BGPalerter con il flag -t per inviare avvisi di test attraverso tutti i canali di notifica configurati. Il connettore di test integrato simula ogni tipo di avviso senza attendere eventi BGP reali.

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

Questo invia messaggi di test al tuo canale Slack e via email. Verifica che gli avvisi arrivino con la formattazione e l'instradamento corretti. Se hai definito più gruppi, ognuno deve ricevere gli avvisi assegnati.

Per il monitoraggio continuo, consulta il journal:

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

Come si confronta BGPalerter con le alternative?

BGPalerter non è l'unica opzione di monitoraggio BGP. Ecco un confronto rapido:

Strumento Tipo Caso d'uso principale
BGPalerter Self-hosted, open source AS singolo, monitoraggio prefissi, avvisi in tempo reale
ARTEMIS Self-hosted, open source Grandi reti, moduli di rilevamento personalizzati, ricerca
Cloudflare Radar SaaS Consultazione rapida, niente self-hosting, alerting limitato
BGPStream Libreria/SaaS Analisi programmatica, ricerca su dati storici
bgp.tools SaaS Esplorazione visiva, dati della community, controlli rapidi

BGPalerter si adatta bene al caso d'uso di un singolo AS self-hosted. Non richiede integrazione router e gira su un piccolo VPS. ARTEMIS è più potente ma molto più complesso da deployare.

Per una difesa in profondità, combina BGPalerter con il deploy di ROA RPKI e un filtraggio delle rotte adeguato sulle tue sessioni BGP.

Qualcosa non funziona?

BGPalerter esce immediatamente: Controlla journalctl -u bgpalerter -e. Cause comuni: YAML malformato in config.yml o prefixes.yml. Valida con python3 -c "import yaml; yaml.safe_load(open('config.yml'))".

Nessun dato da RIPE RIS: Il firewall deve consentire connessioni in uscita verso ris-live.ripe.net sulla porta 80 (WebSocket). Se sei dietro un proxy restrittivo, usa l'URL wss:// sulla porta 443. Aggiorna l'URL del connettore in config.yml di conseguenza.

Avvisi non ricevuti (email): Avvia con -t per isolare il problema. Controlla le credenziali SMTP in config.yml. Verifica che l'indirizzo mittente sia consentito dal server di posta (SPF, autenticazione). Consulta journalctl -u bgpalerter per messaggi di errore SMTP.

Avvisi non ricevuti (Slack): Verifica che l'URL del webhook sia valido. Slack disattiva i webhook delle app inutilizzate. Testa il webhook direttamente: curl -X POST -H 'Content-type: application/json' --data '{"text":"test"}' "https://hooks.slack.com/services/T00/B00/xxxx".

Consumo di memoria elevato: Liste di prefissi grandi consumano più memoria. Se monitori molti ASN, aumenta lo swap o dividi in più istanze BGPalerter con file di prefissi separati.

Il servizio non si riavvia: RestartSec=30s nel file di unità aggiunge un ritardo di 30 secondi tra i tentativi di riavvio. Per fallimenti persistenti, controlla il codice di uscita in systemctl status bgpalerter.

Copyright 2026 Virtua.Cloud. Tutti i diritti riservati. Questo contenuto è un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta è vietata.

Pronto a provare?

Distribuisci il tuo server in pochi secondi. Linux, Windows o FreeBSD.

Vedi piani VPS

Articoli correlati