Zapory sieciowe są często traktowane jako punkt do zaznaczenia: wdrożyć jedną, napisać kilka reguł, iść dalej. Ale stosowane projektowanie zapory sieciowej to dyscyplina sama w sobie—taka, która decyduje o tym, czy segmentacja sieci rzeczywiście zawiera atakującego, czy po prostu daje ci fałszywe poczucie bezpieczeństwa. Ten artykuł przechodzi przez praktyczne decyzje, które oddzielają dobrze zaprojektowane wdrożenie zapory sieciowej od zbioru niespójnych reguł.
Zacznij od Stref, nie od Reguł
Przed napisaniem jednej ACL zdefiniuj strefy zaufania. Typowy układ przedsiębiorstwa oddziela hosty DMZ skierowane do internetu, wewnętrzne sieci użytkowników, warstwy serwerów/danych i sieci zarządzania/OOB. Każda strefa powinna reprezentować odrębny poziom zaufania, a ruch między strefami powinien być wyjątkiem wymagającym uzasadnienia, a nie domyślnym zachowaniem.
Mapuj, co rzeczywiście musi się komunikować z czym. Ten inwentarz przepływu ruchu jest żmudny, ale stanowi podstawę wszystkiego innego. Pominięcie go prowadzi do zbyt permisywnych reguł "allow any-any między podsieciami", które całkowicie poddają w wątpliwość cel segmentacji.
Default-Deny Jest Nienegocjowalne
Każdy interfejs, każda para stref, powinna kończyć się niejawnym lub jawnym odmową. Reguły powinny być dodatkowymi wyjątkami dla zamkniętej postawy, a nie subtraktywnym wyjątkiem dla otwartej. To brzmi oczywisto, ale audyty rutynowo znajdują zapory sieciowe z permisywnymi regułami catch-all pozostawionymi po pośpiesznym wdrożeniu lub "tymczasowej" zmianie rozwiązywania problemów, które nigdy nie zostały usunięte.
Gdy default-deny coś psuje, to faktycznie cenny sygnał—oznacza to, że znalazłeś nieudokumentowaną zależność, którą należy jawnie modelować, a nie po cichu zezwalać.
Kolejność Reguł i Specyficzność
Większość silników zapory sieciowej ocenia reguły od góry do dołu i zatrzymuje się przy pierwszym dopasowaniu. To sprawia, że kolejność jest decyzją projektową, a nie myślą uzupełniającą. Reguły specyficzne (pojedynczy host, pojedynczy port) powinny na ogół poprzedzać reguły szerokie (zakresy podsieci, zakresy portów). Częstym trybem awarii jest umieszczenie szerokiej reguły zezwalającej wcześnie na liście, która po cichu przesłania bardziej restrykcyjne reguły poniżej—te reguły istnieją na papierze, ale nigdy się nie uruchamiają.
Periodycznie kontroluj cieńskie i zbędne reguły. Narzędzia, które wizualizują liczby trafień reguł, są tutaj bezcenne: reguła z zerem trafień w znaczącym oknie czasowym to albo martwy balast, albo, co gorsza, dowód na to, że ruch płynie ścieżką, której się nie spodziewałeś.
Inspekcja Stanowa i Jej Ograniczenia
Nowoczesne zapory sieciowe śledzą stan połączenia, co pozwala pisać reguły tylko dla kierunku inicjującego i ufać, że silnik pozwoli na ruch zwrotny. To jest poważne uproszczenie w stosunku do filtrowania pakietów bezstanowych, ale nie jest to substytut świadomości warstwy aplikacji. Stanowa zapora sieciowa zezwalająca na wychodzące TCP/443 nie wie i nie obchodzi ją, czy ruch ten to legalne HTTPS czy kanał C2 tunelowany przez ten sam port. Gdzie to możliwe, paruj egzekwowanie zapory sieciowej ze świadomością warstwy aplikacji—proxy, inspekcja TLS gdzie polityka na to pozwala, lub identyfikacja aplikacji NGFW—zamiast polegać na numerach portów jako proxy dla intencji.
Filtrowanie Ruchu Wychodzącego Zasługuje na Taką Samą Uwagę
Organizacje obsesyjnie skupiają się na regułach przychodzących i zaniedbują wychodzące. To jest wstecz z perspektywy reagowania na incydenty: gdy atakujący ma punkt zaczepienia, kontrole ruchu wychodzącego to to, co decyduje o tym, czy mogą egzfiltrować dane czy nawiązać połączenie z infrastrukturą. Zdefiniuj jawne polityki ruchu wychodzącego dla strefy—serwery rzadko potrzebują nieograniczonego wychodzącego dostępu do internetu, a stacje robocze rzadko muszą inicjować połączenia z arbitralnymi zewnętrznymi IP-ami na arbitralnych portach. Restrykcyjny ruch wychodzący nie powstrzyma wszystkiego, ale podnosi koszt aktywności po eksploatacji i zwiększa szansę, że anomalny ruch zostanie oflagowany.
Zarządzanie Zmianami i Drift
Zestawy reguł zapory sieciowej gromadzą śmiecie w ciągu czasu: reguły dodane do projektu, który skończył się wiele lat temu, tymczasowe wyjątki, które stały się stałe, i reguły, których nikt nie pamięta celu. Traktuj konfigurację zapory sieciowej jako kod—kontrolowany wersją, poddany przeglądowi peer-review i powiązany z udokumentowanym uzasadnieniem biznesowym dla każdej reguły. Zaplanuj okresowe przeglądy, aby przyciąć nieświeże wpisy. Zapora sieciowa z tysiącem nieudokumentowanych reguł zapewnia mniejsze realne bezpieczeństwo niż mniejszy, dobrze zrozumiały zestaw reguł, ponieważ nikt nie może rozumować o tym, co rzeczywiście pozwala.
Rejestrowanie i Korelacja
Zapora sieciowa, która po cichu blokuje ruch, jest tylko w połowie przydatna. Upewnij się, że odrzucony i dozwolony ruch zainteresowania jest rejestrowany i przesyłany do twojego SIEM lub potoku dziennika, z wystarczającą ilością kontekstu (strefa, ID reguły, źródło/cel, protokół), aby wspierać badania później. Podczas incydentu dzienniki zapory sieciowej są często najszybszym sposobem na ustalenie osi czasu ruchu bocznego lub prób egzfiltracji—ale tylko jeśli przechowywanie i wierność zostały skonfigurowane z wyprzedzeniem.
Myśli Podsumowujące
Stosowane projektowanie zapory sieciowej nie dotyczy wyboru odpowiedniego dostawcy lub najnowszego zestawu funkcji NGFW—chodzi o zdyscyplinowane modelowanie stref, egzekwowanie default-deny, staranną higienę reguł i traktowanie ruchu wychodzącego z taką samą powagą co ruch przychodzący. Zdobądź prawe fundamenty, a zaawansowane funkcje stają się mnożnikami siły zamiast substytutu architektury.
Aby dowiedzieć się więcej o segmentacji sieci, korelacji dzienników i fundamentach blue team, zapoznaj się z powiązanymi segmentami w bibliotece DEFENSE_GRID Korra Studio.
