Polska
GRANDMETRIC Sp. z o.o.
ul. Metalowa 5, 60-118 Poznań, Poland
NIP 7792433527
+48 61 271 04 43
info@grandmetric.com
UK
Grandmetric LTD
Office 584b
182-184 High Street North
London
E6 2JA
+44 20 3321 5276
info@grandmetric.com
US Region
Grandmetric LLC
Lewes DE 19958
16192 Coastal Hwy USA
EIN: 98-1615498
+1 302 691 94 10
info@grandmetric.com
BlogCyberbezpieczeństwo
Konfiguracja FortiGate. Jak uniknąć popularnych błędów? Praktyczne spojrzenie inżyniera Poniżej zebrałem najczęstsze problemy, które widzimy podczas audytów FortiGate u klientów oraz w codziennej pracy.
W praktyce błędy konfiguracji tego popularego firewalla rzadko wynikają z braku wiedzy o protokołach sieciowych, a częściej z niezrozumienia filozofii FortiOS oraz różnic między konfiguracją lokalną a centralnie zarządzaną przez FortiManager (FMG).
Mam nadzieję, że poniższe zestawienie zachęci Cię do przeglądu własnych urządzeń.
Startujemy.
GRUPA 1 – Błędy ogólne w konfiguracji FortiGate
GRUPA 3: Błędy w konfiguracji firewalla lokalnie, bez FortiManagera
GRUPA 4: Błędy przy konfiguracji FortiGate z FortiManager (FMG)
FortiGate przetwarza polityki top to bottom, czyli od góry do dołu. Jeśli znajdzie pierwszą pasującą politykę, wykonuje ją i kończy proces decyzyjny.
Jeśli znaczące dla filtracji ruchu reguły umieścimy na końcu listy przetwarzania polityk, FortiGate może nigdy do nich nie dotrzeć. Wykona wcześniejszą “szerszą” regułę i zgodnie z nią poprowadzi ruch. Często też domyślny widok polityk “Interface Pair View” nie pokazuje faktycznej kolejności reguł, co może wprowadzać dezorientację.
Jak działać zgodnie z kolejnością przetwarzania polityk na FortiGate?
Reguły src:any dst:any service:any często zaczynają życie jako „testowe na chwilę”, a kończą jako główny kanał ruchu w produkcji. W efekcie firewall pełni rolę lepszego routera, kosztem swoich zaawansowanych funkcji filtrowania ruchu. Dodatkowo szerokie ustawianie reguł utrudnia audyty i troubleshooting w razie problemów.
Jak zapanować nad regułami any-any?
Jeśli nie dzielisz interfejsów na strefy, ryzykujesz mnożenie polityk i mieszanie ze sobą ruchu o różnych wymaganiach bezpieczeństwa. Przy każdej rozbudowie infrastruktury trzeba „przeklikać” kolejne kombinacje interfejsów i łatwo o pomyłkę.
Dobre praktyki przy dzieleniu interfejsów na strefy:
Nawet dobrze znający FortiGate inżynier, bez procesu i narzędzi, zacznie „gasić pożary” zamiast budować stabilne środowisko. Zmiany bez change managementu, brak labu, ignorowane logi i policy hit count powodują, że problemy wychodzą na jaw dopiero przy dużych awariach albo audycie.
Dobre praktyki change management:
P.S. Jeśli nie masz FortiGate, możesz zajrzeć do artykułu o poprawnej konfiguracji firewalli.
Fortinet jest jednym z najczęściej wybieranych dostawców firewalli na świecie i z tego powodu jest też regularnie atakowany.
Jeśli firmware nie jest aktualizowany, nikt nie śledzi security advisory Fortinet i nie ma procedury reagowania na krytyczne CVE, to administrator reaguje dopiero po incydencie, a nie na etapie prewencji.
Jak aktualizować FortiGate?
Brak aktywnego wsparcia producenta oznacza brak dostępu do poprawek krytycznych błędów, aktualizacji bezpieczeństwa i szybkiej pomocy w razie incydentu. Sieć staje się podatna na znane luki i trudniej jest reagować na nowe zagrożenia.
Brak walidacji konfiguracji dostępu do serwerów FortiGuard może spowodować, że FortiGate nie pobiera aktualizacji sygnatur ani polityk bezpieczeństwa. W efekcie urządzenie działa na przestarzałych danych, co zwiększa ryzyko przeoczenia nowych zagrożeń i ataków.
Dobre praktyki FortiGuard:
Używanie słabego szyfrowania pozwala atakującym łatwo odszyfrować lub podsłuchać transmisje, nawet jeśli pozostałe mechanizmy bezpieczeństwa działają poprawnie. W efekcie dane wrażliwe i poufne stają się podatne na kradzież lub manipulację. Tu warto przypomnieć, że wytyczne takie jak NIS2 czy RODO oczekują aktualnych, silnych zestawów szyfrów.
Domyślne polityki DoS, szczególnie w firewallach cloudowych, gdzie bywają włączone „z pudełka” (w przeciwieństwie do on-prem), mogą powodować trudne do zdiagnozowania problemy z komunikacją. Z kolei pozostawienie domyślnych polityk SD-WAN oznacza, że ruch nie jest optymalnie kierowany ani kontrolowany według potrzeb biznesowych i priorytetów aplikacji. W efekcie może dochodzić do nieefektywnego wykorzystania łączy, opóźnień i problemów z dostępnością krytycznych usług.
Jeśli wprowadzasz zmiany konfiguracyjne przez GUI, z kilku kont administracyjnych, bez historii i bez backupu, możesz mieć problem szybciej niż myślisz. Często w takim przypadku po aktualizacji firmware „coś przestaje działać”, ale nikt nie ma pewności, jak wyglądała poprzednia wersja konfiguracji ani co się dokładnie zmieniło.
Co radzę odnośnie backupu FortiGate?
Konfigurowanie firewalla metodą copy-paste kończy się sporym bałaganem. Przenosząc fragmenty konfiguracji “na oko”, łatwo się pomylić, a trudno utrzymać spójność konfiguracji.
Co zalecamy już przy kilku urządzeniach FortiGate?
Brak standardyzacji obiektów najczęściej odbija się czkawką w dwóch przypadkach:
Dobre praktyki adresowania obiektów:
Niewłaściwy podział uprawnień RBAC pozwala użytkownikom na dostęp do funkcji lub konfiguracji, do których nie powinni mieć uprawnień. W takim przypadku rośnie ryzyko błędnych zmian, przypadkowego wyłączenia zabezpieczeń lub nieautoryzowanego dostępu do krytycznych zasobów.
Ignorowanie Security Rating powoduje, że znane luki konfiguracyjne i słabe ustawienia pozostają niewykryte mimo że FortiGate sam je wskazuje. W efekcie urządzenie działa poniżej swojego realnego poziomu bezpieczeństwa, a ryzyka są znane dopiero po incydencie lub audycie.
Security Rating sam pokazuje:
Praktyczna wskazówka odnośnie Security Rating:
Bez Automation Stitches FortiGate reaguje wyłącznie pasywnie, a wiele incydentów wymaga ręcznej interwencji administratora. Ich użycie pozwala automatycznie wykrywać zdarzenia i egzekwować reakcje, skracając czas reakcji i ograniczając skutki incydentów. Pozwala też na powiadomienia mailowe w razie wystąpienia krytycznych zdarzeń na firewallu.
Dzięki External Block List FortiGate wykorzystuje zewnętrzną wiedzę o aktualnych zagrożeniach i reaguje dopiero po lokalnym wykryciu ataku. Threat Feeds pozwalają proaktywnie blokować znane złośliwe adresy IP i domeny, znacząco zmniejszając powierzchnię ataku.
Niepoprawnie skonfigurowany VPN zdalnego dostępu często omija kluczowe mechanizmy kontroli (MFA, split-tunnel, polityki dostępu) lub daje użytkownikom zbyt szerokie uprawnienia. W efekcie VPN staje się jednym z najłatwiejszych wektorów wejścia do sieci wewnętrznej. Sterowanie ruchem do VPN np. za pomocą tras statycznych może spowodować problemy z komunikacją użytkownika do serwisów internetowych.
Dodatkowo brak 2FA i polityk geolokalizacji dla VPN pozostawia dostęp zdalny podatny na przejęcie kont i ataki brute-force. W efekcie nieautoryzowani użytkownicy mogą wejść do sieci nawet przy poprawnie skonfigurowanym VPN.
Wystawienie interfejsu zarządzania FortiGate bezpośrednio do internetu naraża urządzenie na ataki brute-force i próby przejęcia kontroli. W efekcie nawet poprawnie skonfigurowane polityki bezpieczeństwa mogą zostać obejście przez dostęp do panelu administracyjnego.
Chroń panel administracyjny:
Trzymanie logów tylko na FortiGate oznacza, że po incydencie masz tyle historii, ile się zmieściło w pamięci urządzenia.
Dobre praktyki przy zbieraniu logów:
Brak zrozumienia rozdziału odpowiedzialności między FortiManagerem a lokalnym FortiGate prowadzi do wprowadzania zmian równolegle w dwóch miejscach i sytuacji, w której nikt nie ma pewności, która wersja polityk jest tak naprawdę obowiązująca.
Klasyczne błędy:
Dobra praktyka:
Gdy używasz jednego ADOM-u do wszystkiego (produkcji, testu i labu) oraz mieszasz obiekty globalne z lokalnymi, przestajesz mieć wyraźną granicę między środowiskami. W takiej konfiguracji bardzo łatwo przypadkowo wypchnąć testowe polityki na produkcję, doprowadzić do konfliktów podczas instalacji zmian i skończyć z sytuacją, w której debugowanie problemu sieciowego staje się żmudnym szukaniem igły w stogu siana.
Instalowanie 100+ zmian na raz, na wszystkie urządzenia to przepis na trudną identyfikację błędu i brak szybkiego rollbacku.
Mniejsza zmiana = większa kontrola
FortiGate sam z siebie jest tylko narzędziem. Dobrze skonfigurowany potrafi skutecznie obronić przed próbami ataków, ale źle skonfigurowany nie wykorzysta swoich możliwości. Przytoczone wyżej 22 błędy to esencja problemów, które widzimy w realnych wdrożeniach: od prostych pułapek typu any-any po organizacyjny brak procesu i testów.
Możesz potraktować ten artykuł jako punkt wyjścia do samodzielnego przeglądu własnych urządzeń lub pretekst do profesjonalnego audytu bezpieczeństwa.
Najczęstsze błędy, które widzimy na audytach, to:
– brak zrozumienia kolejności przetwarzania polityk i „łapanie” ruchu przez zbyt ogólne reguły zanim trafią w właściwe polityki z UTM
– permanentne reguły typu any-any, które zaczęły życie jako „tymczasowe”
– brak spójnej koncepcji stref (zones) i przypadkowe przypisywanie interfejsów
– konfiguracja „klikana” bez backupów, dokumentacji i wersjonowania, często na kilku firewallach niezależnie
– chaos w obiektach adresowych/usługach (różne nazwy dla tych samych sieci) i osierocone obiekty, których nikt nie sprząta
– ignorowanie Security Rating, Threat Feeds i automatyzacji (Automation Stitches)
– brak aktualizacji FortiOS oraz sygnatur, brak łączności z FortiGuard i brak powiadomień o podatnościach
– źle zaprojektowany VPN zdalnego dostępu (bez 2FA, zbyt szerokie uprawnienia, problemy z trasowaniem)
– brak hardeningu, zły RBAC, wystawiony interfejs zarządzający do Internetu, brak logów na zewnętrznym kolektorze
– lokalne zmiany na FortiGate’ach zarządzanych przez FortiManagera, błędne ADOM-y i „blast radius” gigantycznych installi
Błędna konfiguracja polityk powoduje, że firewall:
– przepuszcza ruch, którego nikt nie planował – np. przez szerokie any-any, które „przykrywają” bardziej szczegółowe reguły,
– nie stosuje UTM/SSL inspection, bo ruch wpada wcześniej w prostą regułę bez profili bezpieczeństwa,
– nie blokuje adresów o złej reputacji, gdy reguły deny są za nisko na liście i nigdy nie są trafiane,
– nie daje się audytować – brak komentarzy i dat ważności utrudnia zrozumienie, dlaczego dana polityka istnieje i czy nadal jest potrzebna.
Efekt jest prosty: z zewnątrz „mamy FortiGate’a”, a realnie kontrola dostępu jest dziurawa i nieprzewidywalna.
Typowe problemy, które widzimy w regułach NAT to:
– włączony NAT tam, gdzie nie powinno go być (np. na politykach LAN→LAN / VPN→LAN), co ogranicza widoczność ruchu i powoduje asymetrię,
– błędna lub niekompletna konfiguracja VIP-ów (Virtual IP) – VIP zrobiony, ale polityka firewall nie pasuje do kierunku/portu, więc usługa jest „niby wystawiona, ale nie działa”,
– brak spójności między statycznymi trasami, SD-WAN a politykami – „domyślne” polityki SD-WAN zostawione bez analizy, przez co ruch nie idzie optymalną lub oczekiwaną ścieżką,
– nieprzemyślane sterowanie ruchem do VPN statycznymi trasami, co potrafi odciąć użytkownikowi dostęp do części Internetu przez złe preferencje tras.
Z perspektywy użytkownika objawia się to „magicznie znikającym” ruchem, losowym działaniem usług z Internetu i problemami z dostępem przez VPN.
1. Uruchom i przeanalizuj Security Rating – to wbudowana checklista pokazująca słabe punkty konfiguracji (stare szyfry, zbyt szerokie reguły, brak logowania, brak aktualizacji).
2. Sprawdź status FortiGuard – czy sygnatury IPS/AV/URL są aktualne i czy nie ma problemów z łącznością.
3. Przejrzyj polityki pod kątem: any-any, kolejności, komentarzy, dat ważności, osieroconych reguł
zobacz, czy ruch i zdarzenia są logowane do zewnętrznego kolektora (FortiAnalyzer/SIEM/syslog).
4. Oceń VPN: MFA/2FA, zasięg adresacji, geopolityki, sposób routingu.
5. Przejdź po urządzeniu checklistą lub zrób pełny audyt konfiguracyjny zewnętrznym okiem.
Najczęściej to:
– profile IPS/AV/Web/DNS podpięte do polityk, na których nie ma odpowiedniego ruchu – np. DNS Filter na polityce, gdzie DNS fizycznie nie przechodzi,
– ten sam, ogólny profil stosowany „wszędzie”, bez rozróżnienia na użytkowników, serwery, DMZ, backupy,
– wyłączone logowanie na politykach z UTM – coś niby filtruje, ale nie ma żadnej widoczności
brak aktualnych sygnatur (problemy z FortiGuard, przeterminowane licencje),
– brak Threat Feeds / External Block Lists – firewall nie korzysta z dodatkowych feedów IOC
Jeśli interfejsy są przypisane do stref przypadkowo albo stref w ogóle nie ma, to:
– ten sam typ ruchu (np. użytkownicy z różnych lokalizacji) jest mieszany z ruchem o innych wymaganiach (serwery, DMZ), co utrudnia egzekwowanie polityk bezpieczeństwa,
– przy rozbudowie sieci dokładane są kolejne, doraźne polityki między pojedynczymi interfejsami, co sprzyja tworzeniu „bocznych przejść”,
– łatwiej o przypadkowe dopuszczenie ruchu między segmentami, które miały być od siebie odseparowane,
– do tego dochodzi wystawianie interfejsu zarządzającego/MGMT na Internet, co tworzy bezpośrednie wejście do panelu admina, z pominięciem całej segmentacji.
Strefy (zones) są po to, żeby grupować interfejsy według funkcji – jeśli tego nie robimy, sami prosimy się o „nieszczelności” w segmentacji.
Tu zwykle nakłada się kilka rzeczy naraz:
– reguły any-any, które rozwalają całą ideę „kto do czego ma dostęp”,
– brak lub złe użycie stref – polityki budowane między pojedynczymi portami zamiast między segmentami logicznymi,
– chaos w obiektach adresowych (różne nazwy dla tych samych podsieci) i osierocone obiekty, których nikt nie sprząta,
– brak komentarzy i dat ważności polityk – nikt już nie pamięta, dla kogo była robiona dana reguła i czy nadal jest potrzebna,
– zły podział uprawnień RBAC – zbyt wielu adminów z pełnymi prawami może „na szybko” dorzucać wyjątki, które zostają na stałe.
W takim środowisku segmentacja istnieje tylko na diagramach, a realnie dostęp jest pełen wyjątków i „tymczasowych” obejść.
Źle skonfigurowany VPN zdalnego dostępu najczęściej:
– omija kluczowe mechanizmy kontroli, takie jak MFA/2FA i geopolityki, co ułatwia przejęcie kont i ataki brute-force,
– daje użytkownikowi pełen dostęp do sieci LAN zamiast tylko do konkretnych aplikacji/segmentów, przez co pojedyncze konto = szerokie wejście do sieci,
– korzysta z tras statycznych lub źle ustawionego split-tunnelingu, co powoduje problemy z dostępem do Internetu i usług SaaS,
– bywa pominięty przez logowanie/monitoring – w logach nie widać, co realnie robi użytkownik po zestawieniu tunelu.
Efekt: z perspektywy bezpieczeństwa VPN staje się najsłabszym ogniwem, a z perspektywy usera – źródłem „magicznych” problemów z dostępem.
Brak aktualizacji i brak monitorowania informacji o nowych wersjach/podatnościach prowadzi do tego, że:
– FortiGate działa z publicznie znanymi lukami, często już aktywnie wykorzystywanymi w atakach,
– silniki IPS/AV/Web Filter opierają się na przestarzałych sygnaturach, więc nie widzą nowych rodzin malware i technik ataku,
– organizacja nie spełnia podstawowych wymogów bezpieczeństwa i wymogów regulacyjnych (NIS2, ISO, wymogi branżowe), bo brakuje im procesu patch management,
– administrator reaguje dopiero po incydencie, a nie proaktywnie po publikacji advisory.
Dobry audyt konfiguracji FortiGate robi cztery rzeczy:
1. Inwentaryzuje stan faktyczny – polityki, obiekty, VPN, UTM, logowanie, FortiGuard, FMG, procesy.
2. Mapuje to na ryzyka – pokazuje, które błędy są tylko „bałaganem administracyjnym”, a które realnie otwierają sieć (any-any, brak 2FA, wystawiony mgmt, brak logów, brak aktualizacji).
3. Daje priorytetowy plan naprawczy – quick wins (np. logi, 2FA, komentarze, wyłączenie śmieci), potem zmiany architektoniczne (strefy, segmentacja, FMG), na końcu rzeczy „nice to have”.
4. Dodatkowo wymusza rozmowę o procesach: testy, change management, monitoring logów, co zwykle jest równie ważne jak sama konfiguracja urządzenia.
Niepoprawna konfiguracja polityk powoduje, że firewall:
– przepuszcza ruch, którego nikt nie planował np. przez stosowanie szerokich reguł any-any, które „przykrywają” bardziej szczegółowe reguły,
– nie stosuje UTM/SSL Inspection, bo ruch wpada wcześniej w prostą regułę bez profili bezpieczeństwa,
– nie blokuje adresów o złej reputacji, gdy reguły deny są za nisko na liście i nigdy nie są trafiane,
– nie daje się audytować. Brak komentarzy i dat ważności utrudnia zrozumienie, dlaczego dana polityka istnieje i czy nadal jest potrzebna.
