Sprawdzanie cache sąsiadów ARP i NDP w Sophos Firewall

Jeśli urządzenie jest nieosiągalne mimo poprawnego adresu IP, przyczyną nie musi być błędna reguła firewalla ani trasa. W sieci lokalnej Sophos Firewall potrzebuje również właściwego adresu MAC celu. To powiązanie przechowuje w cache sąsiadów.

W sekcji Network > Neighbors (ARP–NDP) można sprawdzić, jaki adres IP jest obecnie powiązany z określonym adresem MAC i interfejsem. Najpierw należy udokumentować istniejący wpis i porównać go z rzeczywistym stanem sieci. Dopiero gdy powiązanie jest nieaktualne, opróżnia się odpowiednią pamięć cache i pozwala firewallowi ponownie nauczyć się właściwego powiązania.

Nazwy i polecenia w tej procedurze odnoszą się do SFOS 22.0. Diagnostykę należy rozpocząć w WebAdmin, a Device Console używać tylko do dodatkowych kontroli wyraźnie opisanych poniżej.

⚠️ Flush opróżnia wybraną pamięć cache IPv4 lub IPv6, a nie tylko pojedynczy wiersz. Na produkcyjnym firewallu należy więc najpierw zachować bieżący wpis, ograniczyć zakres testu i nie opróżniać pamięci cache w czasie szczytowego obciążenia.

Jak działają ARP, NDP i cache sąsiadów

ARP przypisuje adres IPv4 do adresu MAC w lokalnym segmencie Layer 2. Chodzi o bezpośrednio osiągalne urządzenie, zazwyczaj w tym samym VLAN-ie. W przypadku IPv6 tę funkcję realizuje Neighbor Discovery Protocol (NDP) za pomocą ICMPv6. Firewall potrzebuje tych informacji, zanim wyśle pakiet przez bezpośrednio podłączony interfejs do następnego sąsiada.

W przypadku IPv4 urządzenie wysyła zapytanie ARP o adres MAC odpowiadający adresowi IP. Odpowiedź dostarcza powiązanie, na podstawie którego firewall aktualizuje swoją pamięć cache sąsiadów. Wcześniej poznane powiązania IP-MAC są wykorzystywane ponownie, aby ograniczyć ruch rozgłoszeniowy; w przypadku IPv6 odpowiednie rozpoznawanie sąsiadów realizuje NDP.

Dynamiczne wpisy sąsiadów są uczone i na bieżąco aktualizowane. Udokumentowany domyślny limit czasu dla zapytań ARP i NDP wynosi 600 sekund (10 minut). Nie gwarantuje to, że każdy pojedynczy wpis zniknie dokładnie po 600 sekundach: pamięci cache pozostają do czasu automatycznego lub ręcznego opróżnienia. Następnie firewall może ponownie nauczyć się aktualnych powiązań. Nieaktualny wpis może powstać na przykład po zmianie urządzenia, karty sieciowej lub VM. Z kolei dwukrotne przypisanie tego samego adresu IP może powodować powtarzające się zmiany widocznego adresu MAC.

W polu Neighbor cache entry timeout można zmienić interwał automatycznego czyszczenia i zatwierdzić go przyciskiem Apply. Krótsza wartość wymusza częstsze ponowne uczenie i nie naprawia zduplikowanych adresów IP, błędnych sieci VLAN ani nieaktualnych powiązań statycznych. Przed zmianą należy zapisać wartość początkową. Jeśli test nie przyniesie korzyści, trzeba ponownie wpisać dokładnie tę wartość, kliknąć Apply i przetestować rzeczywistą ścieżkę danych.

W przypadku automatyzacji XML: Dokumentacja referencyjna XML dla SFOS 22.0 i 23.0 opisuje parametr ARPCacheEntryTimeOut w sekcji ARPConfiguration jako interwał opróżniania pamięci cache: udokumentowana wartość domyślna to 2 minuty, a zakres to 1–500; w przykładzie podano Minutes. Są to wartości referencyjne, a nie dowód aktualnej wartości używanej w działającym systemie ani tego, że chodzi o ten sam parametr co w pomocy interfejsu użytkownika, która podaje 600 sekund dla zapytań ARP/NDP. Ta encja ARP dla IPv4 nie potwierdza również istnienia ogólnej konfiguracji wszystkich właściwości NDP dla IPv6. Żadnej z tych wartości dokumentacyjnych nie należy przyjmować jako automatycznej wartości do resetowania lub dostrajania: miarodajna pozostaje aktualna wartość odczytana i zapisana przed zmianą, którą przy wycofywaniu zmiany należy dokładnie przywrócić; następnie należy ponownie sprawdzić pierwotną usługę.

Cache sąsiadów dotyczy wyłącznie bezpośrednio osiągalnych urządzeń w danym segmencie Layer 2. Dla odległego celu firewall nie zapisuje adresu MAC serwera docelowego, lecz adres MAC następnego routera.

To nie jest to samo co Proxy ARP: w takim przypadku zapora odpowiada na interfejsie w imieniu innego adresu docelowego na dotyczące go zapytanie ARP IPv4. Ten szczególny przypadek opisano osobno w artykule Konfiguracja i testowanie Proxy ARP na Sophos Firewall.

Rozpoznawanie ARP flux na wielu interfejsach

ARP flux może wystąpić, gdy wiele fizycznych interfejsów Ethernet Sophos Firewall jest podłączonych do tego samego medium warstwy 2 lub tej samej broadcast domain. Zapora może wtedy odpowiedzieć na jedno żądanie ARP przez oba interfejsy, a urządzenie wysyłające żądanie widzi zmienne lub nieoczekiwane powiązania MAC. Dwa oddzielne VLAN-y, nieprawidłowo skonfigurowany LAG lub zwykły zduplikowany adres IP nie oznaczają automatycznie ARP flux.

Krótki packet capture służy wyłącznie do sprawdzenia zachowania ARP: należy ustalić, czy to samo żądanie dociera do obu portów fizycznych i czy odpowiadają oba interfejsy zapory. Capture nie pokazuje skonfigurowanej wartości arp-flux.

Do Device Console można uzyskać dostęp przez konsolę lokalną lub SSH. Wymagania i dostęp przez SSH opisano w artykule Łączenie z Sophos Firewall przez SSH. Po zalogowaniu należy wybrać Option 4: Device Console. Przed jakąkolwiek zmianą trzeba wykonać miarodajną kontrolę wstępną dla SFOS 22.0:

show arp-flux

Należy zapisać dokładną zwróconą wartość: on albo off. Ustawienie jest globalne, a nie przypisane do pojedynczego interfejsu. Można je zmienić tylko tymczasowo, gdy oba interfejsy celowo współdzielą tę samą broadcast domain, capture potwierdza problematyczne zachowanie, a bieżąca wartość wymaga zmiany. Jeśli zapisano on, w oknie serwisowym testuje się tryb odpowiedzi właściwy dla interfejsu poleceniem:

set arp-flux off

Przy off zapora odpowiada na żądania ARP przez odpowiedni interfejs Ethernet. Następnie obiema ścieżkami sprawdza się osiągalność, wpisy sąsiadów, pierwotną usługę oraz zachowanie ARP w nowym capture.

Po teście, niezależnie od wyniku, należy przywrócić dokładnie wartość zapisaną z show arp-flux. Jeśli wartością początkową było on, wykonuje się:

set arp-flux on

Jeśli wartością początkową było off, zamiast tego wykonuje się:

set arp-flux off

Należy ponownie wykonać show arp-flux, aby potwierdzić przywróconą wartość, a następnie powtórzyć testy ścieżek. Packet capture służy wyłącznie do sprawdzenia wynikającego z ustawienia zachowania.

Jeśli nie ma dowodu na wspólną broadcast domain lub problem pozostaje bez zmian przy off, nie należy zmieniać kolejnych ustawień ARP na podstawie przypuszczeń. Trzeba wrócić do analizy VLAN-u, bridge, LAG-u, tablicy MAC switcha, okablowania i zduplikowanych adresów IP.

Najpierw sprawdź cache sąsiadów

Otworzyć Network > Neighbors (ARP–NDP).
W polu Show wybrać IPv4 neighbor cache albo IPv6 neighbor cache.
Wyszukać odpowiedni adres IP.
Zanotować adres IP, adres MAC i interfejs.
W Static neighbor table wykluczyć istnienie stałego, lecz błędnego powiązania dla tego samego adresu IP.
Porównać adres MAC z urządzeniem końcowym, hiperwizorem, switchem lub następnym routerem.

Interfejs jest równie ważny jak adres MAC. Prawidłowe powiązanie IP-MAC widoczne na niewłaściwym porcie często wskazuje na problem z VLAN-em, bridge, LAG-em lub okablowaniem. Oczekiwany adres MAC można znaleźć na przykład w informacjach sieciowych urządzenia końcowego, w tablicy MAC switcha albo na bezpośrednio połączonym routerze. Jeśli wpisu w ogóle nie ma, należy wysłać z firewalla ukierunkowany ping do odpowiedniego adresu IP, a następnie ponownie sprawdzić widok.

Dla IPv4 i IPv6 udokumentowanym punktem kontroli są dwa widoki pamięci cache w WebAdmin. Pokazują interfejs obok adresu i zapobiegają omyłkowemu odnoszeniu obserwacji IPv4 do problemu IPv6.

Granice stosowania API XML: Get Dynamic Neighbour Entries służy do odczytu i sprawdzania wpisów; Flush All Dynamic Entries usuwa dynamiczne wpisy cache, a nie pojedynczy wpis statyczny. Dokumentacja referencyjna dla SFOS 22.0 i 23.0 podaje opcjonalny parametr skalarny IPFamily z wartościami IPv4 i IPv6, ale bez wartości domyślnej. Nie można z niej wywnioskować, czy pominięcie parametru wybiera jedną z tych rodzin, obie, czy inny zakres. Żadna z dwóch wersji nie zawiera treści żądania; tabela parametrów nie stanowi więc gotowego do wykonania żądania operacji. Do sprawdzania i opróżniania cache należy używać istniejącej procedury GUI z jawnym wyborem rodziny IP. Ostrzeżenie nadal obowiązuje: Flush opróżnia całą wybraną pamięć cache.

Kontrolowane ponowne uczenie nieaktualnego powiązania

Opróżnienie pamięci cache jest krokiem diagnostycznym, a nie trwałą naprawą. Nie usuwa również błędnego statycznego powiązania. Usuniętych wpisów dynamicznych nie można bezpośrednio przywrócić; firewall uczy się ich ponownie z nowego ruchu. Jeśli to samo nieprawidłowe powiązanie pojawia się ponownie, przyczyna nadal znajduje się w sieci.

Udokumentować bieżący adres IP, adres MAC i interfejs.
Odtworzyć błąd za pomocą pojedynczego pingu lub próby połączenia.
Przy podejrzeniu zduplikowanego adresu IP lub manipulacji najpierw zachować aktualny stan i krótki capture. Natychmiastowy flush usunąłby tę wskazówkę.
W polu Show wybrać odpowiednią pamięć cache IPv4 lub IPv6.
Kliknąć Flush. Spowoduje to opróżnienie wybranej pamięci cache.
Ponownie wygenerować ukierunkowany ruch z odpowiedniego urządzenia.
Sprawdzić, jaki adres MAC i interfejs zostały nauczone ponownie.
Ponownie przetestować pierwotną usługę z tym samym źródłem i celem.

W kontrolowanym teście z Device Console można na przykład wysłać cztery pakiety do udokumentowanego adresu docelowego:

ping 192.0.2.10 count 4
ping6 2001:db8:10::10 count 4

Adresy są przykładami i należy je zastąpić rzeczywistym celem IPv4 lub IPv6. Udany ping potwierdza jedynie podstawową osiągalność; następnie nadal trzeba przetestować usługę, która pierwotnie nie działała.

Podczas ponownego uczenia mogą wystąpić krótkie opóźnienia. Znaczne skrócenie timeoutu dla wszystkich wpisów rzadko jest najlepszym rozwiązaniem: firewall musi wtedy częściej ponownie rozwiązywać sąsiadów, ale nie usuwa to zduplikowanego adresu IP ani błędnego portu switcha.

Jeśli po wykonaniu flush tylko publiczny adres IP nadal nie przechodzi na nowy adres MAC firewalla, nieaktualny wpis prawdopodobnie znajduje się u operatora lub na routerze przed firewallem. Osobną procedurę opisano w artykule Rozwiązywanie problemów ARP po migracji firewalla.

Statyczny wpis sąsiada tylko dla stałych powiązań

Statyczny wpis sąsiada trwale wiąże adres IP z adresem MAC i fizycznym interfejsem. Dla jednego adresu IP może istnieć tylko jedno takie powiązanie. Gdy zapytanie dociera do danego portu, firewall najpierw sprawdza statyczną tabelę sąsiadów, a podczas zapisywania usuwa dynamiczne odwołania do tego samego adresu IP. Jeśli brakuje wpisu statycznego, sprawdza pamięci cache sąsiadów i w razie potrzeby dodaje adres MAC. Dla statycznie powiązanej pary IP-MAC firewall nie odpowiada na żadnym innym porcie. Jeśli później adres IP, adres MAC lub port przestanie się zgadzać, połączenie może przestać działać mimo poprawnej konfiguracji urządzenia końcowego.

Statyczne wpisy są więc odpowiednie dla stabilnych systemów, takich jak podłączone na stałe urządzenie infrastruktury ze stałym adresem IP. Zazwyczaj nie nadają się dla klientów DHCP, urządzeń mobilnych, zmian HA lub VM ani zmiennych portów switcha.

W sekcji Network > Neighbors (ARP–NDP) wyświetlić Static neighbor table i wybrać Add. Następnie ustawić następujące wartości:

IP version: wybrać IPv4 lub IPv6.
IPv4/IPv6 address: wpisać stały adres urządzenia.
MAC address: wpisać rzeczywisty adres MAC tego urządzenia.
Interface: wybrać fizyczny interfejs, przez który sąsiad jest osiągalny.

Udokumentowany przykład może używać wartości 192.0.2.10, 02:00:00:00:00:10 i Port1. Są to wartości zastępcze, które trzeba w całości zamienić na rzeczywisty adres IP, adres MAC i port.

Przed zapisaniem należy odnotować, czy wybrano opcję Add as a trusted MAC address to prevent a spoofing attempt. Opcja dodaje powiązanie IP-MAC do listy zaufanych adresów MAC. Należy ją włączyć tylko wtedy, gdy ta strategia ochrony jest stosowana świadomie, ponieważ późniejsza zmiana VM, NIC lub portu może zostać pokazana jako uzasadniony konflikt. Współdziałanie zaufanych wpisów MAC z sieciami dynamicznymi, DHCP i wirtualizacją opisano w artykule Sprawdzanie Spoof Protection i DoS Settings w Sophos Firewall.

Kliknąć Save, aby utworzyć powiązanie, a następnie przetestować dokładnie to urządzenie. Podczas wycofywania testu usunąć nowy wpis z Static neighbor table, wygenerować ukierunkowany ruch i sprawdzić dynamicznie nauczone powiązanie. Następnie otworzyć Intrusion prevention > DoS & spoof protection > Spoof protection trusted MAC. Jeśli pozostał tam odpowiedni zaufany wpis MAC utworzony na potrzeby tego testu, trzeba usunąć go osobno; nie należy zakładać, że usunięcie statycznego wpisu sąsiada usuwa również ten wpis. Trzeba też udokumentować, kto dostosuje zachowany wpis po zmianie sprzętu, adresu IP lub portu. Statyczne powiązanie bez przypisanej odpowiedzialności łatwo staje się później niewidoczną przyczyną błędu.

Granice stosowania API Add/Edit

Dokumentacja referencyjna Add/Edit dla statycznych wpisów sąsiadów w SFOS 22.0 i 23.0 opisuje odrębny kontrakt API, a nie omówioną wyżej encję ARPConfiguration dotyczącą limitu czasu. Wymaga parametru neighname określającego tożsamość zapisanego lub wybranego wpisu sąsiada; parametr neighid jest natomiast opcjonalny. Oba należy odróżnić od IPAddress, MACAddress i Interface. Wartości adresu IP, adresu MAC i portu fizycznego z GUI nie pozwalają ustalić tej tożsamości ani utworzyć gotowego do wykonania żądania JSON lub XML. Dokumentacja określa operację jako JSON, ale nie zawiera przykładu, który jednoznacznie wyjaśniałby format lub przyporządkowanie tożsamości; dlatego nie należy wyprowadzać identyfikatora z wartości w GUI.

Specyfikacja adresów również jest sprzeczna: wymagany parametr IPFamily dopuszcza IPv4 i IPv6, natomiast IPAddress jest ograniczony do typu IPADDRESS, maksymalnie 15 znaków i klas adresów właściwych dla IPv4. Nie pozwala to ustalić wiarygodnego sposobu kodowania IPv6; nie podważa też obsługi IPv6 w opisanej wyżej procedurze GUI. Dla opcjonalnego parametru AddAsATrustedMACAddress dokumentacja podaje wyłącznie Enable. Nie potwierdza to ani wartości Disable, ani skutku pominięcia parametru. Wybór zaufanego adresu MAC pozostaje świadomą decyzją, a pozostały zaufany wpis MAC usuwa się osobno, zgodnie z powyższym opisem. Dopóki tożsamość, format żądania i schemat adresowania IPv6 dla konkretnej wersji SFOS pozostają niejasne, do tworzenia lub edycji należy używać istniejącego GUI zamiast żądania API opartego na domysłach.

Delete Static ARP Entry to odrębna operacja: dokumentacja referencyjna dla SFOS 22.0 i 23.0 wymaga IPAddress do identyfikacji wpisu, a nie kontraktu Add/Edit z neighname i neighid. Ograniczenie do typu IPADDRESS, maksymalnie 15 znaków i klas adresów właściwych dla IPv4 nie określa wiarygodnej reprezentacji dla usuwania wpisów IPv6. Żadna z dwóch wersji nie zawiera przykładu żądania usunięcia ani tabeli statusów; nie wyprowadza się z nich formatu żądania, jego treści ani kontraktu wyników. Zamiast zgadywać żądanie usunięcia API, należy w istniejącym GUI wybrać i usunąć tylko zamierzony zapisany wpis statyczny. Nadal należy osobno sprawdzać i usuwać odpowiadający mu pozostały zaufany wpis MAC, zgodnie z opisem powyżej; usunięcie kaskadowe nie jest gwarantowane.

Sprawdzanie możliwych prób neighbor poisoning

Statyczne powiązanie definiuje oczekiwaną kombinację adresu IP, adresu MAC i interfejsu. Jeśli ten sam adres IP pojawi się z innym adresem MAC albo ta sama kombinacja IP-MAC zostanie wykryta na innym powiązanym porcie, firewall traktuje to jako możliwą manipulację i nie aktualizuje pamięci cache odmiennym powiązaniem.

Jedno powiązanie na adres IP nie oznacza, że adres MAC może odpowiadać tylko jednemu adresowi IP. W przykładzie ARP dla IPv4 zarówno IP1, jak i IP2 są powiązane z MAC1 i portem A. Jeśli każdy z tych adresów IP pojawia się z MAC1 na porcie A, nie jest to próba neighbor poisoning. Istotne jest, aby każda kombinacja IP-MAC-port odpowiadała własnemu statycznemu powiązaniu.

W tym samym przykładzie IP3 z MAC1, bez statycznego wpisu ARP dla IP3, również nie jest klasyfikowany jako próba neighbor poisoning. Samo współdzielenie adresu MAC nie powoduje więc konfliktu z powiązaniami IP1 ani IP2. Przykłady te wyjaśniają sprawdzanie statycznych powiązań ARP; nie stanowią ogólnego potwierdzenia bezpieczeństwa ruchu.

W sekcji Network > Neighbors (ARP–NDP) można włączyć Log possible neighbor poisoning attempts i zapisać ustawienie przyciskiem Apply. Przed testem ograniczonym w czasie należy zapisać, czy pole wyboru jest zaznaczone, a po teście przywrócić ten widoczny stan. Opcja pomaga w diagnostyce, ale nie oznacza, że każde odchylenie należy od razu uznać za atak. Konflikt może również spowodować zduplikowany adres IP, wymieniona karta sieciowa, przeniesiona maszyna wirtualna lub zmiana portu.

Odrzucone pakiety IPv4 ARP można wyświetlić w Device Console podczas krótkiego testu:

drop-packet-capture 'arp'

Przy wielu interfejsach można ograniczyć wyjście do jednego fizycznego portu:

drop-packet-capture interface Port1 'arp'

Port1 jest przykładem i należy go zastąpić odpowiednim interfejsem. Następnie jednokrotnie odtworzyć błąd i zakończyć bieżące wyjście za pomocą Ctrl+C. Filtr pokazuje wyłącznie odrzucone pakiety ARP i nie jest trwałym archiwum logów. Dla IPv6 NDP lub ogólnej analizy pakietów należy użyć Packet Capture w WebAdmin i precyzyjnie ograniczyć źródło, cel, protokół oraz interfejs.

Interpretacja typowych objawów

Po wymianie urządzenia lub NIC cel pozostaje nieosiągalny: porównać stary i ponownie nauczony adres MAC, opróżnić pamięć cache w kontrolowany sposób i ponowić test.
Adres MAC zmienia się wielokrotnie: sprawdzić zduplikowany adres IP, dzierżawę DHCP, klon VM lub zachowanie HA. Statyczny wpis jedynie ukryłby rzeczywisty konflikt.
Powiązanie pojawia się na niewłaściwym interfejsie: sprawdzić VLAN, bridge, LAG, port switcha i okablowanie.
Statycznie powiązane urządzenie przestaje działać po przebudowie: porównać adres IP, adres MAC i fizyczny port z powiązaniem, a następnie świadomie dostosować lub usunąć wpis.
Problem dotyczy tylko IPv6: sprawdzić IPv6 neighbor cache, Router Advertisements, VLAN i ścieżkę ICMPv6. Polecenie IPv4 ARP nie stanowi tutaj dowodu.
Pakiety docierają do firewalla, ale usługa nadal nie działa: osobno sprawdzić regułę firewalla, NAT, routing i ścieżkę powrotną. Cache sąsiadów potwierdza jedynie lokalne dostarczenie w Layer 2.

Kontrola końcowa

Udokumentowano odpowiedni adres IP, oczekiwany adres MAC i interfejs.
Cache IPv4 lub IPv6 sprawdzono przed wprowadzeniem zmiany.
W razie potrzeby opróżniono dokładnie wybraną pamięć cache i wygenerowano ukierunkowany ruch.
Ponownie nauczone powiązanie porównano z urządzeniem końcowym, switchem, hiperwizorem lub routerem.
Statycznego powiązania użyto tylko przy trwale stabilnej kombinacji adresu IP, adresu MAC i portu.
Odróżniono ostrzeżenie o poisoning od zduplikowanego adresu IP, wymiany urządzenia i zmian sieciowych.
Po sprawdzeniu Layer 2 ponownie przetestowano pierwotną usługę.

FAQ

Jaka jest różnica między pamięcią cache ARP i NDP?

ARP rozwiązuje adresy IPv4 na adresy MAC. NDP wykonuje to rozwiązywanie sąsiadów dla IPv6 za pomocą ICMPv6. W Sophos Firewall oba widoki są dostępne w sekcji Network > Neighbors (ARP–NDP).

Czy można opróżnić cache sąsiadów bez przerwy w działaniu?

Wpisy są automatycznie uczone ponownie przez nowy ruch, ale może to powodować krótkie opóźnienia. Ponieważ Flush opróżnia całą wybraną pamięć cache, krok należy zaplanować, udokumentować i wykonać poza okresem szczytowego obciążenia.

Kiedy statyczny wpis sąsiada ma sens?

Tylko wtedy, gdy adres IP, adres MAC i fizyczny interfejs pozostają trwale stabilne, a powiązanie jest utrzymywane operacyjnie. W przypadku DHCP, urządzeń mobilnych, zmian VM lub zmiennych portów dynamiczne uczenie jest zazwyczaj bardziej niezawodne.

Czy komunikat o poisoning zawsze oznacza atak?

Nie. Komunikat wskazuje przede wszystkim odchylenie od oczekiwanego powiązania. Oprócz ataku przyczyną mogą być zduplikowane adresy IP, wymiana urządzenia lub NIC, przeniesione maszyny wirtualne i zmiany portów.