Verificare la cache dei vicini ARP e NDP in Sophos Firewall
Se un dispositivo non è raggiungibile nonostante l’indirizzo IP sia corretto, il problema non è necessariamente una regola firewall o una route errata. Nella rete locale, Sophos Firewall necessita anche dell’indirizzo MAC corretto della destinazione. Questa associazione viene memorizzata nella cache dei vicini.
In Network > Neighbors (ARP–NDP) è possibile verificare quale indirizzo MAC e quale interfaccia sono attualmente associati a un indirizzo IP. Per prima cosa si documenta la voce esistente e la si confronta con la situazione reale della rete. La cache interessata va svuotata e riappresa solo se l’associazione è obsoleta.
Le etichette e i comandi di questa procedura si riferiscono a SFOS 22.0. La diagnosi inizia in WebAdmin; la Device Console serve solo per le verifiche aggiuntive espressamente descritte di seguito.
⚠️ Flush svuota la cache IPv4 o IPv6 selezionata, non una sola riga. Su un firewall di produzione è quindi opportuno registrare prima la voce corrente, limitare l’ambito del test ed evitare di svuotare la cache durante un picco di carico.
Funzione di ARP, NDP e della cache dei vicini
ARP associa un indirizzo IPv4 a un indirizzo MAC nel segmento locale di livello 2. Si tratta di un dispositivo direttamente raggiungibile, in genere nella stessa VLAN. Per IPv6, il Neighbor Discovery Protocol (NDP) svolge questa funzione tramite ICMPv6. Il firewall ha bisogno di queste informazioni prima di poter inviare un pacchetto al vicino successivo tramite un’interfaccia collegata direttamente.
Con IPv4, un dispositivo utilizza una richiesta ARP per chiedere l’indirizzo MAC associato a un indirizzo IP. La risposta fornisce l’associazione con cui il firewall aggiorna la propria cache dei vicini. Le associazioni IP-MAC già apprese vengono riutilizzate per ridurre il traffico broadcast; per IPv6, NDP esegue la corrispondente risoluzione dei vicini.
Le voci dinamiche dei vicini vengono apprese e aggiornate continuamente. Il timeout predefinito documentato per le richieste ARP e NDP è di 600 secondi (10 minuti). Questo non garantisce che ogni singola voce scompaia esattamente dopo 600 secondi: le cache persistono fino a uno svuotamento automatico o manuale. Il firewall può quindi apprendere nuovamente le associazioni attuali. Una voce obsoleta può comparire, ad esempio, dopo un cambio di dispositivo, scheda di rete o VM. Un indirizzo IP assegnato due volte, invece, può far cambiare ripetutamente l’indirizzo MAC visibile.
In Neighbor cache entry timeout è possibile modificare l’intervallo di svuotamento automatico e applicarlo con Apply. Un valore più breve forza un riapprendimento più frequente e non corregge indirizzi IP duplicati, VLAN errate o associazioni statiche obsolete. Prima della modifica si annota quindi il valore iniziale. Se il test non porta benefici, si ripristina esattamente quel valore, si seleziona Apply e si verifica di nuovo il percorso dati reale.
Per l’automazione XML: La documentazione di riferimento XML per SFOS 22.0 e 23.0 descrive, sotto ARPConfiguration, il parametro ARPCacheEntryTimeOut come intervallo di svuotamento della cache: valore predefinito documentato di 2 minuti, intervallo 1–500; l’esempio riporta Minutes. Si tratta di valori di riferimento, non della prova di un valore attuale in uso a runtime né del fatto che si tratti dello stesso controllo descritto nella guida dell’interfaccia utente per il timeout di 600 secondi delle richieste ARP/NDP. Questa entità ARP per IPv4 non dimostra neppure l’esistenza di una configurazione generale di tutte le proprietà NDP per IPv6. Nessuno di questi valori documentati va adottato come valore automatico di ripristino o di ottimizzazione: resta determinante il valore corrente rilevato prima della modifica, che va ripristinato esattamente quando si annulla la modifica; successivamente si verifica nuovamente il servizio originale.
La cache dei vicini riguarda solo i dispositivi direttamente raggiungibili nel rispettivo segmento di livello 2. Per una destinazione remota, il firewall memorizza l’indirizzo MAC del router successivo, non quello del server di destinazione.
Non è la stessa cosa di Proxy ARP: in quel caso il firewall risponde su un’interfaccia, per conto di un altro indirizzo di destinazione, alla relativa richiesta ARP IPv4. Questo caso particolare è trattato separatamente in Configurare e verificare Proxy ARP su Sophos Firewall.
Identificare ARP flux su più interfacce
ARP flux può verificarsi quando più interfacce Ethernet fisiche di Sophos Firewall sono collegate allo stesso mezzo Layer 2 o alla stessa broadcast domain. Il firewall può quindi rispondere a una richiesta ARP attraverso entrambe le interfacce, mostrando al dispositivo richiedente associazioni MAC variabili o inattese. Due VLAN separate, un LAG configurato in modo errato o un normale indirizzo IP duplicato non costituiscono automaticamente ARP flux.
Una breve acquisizione dei pacchetti serve esclusivamente a verificare il comportamento ARP: occorre controllare se la stessa richiesta raggiunge entrambe le porte fisiche e se entrambe le interfacce del firewall rispondono. L’acquisizione non mostra il valore configurato di arp-flux.
È possibile accedere alla Device Console dalla console locale o tramite SSH. I prerequisiti e l’accesso SSH sono descritti in Connettersi a Sophos Firewall tramite SSH. Dopo l’accesso, selezionare Option 4: Device Console. Prima di modificare qualsiasi valore, eseguire il pre-check di riferimento di SFOS 22.0:
show arp-flux
Annotare esattamente il valore restituito, on oppure off. L’impostazione è globale e non specifica di una singola interfaccia. Modificarla solo temporaneamente quando entrambe le interfacce condividono intenzionalmente la stessa broadcast domain, l’acquisizione conferma il comportamento problematico e il valore corrente richiede una modifica. Se il valore annotato è on, testare la modalità di risposta specifica per l’interfaccia in una finestra di manutenzione con:
set arp-flux off
Con off, il firewall risponde alle richieste ARP attraverso l’interfaccia Ethernet corrispondente. Verificare quindi su entrambi i percorsi la raggiungibilità, le voci dei vicini, il servizio originale e il comportamento ARP con una nuova acquisizione.
Al termine del test, ripristinare esattamente il valore annotato con show arp-flux, indipendentemente dal risultato. Se il valore iniziale era on, eseguire:
set arp-flux on
Se il valore iniziale era off, eseguire invece:
set arp-flux off
Eseguire nuovamente show arp-flux per confermare il valore ripristinato, quindi ripetere i test dei percorsi. Usare l’acquisizione dei pacchetti solo per verificare il comportamento risultante.
Se non esiste una prova della broadcast domain condivisa o il problema rimane invariato con off, non si devono modificare altre impostazioni ARP sulla base di ipotesi. L’analisi deve tornare a VLAN, bridge, LAG, tabella MAC dello switch, cablaggio e indirizzi IP duplicati.
Verificare prima la cache dei vicini
- Aprire Network > Neighbors (ARP–NDP).
- In Show, selezionare IPv4 neighbor cache oppure IPv6 neighbor cache.
- Cercare l’indirizzo IP interessato.
- Annotare l’indirizzo IP, l’indirizzo MAC e l’interfaccia.
- In Static neighbor table, escludere la presenza di un’associazione fissa ma errata per lo stesso indirizzo IP.
- Confrontare l’indirizzo MAC con quello dell’endpoint, dell’hypervisor, dello switch o del router successivo.
L’interfaccia è importante quanto l’indirizzo MAC. Un’associazione IP-MAC corretta sulla porta sbagliata indica spesso un problema di VLAN, bridge, LAG o cablaggio. L’indirizzo MAC previsto si trova, ad esempio, nelle informazioni di rete dell’endpoint, nella tabella MAC dello switch o sul router collegato direttamente. Se la voce manca del tutto, si invia dal firewall un ping mirato all’indirizzo IP interessato e si controlla nuovamente la vista.
Per IPv4 e IPv6, le due viste della cache in WebAdmin sono il punto di controllo documentato. Mostrano l’interfaccia oltre all’indirizzo ed evitano di applicare per errore un’osservazione IPv4 a un problema IPv6.
Limiti dell’API XML: Get Dynamic Neighbour Entries legge le voci per verificarle; Flush All Dynamic Entries elimina le voci dinamiche della cache, non una singola voce statica. La documentazione di riferimento per SFOS 22.0 e 23.0 indica il parametro scalare facoltativo IPFamily con IPv4 e IPv6, ma nessun valore predefinito. Non si può dedurre se ometterlo selezioni una delle due famiglie, entrambe o un altro ambito. Nessuna delle due versioni include un payload di richiesta; la tabella dei parametri non fornisce quindi una richiesta operativa eseguibile. Per verificare e svuotare la cache, utilizzare la procedura GUI esistente selezionando esplicitamente la famiglia IP. L’avvertenza rimane valida: Flush svuota l’intera cache selezionata.
Riapprendere in modo controllato un’associazione obsoleta
Lo svuotamento della cache è un passaggio diagnostico, non una soluzione permanente. Inoltre, non rimuove un’associazione statica errata. Non esiste un rollback diretto per le voci dinamiche eliminate: il firewall le riapprende con il nuovo traffico. Se ricompare la stessa associazione errata, la causa è ancora presente nella rete.
- Documentare l’indirizzo IP, l’indirizzo MAC e l’interfaccia correnti.
- Riprodurre il problema con un singolo ping o tentativo di connessione.
- Se si sospetta un indirizzo IP duplicato o una manipolazione, salvare prima lo stato corrente e una breve acquisizione. Uno svuotamento immediato eliminerebbe questo indizio.
- In Show, selezionare la cache IPv4 o IPv6 interessata.
- Fare clic su Flush. In questo modo viene svuotata la cache selezionata.
- Generare nuovamente traffico mirato dal dispositivo interessato.
- Verificare quale indirizzo MAC e quale interfaccia sono stati riappresi.
- Eseguire nuovamente il test del servizio originale con la stessa origine e la stessa destinazione.
Per un test controllato dalla Device Console, è possibile inviare ad esempio quattro pacchetti a un indirizzo di destinazione documentato:
ping 192.0.2.10 count 4
ping6 2001:db8:10::10 count 4
Questi indirizzi sono esempi e devono essere sostituiti con la destinazione IPv4 o IPv6 effettiva. Un ping riuscito conferma solo la raggiungibilità di base; in seguito occorre comunque verificare il servizio che presentava originariamente il problema.
Durante il riapprendimento può verificarsi un breve ritardo. Ridurre drasticamente il timeout in modo generalizzato è raramente la soluzione migliore: il firewall deve risolvere i vicini più spesso, senza correggere un indirizzo IP duplicato o una porta dello switch errata.
Se, dopo lo svuotamento, solo un indirizzo IP pubblico continua a non passare al nuovo indirizzo MAC del firewall, è probabile che la voce obsoleta si trovi presso il provider o in un router a monte. Per questo caso è disponibile la procedura specifica Risolvere i problemi ARP dopo la migrazione di un firewall.
Creare un vicino statico solo per associazioni fisse
Un vicino statico associa in modo permanente un indirizzo IP a un indirizzo MAC e a un’interfaccia fisica. Per ogni indirizzo IP può esistere una sola associazione di questo tipo. Quando arriva una richiesta sulla porta interessata, il firewall controlla prima la tabella dei vicini statici e, al momento del salvataggio, rimuove i riferimenti dinamici per lo stesso indirizzo IP. Se manca una voce statica, controlla le cache dei vicini e aggiunge l’indirizzo MAC se necessario. Per una coppia IP-MAC associata staticamente, il firewall non risponde su nessun’altra porta. Se in seguito l’indirizzo IP, l’indirizzo MAC o la porta non corrispondono più, la connessione può interrompersi anche se l’endpoint è configurato correttamente.
Le voci statiche sono quindi adatte a sistemi stabili, come un dispositivo di infrastruttura cablato in modo permanente e dotato di un indirizzo IP fisso. In genere non sono adatte a client DHCP, dispositivi mobili, failover HA o spostamenti di VM e porte dello switch variabili.
In Network > Neighbors (ARP–NDP), visualizzare Static neighbor table e selezionare Add. Impostare quindi i valori seguenti:
- IP version: Selezionare IPv4 o IPv6.
- IPv4/IPv6 address: Inserire l’indirizzo fisso del dispositivo.
- MAC address: Inserire l’indirizzo MAC effettivo del dispositivo.
- Interface: Selezionare l’interfaccia fisica attraverso la quale è raggiungibile il vicino.
Un esempio documentato potrebbe utilizzare 192.0.2.10, 02:00:00:00:00:10 e Port1. Questi valori sono segnaposto e devono essere sostituiti integralmente con l’indirizzo IP, l’indirizzo MAC e la porta reali.
Prima di salvare, annotare se è selezionata l’opzione Add as a trusted MAC address to prevent a spoofing attempt. L’opzione aggiunge l’associazione IP-MAC all’elenco dei MAC attendibili. Va attivata solo se questa strategia di protezione viene adottata consapevolmente, poiché un successivo cambio di VM, NIC o porta può apparire come un conflitto legittimo. Verificare la Spoof Protection e le impostazioni DoS di Sophos Firewall spiega come le voci MAC attendibili interagiscono con reti dinamiche, DHCP e virtualizzazione.
Con Save si crea l’associazione, quindi si verifica in modo specifico il dispositivo interessato. Durante il rollback del test, rimuovere la nuova voce dalla Static neighbor table, generare traffico mirato e controllare l’associazione appresa dinamicamente. Aprire quindi Intrusion prevention > DoS & spoof protection > Spoof protection trusted MAC. Se rimane una voce MAC attendibile corrispondente creata per questo test, rimuoverla separatamente; non presumere che l’eliminazione del vicino statico elimini anche tale voce. È inoltre opportuno documentare chi dovrà aggiornare una voce mantenuta in caso di sostituzione dell’hardware o di modifica dell’indirizzo IP o della porta. Senza una responsabilità definita, un’associazione statica può diventare in seguito una causa invisibile di errori.
Limiti dell’API Add/Edit
La documentazione di riferimento Add/Edit per i vicini statici in SFOS 22.0 e 23.0 descrive un contratto API distinto dall’entità di timeout ARPConfiguration illustrata sopra. Richiede neighname per l’identità del vicino salvato o selezionato; neighid è invece facoltativo. Entrambi vanno distinti da IPAddress, MACAddress e Interface. I valori di IP, MAC e porta fisica presenti nella GUI non forniscono né questa identità né una richiesta JSON o XML eseguibile. La documentazione descrive l’operazione come JSON, ma non mostra alcun esempio che chiarisca con certezza il formato o l’associazione dell’identità; pertanto, non si deve ricavare un identificatore dai valori della GUI.
Anche le indicazioni sugli indirizzi sono contraddittorie: il parametro obbligatorio IPFamily ammette IPv4 e IPv6, mentre IPAddress è vincolato al tipo IPADDRESS, con un massimo di 15 caratteri e classi di indirizzi impostate sul modello IPv4. Da queste indicazioni non si può ricavare una codifica IPv6 affidabile; ciò non smentisce neppure il supporto IPv6 della procedura GUI descritta sopra. Per il parametro facoltativo AddAsATrustedMACAddress, la documentazione riporta solo Enable. Questo non dimostra né l’esistenza di un valore Disable né l’effetto dell’omissione del parametro. La selezione dell’opzione MAC attendibile rimane una decisione consapevole e un’eventuale voce MAC attendibile residua va rimossa separatamente, come descritto sopra. Finché l’identità, il formato della richiesta e lo schema degli indirizzi IPv6 non sono chiari per la specifica versione di SFOS, per creare o modificare le voci si utilizza la GUI esistente anziché una richiesta API basata su supposizioni.
Delete Static ARP Entry è un’operazione distinta: la documentazione di riferimento per SFOS 22.0 e 23.0 richiede IPAddress per identificare la voce, non il contratto Add/Edit con neighname e neighid. La restrizione al tipo IPADDRESS, a un massimo di 15 caratteri e a classi di indirizzi basate su IPv4 non stabilisce una rappresentazione affidabile per l’eliminazione IPv6. Nessuna delle due versioni include un esempio di richiesta di eliminazione o una tabella degli stati; non se ne ricavano un formato di richiesta, un payload di eliminazione o un contratto sui risultati. Anziché ipotizzare una richiesta di eliminazione API, utilizzare la GUI esistente per selezionare e rimuovere solo la voce statica salvata che si intende eliminare. Continuare a verificare e rimuovere separatamente un’eventuale voce MAC attendibile residua corrispondente, come descritto sopra; l’eliminazione a cascata non è garantita.
Verificare i possibili tentativi di avvelenamento dei vicini
Un’associazione statica definisce la combinazione prevista di indirizzo IP, indirizzo MAC e interfaccia. Se lo stesso IP compare con un altro indirizzo MAC, oppure la stessa combinazione IP-MAC compare su un’altra porta associata, il firewall considera la situazione una possibile manipolazione e non aggiorna la cache con l’associazione divergente.
Una sola associazione per indirizzo IP non significa che un indirizzo MAC possa corrispondere a un solo indirizzo IP. Nell’esempio ARP per IPv4, IP1 e IP2 sono entrambi associati a MAC1 e alla porta A. Se ciascun indirizzo IP compare con MAC1 sulla porta A, non si tratta di un tentativo di avvelenamento dei vicini. Conta che ogni combinazione IP-MAC-porta corrisponda alla propria associazione statica.
Nello stesso esempio, anche IP3 con MAC1 e senza una voce ARP statica per IP3 non viene classificato come un tentativo di avvelenamento dei vicini. La sola condivisione dell’indirizzo MAC non crea quindi un conflitto con le associazioni di IP1 o IP2. Questi esempi spiegano la verifica delle associazioni ARP statiche; non costituiscono un’approvazione generale della sicurezza del traffico.
In Network > Neighbors (ARP–NDP) è possibile attivare Log possible neighbor poisoning attempts e salvare con Apply. Prima di un test limitato nel tempo, si annota se la casella è selezionata e al termine si ripristina questo stato visibile. L’opzione facilita la diagnosi, ma non deve indurre a considerare immediatamente ogni differenza come un attacco. Anche un indirizzo IP duplicato, una scheda di rete sostituita, una VM spostata o una modifica della porta possono generare un conflitto.
I pacchetti ARP IPv4 scartati possono essere visualizzati nella Device Console durante un breve test:
drop-packet-capture 'arp'
In presenza di molte interfacce, l’output può essere limitato a una porta fisica:
drop-packet-capture interface Port1 'arp'
Port1 è un esempio e deve essere sostituito con l’interfaccia interessata. Riprodurre quindi il problema una volta e interrompere l’output in tempo reale con Ctrl+C. Il filtro mostra solo i pacchetti ARP scartati e non è un archivio di log permanente. Per NDP IPv6 o per un’analisi generale dei pacchetti, utilizzare Packet Capture in WebAdmin e limitare in modo mirato origine, destinazione, protocollo e interfaccia.
Interpretare i sintomi più comuni
- La destinazione rimane irraggiungibile dopo la sostituzione di un dispositivo o di una NIC: Confrontare il vecchio indirizzo MAC con il valore appena appreso, svuotare la cache in modo controllato ed eseguire nuovamente il test.
- L’indirizzo MAC cambia ripetutamente: Verificare la presenza di un indirizzo IP duplicato, un lease DHCP, una VM clonata o un comportamento HA. Una voce statica nasconderebbe soltanto il conflitto reale.
- L’associazione compare sull’interfaccia sbagliata: Verificare VLAN, bridge, LAG, porta dello switch e cablaggio.
- Un dispositivo associato staticamente smette di funzionare dopo una modifica: Confrontare l’indirizzo IP, l’indirizzo MAC e la porta fisica con l’associazione, quindi aggiornare o rimuovere consapevolmente la voce.
- Il problema riguarda solo IPv6: Verificare la cache dei vicini IPv6, i Router Advertisements, la VLAN e il percorso ICMPv6. Un comando ARP IPv4 non fornisce alcuna indicazione per questo caso.
- I pacchetti raggiungono il firewall, ma il servizio continua a non funzionare: Verificare separatamente la regola firewall, il NAT, il routing e il percorso di ritorno. La cache dei vicini dimostra solo la consegna locale di livello 2.
Verifica finale
- Sono stati documentati l’indirizzo IP interessato, l’indirizzo MAC previsto e l’interfaccia.
- La cache IPv4 o IPv6 è stata verificata prima di apportare modifiche.
- Se necessario, è stata svuotata solo la cache selezionata ed è stato generato traffico mirato.
- L’associazione riappresa è stata confrontata con l’endpoint, lo switch, l’hypervisor o il router.
- È stata utilizzata un’associazione statica solo per una combinazione IP-MAC-porta permanentemente stabile.
- L’avviso di avvelenamento è stato distinto da un indirizzo IP duplicato, dalla sostituzione di un dispositivo e dalle modifiche di rete.
- Il servizio originale è stato nuovamente verificato dopo il controllo di livello 2.