Sophos Firewall Spoof Protection i DoS Settings sprawdź

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.

Typowa ścieżka menu, w zależności od wersji SFOS, mieści się w zakresie:

Intrusion prevention > DoS & spoof protection

Jeśli w nowszej wersji interfejs jest nieco inaczej oznaczony, powinieneś poszukać DoS, ochrony przed fałszowaniem lub zapobiegania włamaniom. Ważna jest nie dokładna ścieżka kliknięcia, ale to, aby funkcja była świadomie zaplanowana, przetestowana i później logowana.

Do czego służą funkcje

• Spoof Protection: Odrzuca pakiety z nieprawdopodobnym źródłowym adresem IP, ogranicza proste próby fałszowania, uwidacznia błędnie przekierowane pakiety. nie zastępuje czystej strefy, interfejsu i planowania routingu.
• DoS Settings: ogranicza proste wzorce zalewania, sprawia, że głośne ataki lub błędne konfiguracje stają się zauważalne wcześniej. nie zastępuje ochrony dostawcy przed DDoS, nie ma WAF ani czysto zwymiarowanego projektu 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ę; nie powodują automatycznego ominięcia wcześniejszych polityk 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 klienta, gościa lub IoT, w których jako źródła nie powinny pojawiać się żadne zewnętrzne sieci wewnętrzne.
• 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. Document zones, interfaces, VLANs, bridges and LAGs.
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 z witrynami.
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.

Jeśli zwykłe reguły zapory sieciowej są trudne do zrozumienia, należy najpierw wyczyścić regułę i status 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.

Spoof Protection aktywuj ostrożnie

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. Zacznij od przejrzystej strefy lub interfejsu, na przykład WAN lub wyraźnie oddzielonej strefy klienta.
3. Zapisz aktywację.
4. Uruchom zaplanowane połączenia testowe: dostęp do Internetu, VPN, usługi opublikowane, serwery centralne, monitoring.
5. Sprawdź Log Viewer i Packet Capture pod kątem nieoczekiwanych spadków.
6. Nie zajmuj się od razu rzucającymi się w oczy, uzasadnionymi spadkami (z szerokimi wyjątkami), ale najpierw sprawdź routing, źródłowy adres IP i interfejs.

Częstym błędem jest traktowanie Spoof Protection jako czystego haka bezpieczeństwa. W rzeczywistości funkcja sprawdza założenia dotyczące projektu sieci. Jeśli to założenie nie jest poprawne, Spoof Protection niekoniecznie musi być błędne. Często interfejs, trasa, VLAN lub trasa powrotna nie są budowane zgodnie z oczekiwaniami.

Poprawnie rozumieć IP, MAC i pary IP-MAC

Sophos rozróżnia kilka typów kontroli. IP spoofing odrzuca ruch, gdy źródłowy adres IP nie pasuje do tablicy routingu albo do bezpośrednio podłączonej podsieci. MAC filter działa z zaufanymi adresami MAC; musi być utrzymany co najmniej jeden Trusted MAC Address. MAC filter nie jest stosowany do pakietów DHCP. IP-MAC pair filter sprawdza, czy przychodząca kombinacja adresu IP i adresu MAC pasuje do znanej pary.

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.

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.

Ważne jest oczekiwanie: aktywny IP-MAC pair filter bez utrzymanych wpisów Trusted MAC lub IP-MAC nie chroni automatycznie. Jeśli nie ma pasujących wpisów, ruch nie jest blokowany, lecz dozwolony. Ochrona powstaje dopiero dzięki utrzymanym i przetestowanym powiązaniom.

Opcja Restrict unknown IP on trusted MAC jest szczególnie rygorystyczna: pakiety z Trusted MAC bez pasującego powiązania IP mogą zostać odrzucone, jeśli IP jest nieznane z perspektywy zapory. To zysk bezpieczeństwa w kontrolowanych sieciach, ale pułapka przy DHCP, migracjach i tymczasowych zmianach IP.

DoS Settings plan

DoS Settings powinien pasować do środowiska. Rzadko ma sens przejmowanie wartości z innego przykładu bez sprawdzania. Witryna z kilkoma użytkownikami, VoIP i małym WAN zachowuje się inaczej niż centrum danych, sieć szkolna lub witryna 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?
• Które zdarzenia powinny być tylko rejestrowane, a które naprawdę blokowane?
• 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.

W tej masce chodzi nie tylko o klasyczne floody. Są też flagi takie jak Dropped source routed packets, Disable ICMP/ICMPv6 redirect packet i ARP hardening. To sensowne podstawowe hardening, ponieważ może ograniczać manipulacje routingiem lub zachowaniem ARP. Po aktywacji trzeba je jednak przetestować, szczególnie w sieciach z routerami downstream, starszymi segmentami albo nietypowymi projektami Layer 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.

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. Ten udokumentowany przez Sophos przykład ogranicza ruch SYN z przykładowego adresu 198.51.100.50 do 1000 pps na Source:

system dos-config add dos-policy policy-name TestSYN SYN-Flood 1000 pps per-src
system dos-config add dos-rule rule-name TestRuleSYN srcip 198.51.100.50 dos-policy TestSYN

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

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.

Reguły i polityki CLI są przetwarzane przed ustawieniami DoS i spoof w WebAdmin. W obrębie ustawień WebAdmin zapora najpierw sprawdza DoS bypass rules, a następnie pozostałe DoS Settings. Reguła bypass w WebAdmin nie powoduje więc automatycznego ominięcia pasującej polityki CLI.

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ć *.

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 zostaje zaatakowany poprzez dozwolone żądania HTTP: Sprawdź regułę WAF i ochronę serwera WWW.
• Znane złośliwe źródło ataków IP: Threat Feeds lub Sprawdź blokowanie kraju/adresu IP.
• Próba exploita w usłudze: Aktywuj IPS-Policy zgodnie z regułą.
• Linia internetowa jest pełna z powodu DDoS: Uwzględnij dostawcę, czyszczenie lub ochronę przed DDoS.
• Reguła zapory sieciowej pozwala na zbyt wiele: Reguły czyszczenia, NAT i model obiektowy.
• Krople są niezrozumiałe: Popraw logowanie, Packet Capture, syslog lub raportowanie centralne.

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 wydawnicze.

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. Log Viewer filtr dla zapory ogniowej i odpowiednich zdarzeń związanych z bezpieczeństwem.
2. Uruchamiaj ruch testowy z wyraźnym źródłowym adresem IP, docelowym adresem IP i usługą.
3. Użyj Packet Capture w przypadku niejasnych kropli.
4. W przypadku dłuższego przechowywania zaplanuj syslog do SIEM lub serwera logów.
5. Podczas uruchamiania 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.

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.

Typowe błędy

• Spoof Protection aktywuj bez zrozumienia routingu: legalny ruch może zostać zablokowany. Sprawdź wcześniej strefy, interfejsy, trasy i ścieżki powrotne.
• Zastosuj progi DoS bez sprawdzania: VoIP, monitorowanie, skanowanie lub opublikowane usługi mogą zostać zakłócone. Zaplanuj fazę bazową i testową.
• Mylenie Packet Rate i Burst Rate: trwałe tempo pakietów i krótki pik to różne ustawienia. Oba muszą pasować do usługi.
• Rozwiąż każdą anomalię z szerokim wyjątkiem: Hartowanie staje się nieskuteczne i mylące. Ogranicz przyczynę i dokładnie dokumentuj wyjątki.
• Zbyt szeroka DoS bypass rule: w WebAdmin bypass jest sprawdzany przed znajdującymi się tam DoS Settings i może całkowicie ominąć tę kontrolę. Source, Destination, protokół i porty należy utrzymywać wąsko; dodatkowo sprawdzić oddzielne polityki CLI.
• Pozostawienie pustego IP-MAC pair filter: bez utrzymanych wpisów nie powstaje skuteczne powiązanie. Po aktywacji zawsze testować ze znanym klientem.
• Sprzedawaj DoS Settings jako ochronę DDoS: fałszywe oczekiwania co do ataków na przepustowość. Zaplanuj osobno ochronę dostawcy i upstream.
• Nie sprawdzaj logów: Niepoprawne bloki lub ataki pozostają niewidoczne. Zdefiniuj Log Viewer, centralne raportowanie lub syslog jako punkt operacyjny.
• Interpretuj fałszywe ataki jako czysty atak: Błędy routingu lub VLAN są pomijane. Porównaj źródłowy adres IP, interfejs, trasę i Packet Capture.

Operacyjna lista kontrolna

Przed aktywacją: Strefy

• Strefy, interfejsy i routing są zrozumiałe.
• Zdefiniowano usługi krytyczne i przypadki testowe.
• Packet Rate, Burst Rate i aktywne flagi oceniono technicznie.
• Dostępna jest kopia zapasowa lub zmiana dokumentacji.
• Przygotowano rejestrowanie i ocenę.
• Zestaw obszaru pilotażowego lub okna konserwacji.

Po aktywacji:

• Internet, VPN, WAF, DNAT, VoIP i przetestowane monitorowanie.
• Log Viewer sprawdzone pod kątem nieoczekiwanych spadków.
• Packet Capture używany w co najmniej jednym wyraźnym przypadku testowym, gdy występują spadki.
• Wyjątki są stosowane jedynie wąsko i mają ku temu powody.
• DoS bypass rules sprawdzone pod kątem source, destination, protocol i portów.
• Wynik zapisany w dokumentacji operacyjnej.

Regularnie:

• Sprawdzaj DoS i fałszywe zdarzenia.
• Sprawdź wyjątki pod kątem konieczności.
• Przetestuj ponownie po modyfikacjach sieci, zmianach VPN lub nowych VLAN. Powiąż dzienniki
• z IPS, kanałem zagrożeń, WAF i zdarzeniami reguł zapory sieciowej.

Często zadawane pytania