1 30/10/2026 9 min

Arpwatch è uno di quegli strumenti piccoli ma utili che, in una rete reale, finiscono per fare differenza quando vuoi accorgerti in fretta di un cambio anomalo di MAC address, di una nuova associazione IP/MAC o di un possibile spoofing sulla LAN. Su AlmaLinux e Rocky Linux 8/9 l’installazione è abbastanza lineare, ma conviene farla con metodo: prima verifichi i pacchetti disponibili, poi prepari l’interfaccia da monitorare, quindi controlli che il demone scriva i log e invii gli avvisi nel modo atteso.

Qui l’obiettivo non è “installare e basta”, ma mettere Arpwatch in condizione di lavorare davvero. In pratica: scegliere la scheda giusta, evitare di lanciare il servizio a caso su un host che non vede traffico utile, e capire dove leggere gli eventi quando un indirizzo IP cambia proprietario o compare un dispositivo nuovo. Su una rete con più VLAN o con traffico segregato da switch gestiti, questa distinzione conta parecchio.

Che cosa fa Arpwatch e dove ha senso usarlo

Arpwatch ascolta i frame ARP su una interfaccia di rete e costruisce una cronologia delle associazioni IP/MAC osservate. Quando vede un cambiamento, può registrarlo nei log e, se configurato, inviare notifiche. Non sostituisce un IDS, non blocca nulla e non “protegge” da solo la rete: serve a dare visibilità. È quindi più utile su segmenti dove hai bisogno di sapere chi compare, chi cambia e quando accade, ad esempio in uffici, laboratori, reti di produzione con asset stabili o ambienti in cui i lease DHCP devono essere tenuti sotto controllo.

Su AlmaLinux e Rocky Linux 8/9 il punto chiave è che il pacchetto e il servizio esistono nei repository, ma spesso la parte meno banale è l’operatività: capire l’interfaccia corretta, leggere i log giusti e, se necessario, impostare una notifica locale o verso un indirizzo email che sia davvero raggiungibile.

Installazione dei pacchetti su AlmaLinux e Rocky Linux 8/9

Parti con un controllo della disponibilità del pacchetto e installa solo ciò che serve. Su sistemi RHEL-like recenti, il nome del pacchetto è in genere arpwatch.

sudo dnf clean all
sudo dnf makecache
sudo dnf install -y arpwatch

Dopo l’installazione, verifica che il pacchetto sia presente e che il servizio systemd sia stato creato:

rpm -q arpwatch
systemctl list-unit-files | grep -i arpwatch

Se il pacchetto non fosse disponibile nei repository abilitati, il problema non è Arpwatch in sé ma la configurazione dei repository del sistema. In quel caso il controllo da fare è su /etc/yum.repos.d/ e sullo stato della macchina rispetto a eventuali repository aziendali o mirror interni. Non improvvisare con pacchetti presi a mano: prima verifica la provenienza e, se serve, allinea i repo con il tuo standard di provisioning.

Scelta dell’interfaccia da monitorare

Arpwatch deve ascoltare sulla scheda che vede il traffico ARP che ti interessa. Su un server con più interfacce, bonding, VLAN o bridge, non dare per scontato che la prima scheda sia quella corretta. Il caso classico è il server che ha una NIC di management e una NIC di produzione: se monitori la management, vedrai poco o nulla di utile.

Identifica le interfacce attive e il loro ruolo con:

ip -br link
ip -br addr

Se vuoi capire quale interfaccia trasporta davvero il traffico, un controllo rapido con tcpdump aiuta molto. Un campione minimo di ARP è sufficiente per confermare che la scheda vede il dominio di broadcast giusto:

sudo tcpdump -ni enp1s0 arp

Se non vedi pacchetti ARP su quella scheda, Arpwatch non avrà nulla da osservare. In quel caso il fix non è nel demone ma nella selezione dell’interfaccia o nella topologia di rete.

Configurazione del servizio e del file di avvio

Sui sistemi AlmaLinux e Rocky, la configurazione principale è in genere in /etc/sysconfig/arpwatch oppure in un file equivalente usato dall’unità systemd installata dal pacchetto. Il primo passo è leggere la configurazione esistente, senza sovrascriverla alla cieca:

rpm -qc arpwatch
sudo cat /etc/sysconfig/arpwatch

In molti ambienti il parametro importante è l’interfaccia da monitorare. Un esempio tipico, da adattare al tuo host, può essere questo:

# /etc/sysconfig/arpwatch
INTERFACES="enp1s0"

Su alcune installazioni il formato può essere diverso e la variabile può essere già precompilata in modo leggermente differente. Per questo motivo il controllo del file reale installato dal pacchetto è più affidabile di un esempio generico. Se l’unità di sistema usa argomenti in linea, verifica anche con:

systemctl cat arpwatch

Se devi modificare il file, fai prima una copia di sicurezza. La modifica è reversibile e il blast radius è limitato al servizio Arpwatch, ma se sbagli interfaccia il demone resterà attivo senza osservare il segmento corretto.

sudo cp -a /etc/sysconfig/arpwatch /etc/sysconfig/arpwatch.bak.$(date +%F_%H%M%S)

Avvio, abilitazione e prima verifica operativa

Una volta impostata l’interfaccia, abilita e avvia il servizio. Qui la verifica non è solo “systemd dice active”, ma anche “il demone sta scrivendo eventi e non sta fallendo all’avvio”.

sudo systemctl daemon-reload
sudo systemctl enable --now arpwatch
systemctl status arpwatch --no-pager

Nel risultato cerca almeno tre cose: stato active (running), assenza di errori di configurazione e presenza del parametro dell’interfaccia corretta nei dettagli del servizio. Se il servizio non parte, il primo posto da controllare è il journal:

journalctl -u arpwatch -b --no-pager

Un errore frequente è il demone che parte ma non riesce ad aprire la scheda, spesso per nome interfaccia errato o permessi non coerenti con il contesto dell’unità. Un altro caso classico è la configurazione che punta a un device non più esistente dopo un cambio di naming della NIC o una migrazione del sistema.

Dove leggere i log e come interpretare gli eventi

Su sistemi moderni i log passano in gran parte da journald, ma Arpwatch può anche scrivere file locali, a seconda del packaging e della configurazione. Il controllo minimo, dopo l’avvio, è questo:

journalctl -u arpwatch -f

Se il pacchetto usa anche log testuali, cerca riferimenti a file sotto /var/log/. La posizione esatta dipende dalla build del pacchetto e dalla distribuzione, quindi conviene verificarla con la documentazione installata o con il contenuto del file di configurazione. Quando Arpwatch intercetta un nuovo host, un cambio di MAC o un evento sospetto, l’output deve essere abbastanza chiaro da permetterti di distinguere tra un cambiamento previsto e uno anomalo.

Un buon test pratico è generare un piccolo cambiamento nel segmento monitorato, ad esempio collegando un host noto o rinnovando la connessione di un dispositivo già presente. Se il traffico ARP passa davvero sulla scheda corretta, in pochi minuti dovresti vedere almeno un evento coerente con la topologia della rete. Se non compare nulla, torna subito alla verifica del layer fisico/logico della rete, non al tuning del demone.

Notifiche email: configurazione minima e limiti pratici

Arpwatch può inviare avvisi via email, ma questo funziona bene solo se il server ha una catena SMTP corretta. In molti ambienti la notifica locale è più semplice da attivare che non da rendere davvero affidabile. Se la macchina usa un MTA locale o un relay aziendale, controlla prima che l’invio mail sia già funzionante con strumenti standard del tuo ambiente.

Se il pacchetto prevede un indirizzo di destinazione o un alias, imposta un recapito che sia presidiato, non una casella personale lasciata lì per comodità. In un contesto operativo, l’alert deve arrivare a chi gestisce davvero la rete. Se non hai ancora una destinazione stabile, meglio tenere il logging locale e integrare le notifiche solo dopo aver validato il canale SMTP.

Per verificare il percorso mail, controlla la coda del MTA e i log del servizio di posta del sistema. Il problema non è quasi mai Arpwatch in sé, ma la delivery dell’email a valle. Se il recapito non è affidabile, il valore operativo del monitoraggio crolla rapidamente.

Hardening minimo e considerazioni di sicurezza

Arpwatch non espone normalmente una superficie d’attacco ampia, ma resta pur sempre un demone con accesso a informazioni di rete. Il principio prudente è semplice: eseguilo solo sul server necessario, monitora solo l’interfaccia utile e non dare per scontato che i log siano innocui se contengono dettagli di asset e indirizzi della tua rete interna.

Se il server è multiuso, valuta se isolare il servizio con i meccanismi standard del sistema, almeno evitando privilegi inutili e lasciando intatti i permessi dei file di configurazione. Inoltre, se il nodo è esposto o fa parte di una infrastruttura più ampia, tieni allineati aggiornamenti e policy di logging: un avviso di rete che non viene letto o conservato correttamente perde gran parte del suo valore.

Risoluzione dei problemi più comuni

Se Arpwatch parte ma non registra nulla, le cause più probabili sono poche e abbastanza ripetitive. La prima è l’interfaccia sbagliata: il servizio ascolta, ma sul segmento errato. La seconda è la mancanza di traffico ARP visibile su quella scheda, magari perché il server è su una rete troppo silenziosa o perché il dominio di broadcast è diverso da quello atteso. La terza è un problema di permessi o di unità systemd che non riesce a inizializzare correttamente il demone.

Per falsificare rapidamente queste ipotesi, basta un controllo in tre mosse: verifica il nome della NIC con ip -br addr, osserva il traffico con tcpdump -ni <interfaccia> arp e leggi il journal con journalctl -u arpwatch -b. In molti casi la diagnosi si chiude lì. Se invece trovi errori di configurazione, ripristina il backup del file modificato e riavvia il servizio per tornare a uno stato noto.

Se il servizio viene aggiornato o reinstallato, ricontrolla sempre il file effettivamente usato dal pacchetto, perché il path o la sintassi possono cambiare leggermente tra release e build diverse. È un dettaglio banale solo in apparenza: basta un parametro rimasto su una vecchia interfaccia per far sembrare “rotto” un servizio che in realtà sta solo guardando il posto sbagliato.

Esempio di verifica finale dopo l’installazione

Una sequenza finale sensata, dopo aver configurato tutto, è questa: servizio attivo, interfaccia corretta, traffico ARP osservabile, log popolati e nessun errore nel journal. Se vuoi fare una verifica rapida e ordinata, puoi usare questa checklist operativa:

  1. Il pacchetto arpwatch è installato con rpm -q arpwatch.
  2. Il servizio è attivo con systemctl status arpwatch --no-pager.
  3. L’interfaccia configurata è quella giusta e vede traffico ARP con tcpdump -ni <interfaccia> arp.
  4. Il journal mostra avvio pulito e nessun errore con journalctl -u arpwatch -b.
  5. Eventuali file di log locali o notifiche email risultano coerenti con il traffico della rete.

Assunzione: il sistema usa AlmaLinux o Rocky Linux 8/9 con repository standard abilitati e una sola interfaccia primaria da monitorare; se hai bonding, bridge, VLAN o policy di rete particolari, va adattata la scelta della scheda e il percorso di verifica.