A hálózati határvédelem eszközei

Átírás

1 AZ INFORMATIKAI BIZTONSÁG SPECIÁLIS TÉMAKÖREI Hungarian Cyber Security Package A hálózati határvédelem eszközei Höltzl Péter

2 A hálózati határvédelem értelmezése Tűzfal technológiák ismertetése Védelmi funkciók megvalósíthatóságának ismertetése tűzfalaksegítségével Kérdések és válaszok Miről lesz szó?

3 Mi a biztonság? A biztonság kedvező állapot (nincsenek fenyegetések), mely állapotnak jövőbeli változása nem valószínű de nem is zárható ki. A biztonság értelmezhető több területen is, úgy mint jogbiztonság, üzembiztonság, vagyonbiztonság vagy informatikai biztonság. A biztonság nem folyamat és nem termék. A biztonság menedzsment minden olyan tevékenység ami ennek az állapotnak a fenntartását szolgálja. A biztonság tudatosan vállalt maradék kockázat!

4 Az IT biztonság elemei Az IT biztonsági elemei: Érték: Bármi, ami a szervezet számára jelentőséggel bír (adatok, tudás, védjegy, receptek, eljárások, know-how stb). Fenyegetés: Olyan negatív esemény, amelynek esetleges bekövetkezése veszteséget okozna. Sérülékenység: A fenyegetettség bekövetkezését lehetővé tevő hiba. Ellenintézkedések: Minden olyan eszköz, tevékenység, amely az fenyegetések minimalizálását szolgála. Kompromisszumok: Minden intézkedés, védelmi eszköz hordoz magával valamilyen hátrányt. Maradék kockázat: nincs tökéletes (100%-os) védelem!

5 Ellenintézkedések típusai Ellenintézkedések (Control): Preventív: megelőző pl. Tűzfal és IPS bevezetése; Detektív: érzékelő pl. nids, online monitoring; Korrektív: korrigáló pl. biztonsági audit és konfiguráció módosítás; Megvalósítási módszerek: Adminisztratív, pl. belső szabályzás; Fizikai, pl. zárak, beléptető rendszerek, kamerák; Technikai, pl. szoftveres és hardveres megvalósítások;

6 Az IT biztonság tervezésének lépései A tervezés során felmerülő kérdések: Milyen értéket védünk? Milyen kockázati tényezők vannak jelen? A megoldás mennyire hatékonyan csökkenti a kockázatot? Milyen új kockázatot jelent a megoldás? Milyen költségeket és kompromisszumokat jelent a megoldás bevezetése? Bruce Schneier Beyound Fear

7 Mit értünk hálózati határvédelem alatt? Azon fizikai és logikai eszközök összessége, melyek az IT Biztonsági Szabályzat ( IBSZ ) hálózati határvédelemre vonatkozó követelményeit megvalósítják. Az az eszköz, ami két fizikai hálózat között csak az (IBSZ-ben) engedélyezett szabályok szerinti adatáramlást (CC: FDP_IFC és IFF) kényszeríti ki. A tűzfal funkcionalitása: Preventív és detektív kontrollokat valósítanak meg Fizikai és logikai szeparáció technikai eszközökkel (protokoll elemzés)

8 Tűzfalak funkcionalitása Preventív kontroll: Hálózatok fizikai szeparációja (fizikai); Protokoll értelmezés, elemzés (technikai); IPS funkcionalitás (technikai); Szűrés: vírus, spam, tartalom, URL stb. (technikai és adminisztratív); Felhasználók hitelesítése és jogosultságaik kezelése (technikai); Detektív kontroll: nids és IPS funkcionalitás (technikai); naplózás (technikai és adminisztratív);

9 A hálózati határvédelem eszközei Szabályzatok, eljárásrendek (IBSZ) Házirend (policy) karbantartás és a hozzájuk tartozó folyamatok Autentikációs adatbázis karbantartása Hibajavítás (security patch, nem új verzió telepítés!) Monitorozás Naplógyűjtés és elemzés (on-line és periodikus)

10 Funkcionális követelmények A CC-ből megvalósítható funkcionális követelmények: Security audit (FAU) Communication (FCO) Cryptographic support (FCS) User data protection (FDP) Access Control Functions (FDP_ACC és ACF) Information Flow Control (FDP_IFC és IFF) Identification and authentication (FIA) Security management (FMT) Resource Utilisation (FRU) Trusted Path/Channel (FTP)

11 Eredeti állapot: nincs szűrés Routing megtartása: Packet Filter Stateful Packet Filter SOCKS Routing nélkül: Bastion host Proxy Transzparens proxy Moduláris, transzparens proxy Tűzfalak evolúciója

12 Csomagszűrő routerek Működési elv: A bejövő csomagokat tulajdonságaik alapján elfogad (továbbít, routingot végez), elvet vagy eldob illetve naplóz Döntés alapja: A csomagok forrása és célja (port és IP), bizonyos flag-ek. Ezért a szabályok csak a csomagokra vonatkoznak (Packet Filter). Megvalósítás: Mintaillesztés

13 A házirend tárolása A házirend (policy vagy szabályrendszer) tárolására szolgáló leggyakoribb eszköz, a hozzáférési lista (ACL - Acces Control List): A mintra (pattern) feladata a cél (döntés) kiválasztása; A szabály (policy verdict) feladata az illeszkedő (packet) sorsának eldöntése: Engedélyezés vagy tiltás; Ugrás másik szabályra; Naplózás és ugrás másik szabályra; Az ACL-ek feldolgozása általában az első illeszkedésig tart, ezért a számít sorrend (specifikus szabályok előre, átfogók a lista végére).

14 Csomagszűrő routerek értékelése Előnyök: gyors egyszerűen kezelhető szabályrendszer Hátrányok: az alkalmazás szintre nem lát többcsatornás protokollok kezelése nem megvalósítható sok szabály szükséges (válasz packetek kezelése) Ismeretlen elemek kezelése: Az ismeretlen elemeket szűrés nélkül engedik át.

15 Állapot tartó csomagszűrők Működési elv: A bejövő csomagokat tulajdonságaik alapján elfogad, továbbít vagy eldob. Döntés alapja: A teljes TCP és IP rétegek, (forrás, cél port és IP, seq és ack, csomagok sorrend illetve helye) tehát a kapcsolatok (Ezért állapot tartó Stateful Packet Filter - SPF). Megvalósítás mintaillesztéssel és elemzéssel. Megvalósítás: Mintaillesztés Többcsatornás protokollok kezelése: Valamilyen modul segítségével felismeri az alkalmazás szintből, hogy hová kell nyitni a további kapcsolatot, majd azt RELATED-nek jelöli.

16 Állapot tartó értékelése Előnyök: gyors kevesebb szabály (nem kell kezelni a válaszokat) Hátrányok: alkalmazás szintre nem lát többcsatornás protokollok kezelése nehezen megvalósítható Ismeretlen elemek kezelése: Az ismeretlen elemeket szűrés nélkül engedik át.

17 SOCKS tűzfalak Működési elv: Egy speciális, a kliensre telepített alkalmazás elveszi a kapcsolatot az operációs rendszertől és a tűzfalnak adja át. Kicseréli az API hívásokat (beépül az alkalmazás és a TCP réteg közé, fixen a SOCKS szerverhez kapcsolódik) bár létezik olyan alkalmazás ami natívan beszéli a protokollt. Csak kliens védelemre alkalmas (a SOCKS proxy szerver oldalán csak 1 kapcsolat lehet, tehát nem tud sok klienst kiszolgálni. Döntés alapja: A csomagok forrása és célja (port és IP) illetve megvalósítás függően az alkalmazási réteget is elemezheti.

18 SOCKS tűzfalak értékelése Előnyök: SOCKSv5-től felhasználói authentikáció megvalósítható (pl. Kerberos SSO) Hátrányok: A kliens alkalmazások általában nem támogatják a SOCKS protokollt. Az OS-re telepíteni kell a SOCKS klienst (API csere). Szerver nem védhető. Ismeretlen elemek kezelése: Megvalósítás függő, alapvetően nincs alkalmazás szintű védelem.

19 Bastion hostok Működési elv: A több hálózathoz csatlakozó (dual home vagy multi home) hoszton a bejelentkezett felhasználók szolgáltatásokat vehetnek igénybe (kombinálható csomagszűréssel). Döntés alapja: A felhasználók autenikációján alapszik.

20 Bastion hostok értékelése Előnyök: Felhasználói autentikáció általában van A kliens alkalmazás ellenőrizhető, kézben tartható Hátrányok: elavult nehezen karbantartható (pl. eltérő verziók felhasználónként) erőforrás igényes a felhasználó potenciális veszélyforrást jelent az alkalmazások sérülékenységei ellen nem nyújt védelmet Ismeretlen elemek kezelése: Nem értelmezhető

21 Alkalmazásszintű tűzfalak Működési elv: A kliens a tűzfalon futó alkalmazással (proxy) tart kapcsolatot, az alkalmazás pedig a szerverrel. Fontos hogy ezek a proxyk gyorsítótár (cache) funkcióval nem rendelkeznek. Döntés alapja: Az alkalmazási réteg protokollja. Megvalósítás: Összetett. Mintaillesztés a hálózati rétegekben valamint mintaillesztés és értelmezés az alkalmazási rétegben. Az értelmezés mélysége függ a megvalósítástól.

22 Proxy tűzfalak értékelése Előny: Alkalmazás szintű védelem Protokoll értelmezés, kifinomultabb szűrés Többcsatornás protokollok elemzése lehetővé válik Hátrány: Proxy használatára felkészített kliens szükséges illetve azt támogató protokoll Lassabb, bonyolultabb a konfigurálás Ismeretlen elemek kezelése: Megvalósítás függő, az ismeretlen elemek eldobása lehetséges

23 Transzparencia Transzparens működés: A kliens és a szerver azt hiszi, hogy közvetlenül egymással kommunikálnak. Nem transzparens működés: A kliens a tűzfallal kommunikál (eltérő protokoll használat lehetséges!). A transzparencia értelmezhető: Hálózati szinten (TCP/IP) Alkalmazási szinten Kliens vagy szerver oldalon Lehet szimmetrikus vagy asszimetrikus A hálózati és alkalmazásszintű transzparencia lazán kötődik

24 Hálózati szintű transzparencia Kliens oldali: A kliensek a valódi célszervert IP-jét címzik A kliensek a tűzfal IP-jét címzik Szerver oldali: A szerverek a valódi kliens IP-jéről vagy a tűzfal IP címéről látják a kapcsolatot

25 Alkalmazásszintű transzparencia Szerver típusú kérés (protokoll) használata, pl.: GET / HTTP/1.0 Host: Connection: Keep Alive Proxy típusú kérés (protokoll) használata, pl.: GET HTTP/1.0 Proxy Connection: Keep Alive Szimmetrikus vagy aszimmetrikus transzparencia: mindkét oldalon ugyanolyan, vagy különböző protokoll használat

26 Transzparens proxyk Működési elv: A kapcsolatot valamilyen módon eltérítik eredeti céljától a proxyhoz (Ehhez gyakran csomagszűrőt használnak). A kliens és a szerver számára a kommunikáció transzparens. Döntés alapja: A kliens és a protokoll minden eleme alkalmazás szinten és az azt hordozó többi réteg (TCP/IP) Megvalósítás: Összetett. Mintaillesztés a hálózati rétegekben valamint mintaillesztés és értelmezés az alkalmazási rétegben. Az értelmezés mélysége függ a megvalósítástól.

27 Moduláris proxyk Működési elv: A feladatokat modulokra osztják és a modulokat kapcsolják egymáshoz. Funkcionalitásban egyezik a transzparens proxykkal. Döntés alapja: A transzparens proxykkal egyező Megvalósítás: A transzparens proxykkal egyező

28 Moduláris proxyk értékelése Előnyök: Összetett és többcsatornás protokollok elemzése lehetővé válik Nagyobb rugalmasság, stabilitás (KISS elv), mélyebb elemzés, skálázhatóság Hátrány: Nagyobb CPU igény Ismeretlen elemek kezelése: Megvalósítás függő, az ismeretlen elemek eldobása lehetséges

29 Címfordítás Az a technológia, mely az eszközön (router vagy tűzfal) áthaladó csomagok forrás vagy cél címét megváltoztatja (NAT: Network Address Translation) Fajtái: Egy-egy NAT Sok-egy NAT Forrás és cél NAT (SNAT vagy DNAT) PAT (Port Address Translation)

30 Címfordítás csomagszűrőkkel Csomagszűrők az adott szabályrendszert (minta) illesztik csomagról-csomagra, majd végrehajtják az ott előírt feladatot, ami engedély esetében a routing: Alapvetően ugyanazt az IP csomagot továbbítják Címfordításkor a csomagszűrő az áthaladó csomag forrását (esetleg célját) módosítják A válaszok esetében pedig vissza fordítanak

31 Címfordítás proxy tűzfalakkal A proxyk a kliens oldali kapcsolatokat végződtetik, majd a protokoll értelmezés után független kapcsolatot építenek a szerver oldalon, ezért: A szerver oldali kapcsolatának forrása a tűzfal címe (tehát a proxyk natívan végzik a csomagszűrők NAT funkcionalitását) Címfordításkor a szerver oldali kapcsolat forrása nem a tűzfal címe (hanem pl. a kliens IP-je).

32 A Zorp bemutatása Moduláris, alkalmazásszintű tűzfal Nem transzparens és transzparens, melyet SPF segítségével valósít meg 100% RFC szerinti protokoll elemzés (mély protokoll elemzés) Összetett protokollok elemzése (SSL) Központi menedzsment és felügyeleti rendszer Saját PKI rendszer Felhasználó azonosítés protokollon kívül és belül Tartalomszűrés (vírus, spam) és audit

33 A Zorp világnézete A kapcsolatba kerülő forrásokat (kliensek) és célokat (szervereket) zónarendszerbe sorolja, melyek hierarchiába rendezhetőek (öröklődés). A politikát a zónák közötti adatáralmásban érvényesíti (minden kapcsolatot un. Service-ek formájában visz át). A klienseket forrás címük azonosít, de a protokollon kívüli autentikáció is támogatott. A házirend ACL helyett programozási nyelv (rugalmasság, flexibilitás).

34 Zorp protokoll értelmező modulok Minden modul csak egyetlen, jól körülhatárolt funkciót hajt végre! (KISS) A protokoll értelmező modulok (proxy). összekapcsolhatóak: pl. SSL és Proxy modulok Értelmezett protokollok: HTTP, FTP, POP3, IMAP4, SMTP, TELNET, WHOIS, FINGER, LP, RSH, SQLNET, RADIUS, NNTP, LDAP, TFTP, MSRPC, SIP, SSH, VNC, RDP(v4 v5 és v6) és az általános PlugProxy. Az ismeretlen protokoll elemeket eldobják (100% RFC compliance).

35 Proxy modulok összekapcsolása Az egyes modulokat programozási nyelv kapcsolja össze, ezért Beágyazott protokollok ellenőrzése: SSL és protokoll proxy összekapcsolása (SSL + HTTP = HTTPS) Proxyk és szűrő modulok összekapcsolása (pl. SSL + POP3 + tartalom szűrés)

36 Központi menedzsment rendszer A tűzfalak beállításait a központ ZMS rendszerben tárolja, ahonnan a konfigurációk lekerülnek a tűzfalakra. Minden tűzfal egységes zónaszemlélettel rendelkezik (ez biztosítja a rendszer megkerülhetetlenségét házirend szinten). A házirendet grafikus kezelőfelületről kell karbantartani. A tűzfalak lecsupaszított eszközök (need-to-know elv).

37 Grafikus adminisztrátori felület

38 Központi felügyeleti rendszer Az egyes tűzfalak állapotát a Zorp monitorozó rendszer figyeli, az összegyűjtött adatokat adatbázisban tárolja. A monitorozó rendszer képes , SNMP és SMS riasztásokat küldeni a rendszer üzemeltetőinek.

39 Saját PKI rendszer A tűzfalak, a menedzsment és az autentikációs rendszer közötti kommunikáció SSL védett csatornákon folyik, mely közös PKI rendszerben menedzselhető. Az SSL proxykhoz szükséges tanúsítványok és a megbízható CA-k tanúsítványai a közös PKI rendszerrel menedzselhető. Kapcsolódási lehetőség külső, már meglévő PKI rendszerekhez.

40 Szolgáltatásonkénti autentikáció Többféle autentikációs mechanizmus és protokoll támogatása. Szolgáltatásonkénti autentikáció a protokollon kívüli, független csatornán.

41 További határvédelmi funkcionalitások nids és IPS funkcionalitás Tartalomszűrés Autentikáció Naplózás VPN végződtetés (terminálás)

42 nids és IPS funkcionalitás tűzfalakon Működési elv: az eszközön áthaladó, engedélyezett forgalomban rossz szándékú aktivitás érzékelése és blokkolása Csomagszűrők esetében ez csak kiegészítő eszközzel (modullal) megvalósítható Proxyk esetében, amennyiben az ismeretlen protokollelemeket az tiltja, több IPS funkcionalitás megvalósítható

43 Vírusszűrés Vbuster Kraspersky Nod32 Clamav Spam szűrés: Spamassassin Commtouch Tartalom szűrés több modullal spamassassin html sed Tartalomszűrés

44 Autentikáció Célja a felhasználó identitásának pontos meghatározása, majd felhasználói jogok hozzárendelése. Az authentikációs rendszer: személyek megkülönböztető karakterisztikák (tudás, birtok, biometria) authentikációs mechanizmus (protokoll) hozzáférésvezérlési mechanizmus (DAC, MAC)

45 Autentikáció tűzfalakon Protokollon belüli (inband): egyes protokollok (pl. ftp és http) támogatják a kliens autentikácóját a proxyn, tűzfalon. Protokollon kívüli (outband): valamilyen külső eszközzel, független csatornán azonosítjuk a klienst (így a protokoll nem befolyásolja az autentikációs mechanizmust).

46 Naplózás Minden tűzfal megoldás az által értelmezett protokollelemekel kapcsolatos naplózási funkciókat képes megvalósítani. Csomagszűrők csak TCP/IP szinten naplóznak Proxyk esetében ez akár a teljes kapcsolat és minden protokoll elem naplózását is jelentheti (erőforrás igényes). Accounting információk naplózása lehetséges.

47 Virtuális Magánhálózatok Olyan technológiák összessége, mely egymástól távol eső eszközöket és hálózatokat kötnek össze úgy, hogy a köztük megvalósult kommunikáció bizalmassága, sértetlensége és hitelessége ne sérüljön. Megvalósítás: általában valamilyen autentikált, rejtjelezett csatornát használnak. Alkalmazás szinten: SSLv3 vagy TLSv1 (OpenVPN). Transzport szinten: IPSec, L2TP vagy PPTP.

48 VPN megvalósítás tűzfalon A kikényszerített házirend a VPN csatornákon is érvényes. Rejtjelezett kapcsolatokban is lehetséges protokoll ellenőrzés, vírus és tartalom szűrés (melynek feltételeit az IBSZ-ben rögzíteni kell). VPN-ek autentikációja a központi PKI rendszerhez.

49 A hálózati határvédelem értelmezése Tűzfal technológiák ismertetése Védelmi funkciók megvalósíthatóságának ismertetése tűzfalaksegítségével Kérdések és válaszok Miről volt szó?