Sophos Firewall: Blokowanie krajów i złośliwych IP

Gdy usługi są dostępne z Internetu, często szybko pojawia się niepożądany ruch: skanowanie portów, próby logowania, znane botnety lub dostęp z krajów, z których nie oczekuje się użytkowników. Na Sophos Firewall można blokować takie źródła na kilku poziomach.

Ten artykuł wyjaśnia dwie typowe metody:

• Blokowanie krajów lub sieci źródłowych za pomocą reguły zapory
• Tłumaczenie niepożądanych źródeł na nieistniejący adres IP za pomocą reguły Black Hole DNAT

Dodatkowo zalecamy Sophos Firewall Threat Feeds, aby automatycznie blokować znane złośliwe IP, domeny lub URL.

Orientacja

Przed zablokowaniem źródeł musi być jasne, którego ruchu to dotyczy: opublikowanych usług, lokalnych usług firewalla, ruchu wychodzącego klientów czy ruchu WAF. Właściwa metoda zależy właśnie od tego.

Która metoda jest odpowiednia?

• Reguła zapory z Drop: Blokuje ruch na podstawie Source Country, Source Network lub Source Host. Pasuje do blokad krajów, pojedynczych sieci lub ręcznie utrzymywanych list złych IP.
• Black Hole DNAT: Przekierowuje niepożądany ruch na nieistniejący wewnętrzny adres IP. Jest przydatne, gdy ruch do opublikowanych usług ma zostać przechwycony wcześnie.
• WAF Blocked countries: Dotyczy serwerów WWW publikowanych przez WAF. Kraje są blokowane bezpośrednio w regule WAF.
• Local service ACL exception rule: Steruje lokalnymi usługami firewalla, takimi jak WebAdmin, User Portal, VPN Portal lub SSH. To właściwe miejsce, gdy trzeba chronić sam firewall.
• Threat Feeds: Korzystają z dynamicznych list znanych złośliwych źródeł. Pasują do botnetów, skanerów, infrastruktury malware i znanych adresów IP atakujących.

Wybór metody zależy od tego, gdzie ruch jest technicznie przetwarzany. Reguły zapory nie zawsze działają dla ruchu kierowanego do adresu używanego w WAF. W takich przypadkach często lepsza jest reguła WAF dla krajów lub reguła Black Hole DNAT.

Ruch przychodzący, wychodzący czy lokalna zapora

Przed utworzeniem reguły blokującej należy jasno określić, o jaki typ ruchu chodzi. W przeciwnym razie można zablokować ruch w niewłaściwym miejscu i później zastanawiać się, dlaczego atak jest nadal widoczny lub dlaczego legalny ruch nie działa.

• Ruch przychodzący do opublikowanego serwera: Przekierowanie portów na RDP, HTTPS, SMTP lub własną aplikację. Kolejność DNAT, reguła WAF, reguła zapory, IPS i logowanie
• Ruch przychodzący do samej zapory: WebAdmin, User Portal, VPN Portal, SSH, Ping lub DNS na zaporze. Device Access i Local Service ACL Exception Rules
• Ruch wychodzący od wewnętrznych klientów: Klienci łączą się z podejrzanymi celami w Internecie. Reguła zapory, Threat Feeds, Web Protection, DNS Protection i logowanie
• Serwery WWW przez WAF: publiczna aplikacja webowa za Web Server Protection. Reguła WAF, Blocked countries, uwierzytelnianie, MFA i logi WAF

To rozróżnienie jest ważne, ponieważ reguła krajowa w Rules and policies > Firewall rules nie automatycznie zabezpiecza każdej powierzchni ataku zapory. Dla opublikowanych serwerów najważniejsza jest zazwyczaj ścieżka NAT i WAF. Dla portali administracyjnych najpierw liczy się, czy lokalna usługa zapory jest w ogóle dostępna z danej strefy. Dla ruchu wychodzącego klientów Threat Feeds, Web Protection i DNS Protection są często czystszymi narzędziami.

Nie mylić z Device Access

Country Blocking i Black Hole DNAT chronią przede wszystkim ruch przetwarzany przez reguły zapory lub NAT. Lokalne usługi Sophos Firewall to inny przypadek. Należą do nich na przykład WebAdmin, SSH, User Portal, VPN Portal, DNS, Ping i częściowo także usługi zdalnego dostępu.

Dla tych lokalnych usług najpierw istotne jest Administration > Device access. Tam decyduje się, z których stref usługa jest zasadniczo dostępna. Jeśli dostęp ma być dozwolony tylko dla pojedynczych adresów IP administratorów, krajów lub źródeł wsparcia, właściwym punktem kontrolnym są Local service ACL exception rules. Procedura jest opisana w zabezpieczaniu dostępu do Sophos Firewall przez Device Access.

⚠️ Reguła blokowania krajów nie zastępuje poprawnej konfiguracji Device Access. Jeśli WebAdmin, User Portal, VPN Portal lub SSH są zbyt szeroko dostępne, sama zapora pozostaje powierzchnią ataku. Country Blocking może zmniejszyć ryzyko, ale nie zastąpi podstawowego wzmocnienia dostępu.

Dla szczególnie wrażliwych usług lokalnych WAN nie powinien być szeroko aktywowany w Local service ACL. Lepsza jest exception rule, która dopuszcza tylko oczekiwane źródła albo blokuje niepożądane kraje. Dla WebAdmin stały adres IP administratora lub VPN zarządzający jest zwykle czystszy niż filtr kraju, ponieważ Geo-IP nie jest realną weryfikacją tożsamości.

Planowanie reguł blokujących

Reguły blokujące należy planować tak, aby przypadkowo nie przerywać prawidłowego ruchu.

Blokowanie krajów za pomocą reguły zapory

Dla ogólnego blokowania krajów można utworzyć regułę zapory z Drop.

Ścieżka menu:

Rules and policies > Firewall rules

Zalecane pola:

• Rule name: opisowa nazwa, na przykład BLOCK_COUNTRY_PANAMA
• Rule position: Top
• Action: Drop
• Source zones: Any
• Source networks and devices: kraj, grupa krajów, lista IP lub grupa hostów
• During scheduled time: All the time
• Destination zones: Any
• Destination networks: Any
• Services: Any lub zdefiniowana usługa

Dla blokowania krajów ważne jest, aby Source zones i Destination zones nie były ustawione zbyt wąsko. Jeśli wpisze się tylko WAN jako Source zone, reguła może nie działać dla wszystkich istotnych ścieżek ruchu.

Kraje i grupy krajów są używane jako obiekty w Hosts and services. Przy wielu krajach Country host group jest czytelniejsza niż wiele pojedynczych krajów bezpośrednio w każdej regule. Listy złych IP powinny trafić do odpowiednich obiektów IP host lub IP host group. Trzeba znać ich granice: listy IP host nie są przeznaczone dla dowolnie dużych dynamicznych feedów. Dla stale zmieniającej się infrastruktury atakujących łatwiejsze w utrzymaniu są Threat Feeds.

Blokowanie krajów powinno być również rozumiane jako kontrola Best-Effort. Dane Geo-IP mogą być błędne, użytkownicy podróżują, atakujący używają proxy lub skompromitowanych systemów w dozwolonych krajach, a usługi chmurowe korzystają z globalnie rozproszonej infrastruktury. Dlatego reguła krajowa nigdy nie powinna być jedynym środkiem ochrony.

Kiedy nie blokować zbyt szeroko

Reguła blokująca jest szybko utworzona, ale później może powodować trudne do zrozumienia skutki uboczne. Szczególnie ostrożnym należy być, gdy produktywne aplikacje zależą od zewnętrznych platform, CDN, dostawców płatności, usług chmurowych, dostawców monitoringu lub partnerów wsparcia.

Przed szerokim blokowaniem krajów lub IP należy wyjaśnić:

• Czy są użytkownicy, partnerzy lub dostawcy usług w dotkniętych krajach?
• Czy aplikacja korzysta z infrastruktury chmurowej lub CDN z zmieniającymi się adresami źródłowymi?
• Czy aktualizacje, webhooki, monitorowanie, kopie zapasowe lub dostęp wsparcia są inicjowane przez zewnętrzne usługi?
• Czy istnieje możliwość najpierw tylko logowania lub przetestowania reguły czasowo ograniczonej?
• Czy wiadomo, kto sprawdza fałszywe pozytywy i jak zatwierdzana jest wyjątek?

Dla usług internetowych z rzeczywistym logowaniem użytkowników reguły krajowe są często tylko dodatkowym środkiem. MFA, ścisłe reguły zapory, aktualne systemy docelowe, IPS, ochrona WAF, logowanie i Threat Feeds pozostają ważniejsze niż jak najdłuższa lista blokad.

Planowanie Allowlist przed Blocklist

Dla krytycznych usług Allowlist jest często czystsza niż coraz dłuższa Blocklist. Jeśli usługa musi być dostępna tylko dla stałych partnerów, oddziałów, systemów monitorujących lub lokalizacji administratorów, najpierw należy zezwolić na te źródła i zablokować resztę. To zmniejsza nakład pracy na utrzymanie i zapobiega konieczności reaktywnego blokowania każdej nowej IP skanera.

Allowlist pasuje szczególnie dobrze do:

• Dostępów administracyjnych do opublikowanych usług zarządzania
• Interfejsów B2B z znanymi adresami IP partnerów
• Monitoringu, kopii zapasowych, webhooków lub punktów końcowych API z stałymi systemami źródłowymi
• Tymczasowych dostępów wsparcia z biletem, datą wygaśnięcia i przeglądem

Blocklist pasuje bardziej, gdy usługa musi być świadomie publicznie dostępna, ale należy zmniejszyć liczbę podejrzanych źródeł. Wtedy reguła powinna być prowadzona z logowaniem, datą przeglądu i jasnymi wyjątkami. Dla serwerów WWW publikowanych przez WAF dodatkowo istotny jest artykuł o bezpiecznym publikowaniu serwerów WWW przez Sophos Firewall WAF, ponieważ tam kraje, uwierzytelnianie i ochrona serwera WWW są kontrolowane bliżej opublikowanej aplikacji.

Filtry krajów WAF traktować osobno

W Web Server Protection reguła WAF ma własne pola Allowed client networks, Blocked client networks, Blocked countries oraz Block IP addresses of unknown country-origin. Te ustawienia należą do opublikowanej aplikacji webowej i nie są tym samym co normalna reguła firewall Drop.

To praktyczne, ponieważ filtr krajów jest bezpośrednio powiązany z publikacją WAF. Jednocześnie trzeba uważać: Block IP addresses of unknown country-origin może wykluczyć legalnych użytkowników, jeśli ich adresu IP nie da się jednoznacznie przypisać. Przed aktywacją warto sprawdzić własny zewnętrzny adres IP w GeoIP2 Databases Demo. Tę opcję należy włączyć tylko wtedy, gdy efekt został przetestowany i jest znany w procesie wsparcia.

Dla reguł WAF filtry krajów są tylko jednym elementem. Uwierzytelnianie, MFA, certyfikat, Web Server Protection, sygnatury IPS/WAF, logowanie i aktualny serwer backend pozostają ważniejsze niż długa lista blokowanych krajów.

Black Hole DNAT i Threat Feeds

Przy opublikowanych usługach sensowne może być przechwycenie niepożądanych źródeł jeszcze przed produkcyjną regułą DNAT. Dla dynamicznej infrastruktury atakujących pomocne są dodatkowo Threat Feeds.

Black Hole DNAT dla niepożądanych źródeł

Reguła Black Hole DNAT tłumaczy ruch na cel, który nie istnieje w sieci. Ruch trafia w próżnię i nie dociera do właściwej usługi.

Jest to szczególnie przydatne, gdy usługa jest publikowana przez DNAT i chce się przechwycić określone źródła przed właściwym przekierowaniem portów.

Black Hole DNAT powinno być stosowane celowo. Nadaje się przede wszystkim do ruchu do opublikowanych usług, gdzie pod spodem znajduje się normalna reguła DNAT. Dla ogólnego ruchu wychodzącego klientów, lokalnych usług zapory lub serwerów WWW publikowanych przez WAF, zazwyczaj lepszym punktem kontrolnym jest reguła zapory, Device Access lub ustawienie WAF.

W regule NAT ważne jest, aby nie pomylić pierwotnej perspektywy atakującego z przetłumaczonym celem fikcyjnym. Reguła powinna znajdować się w Rules and policies > NAT rules powyżej produkcyjnej reguły DNAT. Original source zawiera zablokowaną listę IP, kraj lub grupę krajów. Original destination to publiczny adres WAN lub obiekt hosta WAN, do którego odwołuje się atakujący. Translated destination to nieroutowany host fikcyjny. W tym wzorcu translacja źródła i usługi zwykle pozostaje ustawiona na Original.

Po zapisaniu należy sprawdzić w Log Viewer, czy trafiana jest oczekiwana NAT Rule ID. Jeśli normalna reguła DNAT nadal pasuje, reguła Black Hole znajduje się zbyt nisko, źródło nie pasuje albo wskazana usługa lub destination nie odpowiada ruchowi testowemu.

Do reguły Black Hole DNAT nadal należy pasująca reguła firewall albo ścieżka logowania, aby trafienie było możliwe do prześledzenia. NAT tylko tłumaczy adresy, nie jest samodzielnym zezwoleniem na dostęp. Jeśli później nikt nie wie, po co istnieje host-dummy albo jakie źródło jest przechwytywane, ta technika szybko staje się zaszłością.

Przykład:

• Rule name: BLOCK_BAD_IPS_COUNTRIES
• Rule position: Top
• Original source: lista złych IP, kraj lub grupa krajów
• Original destination: publiczny adres IP WAN lub obiekt hosta WAN
• Original service: Any lub opublikowana usługa
• Translated source (SNAT): Original
• Translated destination (DNAT): Host-dummy, który nie istnieje
• Translated service (PAT): Original
• Inbound interface: Any
• Outbound interface: Any

Host-dummy powinien używać adresu IP, który nie istnieje w sieci i nie jest routowany. Ważne jest, aby ta reguła znajdowała się powyżej właściwych reguł DNAT. Reguły NAT są przetwarzane od góry do dołu. Jeśli najpierw pasuje normalna reguła DNAT, reguła Black Hole DNAT jest za późno.

Host-dummy nie powinien być wybierany przypadkowo. Sensowne jest użycie adresu z wewnętrznej, nieużywanej sieci dokumentacyjnej lub dummy, która nie jest routowana i nie jest później planowana dla rzeczywistych systemów. Reguła powinna jasno opisywać, dlaczego ten host istnieje, aby nie został przypadkowo usunięty lub użyty produkcyjnie.

Dlaczego kolejność jest kluczowa

W przypadku reguł NAT wygrywa pierwsza pasująca reguła. Reguła Black Hole DNAT musi więc znajdować się bardzo wysoko, zazwyczaj na samej górze tabeli reguł NAT.

Przykładowa kolejność:

1. Black Hole DNAT dla listy złych IP i zablokowanych krajów
2. Specyficzne reguły DNAT dla opublikowanych usług
3. Specjalne reguły SNAT
4. Ogólna reguła MASQ dla ruchu wychodzącego

W przypadku reguł zapory obowiązuje ta sama zasada: specyficzne reguły blokujące znajdują się powyżej ogólnych reguł zezwalających. W przeciwnym razie może się zdarzyć, że ruch zostanie już dozwolony, zanim zostanie sprawdzona reguła Drop.

Nie zostawiaj źródła niepotrzebnie na Any

Dla opublikowanych usług należy jak najbardziej ograniczyć źródło.

Sensowne źródła mogą być:

• Pojedyncze publiczne adresy IP
• Sieci partnerów lub oddziałów
• Kraje, z których oczekuje się dostępu
• FQDN Hosts lub DNS Host Groups, jeśli pasują
• Utrzymywane Host Groups z dozwolonymi adresami IP administratorów

Any ma sens tylko wtedy, gdy usługa naprawdę musi być dostępna na całym świecie. Wtedy należy aktywować dodatkowe środki ochrony: logowanie, IPS, MFA tam, gdzie to możliwe, silne uwierzytelnianie, aktualne systemy docelowe i Threat Feeds.

IPv6 trzeba zaplanować osobno. Reguła krajowa IPv4 nie dowodzi, że ta sama aplikacja jest chroniona również przez IPv6. W środowiskach dual-stack potrzebne są odpowiednie reguły IPv6, logowanie i ścieżka testowa. Jeśli IPv6 nie jest używane produkcyjnie, należy je świadomie wyłączyć, blokować albo wprowadzić z dokumentacją.

Dodatkowe użycie Threat Feeds

Ręczne listy i reguły krajowe są statyczne. Infrastruktura atakujących zmienia się jednak ciągle. Dlatego zalecamy dodatkowo Sophos Firewall Threat Feeds.

Threat Feeds pomagają szczególnie w przypadku:

• Znanych adresów IP skanerów
• Botnetów
• Infrastruktury malware
• Skompromitowanych hostów
• Dynamicznie utrzymywanych list złych IP

Dzięki temu nie trzeba ręcznie utrzymywać każdej pojedynczej IP. Zapora może blokować znane złe źródła, zanim dotrą do opublikowanej usługi.

Testy i eksploatacja

Po zmianie należy świadomie sprawdzić liczniki, logi i oczekiwane ścieżki dostępu.

Eksploatacja i przegląd list blokujących

Listy blokujące są pomocne tylko wtedy, gdy są zrozumiałe w eksploatacji. Reguła krajowa lub lista złych IP nie powinna po prostu rosnąć w nieskończoność, bez sprawdzania trafień, wyjątków i skutków ubocznych.

Dla każdej ręcznej listy blokującej powinno być udokumentowane:

• Dlaczego źródło zostało zablokowane
• Czy jest to blokada tymczasowa czy stała
• Kto utrzymuje listę
• Kiedy reguła zostanie ponownie sprawdzona
• Jakie usługi lub reguły DNAT są dotknięte
• Jak zatwierdzany jest fałszywy pozytyw

Szczególnie w przypadku sieci chmurowych, CDN, hostingowych lub wsparcia należy być ostrożnym. Pojedynczy adres IP może później należeć do innego klienta, zakres CDN może zawierać legalne usługi, a zewnętrzny dostawca usług może zmienić swój adres IP. Jeśli legalny dostęp zostanie zablokowany, nie należy natychmiast wyłączać całej reguły. Lepiej jest wprowadzić ścisły wyjątek z powodem, biletem i datą przeglądu.

Dla opublikowanych serwerów należy dodatkowo sprawdzić, czy lista blokująca rzeczywiście działa przed produkcyjną regułą DNAT. Kontrola operacyjna w artykule o publikowaniu serwerów przez DNAT na Sophos Firewall pomaga ocenić opublikowane usługi, reguły NAT i logowanie razem. Jeśli zablokowane źródła przechodzą przez regułę zapory, odpowiednią ścieżką testową jest testowanie reguł firewalla z Log Viewer, Policy Test i Packet Capture.

Sensowny przegląd nie polega tylko na spojrzeniu na regułę. Należy sprawdzić w Log Viewer, czy reguła nadal trafia, jakie źródła są dotknięte i czy trafienia odpowiadają oczekiwanemu ryzyku. Dla długoterminowej analizy lepsze są Central Firewall Reporting lub Sophos Firewall Syslog an SIEM senden niż same lokalne logi.

Procedura testowa po zmianie

Po nowej regule blokującej należy sprawdzić nie tylko, czy niepożądany dostęp zniknął. Ważne jest również, czy pożądany ruch nadal działa i czy zapora rejestruje trafienie w sposób zrozumiały.

Praktyczna procedura:

1. Utwórz regułę z opisową nazwą, logowaniem i ścisłym opisem.
2. Jeśli to możliwe, najpierw przetestuj z małą listą źródeł lub pojedynczym krajem.
3. Sprawdź oczekiwany blok z odpowiedniego zewnętrznego źródła.
4. W Log Viewer przefiltruj według źródła, celu, usługi, ID reguły zapory i ID reguły NAT.
5. Przetestuj legalny dostęp z dozwolonego źródła.
6. Dla opublikowanych serwerów sprawdź, czy produkcyjna reguła DNAT nadal działa dla dozwolonych źródeł.
7. Udokumentuj datę przeglądu i właściciela reguły.

Jeśli nie jest możliwy czysty test z zewnątrz, zmiana powinna być przynajmniej monitorowana za pomocą Log Viewer, Packet Capture i wąskiego okna konserwacyjnego. Reguła blokująca bez widocznych trafień i bez właściciela jest po kilku miesiącach trudna do odróżnienia od starego obciążenia.

Troubleshooting

Jeśli brakuje oczekiwanego efektu, należy krok po kroku sprawdzić logi, rule matching i zachowanie policy.

Typowe błędy

• Black Hole DNAT znajduje się poniżej normalnej reguły DNAT: Najpierw pasuje normalna reguła DNAT, reguła blokująca nie działa
• Cel-dummy istnieje jednak w sieci: Ruch trafia nieoczekiwanie na rzeczywisty system
• Źródło jest różnie utrzymywane w regule NAT i regule zapory: Reguły stają się trudne do zrozumienia i rozchodzą się
• Country Blocking jest używane jako jedyny środek ochrony: Boty z dozwolonych krajów mogą nadal atakować
• WAF i DNAT są mieszane: Reguła firewall Drop nie chroni automatycznie każdej publikacji WAF. WAF Blocked countries trzeba sprawdzać osobno.
• Lokalne usługi firewalla są chronione zwykłymi regułami firewall: Dla WebAdmin, User Portal, VPN Portal i SSH najpierw sprawdzić Device Access oraz Local Service ACL.
• IPv6 zostaje pominięte: Reguła IPv4 nie blokuje ścieżki IPv6.
• Tymczasowe blokady IP nigdy nie są sprawdzane: Stare wpisy później blokują legalne dostępy lub powodują niepotrzebną złożoność
• Zakresy chmurowe lub CDN są zbyt szeroko blokowane: Aplikacje biznesowe, aktualizacje lub zewnętrzni dostawcy usług mogą przestać działać
• Logowanie jest wyłączone: W Log Viewer nie jest jasne, która reguła zadziałała

Rozwiązywanie problemów

Jeśli reguła blokująca nie działa, należy sprawdzić w tej kolejności:

1. Czy reguła NAT lub zapory naprawdę znajduje się powyżej reguł zezwalających?
2. Czy adres IP źródła pasuje do listy złych IP lub wybranego kraju?
3. Czy ruch jest przetwarzany przez regułę WAF, regułę DNAT lub regułę zapory?
4. Czy logowanie na dotkniętej regule zapory jest aktywne?
5. Czy Log Viewer pokazuje oczekiwane ID reguły zapory lub ID reguły NAT?
6. Czy widać ruch w Diagnostics > Packet capture?
7. Czy istnieje nowszy wyjątek, grupa hostów lub wykluczenie Threat Feed, które wpływa na oczekiwany blok?
8. Czy tymczasowa blokada po incydencie została pozostawiona na stałe?

Do analizy pomagają również sprawdzanie kolejności, dopasowania i logów, gdy reguła firewalla nie działa, użycie narzędzia Packet Capture w WebAdmin i zrozumienie NAT na Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Jeśli zablokowany ruch faktycznie należy do opublikowanego serwera, należy dodatkowo sprawdzić produkcyjną regułę DNAT: Czy reguła Black-Hole-DNAT rzeczywiście znajduje się powyżej, czy trafia ten sam publiczny adres docelowy i czy usługa jest identyczna lub celowo szersza? Dla pełnej publikacji pasuje publikowanie serwera przez DNAT na Sophos Firewall.

FAQ