Mérési útmutató a Hálózati protokollok vizsgálata proxy technológiával (Zorp) című méréshez

Átírás

1 Mérési útmutató a Hálózati protokollok vizsgálata proxy technológiával (Zorp című méréshez Pfeiffer Szilárd április 7. A mérést kidolgozta: Pfeiffer Szilárd Balasys IT Kft. BME, CrySyS Adat- és Rendszerbiztonság Laboratórium

2 Tartalomjegyzék 1. Elméleti összefoglaló Forgalom szabályozása Forgalom tiltása Forgalom engedélyezése vizsgálat nélkül Forgalom engedélyezése vizsgálattal Hozzáférés-vezérlés Alkalmazandó szabály kiválasztása Haladó ismeretek Testre szabott proxy implementálása Python nylelvű proxy implementálása Proxyk egymásba ágyazása Gyakorlati összefoglaló Architektúra Gépek beállítása Gépek elérése Konfigurációs fájlok Feladatok Működés ellenőrzése Alapértelmezett tiltás beállítása Specifikus szabályok felvétele Saját proxy osztály létrehozása Titkosított forgalom átvitele proxy segítségével Titkosított forgalom átvitele titkosítás bontásával Jegyzőkönyv 11 Tárgymutató 12 2

3 1. Elméleti összefoglaló A következőkben rövid áttekintést nyújtunk a Zorp környezetben használt alapvető fogalmakról, a hozzáférés-vezérlési lista specifikumairól, a hozzáférés engedélyezésének és tiltásának különböző módjairól Forgalom szabályozása Zorp esetén a forgalom szabályozás követlező módjai közül választhatunk[1, Service] forgalom tiltása csomagok eldobása (DenyService csomagok visszautasítása (DenyService forgalom engedélyezése csomagszűrő jellegű működés (PFService applikációs szintű proxy (Service A forgalom tiltásának első változatában tűzfal a beérkezett csomagok mindennemű válasz nélkül dobja el, ezzel egyrészt csökkentve a saját terhelését, hiszen a kliensnek küldött visszautasító válasz is hálózati terhelés, másrészt késleltetésre kényszeríti a klienst, mivel az kénytelen kivárni az adott protokollban (pl: TCP előírt időt a válasz esetleges megérkezéséig. Így ha ezt a módozatot használjuk kliens oldalon nincs közvetlen bizonyíték arra, hogy az adott szolgáltatás nem működik, erre csupán a várt válasz meg nem érkezése, illetve az ez által okozott időtúllépés utal Forgalom tiltása Csomagok visszautasítása amennyiben erre a protokoll lehetőséget ad, annyit jelent, hogy a szerver küld választ a kliens felé az általa kezdeményezett forgalom visszautasításáról. Ennek konkrét módja a DenyService paramétereiként adható, illetve adandó meg, az alábbiak szerint. DenyService( name= TCPReset, ipv4_setting=denyipv4.tcp_reset, ipv6_setting=denyipv6.tcp_reset DenyService( name= ICMPPortUnreachable, ipv4_setting=denyipv4.icmp_port_unreachable, ipv6_setting=denyipv6.icmp_port_unreachable Az első esetben (TCPReset a klienstől érkező forgalomra válaszként egy TCP resetet küld a Zorp, míg a második esetben (ICMPPortUnreachable egy ICMP port unreachable lesz a válasz mind IPv4, mind IPv6 esetén. Értelem szerűen előbbi csak TCP forgalmak esetén értelmes, míg az utóbbi TCP és UDP esetén is használható, ugyanakkor tetszőleges IP alapú forgalomra nem értelmes, hiszen a válasz azt tartalmazza, hogy a célzott port (ami TCP/UDP specifikus nem elérhető. 3

4 Forgalom engedélyezése vizsgálat nélkül Az egyszerűbb, egyszersmind kevesebb beállítási lehetőséget és ezzel együtt kisebb rugalmassági szintet biztosító, valamint alacsonyabb biztonsági szintet nyújtó forgalomátengedési lehetőség a PFService, melynek működése gyakorlatban megegyezik az IPTables működésével. PFService( name= PacketFilter Ebben az esetben az érkező forgalom teljes egészében kernel-space kerül feldolgozásra, azzal csak a Zorp kernel modulja foglalkozik, a user-space daemon (Zorp számára forgalom voltaképpen nem is létezik. A routing, az esetleges cím- és porthamisítások, illetve a NAT teljes egészében a kernel modul által történik Forgalom engedélyezése vizsgálattal Amennyiben szeretnénk az adott forgalmat mélyebb elemzésnek (deep packet inspection alávetni, akkor egy harmadik engedélyezési módra lesz szükségünk (Service, amiben csak forgalom engedélyezésére, vagy tiltására vonatkozó döntés meghozását, illetve a forgalom elterelését a user-space felé végzi a kernel modul, minden egyéb (routing, NAT, cím-, porthamisítás, protokoll elemzés, módosítás,... a Zorp feladata. Service( name= DeepInspection, proxy_class=httpproxy A labor gyakorlat szempontjából leginkább említésre méltó különbség az előző (PFService és a mostani (Service átengedési mód között, a protokoll elemzésének lehetősége, illetve az ebben rejlő lehetőségek, valamint az ezzel járó konfigurációs változtatások. A fenti példában a Service konfigurációja egy új paraméterrel bővül (proxy_class, ami a protokoll elemzését végző modul (proxy típusát adja meg. Ezen típus tulajdonképpen egy Python nyelvű osztály neve, lévén a Zorp C/C++(11 nyelven írt protokollelemzői Python nyelven egészíthetőek ki. Természetesen a Zorp tartalmaz számos teljes értékű és megfelelő alapértelmezett paraméterekkel rendelkező proxyt. Amennyiben ezt a probléma bonyolultság megköveteli, nem csupán a paraméterek módosíthatók, hanem számos ponton az alapértelmezett működés is felülbírálható, kiegészíthető, sőt lehetőség van teljes egészében Python nyelven implementált proxyk létrehozására is, amire a labor keretein belül szintén látunk példát Hozzáférés-vezérlés Alkalmazandó szabály kiválasztása Ellentétben számos más tűzfal megoldással a hozzáférés-vezérlési szabályok kiértékelése nem az első illeszkedő szabály megtalálásáig történik (first match, hanem minden egyes esetben minden egyes szabály kiértékelődik és ezek közül a leginkább illeszkedő (best match fog érvényre jutni[1, Best match]. A kiválasztás során számos feltétel megadható (pl: forrás/cél IP cím, port,..., illetve azonos típusú feltételekből akár több is. Az azonos típusú feltételek egymással vagy, míg a különböző típusú feltételek egymással és kapcsolatban állnak. Az alábbi példában lévő szabályra tehát csak azok a forgalmak illeszkednek, amik az címet célozzák, ezen belül is az 53-as portot. Gyakorlatban az alábbihoz hasonló szabály segítségével lehet a Google publikus DNS szerveréhez a forgalmat kiengedni, oly módon, hogy ez egy csomagszűrő esetén történne. 4

5 PFService(name= PacketFilter Rule( dst_subnet= /32, dst_port=53, service= PacketFilter A szabály alapvetően két részből áll. Egyrészt a forgalom illeszkedési feltételek (match megadásából, másrészt a forgalom kiváltandó művelet megadásából (service. A művelet csak akkor fog végrehajtódni, amennyiben a feltételek teljesülnek, az összes illeszkedő szabály közül az az egy jut érvényre, amelyiknek az illeszkedése a legjobb. Lássuk a következő példa konfigurációt: PFService(name= PacketFilter Rule( id=1, dst_subnet= /32 service= PacketFilter Rule( id=2, dst_port=53, service= PacketFilter Az egyes számú szabályunk minden olyan esetben illeszkedik, ha csomag a IP címet célozza, míg a kettes számú akkor, ha a cél port 53. Kézenfekvő a kérdés, hogy mi történik abban az esetben, ha a forgalomra mindkét feltétel igaz. Ilyenkor feltételek közötti precedencia[1, Conditions] dönt. Amelyik feltétel precedenciája nagyobb, annak az illeszkedése lesz jobb. Ez esetben a kettes számú szabályé, amiből jól látszik, hogy a konfigurációban megadott szabályok sorrendjének nincs jelentősége. Ugyanakkor persze az is igaz, hogy a fenti példa meglehetősen mesterkélt, hiszen mindkét esetben ugyanaz a művelet hajtódik végre, így az eredmény is ugyanaz lesz. Ha az adott forgalom a szabályrendszer egyetlen elemében megadott feltételeknek sem felel meg, vagyis egyetlen szabályra sem illeszkedik, akkor a sorsáról az IPTables dönt, alapértelmezés szerint az adott csomag eldobásra kerül Haladó ismeretek Testre szabott proxy implementálása Zorp esetén az egyes proxyk pontosabban szólva proxy osztályok testre szabása minden esetben származtatást jelent az alapvetően C/C++(11 nyelven írt, de Python nyelven kiterjesztett ősosztályból, szintén Python nyelven. from Zorp.Http import HttpProxy class MyHttpProxy(HttpProxy: def config(self: HttpProxy.config(self self.timeout = def default(: Service(name= CustomizedHttpservice, proxy_class=myhttpproxy Rule(dst_port= 80, service= CustomizedHttpservice 5

6 A fenti példa nem tesz egyebet, mint a Zorp részeként szállított HttpProxy timeout értékét írja felül, így ez a testre szabott proxy egy percet fog várakozni, mielőtt a kapcsolatot időtúllépés miatt megszakítaná, az alapértelmezett 5 perces értékkel szemben. Ezt úgy éri el, hogy származtat a megfelelő ősosztályból (HttpProxy és felüldefiniálja annak config függvényét. Ebben a függvényben írhatóak felül az alapértelmezett értékek, illetve állíthatóak be olyan paraméterek, melyeknek nincs alapértelmezett értéke Python nylelvű proxy implementálása Zorp esetén lehetőség van arra is, hogy saját, vagy a szállított proxyk által egyáltalán nem támogatott protokollokhoz teljes egészében Python nyelven írjunk proxyt. Ehhez egy létező létező proxyból AnyPyProxy való származtatásra lesz szükség, ami voltaképpen csak egy váz, ahol az alapvető paraméterek a már megismert metódus szerint (config a függvény felüldefiniálásával történik, míg a hálózati forgalom tényleges kezelését, a protokoll elemzését, esetleges módosítását a proxythread függvény részeként kell implementálni. class FullyCustomizedProxy(AnyPyProxy: def config(self: self.client_max_line_length = def proxythread(self: self.readdata( self.analyzedata( if (necessary: self.modifydata( self.writedata( Fontos megjegyezni, hogy ezen proxy használatakor hálózati forgalom mindennemű kezelésének (olvasás/írás kliens/szerver oldalon, hibakezelés,... feladata ránk hárul, amennyiben a proxyt a teljes forgalom kezelésére használjuk, nem pedig egy már létező protokoll adat részének további elemzésére, ahogy azt a következő fejezetben látni fogjuk Proxyk egymásba ágyazása A Zorp lehetővé teszi proxyk egymásba ágyazását (stacking, melynek jelentősége abban áll, hogy minden proxy a saját maga által ismert részeket HttpProxy esetén ez a HTTP protokoll értelmezi, majd a számára csak adatként kezelendő részeket tovább tudja adni egy másik protokoll értelmező számára további elemzésre. Ez az egymásba ágyazás nem feltétlenül kell, hogy egylépcsős legyen, bonyolultabb esetekben lehetnek akár többszörös egymásba ágyazások is. class AnyPyProxyRequest(AnyPyProxy: def proxythread(self: pass class AnyPyProxyResponse(AnyPyProxy: def proxythread(self: pass class MyHttpProxy(HttpProxy: def config(self: HttpProxy.config(self self.request_stack["*"] = (HTTP_STK_DATA, (Z_STACK_PROXY, AnyPyProxyRequest self.response_stack["*"] = (HTTP_STK_DATA, (Z_STACK_PROXY, AnyPyProxyResponse 6

7 A fenti példában egy olyan testre szabott HTTP proxy implementáció látható, ami mind a HTTP kérések (request mind a HTTP válaszok (response adat részét továbbítja egy-egy az AnyPyProxy ősosztályból származó újabb proxy felé, ahol azok kezelése kell megtörténjen. 2. Gyakorlati összefoglaló 2.1. Architektúra A mérés alapvetően virtualizált környezetben (VMware történik, egy kliens-szerver architektúrában, ahol a kliens és a szerver között egy tűzfal (Zorp helyezkedik el, amivel a tulajdonképpeni mérési feladatok elvégzendőek. A kapcsolatok minden esetben a kliens gépről kezdeményeződnek, a tűzfal gépen keresztül jutnak el a szerverre. A szerverek az utolsó mérési feladattól eltekintve az erre a célra szolgáló virtuális gépen futnak Gépek beállítása Az importálást követően minden virtuális gép négy hálózati interfésszel rendelkezik a következők szerint: 1. internet kapcsolat célja: az internet elérésének biztosítása frissítések telepítésének céljából működése a VMware által biztosított virtuális DHCP szerver segítségével kap IP címet, viszont elkerülendő az esetleges routing problémákat alapértelmezés szerint nem aktív azonosítása az operációs rendszerben eth0 néven érhető el 2. kliens oldal célja: olyan kapcsolat biztosítása a kliens és a tűzfal között, amin kizárólag ezen két gép közötti forgalom zajlik működése a VMware által megvalósított belső hálózatok kiépítésére szolgáló típussal, mely az architektúrát felvázoló ábra szerint kap IP címeket azonosítása az operációs rendszerben eth1 néven érhető el 3. szerver oldal célja: olyan kapcsolat biztosítása a szerver és a tűzfal között, amin kizárólag ezen két gép közötti forgalom zajlik működése a VMware által megvalósított belső hálózatok kiépítésére szolgáló típussal, mely az architektúrát felvázoló ábra szerint kap IP címeket azonosítása az operációs rendszerben eth2 néven érhető el 7

8 Client Firewall Server eth1 eth1 eth2 eth / / / /16 fd00::10:0:0:1/96 fd00:10:0:255:254/96 fd00::10:1:255:254/96 fd00::10:1:1:1/ x x x Host 1. ábra. Virtuális gépek kialakítása, ahol az x helyére rendre a mérőhely számát kell behelyettesíteni 2.3. Gépek elérése A virtuális gépek kialakítása az 1. ábrán láthatóak szerint történik. az autentikáció felhasználónév jelszó párossal történik két felhasználóval rendelkezik (root, balasys a felhasználónév és a jelszó megegyezik A bejelentkezés a gépekre vagy a gépen közvetlenül felhasználónév (balasys jelszó (balasys páros megadásával, vagy SSH segítségével, az alábbi parancsot használva a jelszó megadása után történik. ssh virtualis_gep_ip_cime -l felhasznalonev Az egyes gépek az eth0 interfészeiken a virtuális környezet DHCP szervere által kiosztott, IP címeken keresztül érhetőek el. A konkrét címek kiderítéséhez az alábbi parancs kiadása szükséges, közvetlenül a virtuális gépre bejelentkezve. ip -4 addr show dev wlan0 A virtuális gépek billentyűzetkiosztása angol. Amennyiben a magyar nyelvű kiosztás használata a mérés során kényelmesebbnek tűnik, a váltás következő paranccsal végezhető el: sudo loadkeys hu 8

9 2.4. Konfigurációs fájlok A Zorp konfigurációs fájljai hasonlóan más alkalmazásoknál használt könyvtárszerkezethez az /etc/zorp könyvtárban kapnak helyet. Alapvetően három állomány kódosítására van szükség a gyakorlatban. instances.conf az egyes Zorp példányokhoz kapcsolódó beállítások kapnak itt helyet (pl: naplózás részletessége, szabályokat leíró konfigurációs fájl,... zones.py a zónák definícióit tartalmazza policy.py a tényleges tűzfalszabályokat, illetve a általuk indítandó szolgáltatások (Service, illetve a tényleges forgalom-ellenőrzést és manipulációt végző osztály (Proxy leírását tartalmazza A mérés során csak az utóbbi állomány módosítására lesz szükség, ehhez tetszőleges szövegszerkesztő (nano, vim,... használható. 3. Feladatok 3.1. Működés ellenőrzése A kialakított hálózati topológia működésének ellenőrzésére hajtsa végre az alábbiakat: 1. jelentkezzen be mindhárom virtuális gépre SSH segítségével 2. ellenőrizze a kliens és a szerver gépeken a tűzfal elérését az arping -I interfésznév cél_ip_cím parancs segítségével 3. a jegyzőkönyvezze a kiadott parancsot a parancs kimenetének azon részét, ami az elküldött kérést és az arra érkező választ tartalmazza Ezt követően kísérelje meg a kliens gépről a szerver gép elérését: 1. ellenőrizze szerver gép elérését IPv4 protokollon a következő paranccsal: ping szerver.ip.cime 2. ellenőrizze web szerver elérését IPv4 protokollon a következő paranccsal: wget -O /dev/null 3. ellenőrizze web szerver elérését IPv4 protokollon a következő paranccsal 1 curl -insecure -o /dev/null Alapértelmezett tiltás beállítása Módosítsa a Zorp konfigurációs állományokat, hogy minden forgalom tiltásra kerüljön oly módon, hogy a kliens értesüljön a tiltásról. A tiltás megvalósítására egyetlen szabályt használjon! A konfiguráció módosítását követően indítsa újra a Zorpot, majd ismételje meg a működés ellenőrzésekor (3.1 végrehajtottakat és dokumentálja azokat az ott leírtaknak megfelelően, illetve jegyzőkönyvezze a konfigurációs változtatásokat (Rule,Service! 1 Megjegyzés: -insecure helyett a -k akkor is letölti a certificatet ha az nem megbízható. 9

10 3.3. Specifikus szabályok felvétele Módosítsa a konfigurációs állományokat úgy, hogy az ICMP forgalom átengedése PFService, a HTTP forgalom pedig Service segítségével valósuljon meg, ahol a proxy típusa legyen a Zorp részeként szállított HttpProxy! Ehhez alkosson az általános tiltó szabálynál specifikusabb, az ICMP, illetve a 80-as porton zajló TCP forgalomra jobban illeszkedő (1.2.1 szabályokat. 2 Jegyzőkönyvezzen az előző mérésnél leírtak szerint! 3.4. Saját proxy osztály létrehozása A fentiekben ismertetetteknek (1.3.1 megfelelően hozzon létre egy testre szabott HttpProxy változatot, melynek segítségével cserélje le a User-Agent HTTP fejléc értékét, az alábbi kódrészlet megfelelő helyre történő beillesztésével. self.request_header["user-agent"] = (HTTP_HDR_CHANGE_VALUE, "Forged Browser" Ellenőrizze a kapcsolat kiépülését a szerver alkalmazás (Apache napló állományában (ennek helye: /var/log/apache2/access.log, illetve a tűzfal gép rendszernapló állományában (/var/log/syslog. Jegyzőkönyvezze a tűzfalon keresztüli elérést bizonyító szerver oldali naplósort, illetve a konkrét HTTP parancs (GET átviteléről szóló tűzfal napló bejegyzést! Jegyzőkönyvezzen az előző mérésnél leírtak szerint! 3.5. Titkosított forgalom átvitele proxy segítségével Hozzon létre egy újabb szabályt a HTTPS forgalom (port 443 átvitelére! A proxy típusa a Zorp részeként szállított PlugProxy legyen! 1. hajtsa végre az ellenőrzést az előző mérésnél leírtak szerint 2. ellenőrizze és jegyzőkönyvezze a szerver által felmutatott tanúsítvány kibocsátójának (issuer nevét (CN: openssl s_client -connect : Titkosított forgalom átvitele titkosítás bontásával Illessze be az alábbi a titkosítás kibontására szolgáló konfigurációs részletet a korábban létrehozott saját proxy osztály alá. Ezt követően módosítsa a Service definícióját, hogy az használja az EncryptionPolicy osztályt, illetve cserélje le a jelenleg használt PlugProxy osztályt a korábban létrehozott saját HttpProxy osztályra. EncryptionPolicy( name="https_encryption_policy", encryption=twosidedencryption( client_certificate_generator=dynamiccertificate( private_key=privatekey.fromfile( key_file_path="/etc/zorp/certs/key.pem", passphrase="", trusted_ca=certificate.fromfile( certificate_file_path="/etc/zorp/certs/trusted.pem", private_key=privatekey.fromfile("/etc/zorp/certs/trusted.pem", passphrase="passphrase", 2 a megfelelő protokoll azonosítok a Python socket moduljában IPPROTO_TCP, IPPROTO_ICMP, illetve IPPROTO_ICMPV6 néven érhetőek el 10

11 ..., untrusted_ca=certificate.fromfile( certificate_file_path="/etc/zorp/certs/untrusted.pem", private_key=privatekey.fromfile("/etc/zorp/certs/untrusted.pem", passphrase="passphrase",,, client_verify=clientnoneverifier(, server_verify=servercertificateverifier( trusted=false Service( name="https_service", encryption_policy="https_encryption_policy", proxy_class=myhttpproxy A feladat megoldásához töltse le a tűzfal számára a titkosításhoz szükséges kulcsot és tanusítványokat ( és másolja be a tűzfal virtuális gépének /etc/zorp/certs mappájába a kicsomagolt pem fájlokat, majd állítsa be a megfelelő jogosultságokat (user:rw-, group:r, others:! Hajtsa végre az ellenőrzést az előző mérésnél leírtak szerint! 4. Jegyzőkönyv A jegyzőkönyvet a mérés után egy héten belül el kell küldeni a mérésvezetőnek pdf formátumban. A jegyzőkönyvnek az alábbiakat kell tartalmaznia: Hallgató(k neve és Neptun kódja Mérés neve Mérés időpontja Mérőhely száma Feladatok megoldása A megoldások leírásánál törekedni kell a tömör, de érthető válaszra. A leírásból a megoldásnak reprodukálhatónak kell lennie! Hivatkozások [1] Szilárd Pfeiffer. Zorp GPL Tutorial. BalaSys Ltd., Alíz utca 2. H-1117 Budapest,

12 Tárgymutató Apache, 10 arping, 9 billentyűzetkiosztás, 8 deep packet inspection, 4 HTTP, 10 HTTPS, 10 ICMP, 10 IPTables, 4, 5 IPv4, 9 IPv6, 9 ping, 9 policy EncryptionPolicy, 10 proxy HttpProxy, 10 PlugProxy, 10 Python, 4 service DenyService, 3, 9 PFService, 4, 10 Service, 4, 10 SSH, 8, 9 VMware, 7 w3m, 9 12