Miért nem elegendőek a proxy-alapú tűzfalak

 

 


 

Már egy jó ideje a proxy-alapú tűzfalakra vagy webproxy-kra alapvető biztonsági elemként tekintenek, de a kérdés továbbra is fennáll: a proxy-k valóban segítenek a felhasználók biztonságában?

 

Az első proxy alapú tűzfalakkal el lehetett érni azokat az alapvető feladatokat, hogy mely felhasználók milyen oldalakat érhettek el az interneten. De azóta a technológia fejlődött és eljutott arra a szintre, hogy olyan további funkciókat is nyújtson, mint a malware detektálás és blokkolás, adatvédelem (DLP), SSL/TLS forgalom vizsgálat és sávszélesség szabályozás.

 

Azonban a webproxy-knak jelentős hátrányaik vannak, melyek miatt nem lehet rájuk egy igazán hatékony biztonsági eszközként tekinteni.

  • Implementáció

 

Ismervén a proxy-alapú tűzfalak implementálási lehetőségeit technikai oldalról, kinyilvánítható, hogy a teljes forgalom nem lesz védett/vizsgálható. A leggyakoribb módja a proxy beállítások terítésére a PAC (Proxy Auto Configuration) fájlok vagy közvetlenül a proxy szerver cím megadása a felhasználó operációs rendszerében vagy böngészőjében.

 

A PAC fájlok JavaScript függvényeket használ, hogy hova küldje a forgalmat, a meghatározott proxy szerverek fel vagy közvetlenül az internetre. Az explicit proxy beállítások az összes böngészőből kezdeményezett forgalmat a proxy szerveren keresztül továbbítják.

 

Az elsődleges problémák ezekkel a megoldásokkal:

  • Nem minden alkalmazás képes proxy-t használni. Ezáltal egyes alkalmazások figyelmen kívül hagyják a rendszer proxy szerver beállításait és mindig direktben küldik ki a forgalmukat.
  • A témában jártas felhasználók pedig könnyedén megkerülik a proxy szervereket VPN-t, szerver oldali böngésző alkalmazásokat használva (például a Puffin böngésző, a Google Translate), anonimizáló és forgalmat titkosítő böngésző alkalmazásokkal (például a Tor böngésző) és egyéb metódusokat használva.
  • Hatékonyság

 

A hagyományos proxy-alapú tűzfalak nem úgy lettek megtervezve, hogy napjaink legfejlettebb biztonsági fenyegetettségeivel megbirkózzanak, hanem csak egy korlátozott számú protokollt képesek vizsgálni, mint pl. a HTTP, HTTPS, FTP és DNS. Ez azt jelenti, hogy ha csak web proxyt használunk az ahhoz vezet, hogy jelentős vakfoltunk lesz a teljes forgalom vizibilitásában és nem leszünk képesek azonosítani olyan alkalmazásokat és fenyegetettségeket melyek nem standard portokon kommunikálnak vagy esetleg teljesen más protokollokat használnak. Továbbá mint korábban is említettem, sok alkalmazás képtelen proxy-t használni és ezt mind kivétel szabályokkal kell kezelni és direktben kiengedni.


Egy új megközelítés: Secure Access Service Edge (SASE)

 

A SASE feltörekvőben lévő megoldás a hagyományos webproxy-k problémáira hivatott megoldást nyújtani, mely által komplett Zero Trust megközelítésű hozzáférést tudunk biztosítani a Internethez, a SaaS alkalmazásokhoz és a házon belül hosztolt alkalmazásokhoz. Egy valós SASE megoldás hálózati és biztonsági funkciókat nyújt egy egységes szolgáltatásként a felhőből. Ez magába foglal olyan különböző technológiákat, mint a cloud access security broker (CASB), Zero Trust Nework Access (ZTNA), firewall as a service (FWaaS), fejlett fenyegetettségek elleni védelem és egyebek.

 

A SASE termékek csak a felhőből érhetőek el és nagyobb kontrollt és vizibilitást tesznek lehető a felhasználó forgalma felett a dinamikus skálázhatóság miatt. Ennek köszönhetően, mivel a SASE több technologiát is támogat – pl. IPSec és SSL VPN, mind a végpontokon mind az egyéb telephelyeken -, lehetővé teszi a biztonsági szabályok kikényszerítését a teljes forgalomra, időponttól és helytől függetlenül. A szabályok innentől kezdve inkább üzleti döntések lesznek, mint erőltetett kompromisszumokat a technikai korlátok miatt.

Top