Sprawdzanie Spoof Protection i DoS Settings w Sophos Firewall

Spoof Protection i DoS Settings należą do klasycznych funkcji hartowania Sophos Firewall. Funkcje te redukują proste, zaszumione lub wyraźnie nieprawidłowe pakiety, zanim staną się niepotrzebnym szumem w logach, regułach lub opublikowanych usługach. Jednocześnie ustawienia te nie stanowią magicznej ochrony przed każdym rodzajem ataku.

W artykule sklasyfikowano te funkcje jako ostrożne, podstawowe utwardzanie: najpierw zapoznaj się z projektem sieci i ścieżkami powrotnymi, następnie aktywuj, przetestuj i sprawdź logi. To rozróżnienie jest szczególnie ważne: funkcje te uzupełniają czyste reguły zapory ogniowej, IPS, Threat Feeds, WAF i rejestrowanie. Nie zastępują one tych elementów składowych.

Krótko wyjaśnione

Spoof Protection sprawdza, czy pakiety z wiarygodnym adresem źródłowym docierają do oczekiwanego interfejsu. Na przykład, jeśli z Internetu pojawi się pakiet z wewnętrznym adresem źródłowym, w większości projektów jest to podejrzane. Z drugiej strony DoS Settings reaguje na pewne wzorce ataków typu Flood lub Connection, na przykład zauważalne ilości ruchu SYN, UDP lub ICMP.

W SFOS 22 i SFOS 23 ścieżka w WebAdmin to:

Intrusion prevention > DoS & spoof protection

Ustawienia na tej stronie wpływają na przetwarzanie pakietów. Przed użyciem Apply lub Save należy zapisać dotychczasowe wartości i określić sposób wycofania zmiany.

Do czego służą funkcje

• Spoof Protection: odrzuca pakiety z niewiarygodnym źródłowym adresem IP, ogranicza proste próby spoofingu i ułatwia wykrywanie nieprawidłowo routowanych pakietów. Funkcja ta nie zastępuje jednak prawidłowego planowania stref, interfejsów i routingu.
• DoS Settings: ograniczają proste wzorce floodingu i pozwalają wcześniej zauważyć ataki generujące duży ruch lub błędne konfiguracje. Funkcja ta nie zastępuje jednak ochrony DDoS zapewnianej przez dostawcę, WAF ani odpowiednio zwymiarowanej infrastruktury upstream.

W praktyce funkcje te są szczególnie interesujące jako podstawowe wzmocnienie. Korzyścią jest ograniczenie oczywistych nonsensów. W rzeczywistych wolumetrycznych atakach DDoS połączenie internetowe często jest już w pełni obciążone, zanim zapora sieciowa może znacząco zareagować. Wtedy potrzebna jest ochrona po stronie dostawcy, scrubbing upstream lub inna architektura.

Nie mieszać typów ochrony

Na tym samym ekranie znajdują się różne mechanizmy, które podczas eksploatacji odpowiadają na różne pytania.

• Enable spoof prevention: włącza Spoof Prevention dla wybranych stref. Błędnie rozumiane strefy lub ścieżki powrotne mogą wpływać na legalny ruch.
• Trusted MAC i pary IP-MAC: znane adresy MAC lub kombinacje IP-MAC są traktowane jako zaufane. W przypadku urządzeń mobilnych, zmian DHCP lub wirtualizacji może to zwiększyć nakład pracy związany z utrzymaniem.
• DoS settings: określają progi i flagi dla SYN-, UDP-, TCP- lub ICMP/ICMPv6-flooding. Zbyt rygorystyczne wartości zakłócają legalne skoki obciążenia, skany, monitoring lub VoIP.
• DoS bypass rule: wyłącza określony ruch z DoS Settings w WebAdmin. Szerokie wyjątki osłabiają tę ochronę. Zależności od wersji dotyczące współdziałania z politykami CLI opisano w sekcji CLI.

To rozróżnienie jest ważne, ponieważ błąd po aktywacji nie musi automatycznie oznaczać problemu z regułą zapory. Czasem próg DoS jest zbyt agresywny, czasem powiązanie IP-MAC nie jest już prawidłowe, a czasem Spoof Protection wskazuje rzeczywisty problem z routingiem lub VLAN.

Kiedy Spoof Protection ma sens

Spoof Protection pasuje szczególnie dobrze do wyraźnie podzielonych na segmenty sieci, w których sieci źródłowe, interfejsy i trasy są wyraźnie zaplanowane. Im jaśniejsza struktura sieci, tym łatwiej jest ocenić, czy adres źródłowy w interfejsie jest wiarygodny.

Przydatne aplikacje:

• Internet WAN, na którym nie powinny pojawiać się żadne wewnętrzne źródła RFC1918.
• DMZ lub strefy serwerów z przejrzystymi sieciami źródłowymi i docelowymi.
• Strefy klientów, gości lub IoT, w których obce sieci wewnętrzne nie powinny występować jako źródło ruchu.
• Lokalizacje, w których trasy, VLAN i strefy są wyraźnie udokumentowane.
• Środowiska, w których utracone pakiety muszą być później identyfikowalne za pomocą Packet Capture i dzienników.

Sprawy stają się trudniejsze w przypadku routingu asymetrycznego, złożonych sieci tranzytowych, tymczasowych ścieżek migracji, niepoprawnie udokumentowanych VLAN lub wielu zapór sieciowych na tej samej ścieżce danych. Prawidłowy strumień danych może wyglądać na podszywanie się, chociaż projekt routingu lub ścieżka zwrotna jest w rzeczywistości nieczysta.

Sprawdź przed aktywacją

Spoof Protection i DoS Settings nie powinny być aktywowane na ślepo w środowisku produkcyjnym. Z góry powinno być jasne, których sieci i usług dotyczy problem.

Ważne punkty kontrolne:

1. Udokumentować strefy, interfejsy, VLAN-y, mosty i LAG-i.
2. Sprawdź trasy statyczne, trasy SD-WAN, trasy VPN i ścieżki asymetryczne.
3. Zidentyfikuj opublikowane usługi poprzez DNAT lub WAF.
4. Zwróć uwagę na usługi krytyczne, takie jak VoIP, monitorowanie, tworzenie kopii zapasowych, skanowanie, VPN i połączenia między lokalizacjami.
5. Przygotuj rejestrowanie i centralną ocenę, jeśli zdarzenia mają być później identyfikowalne.
6. Ustaw okno konserwacji lub obszar pilotażowy dla pierwszej aktywacji.
7. Sprawdź istniejące DoS bypass rules, wpisy Trusted MAC i powiązania IP-MAC.
8. Zapisz bieżący typ kontroli spoof i wybrane strefy, Restrict unknown IP on trusted MAC, wszystkie flagi Apply, wartości Packet Rate i Burst Rate oraz istniejące wyjątki i powiązania. Wartości te będą potrzebne do wycofania zmiany.

Jeśli nawet zwykłe reguły firewalla są trudne do prześledzenia, należy najpierw uporządkować zestaw reguł i konfigurację routingu. W przypadku indywidualnych połączeń testowych lepszym początkiem będzie Przetestuj regułę zapory sieciowej za pomocą Log Viewer, Test zasad i Packet Capture.

Ostrożnie aktywuj Spoof Protection

Podejście krok po kroku ma sens w przypadku Spoof Protection. Należy najpierw zabezpieczyć najjaśniejsze obszary, a nie od razu każdą strefę specjalną.

Proces praktyczny:

1. Zapisz bieżącą konfigurację lub przynajmniej udokumentuj ustawienia, których to dotyczy.
2. W Intrusion prevention > DoS & spoof protection wybierz Enable spoof prevention, wymagany typ kontroli i początkowo tylko dobrze udokumentowane strefy.
3. Wybierz Apply.
4. Uruchom zaplanowane połączenia testowe: dostęp do Internetu, VPN, usługi opublikowane, serwery centralne, monitoring.
5. Sprawdzić w Log Viewer i Packet Capture, czy występują nieoczekiwanie odrzucane pakiety.
6. W przypadku nietypowego odrzucania prawidłowych pakietów nie stosować od razu szerokich wyjątków, lecz najpierw sprawdzić routing, Source-IP i Interface.

Częstym błędem jest traktowanie Spoof Protection wyłącznie jako pola wyboru dotyczącego bezpieczeństwa. W rzeczywistości funkcja ta sprawdza pewne założenie dotyczące projektu sieci. Jeśli to założenie nie jest prawdziwe, nie musi to oznaczać, że Spoof Protection działa nieprawidłowo. Często okazuje się wtedy, że interfejs, trasa, VLAN lub ścieżka powrotna nie są skonfigurowane zgodnie z oczekiwaniami.

Poprawnie rozumieć IP, MAC i pary IP-MAC

Sophos rozróżnia kilka rodzajów kontroli. IP spoofing odrzuca ruch, jeśli źródłowy adres IP nie odpowiada tablicy routingu lub pakiet nie pochodzi z bezpośrednio podłączonej podsieci. MAC filter odrzuca pakiety, których adres MAC nie jest wpisany jako Trusted MAC; w tym celu musi być skonfigurowany co najmniej jeden Trusted MAC Address. Filtr MAC nie jest stosowany do pakietów DHCP. IP-MAC pair filter sprawdza, czy przychodząca kombinacja adresu IP i adresu MAC odpowiada znanej parze.

Jest to przydatne w statycznych, jasno kontrolowanych sieciach, ale w środowiskach dynamicznych szybko generuje pracę utrzymaniową. DHCP, roaming Wi-Fi, maszyny wirtualne, hypervisory, klastry, NAC, stacje dokujące lub wymiana urządzeń mogą tworzyć legalne zmiany MAC/IP. W takich sieciach należy najpierw obserwować i wiązać tylko tam, gdzie rzeczywistość operacyjna jest wystarczająco stabilna.

Przykład z przełącznikiem rdzeniowym: przełącznik realizuje routing między VLAN-ami i używa Sophos Firewall jako bramy domyślnej. Klient w VLAN 1 z adresem 10.10.10.5 wysyła żądanie do Internetu, które trafia na interfejs LAN firewalla. To, że przełącznik zna VLAN-y, nie oznacza jeszcze, że ich podsieci są bezpośrednio podłączone do firewalla. Przed włączeniem należy sprawdzić na firewallu trasę dla 10.10.10.5 i bezpośrednio podłączone podsieci. Jeśli udokumentowane warunki IP spoofing nie są spełnione, żądanie może zostać odrzucone mimo prawidłowego adresu klienta. Sam test dostępu przez WAN nie zastępuje tej kontroli ścieżki wewnętrznej.

Sposób sprawdzania lokalnej tabeli sąsiadów i świadomego tworzenia statycznego powiązania adresu IP, MAC oraz interfejsu opisano w Sprawdzanie pamięci podręcznej sąsiadów ARP i NDP.

Należy rozróżnić te sytuacje: jeśli nie skonfigurowano żadnego Trusted MAC, włączony IP-MAC pair filter przepuszcza cały ruch przez tę kontrolę. Pusta lista Trusted MAC to nie to samo co pakiet niezgodny ze skonfigurowanym powiązaniem IP-MAC. Gdy wpisy istnieją, filtrowanie zależy od powiązań i opcji Restrict unknown IP on trusted MAC; brak pasującej pary nie oznacza zawsze blokady niezależnie od tej opcji. Ochrona wymaga utrzymywanych i przetestowanych powiązań.

Opcja Restrict unknown IP on trusted MAC jest szczególnie restrykcyjna: przy włączonym IP-MAC pair filter w wybranych strefach Sophos opisuje dla zaznaczonej opcji odrzucanie pakietów z Trusted MAC bez powiązania z adresem IP, gdy adres IP jest nieznany. „Nieznany” oznacza tutaj: brak pasującego wpisu w tablicy routingu lub brak pochodzenia z bezpośrednio podłączonej podsieci. Zwiększa to bezpieczeństwo w kontrolowanych sieciach, ale może powodować problemy przy DHCP, migracjach i tymczasowych zmianach adresów IP.

Dla niezaznaczonej opcji ogólna pomoc do SFOS 22 i SFOS 23 opisuje dopuszczanie Trusted MAC z dowolnym adresem IP oraz Trusted MAC bez powiązania z adresem IP. Natomiast osobna instrukcja Add stwierdza ogólnie, że w przypadku powiązania akceptowana jest tylko pasująca para IP-MAC. Nie wolno łączyć tych stwierdzeń w bezwarunkową gwarancję blokowania. Należy sprawdzić łącznie rodzaj kontroli, strefę, powiązanie i pole wyboru oraz przetestować w zainstalowanym buildzie wymagane przypadki dozwolone i przypadki niezgodne; jeśli działanie jest niejasne, przed wdrożeniem produkcyjnym należy wyjaśnić je z Sophos Support.

Pojedynczy wpis Trusted MAC tworzy się w Intrusion prevention > DoS & spoof protection, w sekcji Spoof protection trusted MAC, za pomocą Add. Po wpisaniu adresu MAC wybiera się Static i podaje co najmniej jeden adres IPv4 lub IPv6, rozdzielając kolejne adresy przecinkami, albo wybiera się DHCP, aby automatycznie powiązać adresy przydzielone z dzierżawy. Po Save należy przetestować jeden zgodny i jeden celowo niezgodny przypadek IP-MAC; sama widoczność wpisu nie potwierdza jeszcze działania filtra.

Dla SFOS 23 udokumentowano opcje wyszukiwania i filtrowania listy Trusted MAC, które pomagają znaleźć wpis wymagający aktualizacji. Ten widok listy nie zmienia filtrowania pakietów i nie oznacza, że SFOS 22 nie ma takich elementów sterujących.

Kontrolowane importowanie Trusted MAC

Wiele wpisów Trusted MAC można zaimportować jako plik .csv lub .txt w Intrusion prevention > DoS & spoof protection. W sekcji Spoof protection trusted MAC wybrać Import, wskazać plik za pomocą Browse i przesłać go za pomocą Upload file. W każdym wierszu należy podać adres MAC i IP Association. Pierwszy wiersz musi zawierać dokładnie MAC Address,IP Association,IP Address. Dozwolone wartości IP Association to Static, DHCP, DHCPv6 i None. Przy Static można podać maksymalnie 16 adresów IP na jeden adres MAC, oddzielonych przecinkami; przy pozostałych trzech typach przypisania pole IP pozostaje puste.

Poniższy przykład formatu przedstawia statyczne powiązania IPv4 i IPv6 oraz trzy typy przypisania bez pola IP:

MAC Address,IP Association,IP Address
02:00:00:00:00:01,Static,192.0.2.10,192.0.2.11
02:00:00:00:00:02,Static,2001:db8::10,2001:db8::11
02:00:00:00:00:03,DHCP
02:00:00:00:00:04,DHCPv6
02:00:00:00:00:05,None

Adresy MAC i IP są fikcyjnymi wartościami przykładowymi, a nie urządzeniami, które należy dopuścić. Każdy wiersz należy zastąpić rzeczywistym adresem MAC urządzenia i świadomie wybranym typem przypisania. Static jest odpowiednie dla znanych stałych adresów, a DHCP lub DHCPv6 dla automatycznego powiązania z dzierżawą; None nie zawiera powiązania z adresem IP i dlatego nie zastępuje kontroli statycznej pary.

Podczas importu firewall odrzuca cały wpis, jeśli zawiera on nieprawidłowy adres MAC, nieprawidłową wartość IP Association lub nieprawidłowy adres IP. Należy odróżnić od tego wartości IP wpisane mimo wybrania DHCP, DHCPv6 lub None: te wartości IP są odrzucane; nie oznacza to automatycznie usunięcia całego wpisu MAC. Dlatego najpierw należy zaimportować kilka wierszy pilotażowych, następnie sprawdzić widoczne powiązania i przetestować jeden dozwolony oraz jeden celowo nieprawidłowy przypadek IP-MAC. Pomyślne przesłanie pliku nie dowodzi jeszcze, że zamierzona logika filtrowania działa.

Planowanie DoS Settings

Ustawienia DoS Settings powinny być dopasowane do środowiska. Rzadko ma sens przejmowanie wartości z innego przykładu bez sprawdzania. Lokalizacja z kilkoma użytkownikami, VoIP i małym WAN zachowuje się inaczej niż centrum danych, sieć szkolna lub lokalizacja z regularnym skanowaniem i monitorowaniem.

Przed adaptacją odpowiedz na następujące pytania:

• Które usługi publiczne są narażone?
• Czy występują uzasadnione szczyty obciążenia, skany, monitorowanie lub kontrole stanu?
• Czy używany jest VoIP, VPN, WAF, DNAT lub transfer dużych plików?
• Dla których protokołów należy włączyć flagę Apply, aby firewall rzeczywiście odrzucał i rejestrował przekroczenia progów?
• Kto sprawdza logi po aktywacji?

DoS Settings może pomóc w ograniczeniu prostych wzorców zalań. Jednak zbyt rygorystyczne progi mogą również wpływać na legalny ruch. Szczególną ostrożność należy zachować w przypadku VoIP, systemów monitorowania, zadań tworzenia kopii zapasowych, skanowania pod kątem luk w zabezpieczeniach i intensywnie używanych opublikowanych usług.

Typy floodingu powodują różne rodzaje obciążenia: SYN flood tworzy wiele półotwartych połączeń TCP; serwer odpowiada pakietem SYN-ACK, ale nie otrzymuje końcowej odpowiedzi. TCP flood oznacza ogólnie wysoką częstotliwość pakietów TCP. UDP flood może obciążać host docelowy sprawdzaniem portów i odpowiedziami ICMP dotyczącymi nieużywanych portów. ICMP/ICMPv6 flood obejmuje dużą liczbę Echo Requests i może zużywać przepustowość. W przypadku DDoS obciążenie pochodzi z wielu urządzeń; pojedynczy limit Source nie odpowiada zatem na to samo pytanie co limit Destination.

W formularzu istotne są również następujące flagi:

• Dropped source routed packets: odrzuca pakiety, których trasę określa nadawca. Ogranicza to możliwość manipulowania routingiem w ten sposób.
• Disable ICMP/ICMPv6 redirect packet: nie przyjmuje komunikatów ICMP Redirect ani ICMPv6 Redirect. Routery downstream mogą wysyłać takie komunikaty również w uzasadniony sposób, aby wskazać lepszą lub aktywną trasę; opcja ta zmienia więc założenie dotyczące routingu, a nie tylko wykrywanie ataków.
• ARP hardening: dopuszcza ARP Replies tylko wtedy, gdy źródłowy i docelowy adres IP znajdują się w tej samej podsieci. Sophos opisuje to jako ochronę przed ARP Flood i ARP Poisoning.

Opcje te stanowią sensowne podstawowe wzmocnienie zabezpieczeń, ponieważ mogą ograniczać manipulacje zachowaniem routingu lub ARP. Mimo to po ich włączeniu należy przeprowadzić testy, zwłaszcza w sieciach z routerami downstream, starszymi segmentami lub nietypową architekturą warstwy 2.

Dla progów w WebAdmin ważne są dwa pojęcia:

• Packet rate: liczba pakietów, które host może wysłać lub odebrać na minutę, zanim ruch zostanie odrzucony.
• Burst rate: liczba pakietów, które są początkowo przepuszczane bez sprawdzania Packet Rate. Później mogą być tolerowane sporadyczne krótkie skoki powyżej Packet Rate, ale nie częste ani utrzymujące się przekroczenia.

Apply flag decyduje, czy skonfigurowany limit jest rzeczywiście stosowany dla danego protokołu. Zbyt wysokie wartości dają niewiele. Zbyt niskie blokują legalne piki. Dlatego wartości trzeba dopasować do własnego ruchu, opublikowanych usług i znanych okien serwisowych.

Aby ustalić wiarygodny poziom odniesienia, należy najpierw zapisać normalne szczyty i planowane obciążenia wyjątkowe. Następnie dla każdego protokołu dobrać wartość na podstawie zmierzonego prawidłowego szczytu i wydajności chronionej usługi; Sophos nie podaje jednej uniwersalnej wartości produkcyjnej. Po każdej zmianie wykonać jeden zdefiniowany test obciążenia i porównać Traffic dropped. Licznik narasta od ostatniego ponownego uruchomienia zapory, dlatego trzeba zapisać również czas testu i wartość początkową.

Prawidłowe odczytywanie stanu DoS

W Intrusion prevention > DoS attacks SFOS pokazuje w czasie rzeczywistym, dla którego Source lub Destination obowiązuje limit i ile pakietów zostało odrzuconych. Kliknąć typ ataku, aby otworzyć szczegóły; do tego widoku prowadzi również łącze statusu z DoS & spoof protection. Po wykryciu ograniczenie obowiązuje początkowo przez dziesięć sekund. Jeśli atak w tym czasie się zakończy, ograniczenie zostaje zniesione. Jeśli trwa nadal, firewall cyklicznie resetuje ten licznik co dziesięć sekund i nadal ogranicza ruch. Nowy atak z tego samego Source lub do tego samego Destination ponownie resetuje licznik i ponownie aktywuje ograniczenie. Po zakończeniu ataku dane znikają po 30 sekundach. Pusty widok statusu nie dowodzi zatem, że wcześniej nie wystąpiło zdarzenie DoS; do analizy wstecznej potrzebne są zarejestrowane zdarzenia.

Limity w WebAdmin obowiązują dla poszczególnych Source lub Destination, a nie jako ogólna suma dla wszystkich hostów. Przykład służący wyłącznie objaśnieniu, z Burst rate 100: pierwsze 100 pakietów jest początkowo dopuszczanych bez sprawdzania Packet rate; następnie następuje porównanie częstotliwości. Poniżej skonfigurowanej częstotliwości ruch jest akceptowany, a powyżej może być odrzucany. 100 nie jest zalecaną wartością produkcyjną.

Nie utożsamiać przykładowego przebiegu z licznikiem czasu statusu: ogólna pomoc do SFOS 22 i SFOS 23 nazywa ten przebieg próbą ARP Flood i opisuje dalsze odrzucanie pakietów oraz wpisy w logach, jeśli następny pakiet z tego samego Source nadejdzie w ciągu 30 sekund. Opisuje dopuszczenie ruchu, jeśli od poprzedniego pakietu upłynęło więcej czasu, ale wyraźnie nie przewiduje automatycznego dodania do Allow List wyłącznie na podstawie 30 sekund bez ruchu. Natomiast osobna pomoc dotycząca statusu DoS opisuje omówione powyżej cykliczne ograniczenie dziesięciosekundowe. Nie są to wiarygodne, uniwersalne czasy dopuszczenia ruchu ani oczekiwania dla każdego typu floodingu. Nie należy wnioskować o dopuszczeniu ruchu wyłącznie na podstawie licznika czasu: należy łącznie ocenić typ ataku, status na żywo, logi i jednoznacznie wyodrębniony prawidłowy przepływ testowy; niewyjaśnione zachowanie należy wyjaśnić z Sophos Support.

Używanie sygnatur DDoS tylko na obsługiwanych modelach

Sophos udostępnia sygnatury DDoS wyłącznie na XGS 5500 i firewallach o większej wydajności. Na obsługiwanym modelu procedura wygląda następująco:

1. W sekcji Intrusion prevention > IPS policies > Add utworzyć własną IPS Policy z dowolnie wybraną jednoznaczną nazwą i zapisać ją za pomocą Save.
2. Przy tej zapisanej Policy wybrać Edit, następnie Add i wprowadzić jednoznaczną nazwę reguły.
3. Wybrać Select all, w Smart filter wpisać ddos i zastosować filtr klawiszem Enter. Świadomie ustawić Action na Drop packet.
4. Za pomocą Save zapisać najpierw regułę, a następnie za pomocą drugiego Save zapisać Policy zawierającą tę regułę.
5. W sekcji Rules and policies > Firewall rules przypisać Policy do reguły firewalla, która rzeczywiście obsługuje przewidziany ruch; przypisanie i skuteczność ochrony sprawdzić oddzielnie, zgodnie z procedurą pilotażu IPS. Bez tego przypisania Policy nie działa.

Te sygnatury uzupełniają lokalne progi DoS, ale nie zastępują ochrony DDoS u dostawcy. Jeśli łącze internetowe jest już wysycone, firewall nie usunie wąskiego gardła przed połączeniem WAN. Model, licencję, dopasowanie reguły i kontrolowany test trzeba więc sprawdzić osobno.

Reguły CLI z system dos-config

Za pośrednictwem Device Console można tworzyć własne polityki DoS i odpowiadające im reguły. Jest to między innymi konieczne dla IP Flood, ponieważ tego typu nie można skonfigurować w WebAdmin. Jednostki są różne: WebAdmin używa pakietów na minutę, natomiast system dos-config pakietów na sekundę (pps).

Po zalogowaniu przez SSH należy wybrać w menu głównym 4. Device Console. Polecenia wykonuje się przy promptcie console>, a nie w Advanced Shell.

Najpierw tworzy się politykę z typem ataku, limitem i sposobem zliczania. Następnie reguła określa, jakiego ruchu dotyczy polityka. Udokumentowany przykład SYN przewiduje politykę TestSYN i regułę TestRuleSYN dla Source 198.51.100.50, z limitem 1000 pps na Source.

Przed utworzeniem obiektów sprawdzić pomoc wersji docelowej: opublikowana pomoc SFOS 22 i SFOS 23 używa tokenu rule_name dla add dos-rule w blokach składni i opcji, ale rule-name w przykładach. Nie potwierdzono, że te zapisy są wymienne. Najpierw otworzyć pomoc dla system dos-config w Device Console zainstalowanej wersji i sprawdzić akceptowany token dodawania oraz parametry. Jeśli wątpliwości pozostają, nie tworzyć reguły i poprosić Sophos Support o wyjaśnienie. Pełne polecenie dodawania reguły celowo nie jest tutaj podane jako wzór do kopiowania. Także poniższą politykę tworzyć dopiero po tej kontroli; sama polityka nie wiąże jeszcze przykładowego ruchu. Przykład nie jest przedstawiany jako pomyślnie przetestowany.

system dos-config add dos-policy policy-name TestSYN SYN-Flood 1000 pps per-src

1000 pps jest przykładem składni, a nie zaleceniem dla sieci produkcyjnej. We własnej regule trzeba świadomie dostosować co najmniej następujące elementy:

• SYN-Flood: alternatywnie UDP-Flood, ICMP-Flood lub dostępny tylko tutaj IP-Flood
• per-src: limit na Source; alternatywnie per-dst na Destination lub global dla całego pasującego ruchu
• rzeczywiście wymagane warunki dla Source, Destination, Zone, Interface i protokołu
• limit na podstawie zmierzonej linii bazowej i możliwości chronionej usługi

Tryb zliczania global nie dotyczy liczników w Intrusion prevention > DoS attacks. Te liczniki interfejsu nie potwierdzają więc globalnie zagregowanego limitu CLI. Konfigurację sprawdzić za pomocą show, a działanie ochrony ocenić osobno na podstawie jasno określonego przepływu testowego, ograniczonego przedziału czasu i odpowiednich logów.

Limity i pola dopasowania CLI są zdefiniowane dokładniej, niż sugeruje krótka reguła przykładowa:

system dos-config flush dos-rules usuwa wszystkie reguły DoS CLI i nie jest wycofaniem pojedynczego testu. Przed takim działaniem globalnym należy zapisać istniejące reguły osobno za pomocą show oraz zabezpieczyć konfigurację. Przy zwykłym wycofaniu usuwa się konkretną nazwaną regułę. Opublikowana pomoc opisuje flush dla reguł, a nie jako usunięcie powiązanych polityk.

Po utworzeniu należy najpierw sprawdzić, czy nazwy, typ, limit i warunek reguły są prawidłowe:

system dos-config show dos-policies policy-name TestSYN
system dos-config show dos-rules rule-name TestRuleSYN

Aby wycofać zmianę, należy najpierw usunąć regułę, a następnie nieużywaną już politykę:

system dos-config delete dos-rule rule-name TestRuleSYN
system dos-config delete dos-policy policy-name TestSYN

Składnia CLI jest udokumentowana w Sophos Firewall Command Line Help. Mimo to należy ją najpierw zastosować w kontrolowanym przepływie testowym. Reguły DoS w CLI obsługują tylko IPv4. Przy aktywnej polityce IP-Flood kolumna Applied w Intrusion prevention > DoS attacks nadal pokazuje No; Sophos opisuje to jako oczekiwane zachowanie.

To ograniczenie do IPv4 dotyczy reguł DoS w CLI, a nie natywnych DoS settings w sekcji Intrusion prevention > DoS & spoof protection w WebAdmin: znajdujące się tam ustawienia DoS chronią zarówno ruch IPv4, jak i IPv6, jeśli skonfigurowano odpowiednie flagi protokołów i progi.

Dla SFOS 22 udokumentowano przetwarzanie reguł i polityk CLI przed ustawieniami DoS i spoof w WebAdmin; przy tej kolejności reguła bypass WebAdmin nie powoduje automatycznego ominięcia pasującej polityki CLI. Sprawdzona pomoc CLI SFOS 23 nie określa tej kolejności między warstwami. Nie jest to dowód zmiany działania: przed poleganiem na tym współdziałaniu potwierdzić je dla zainstalowanej wersji. W obrębie WebAdmin obie wersje nadal dokumentują najpierw DoS bypass rules, a potem DoS Settings dla pozostałego ruchu.

Reguł DoS bypass używać tylko wąsko

Reguły DoS bypass są przydatne, gdy jasno znany strumień danych byłby w przeciwnym razie regularnie błędnie blokowany przez DoS Settings w WebAdmin. Typowymi przykładami są monitoring, Health Checks lub precyzyjnie określona usługa między znanymi adresami IP. Wyjątek powinien być wtedy jak najbardziej precyzyjny: konkretne źródło, konkretny cel, właściwy protokół i wąski zakres portów.

Szerokie reguły bypass z dużymi sieciami, logiką any albo ogólnymi zakresami portów są niebezpieczne. Takie wyjątki oślepiają kontrolę DoS dokładnie tam, gdzie później może być potrzebna. Jeśli szeroki wyjątek wydaje się konieczny, należy najpierw sprawdzić, czy progi, architektura lub przypadek testowy nie zostały błędnie ocenione.

Dla ustawień WebAdmin kolejność jest ważna: Sophos Firewall najpierw sprawdza, czy pasuje DoS bypass rule, a dopiero potem stosuje znajdujące się tam DoS Settings do pozostałego ruchu. Zbyt szeroka reguła bypass może więc unieskutecznić tę ochronę. Dla reguł bypass trzeba świadomie ustawić Source, Destination, protokół, Source Port i Destination Port, zamiast wygodnie używać *.

Wyjątek tworzy się w Intrusion prevention > DoS & spoof protection, w sekcji DoS bypass rule, za pomocą Add. SFOS 22 i SFOS 23 wymagają podania IP version, adresów IP Source i Destination, Protocol, Source Port i Destination Port; * oznacza dowolny adres lub dowolny port. Dla kontroli stanu HTTPS z 198.51.100.20 do 203.0.113.10 odpowiednia konfiguracja wyglądałaby następująco: IP version IPv4, Source 198.51.100.20, Destination 203.0.113.10, Protocol TCP, Source Port * i Destination Port 443. Oba adresy przeznaczone do dokumentacji należy zastąpić rzeczywistymi adresami punktów końcowych. Source Port pozostaje zmienny wyłącznie dlatego, że klienci zazwyczaj używają dynamicznego portu źródłowego. Po Save przetestować dokładnie ten przepływ i inny przepływ; tylko zdefiniowana kontrola stanu może omijać ochronę DoS skonfigurowaną w WebAdmin.

Sprawdzenie zmiany i failover w HA

W klastrze HA urządzenie Primary synchronizuje do Auxiliary konfigurację firewalla, w tym reguły, policies, settings i polecenia CLI. Zmiany DoS i spoof należy wykonywać na bieżącym Primary. Następnie sprawdzić stan HA w System services > High availability oraz ponownie skontrolować wpisy WebAdmin i reguły CLI. W Active-active test obciążenia powinien objąć obie ścieżki przetwarzania. W Active-passive kontrolowany failover należy uwzględnić w oknie serwisowym, jeśli zezwala na to procedura operacyjna. Nie tworzyć odmiennej konfiguracji na Auxiliary.

Uwaga dotycząca SFOS 22.0 MR2

Release Notes dla SFOS 22.0 MR2 Build 546 podają, że usunięto problem NC-180226: WebAdmin wcześniej nie zgłaszał błędu przy dodawaniu zduplikowanego adresu MAC w Spoof protection trusted MAC. W starszych buildach 22.0 brak błędu nie dowodzi więc unikalności wpisu. Należy sprawdzić listę i rzeczywiste powiązanie albo zaktualizować system do poprawionego buildu.

Automatyzacja XML: zachowanie tożsamości i pól nadrzędnych

Przed automatyzacją tych ustawień sprawdzić zapisaną konfigurację i API help właściwą dla obiektu w zainstalowanym buildzie. Poniższe powiązania wyjaśniają dokumentację SFOS 22/SFOS 23; nie są przetestowanymi szablonami żądań. Bezpieczne korzystanie z XML API opisuje jawne operacje zapisu, ochronę dostępu i oddzielne kontrole transportu, odpowiedzi XML oraz zapisanego obiektu.

Reguła bypass: stare i nowe dopasowanie zamiast nazwy

DoSBypassRules nie ma udokumentowanej tożsamości Name. Dopasowanie składa się z IPFamily (IPv4 lub IPv6), SourceIPNetmask, DestinationIPNetmask i Protocol (TCP, UDP, ICMP lub AllProtocol), a dla TCP/UDP dodatkowo z SourcePort i DestinationPort. Porty to pojedyncze wartości od 1 do 65535 lub *; dokumentacja nie potwierdza tu payloadu zakresu portów. Dla dodawania/edycji tabela podaje domyślnie * dla obu adresów i TCP dla protokołu. Nie przyjmować tych szerokich wartości jako zamierzonego wyjątku, lecz świadomie określić pełne dopasowanie.

Przy aktualizacji DoSBypassRules/OldConfiguration zawiera poprzednią kombinację tych samych pól, a bezpośrednie elementy podrzędne DoSBypassRules zawierają nowe, oczekiwane dopasowanie. OldConfiguration należy do tożsamości aktualizacji, nie do tworzenia ani usuwania. Dokumentacja Delete wymienia pola dopasowania, nie nazwę. Przed usunięciem zidentyfikować rzeczywiście zapisaną kombinację. Przykład Add/Edit wyraźnie oznacza porty jako przeznaczone tylko dla TCP/UDP, ale listy parametrów, również dla Delete, bezwarunkowo określają oba porty jako obowiązkowe. Nie wynika z tego wiarygodny, wykonywalny payload usuwania dla ICMP/AllProtocol: wyjaśnić pomoc właściwą dla obiektu i build, zamiast wysyłać wymyślone wartości portów.

Trusted MAC: klucz MAC i oddzielne rodziny adresów

W TrustedMAC tożsamością jest MACAddress; przy aktualizacji TrustedMAC/OldConfiguration/MACAddress przechowuje stary klucz, a TrustedMAC/MACAddress zawiera oczekiwany adres MAC. Delete wymienia tylko MACAddress, nie Name ani OldConfiguration. Przed Update lub Delete zabezpieczyć konkretny wpis i jego powiązania, a następnie ponownie sprawdzić listę.

TrustedMAC/IPV4Association i TrustedMAC/IPV6Association są niezależnymi przypisaniami z wartościami Static, DHCP lub None; tabela API podaje dla każdego domyślnie Static. Odpowiadające im pola adresów CSV nazywają się dokładnie IPV4Address i IPV6Address. Import pliku używa również DHCPv6: nie przenosić tej wartości do IPV6Association bez sprawdzenia. W przypadku AssociateIP wartość przykładowa i opis są sprzeczne; nie wyprowadzamy z nich dozwolonej wartości zapisu. Wcześniejsze zastrzeżenia dotyczące rzeczywistego filtrowania IP-MAC pozostają konieczne także dla wpisów zarządzanych przez API.

Import pliku to oddzielna operacja Upload_TrustedMAC z Upload_TrustedMAC/TrustedMACListFile dla .csv lub .txt. Przykład podaje nazwę pliku przekazanego przez multipart, ale nie potwierdza konkretnej nazwy części multipart ani jej powiązania z tym polem XML. Nie wyprowadzać z przykładu gotowego żądania przesyłania; najpierw wyjaśnić kontrakt przesyłania właściwy dla buildu, a potem sprawdzić zaimportowane powiązania.

Nie spłaszczać Spoof Prevention i DoS Settings

Powtórzona nazwa w przykładzie jest zamierzona: SpoofPrevention to korzeń, a SpoofPrevention/SpoofPrevention to przełącznik. SpoofPrevention/RestrictUnknownIPOnTrustedMAC jest oddzielnym przełącznikiem. Trzy typy kontroli mają osobne listy stref: SpoofPrevention/IPSpoofing/EnableOnZone/Zone, SpoofPrevention/MACFilter/EnableOnZone/Zone i SpoofPrevention/IPMACFilter/EnableOnZone/Zone. Przykład pokazuje Enable/Disable, tabela parametrów natomiast on/off, a uwaga o wyłączeniu jest niejednoznaczna. Ani te informacje, ani pominięte lub puste listy stref nie potwierdzają składni czyszczenia lub wyłączania. Przed zapisem wyjaśnić wartości i wycofanie zmiany w zainstalowanym buildzie.

Pod DoSSettings elementy SYNFlood, UDPFlood, TCPFlood i ICMPFlood mają własne elementy nadrzędne Source i Destination. Pod Source znajdują się PacketRatePerSource, BurstRatePerSource i ApplyFlag; pod Destination — PacketRatePerDestination, BurstRatePerDestination i ApplyFlag. Na przykład DoSSettings/UDPFlood/Destination/ApplyFlag dotyczy tylko limitu UDP dla celu. Tabela dopuszcza szybkości pakietów 1–600000 i wartości burst 1–10000; domyślne 1 i liczby z przykładu nie są poziomem bazowym dla produkcji. Dodatkowe flagi znajdują się pod DoSSettings/DroppedSourceRoutedPackets/Destination/ApplyFlag, DoSSettings/DisableICMPRedirectPacket/Destination/ApplyFlag i DoSSettings/DisableARPFlooding/Destination/ApplyFlag. Nie łączyć powtarzających się etykiet tabeli w globalne PacketRate, BurstRate lub ApplyFlag; zachować zapisane wartości wraz ze ścieżką nadrzędną.

Odczytywanie kodów z operacją i zapisanym stanem

Dokumentacja wymienia następujące kody właściwe dla operacji, nie uniwersalne wyniki HTTP:

• Add DOS ByPass Rules: 200, 400, 401, 403, 409, 500; Edit DOS ByPass Rules: 200, 400, 401, 403, 404, 500. W szczególności nie zamieniać 409 dla Add z 404 dla Edit.
• Configure Spoof Prevention i Configuration DOS Settings: każda 200, 400, 401, 403, 404, 500.
• Upload Trusted MAC List: 200, 400, 401, 403, 404, 409, 500.
• Delete DOS ByPass Rule i Delete Trusted MAC: na tych stronach tylko 200, 500.
• Add Trusted MAC i Update Trusted MAC: każda 200 z Operation Successful. i 500 z Operation Fail..

Dla pozostałych wymienionych operacji komunikaty w pełnych źródłach pozostają symbolami JavaScript, a nie rozwiązanymi tekstami odpowiedzi:

Po każdej zmianie porównać odpowiedź z faktycznie zapisanymi strefami, szybkościami, powiązaniami lub kombinacją bypass. Przy błędzie lub niejasnej odpowiedzi ponownie odczytać stan przed kolejną próbą; nie tworzyć wpisu ponownie na ślepo ani nie wnioskować o działaniu filtra tylko z 200. Następnie oddzielnie sprawdzić pasujący i niepasujący przepływ testowy, jak opisano powyżej.

Czego te ustawienia nie rozwiązują

Spoof Protection i DoS Settings to ważne elementy składowe, ale nie rozwiązują każdego problemu bezpieczeństwa.

• Serwer jest atakowany za pośrednictwem dozwolonych żądań HTTP: sprawdzić regułę WAF i Webserver Protection.
• Atakuje znany złośliwy źródłowy adres IP: sprawdzić Threat Feeds lub blokowanie krajów/adresów IP.
• Próba wykorzystania exploita przeciwko usłudze: włączyć IPS-Policy odpowiednią dla reguły.
• Łącze internetowe jest wysycone przez DDoS: zaangażować dostawcę, zastosować scrubbing lub ochronę przed DDoS przed zaporą.
• Reguła zapory zezwala na zbyt wiele: uporządkować zestaw reguł, NAT i model obiektów.
• Nie można ustalić przyczyn odrzucania pakietów: usprawnić logowanie, Packet Capture, Syslog lub Central Reporting.

Artykuł Publikuj serwer z DNAT na Sophos Firewall ma również zastosowanie w przypadku serwerów dostępnych publicznie. Chodzi o NAT, reguły firewalla i typowe błędy przy udostępnianiu usług.

Logi i kontrola następcza

Po aktywacji powinieneś nie tylko sprawdzić, czy normalny dostęp do Internetu nadal działa. Ważne jest, czy firewall wyraźnie pokazuje oczekiwane i nieoczekiwane zdarzenia.

Sprawdź:

1. W Log Viewer odfiltrować zdarzenia Firewall i istotne zdarzenia Security.
2. Wygenerować ruch testowy z jednoznacznie określonymi Source-IP, Destination-IP i Service.
3. W przypadku niejasnych przyczyn odrzucania pakietów użyć Packet Capture.
4. W przypadku dłuższego przechowywania zaplanuj syslog do SIEM lub serwera logów.
5. Podczas uruchamiania Sophos Fusion (dawniej Sophos Central) sprawdź, czy Centralne raportowanie zapory ogniowej powoduje, że żądane zdarzenia są widoczne.

Jeśli pakiet zostanie upuszczony, ale przyczyna nie jest jasna, pomaga systematyczna analiza upuszczania pakietów w Sophos Firewall: sprawdź przyczyny. Opisuje także, dlaczego Log Viewer i Packet Capture odpowiadają na różne pytania.

SFOS rejestruje ruch odrzucony przez te mechanizmy ochrony. Przed testem DoS zapisać czas, Source, Destination, Protocol i liczniki. Podczas testu Intrusion prevention > DoS attacks pokazuje w czasie rzeczywistym Source lub Destination oraz odrzucone dane. Stan znika 30 sekund po zakończeniu ataku, a Traffic dropped narasta od ostatniego restartu, dlatego miarodajne jest tylko ograniczone czasowo porównanie przed i po. Tryb CLI global nie dotyczy tych liczników interfejsu; nawet takie porównanie nie weryfikuje więc globalnej agregacji. Dla globalnej polityki CLI oddzielić kontrolę konfiguracji za pomocą show od kontroli określonego przepływu testowego i jego odrzuceń/logów. Packet Capture pokazuje dodatkowo interfejs wejściowy i adresy pakietu, ale sam nie dowodzi, który mechanizm odrzucił przepływ.

Rozwiązywanie problemów po aktywacji

Po zmianie nie należy zbyt szybko interpretować objawów jako ataku. Najszybsza analiza to zwykle porównanie oczekiwania, obserwacji i następnego testu.

• Pojedyncza sieć traci dostęp: sieć źródłowa może przychodzić innym interfejsem niż oczekiwano. Porównać route, VLAN, SD-WAN Route i Packet Capture.
• Wielu klientów za NAT-em wykonanym przed zaporą zwraca uwagę: jeśli NAT zastosowano przed Sophos Firewall, zapora widzi wielu klientów jako jeden wspólny adres źródłowy. Sprawdzić próg, ścieżkę NAT i legalny szczyt obciążenia.
• VoIP, monitoring lub scanner generuje dropy: regularne tempo pakietów może wyglądać jak flooding. Sprawdzić wąskie okno testowe, Log Viewer i w razie potrzeby precyzyjną regułę bypass.
• Urządzenia przestają działać po zmianie DHCP: binding IP-MAC albo logika Trusted MAC może już nie pasować. Sprawdzić lease, adres MAC i binding.
• Brakuje tylko ruchu zwrotnego: prawdopodobna jest asymetryczna ścieżka albo zła brama. Osobno sprawdzić kierunek tam i z powrotem przy użyciu Packet Capture.
• Zmiana ARP lub ICMP powoduje efekty uboczne: ARP hardening, source-routed packets albo ICMP redirect mogą trafić w nietypowe projekty sieci. Sprawdzić routery downstream, segmenty Layer 2 i ścieżkę routingu.

Bezpieczne wycofanie

Jeśli blokowany jest legalny ruch, a przyczyny nie da się ustalić w oknie serwisowym, nie należy improwizować szerokiego wyjątku. Przywrócić zapisane wartości Packet Rate i Burst Rate, flagi Apply, typ kontroli spoof, strefy oraz Restrict unknown IP on trusted MAC; usunąć wyłącznie nowo utworzone wpisy bypass lub Trusted MAC. Użyć Apply albo Save i powtórzyć ten sam przepływ testowy. Dla policy CLI najpierw usunąć tylko nazwaną regułę, a potem nieużywaną już dedykowaną policy. flush dos-rules nie jest częścią tego rollbacku.

Typowe błędy

• Włączanie Spoof Protection bez zrozumienia routingu: prawidłowy ruch może zostać zablokowany. Najpierw sprawdzić strefy, interfejsy, trasy i ścieżki powrotne.
• Przyjmowanie progów DoS bez weryfikacji: działanie VoIP, monitoringu, skanowania lub opublikowanych usług może zostać zakłócone. Zaplanować ustalenie poziomu bazowego i fazę testową.
• Mylenie Packet Rate i Burst Rate: stała szybkość pakietów i krótkotrwały skok to różne parametry regulacji. Oba muszą być dostosowane do usługi.
• Rozwiązywanie każdej nieprawidłowości szerokim wyjątkiem: utwardzanie zabezpieczeń staje się nieskuteczne i nieprzejrzyste. Zawęzić przyczynę, a wyjątki definiować wąsko i dokumentować.
• Zbyt szerokie definiowanie DoS bypass rule: w WebAdmin obejście jest sprawdzane przed tamtejszymi DoS Settings i może całkowicie ominąć tę kontrolę. Wąsko określić Source, Destination, protokół i porty; dodatkowo sprawdzić odrębne polityki CLI.
• Pozostawienie pustego filtra IP-MAC-Pair: bez utrzymywanych wpisów nie powstaje skuteczne powiązanie. Po włączeniu zawsze przeprowadzić sprawdzenie przy użyciu znanego klienta testowego.
• Przedstawianie DoS Settings jako ochrony przed DDoS: w przypadku ataków wysycających przepustowość tworzy to fałszywe oczekiwania. Osobno zaplanować ochronę po stronie dostawcy i w sieci nadrzędnej.
• Brak sprawdzania logów: błędne blokady lub ataki pozostają niewidoczne. Uwzględnić Log Viewer, Central Reporting lub Syslog w procedurach operacyjnych.
• Interpretowanie pakietów odrzucanych z powodu spoofingu wyłącznie jako ataku: błędy routingu lub VLAN pozostają niezauważone. Porównać Source-IP, Interface, Route i Packet Capture.

Operacyjna lista kontrolna

Przed włączeniem:

• Przeanalizowano strefy, interfejsy i routing.
• Zdefiniowano usługi krytyczne i przypadki testowe.
• Przeprowadzono ocenę techniczną Packet Rate, Burst Rate i włączonych flag.
• Dostępna jest kopia zapasowa lub dokumentacja zmiany.
• Przygotowano rejestrowanie i analizę zdarzeń.
• Wyznaczono obszar pilotażowy lub okno serwisowe.

Po włączeniu:

• Przetestowano Internet, VPN, WAF, DNAT, VoIP i monitoring.
• Sprawdzono Log Viewer pod kątem nieoczekiwanego odrzucania pakietów.
• W przypadku odrzucania pakietów użyto Packet Capture dla co najmniej jednego jednoznacznego przypadku testowego.
• Wyjątki ustawiono wyłącznie w wąskim zakresie i z uzasadnieniem.
• Sprawdzono DoS bypass rules pod kątem Source, Destination, protokołu i portów.
• Zapisano wynik w dokumentacji eksploatacyjnej.

Regularnie:

• Sprawdzać zdarzenia DoS i spoofingu.
• Kontrolować, czy wyjątki są nadal potrzebne.
• Ponawiać testy po przebudowie sieci, zmianach VPN lub dodaniu nowych VLAN-ów.
• Korelować logi ze zdarzeniami IPS, Threat-Feed, WAF i reguł firewalla.

Często zadawane pytania