Firewall Hardening – Deo 5: Fortinet FortiGate hardening

Prethodni deo serije pokrio je pfSense/OPNsense — otvorene, open-source platforme. Ovaj deo prelazi na Fortinet FortiGate, jednu od najrasprostranjenijih komercijalnih NGFW platformi, sa sopstvenom terminologijom (FortiOS, FortiGuard, Security Fabric) i specifičnim hardening koracima. Pre nego što pređemo na konkretne preporuke, vredi pogledati stvaran, nedavan primer koji ilustruje zašto svaka od njih ima realnu, ne teoretsku težinu.

FortiBleed — konkretna ilustracija zašto osnovna higijena nije opciona

Početkom 2026. godine otkrivena je masovna kampanja kompromitacije, nazvana FortiBleed, u kojoj su napadači prikupili i verifikovali administratorske kredencijale za FortiGate uređaje izložene internetu u 194 zemlje. Analiza kompromitovanih naloga pokazala je da je otprilike 63 procenta bilo ili podrazumevani Fortinet sistemski nalog, ili generički administratorski nalog koji nikad nije preimenovan — drugim rečima, većina uspešnih kompromitacija nije zahtevala nikakvu sofisticiranu tehniku, samo ciljanje najpredvidljivijih, nepromenjenih kredencijala.

Paralelno sa tim, otkrivena je i tehnički ozbiljnija ranjivost, CVE-2026-24858 (CVSS ocena 9.4), koja je iskorišćavala propust u FortiCloud SSO implementaciji — napadač koji je kontrolisao bilo koji FortiCloud nalog mogao je, kroz grešku u proveri identiteta između različitih klijenata (cross-tenant), da se autentifikuje na tuđe FortiGate uređaje kao da je legitiman administrator, sve dok je FortiCloud SSO bio uključen na tim uređajima. Ovo je poseban, poučan slučaj: mera koja je trebalo da olakša administraciju (centralizovana SSO prijava preko Fortinet-ovog sopstvenog cloud servisa) postala je sama po sebi vektor napada za organizacije koje su je koristile.

Šta treba uraditi

• Preimenovati ili onemogućiti podrazumevani administratorski nalog odmah po instalaciji, i nikad koristiti generičko, predvidivo ime naloga za rutinsku administraciju — direktna, dokazana pouka iz FortiBleed kampanje
• Ako se FortiCloud SSO ne koristi svesno, sa jasnim razlogom, ostaviti ga isključenim — mnoge organizacije ga uključe tokom registracije uređaja bez stvarne namere da ga koriste, ostavljajući nepotreban, dodatan put pristupa aktivnim
• Za organizacije koje SSO koriste, pratiti bezbednosna obaveštenja Fortinet-a (PSIRT blog) redovno, i po prijemu obaveštenja o kompromitaciji, sprovesti preporučenu proceduru bez odlaganja — prekinuti sve aktivne administratorske i VPN sesije, resetovati sve lozinke, i proveriti konfiguraciju na znakove neovlašćenih izmena (novi VPN korisnici, neočekivani resetovi lozinki, VPN konekcije sa neuobičajenih lokacija)

Nikad administracija na WAN interfejsu — pravilo bez izuzetka u praksi

Ovo je preporuka koja se ponavlja kroz gotovo svaki ozbiljan vodič za FortiGate hardening, i vredi objasniti zašto je tako čvrsto formulisana: značajan broj ozbiljnih, visoko rangiranih CVE ranjivosti kod FortiGate uređaja tokom proteklih godina bio je iskoristiv upravo zato što je neko konfigurisao administrativni pristup (HTTPS, SSH) direktno na WAN interfejsu — izlažući ranjivu upravljačku površinu direktno internetu, umesto da ostane iza dodatnog sloja mrežne izolacije.

Šta treba uraditi

• Onemogućiti administrativni pristup (HTTPS, SSH, i pogotovo stariji, nešifrovani HTTP i Telnet) na WAN interfejsu kao apsolutno podrazumevano stanje — kroz Network → Interfaces, podesiti administrative access odvojeno za svaki interfejs
• Za udaljenu administraciju, koristiti VPN tunel (isti princip opisan za pfSense/OPNsense u prethodnom delu serije) kako bi administratorov uređaj efektivno bio deo interne, upravljačke mreže, umesto direktnog izlaganja upravljačkog porta
• Ako postoji vrlo konkretan, dokumentovan razlog da administracija na WAN interfejsu mora ostati uključena, to je prihvatljivo isključivo ako su istovremeno ispunjena oba dodatna uslova: svaki administratorski nalog ima konfigurisane trusted hosts (detaljnije objašnjeno dalje u tekstu), i postoji eksplicitna Local-In politika koja dodatno ograničava koji izvori uopšte smeju da dopru do te upravljačke površine
• Za potrebe udaljenog upravljanja bez izlaganja same upravljačke površine, razmotriti FortiGate Cloud ili FortiManager kao alternativu — ovi servisi omogućavaju centralizovano upravljanje bez potrebe da svaki pojedinačni uređaj ima direktno izložen administrativni pristup

Trusted Hosts — dodatan, nezavisan sloj ograničenja po nalogu

Ovo je FortiOS mehanizam vredan detaljnog objašnjenja jer radi na drugačijem nivou od standardnog firewall pravila — trusted hosts se konfigurišu po pojedinačnom administratorskom nalogu (ne kao opšte pravilo za sve naloge), i ograničavaju sa kojih tačno IP adresa ili mrežnih opsega taj konkretan nalog uopšte sme da se prijavi. Pokušaj prijave sa bilo koje druge adrese, čak i uz ispravne kredencijale, biva odbačen na nivou same autentifikacije, pre nego što stigne do provere lozinke.

Šta treba uraditi

• Konfigurisati trusted hosts za svaki administratorski nalog, ograničavajući ga na poznatu, upravljačku mrežu ili konkretne IP adrese administratora, po istom principu koji smo detaljno objasnili za URA "Access this computer from the network" pravo u AD hardening seriji
• Postavljati specifičnije IP adrese pre opštijih u listi trusted hosts (do deset unosa po nalogu) — ako se koristi opšti opseg (0.0.0.0/0.0.0.0) uopšte, on treba da bude poslednji u redosledu, ne prvi, po istom principu redosleda opisanom u prvom delu serije
• Kreirati odvojen administratorski nalog za svaku osobu ili ulogu, sa sopstvenim, individualno konfigurisanim trusted hosts, umesto deljenja jednog naloga sa širokim trusted hosts opsegom koji pokriva sve moguće administratore odjednom

2FA i razdvajanje uloga — ista disciplina primenjena kroz FortiToken

Isti princip obavezne MFA za administrativan pristup opisan kroz svaku prethodnu seriju o kritičnoj infrastrukturi na ovom blogu primenjuje se ovde kroz FortiToken/FortiToken Mobile — Fortinet-ovu nativnu implementaciju vremenski-baziranih jednokratnih lozinki (TOTP), sa dva probna tokena uključena besplatno uz svaki registrovan FortiGate uređaj.

Šta treba uraditi

• Uključiti dvofaktorsku autentifikaciju za svaki administratorski nalog kroz System → Administrators, dodeljujući FortiToken svakom pojedinačno
• Kreirati odvojene naloge po osobi ili ulozi, ne deliti jedan administratorski nalog između više ljudi — ovo omogućava praćenje aktivnosti do konkretne osobe kroz logove, isti princip individualne odgovornosti opisan kroz svaku prethodnu seriju na ovom blogu
• Koristiti Administrative Access Profiles za ograničavanje šta svaki nalog sme da radi na osnovu stvarne uloge — isti princip least privilege primenjen ovde kroz FortiOS specifičan mehanizam umesto svima dodeljivati pun super_admin profil

Smanjenje površine napada — isključivanje nepotrebnih servisa i protokola

Isti princip minimizacije opisan kroz svaku prethodnu seriju na ovom blogu ima ovde konkretnu FortiOS implementaciju kroz Feature Visibility i podešavanja protokola administrativnog pristupa po interfejsu.

Šta treba uraditi

• Onemogućiti nekorišćene servise (HTTP administrativni pristup, FTP, SNMP ako se ne koristi za monitoring, Telnet) kroz System → Feature Visibility
• Dozvoliti isključivo HTTPS i SSH za administrativan pristup, nikad HTTP ili Telnet — nešifrovani protokoli prenose kredencijale i sadržaj sesije u čitljivom obliku, isti rizik opisan za nešifrovan SMB u Windows fajl server seriji
• Uključiti Redirect to HTTPS kroz System → Settings → Administrator Settings, kako bi svaki pokušaj HTTP prijave bio automatski preusmeren, umesto da HTTP ostane funkcionalan alternativan put
• Postaviti TLS 1.2 (ili noviji, gde FortiOS verzija to podržava) kao minimalnu verziju za enkriptovan administrativan pristup, po istom principu isključivanja starijih, ranjivih verzija protokola opisanom kroz seriju o hardeningu Windows i Linux servera
• Razmotriti promenu podrazumevanih portova za HTTPS i SSH administrativan pristup — ista, ograničena vrednost (smanjenje pozadinske buke skeniranja, ne stvarna zaštita protiv ciljanog napada) opisana za pfSense/OPNsense u prethodnom delu serije

Centralizovano logovanje — FortiAnalyzer ili spoljni syslog

Isti princip centralizovanog logovanja koji se provlači kroz svaku prethodnu seriju na ovom blogu — log koji ostaje isključivo na kompromitovanom uređaju nije pouzdan izvor u trenutku kad je najpotrebniji — primenjuje se identično ovde, sa Fortinet-ovom sopstvenom platformom (FortiAnalyzer) kao namenskim rešenjem, ili standardnim spoljnim syslog serverom kao alternativom.

Šta treba uraditi

• Uključiti logovanje sistemskih izmena, pokušaja prijave, i akcija firewall politike kroz Log & Report → Log Settings
• Konfigurisati prosleđivanje logova ka FortiAnalyzer-u ili spoljnom, bezbedno čuvanom syslog serveru, ne osloniti se isključivo na lokalno čuvanje logova na samom uređaju
• Integrisati FortiGate telemetriju sa SIEM sistemom gde postoji, po istom principu centralizovane vidljivosti opisanom kroz celu ovu seriju na ovom blogu

Fizička bezbednost i USB zaštita — često zaboravljen sloj

Vredi eksplicitno pomenuti dimenziju koja se lako zaboravi usred fokusa na mrežnu i logičku bezbednost: fizički pristup FortiGate uređaju omogućava zaobilaženje svih softverskih zaštita, uključujući mogućnost učitavanja izmenjenog firmvera nakon ručnog restarta uređaja.

Šta treba uraditi

• Smestiti FortiGate uređaj u fizički obezbeđenu lokaciju, po istom principu opisanom za domain kontrolere i Hyper-V hostove u ranijim serijama na ovom blogu
• Potvrditi da je USB instalacija firmvera i konfiguracije onemogućena — podrazumevano jeste isključena, ali vredi eksplicitno proveriti da nije nenamerno uključena tokom nekog ranijeg koraka administracije

Sledeći, poslednji deo serije prelazi na Palo Alto Networks — platformu poznatu po App-ID i posebnom pristupu segmentaciji kroz zone i politike, sa sopstvenim skupom hardening preporuka koje zatvaraju krug ove serije o firewall bezbednosti.