InfoSec bez stresa

Prva dva dela serije pokrila su principe nezavisne od platforme — tehničku autentifikaciju i odbranu od BEC-a. Ovaj deo prelazi na konkretnu, najrasprostranjeniju poslovnu email platformu — Exchange Online (deo Microsoft 365) i, gde se razlikuje, on-premise Exchange Server. Većina organizacija danas koristi Exchange Online, pa je fokus ovog teksta pretežno tamo, sa napomenama gde on-premise okruženje zahteva drugačiji pristup. Legacy authentication — "zadnja vrata" pored MFA-a Ovo je koncept vredan detaljnog objašnjenja, jer predstavlja jedan od najčešćih, a najmanje očiglednih propusta u Microsoft 365 okruženjima. Legacy (starija, osnovna) autentifikacija — protokoli poput POP3, IMAP, starijeg SMTP AUTH-a, i Exchange ActiveSync-a sa osnovnom autentifikacijom — ne podržavaju moderne autentifikacione mehanizme, što konkretno znači da ne mogu da sprovedu MFA proveru čak i kad je MFA za taj nalog inače uključena. Napadač koji poseduje ukradenu lozinku (ali ne i drugi faktor)...

Prvi deo serije pokrio je tehničku autentifikaciju — SPF, DKIM, DMARC. Ovaj deo se bavi onim što ostaje čak i kad je sva tehnička autentifikacija besprekorno podešena: napadima koji ne pokušavaju da zaobiđu tehničku proveru, već je jednostavno zaobilaze na drugi način — ili tako što uopšte ne koriste vaš domen, ili tako što kompromituju legitiman nalog koji već prolazi svaku tehničku proveru jer to zaista jeste taj nalog. Business Email Compromise (BEC) je kategorija napada koja ovo najbolje ilustruje, i vredi na samom početku razumeti zašto je tehnička odbrana iz prvog dela serije, ma koliko dobro postavljena, samo deo odgovora. Zašto BEC zaobilazi tačno ono što smo upravo izgradili BEC napadi (poznati i kao CEO fraud ili izvršno predstavljanje) prema podacima FBI-jevog Internet Crime Complaint Center-a koštali su organizacije preko 16,6 milijardi dolara u jednoj nedavnoj godini, kroz više od 256.000 prijavljenih slučajeva, sa prosečnim gubitkom od oko 129.000 dolara po napadu. On...

Ovim tekstom počinje nova serija posvećena email bezbednosti — počev od tri protokola koji čine osnovu email autentifikacije (SPF, DKIM, DMARC), preko anti-phishing i BEC zaštite, do konkretnih platformi (Exchange, Google Workspace) u kasnijim delovima. Email ostaje, i u 2026. godini, najčešći ulazni vektor za ozbiljne bezbednosne incidente — ne zato što su druge tehnike napredovale manje, već zato što email inherentno zahteva da čovek na drugom kraju donese odluku (kliknuti ili ne, verovati pošiljaocu ili ne), što ga čini metom koja zaobilazi tehničku odbranu direktnim ciljanjem ljudskog rasuđivanja. Zašto ovo više nije opciono — regulatorni i tehnički pritisak istovremeno Vredi otvoriti seriju konstatacijom koja je bila diskutabilna pre par godina, a danas nije: email autentifikacija prestala je da bude preporuka i postala tehnički i, u sve više jurisdikcija i industrija, regulatorni zahtev. Najveći mailbox provajderi (Google, Yahoo, Microsoft) sprovode zahteve za autentifikacijo...

VPN je pominjan usput kroz gotovo svaku prethodnu seriju na ovom blogu — kao alternativa izlaganju RDP ili SSH porta, kao način udaljenog pristupa firewall administraciji, kao osnovna zaštita saobraćaja između lokacija. Ovaj tekst mu daje pažnju koju zaslužuje kao samostalna tema: koji protokol odabrati i zašto, kako podesiti autentifikaciju da VPN ne postane sam sebi slaba tačka, i gde se u 2026. godini VPN uklapa u širu priču o zero trust pristupu koja sve više preoblikuje kako se udaljeni pristup uopšte razmišlja. Zašto VPN i dalje zaslužuje pažnju u eri zero trust-a Vredi ovo pitanje postaviti direktno, jer je legitimno: sve više izveštaja i proizvođača govori o zameni VPN-a sa ZTNA (Zero Trust Network Access) pristupom, opisanim detaljnije kasnije u tekstu. Realnost za veliku većinu organizacija, posebno manjih i srednjih, jeste da je zero trust putovanje, ne prekidač koji se jednostavno uključi — migracija zahteva vreme, budžet, i promenu navika koje se ne dešavaju preko noći...

Prethodni deo serije pokrio je Fortinet FortiGate. Ovaj, poslednji deo serije prelazi na Palo Alto Networks — platformu koja je u velikoj meri i definisala kategoriju NGFW-a kroz App-ID i User-ID koncepte pomenute u trećem delu serije. Isti obrazac koji smo videli kod Fortinet-a ponavlja se i ovde: stvaran, dokumentovan incident koji ilustruje zašto osnovni hardening management pristupa nije opciona preporuka, već direktan odgovor na aktivno iskorišćavan rizik. CISA upozorenje — management interfejs izložen internetu kao ponovljen obrazac napada CISA je izdala hitno upozorenje nakon što je Palo Alto Networks potvrdio aktivno iskorišćavanje neautentifikovane ranjivosti za izvršavanje udaljenih komandi, usmerene specifično na management interfejse PAN-OS uređaja koji su bili izloženi internetu. Vredi primetiti da ovo nije izolovan slučaj specifičan samo za jednog proizvođača — isti obrazac (management interfejs izložen internetu kao primaran vektor kompromitacije) ponovio se kod Fort...

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

Prethodna tri dela serije pokrila su principe nezavisne od proizvođača — osnove, segmentaciju, napredne NGFW mogućnosti. Ovaj deo prelazi na prvu konkretnu platformu: pfSense i OPNsense, dva najrasprostranjenija besplatna, open-source firewall rešenja, oba izgrađena na FreeBSD osnovi (OPNsense konkretno na HardenedBSD ogranku). Principi opisani ranije u seriji ovde dobijaju tačna imena podešavanja i mesta u web interfejsu — a i pfSense i OPNsense dele dovoljno zajedničke arhitekture da veći deo ovog teksta važi podjednako za oba, uz eksplicitnu napomenu gde se razlikuju. Sveža instalacija nije podešena za produkciju — isti obrazac koji smo videli kroz celu ovu seriju blogova Fresh pfSense/OPNsense instalacija dolazi sa dobro poznatom, podrazumevanom lozinkom (pfsense za pfSense), i automatizovani botovi skeniraju internet za izložene instance sa tom podrazumevanom lozinkom u roku od minuta od izlaganja bilo kog IP-a. Kompromitovan firewall nije samo jedan kompromitovan uređaj — to ...