Összetett informatikai biztonsági rendszer kiépítése pénzintézetben.Ügyfél: Pénzintézet (nem kiadható). Feladat: összetett IT-biztonsági rendszer kiépítése. A kiépített rendszer topológiájaf  f MegvalósításA LAN IEEE 802.1X képes Cisco switchekből áll. Az intelligens hozzáférés-vezérlést a Juniper UAC megoldása biztosítja az alábbiak szerint: A szerverek szabadon hozzáférhetnek a hálózathoz, a switchek megfelelő portjai nincsenek IEEE 8021X‑re beállítva. A nyomtatók és „buta” vékony kliensek csak akkor férnek hozzá a hálózathoz, ha MAC‑címük szerepel az UAC megoldás központi elemének, az Infranet Controller 4000-nek (továbbiakban: IC4000) a MAC‑adatbázisában. Az „okos” vékony klienseket digitális tanúsítvány segítségével azonosítja az IC4000. A számítógépeken fut az UAC megoldás kliens oldali része, az Odyssey Access Client (továbbiakban: OAC) szoftver. Ez egyrészt hitelesíti a számítógépet (machine account), másrészt a számítógépbe belépni szándékozó felhasználót. Ezen hitelesítések Windows AD‑vel történnek. A machine account segítségével bejelentkezett felhasználó nélkül is fel tud egy számítógép kapcsolódni a hálózatra, így pl. éjszaka a rendszergazdák távolról tudják frissíteni a rajta lévő programokat. A sikeres hitelesítést követően az OAC Host Checker komponense ellenőrzi, hogy a számítógép megfelel-e a vele szemben támasztott feltételeknek (működő antivírus szoftver, Windows patchek megléte, stb.). Az OAC Host Enforcer komponense (tulajdonképpen egy kliens oldali tűzfal) a Host Checker ellenőrzésének eredménye alapján, az IC4000 utasítása szerint vezérli a számítógép hálózathoz való hozzáférését (teljes, vagy részleges).
A hálózatban támogatott a távmunka, melyet a távmunkások laptopjaira telepített Juniper NetScreen-Remote program és a központban elhelyezett Juniper SSG‑140‑SH tűzfal között kiépülő IPSec VPN tesz lehetővé. A távmunkások számítógépein szintén fut az OAC, és a LAN számítógépeihez hasonló módon férhetnek csak hozzá a belső erőforrásokhoz. Annyi különbség van csak, hogy itt nem IEEE 802.1X‑alapú a hozzáférés vezérlése, hanem a tűzfal és az IC4000 együttműködése szabályozza azt. A tűzfal ún. Infranet Enforcerként működik, a Host Checker ellenőrzésének eredménye alapján az IC4000 letölti a megfelelő policy‑t rá, ami meghatározza, hogy a távmunkás mit és hogyan ér el a belső hálózatból.
A laptopokon lévő adatok illetéktelen kezekbe kerülését (pl. a laptop ellopása, vagy elvesztése esetén) az Utimaco SafeGuard Easy programjával végzett merevlemez titkosítás védi. Ennek feloldásához – a gép operációs rendszerének elindításához – szükséges erős azonosítás Aladdin eTokenekkel valósul meg. A hálózatot a külvilágtól két, sorba kötött tűzfal védi. Ezek közül a belső a projekt előtt is megvolt, a külső pedig egy Juniper SSG‑140‑SH berendezés, mely egy intelligens, állapottartó, csomagszűrű tűzfal. Ennek kiválasztásához az alábbiak vezettek: A pénzintézetet a külvilágból érkező spamektől, vírusoktól, stb. az adatútba helyezett Secure Computing Webwasher berendezés védi. E security gateway az anti‑x funkciókon túl ún. secure proxy funkciót, valamint URL szűrést is nyújt, sőt képes a HTTPS forgalom ellenőrzésére is. Az illetéktelen adatoknak a külvilágba való kijutását pedig adatszivárgás kiszűrő funkciója segítségével akadályozza meg. A hálózat védelmét fokozza a kitüntetett szegmenseken haladó forgalomban támadásokat figyelő és gátló Juniper IDP 200 betörés‑elhárító eszköz. A Juniper eszközök menedzsmentjére a Juniper Netscreen-Security Manager szolgál. Központosított naplózó elemző rendszerként a Zuriel LOGalyze lett üzembe állítva. Ennek a működéséhez el kellett készíteni, majd importálni kellett a fentiekben ismertetett eszközök naplóformátumait leíró sablonokat. A teljes rendszer átfogó (eszköz- és gyártófüggetlen) menedzselését az op5 cég Network Management Suite családjának op5 Monitor és op5 Statistics szoftverei végzik. Előbbi egy (Nagiosra épülő) központosított monitorozási és riasztási (jelenleg e‑mail‑ben és smsben) rendszert, utóbbi egy kapacitástervezéshez jól használható (Cactira épülő) grafikus, statisztikai rendszert jelent. A nagyobb rendelkezésre állás biztosítása végett az IT-rendszer fent felsorolt elemeit APC UPS‑ek védik a tápellátásban bekövetkező hibáktól (túl alacsony/magas feszültség, stb.), továbbá 30 perces áthidalási időt biztosítanak az áramszolgáltatás kiesése esetén. (Ezek nem e projekt keretében lettek telepítve.) Az informatikai rendszer megbízható működését segíti a mentő és archiváló rendszer, mely azonban nem e projekt keretében lett kiépítve. Bár a külön licencelhető ún. Coordinated Threat Control funkció révén az IDP 200 képes lenne együttműködni az IC4000-rel, de e funkciót jelen megvalósítás során nem kérték. A rendszerben alkalmazott valamennyi elem – SSG‑140‑SH, IDP 200, IC4000, op5 és NSM szoftverek, Webwasher – támogatja az eszközredundanciát, de jelen projektben ezt nem kellett bevezetni. 
Pénzintézet 14 telephelyének összekötése IKEv2 IPSec VPN‑nel, redundáns központtalÜgyfél: pénzintézet (nem kiadható). Cél: A pénzintézetnek egy ide vonatkozó, hatályos törvénynek való megfelelés végett két, egymástól távol lévő adatközpontot kell kialakítania és meg kell teremtenie a másodlagos központ használatának feltételeit katasztrófa helyzetben. Háttér: Jelen esettanulmányban leírt projekt megvalósítása előtt a dolgozók a központban lévő terminálszerveren keresztül használták a munkájukhoz szükséges alkalmazásokat. A 13 fiókiroda és a központ drága és – még a terminálszerveres környezethez képest is – lassú bérelt vonalakkal volt összekapcsolva. A szerverpark elavult. A teljes célt két lépésben kívánja a pénzintézet elérni. Először a hálózati infrastruktúrát kell kialakítani, majd – a terminálszerveres munkakörnyezet megtartásával – a meglévő szerverfarm modernizálása, a másodlagos központban új szerverfarm kialakítása, a két szerverfarm adatai szinkronizációjának és mentésének megteremtése a feladat. A szerverfarmok kialakításakor virtualizációs technológiát használnak. Jelen esettanulmány csak az első lépés megvalósítását mutatja be, mivel a második nem tartozik az IT-biztonság témakörébe. Feladat: pénzintézet 12 fiókirodájának és 2 központjának összekötése VPN‑en úgy, hogy a megoldás katasztrófa helyzet esetén tegye lehetővé, hogy a fiókirodák a tartalék központot elérve tovább dolgozhassanak. MegvalósításInternet hozzáférésA meglévő szolgáltató nem tudta a bérelt vonalas összeköttetést a két központos kialakítás kezelésére képessé tenni, ezért egy, az új környezetnek megfelelő és költséghatékony szolgáltatást kellett választani a 14 telephely összekötésére. A pénzintézet a fiókirodáinál elérhető Internet szolgáltatók (ISP‑k: Internet Service Providerek) által kínált szolgáltatások vizsgálata, illetve ezeknek a szakembereink által az új környezet kialakítására vonatkozó tanulmánnyal való összevetése alapján kötött szerződést a kiválasztott Internet szolgáltatóval. (E tanulmány többek között tartalmazta az igényelt sávszélességeket minden telephely esetében, mind normál, mind katasztrófa helyzetben, mind a fiókiroda-központ, mind a központ-fiókiroda irányban.) Mivel a központokba 4 Mbps-os kapcsolat volt szükséges és 2 Mbps‑osnál nagyobb sávszélességű bérelt vonalat nem szoktak a szolgáltatók adni, a kívánt sávszélesség pedig ADSL‑lel nem szolgálható ki, ezért vagy nagyon drága berendezést és külkapcsolatot (pl. E3) kellett volna a központokba venni, vagy 2 db 2 Mbps‑os bérelt vonalat, amit olcsóbb berendezéssel is le lehet kezelni. Szakembereink és a kiválasztott Internet szolgáltató is ezt javasolta. A fiókirodáknak 4 Mbps/256 kbps (letöltési/feltöltési) ADSL, a központoknak 2×2 Mbps (full duplex) bérelt vonali Internet kapcsolata lett. VégberendezésekAz Internet kapcsolatokhoz igazodva – több gyártó megoldásai közül – a pénzintézet a Juniper Networks által gyártott Secure Services Gateway termékek mellett döntött. Ezek ugyanis az Internet- és VPN-kapcsolat megteremtése mellett fejlett tűzfalfunkciókkal védik a telephelyeket. A fiókirodákban telepített SSG-5-SB modelleket közvetlenül ADSL modemre, a központokba kerülő SSG-20-SH modelleket pedig közvetlenül bérelt vonali modemre kötve, külön router nélkül kialakítható volt a hálózat. A központi tűzfalak a bérelt vonali soros kapcsolatban DTE, vagy DCE szerepet tölthetnek be, melyet az összekötő kábelnek a nem a tűzfalhoz csatlakozó vége határoz meg. Jelen projektben az adott topológiában általában használatos, és a szolgáltató által kért DTE változatú kábelt használtunk. A központi tűzfalak a bérelt vonali modemekhez szinkron soros modulok és X.21-es DTE kábelek segítségével csatlakoznak. Mivel mindegyik központ 2 db 2 Mbps-os, X.21-es interfészű modemen keresztül kapcsolódik az Internetre, ezért ehhez illeszkedve 2×2 db modul és 2×2 db X.21-es kábel lett telepítve. TopológiaA központokban lévő Internet csatlakozás 2 db 2 Mbps-os bérelt vonalát „multilink PPP” technológiával egyetlen virtuális vonallá fogtuk össze. A „multilink PPP” technológia egyrészt egy virtuális, 4 Mbps-os vonalat hoz létre, így az alkalmazások számára nagyobb „látható” sávszélességet biztosít, mint külön-külön a fizikai vonalak. Másrészt képes a két fizikai vonal között terheléselosztásra, azaz, ha az egyik terhelt, akkor a másikon továbbítja az adatot. Ezen túl pedig hibatűrést is biztosít, hiszen az egyik fizikai vonal kiesése esetén néhány másodpercen belül minden forgalmat átterel a megmaradt fizikai vonalra. A rendszer további redundáns eleme, hogy a fő központ mellett létezik egy tartalék központ is, ami – a kettőzött szerverpark létrehozását követően – alkalmas a fő központ kiesése esetén annak szerepét átvenni. A meglévő rendszerben a különféle partnerek által nyújtott szolgáltatások elérését biztosító Extranet hálózathoz egy 64 kbps-os bérelt vonalon (az Extranet hálózatot üzemeltető cég tulajdonában és kezelésében lévő, de pénzintézetnél üzemelő router segítségével) csatlakozott a központ. E kapcsolaton keresztül lehetett Internetezni is. Ez a kapcsolat az új hálózati kialakításban is megmaradt. Ugyanakkor a központokban (a 2. lépés során) telepítendő szerverek hatékony frissítéséhez nem elegendő a 64 kbps-os bérelt vonal. Ezért a szervereknek a központok újonnan kiépítendő 2×2 Mbps-os Internet csatlakozásán át kell elérniük a frissítésekhez szükséges oldalakat. Ezen kapcsolatok biztonságát az új infrastruktúra kialakítása során szállított SSG-20-SH tűzfalak biztosítják. A szerverek új infrastruktúrán keresztüli Internet elérésének biztonságát növeli, hogy az alap tűzfal funkciókat kiegészítettük a tűzfalakon – külön licencekkel – aktivált behatolás elhárító (Deep Inspection) megoldással. A topológia – habár a megvalósított rendszer támogatná, de – pénzintézet elvárásai alapján úgy lett kialakítva, hogy a fiókirodák dolgozói sem a saját Internet csatlakozásukon (split tunnel), sem a központén keresztül (tunnel all) nem Internezhetnek. Ráadásul a fiókirodák csak a központtal kommunikálhatnak, egymással – bár a megvalósításban használt eszközök ezt is lehetővé tennék – nem. A rendszer rendelkezésre állását tovább lehetne növelni, ha mindegyik telephely rendelkezne tartalék Internet kapcsolattal. Jelenleg ugyanis, ha bármelyik telephely (akár fiókiroda, akár központ) Internet kapcsolata meghibásodik, akkor nem tudja ellátni feladatát (nem éri el a központ IT-erőforrásait, vagy nem teszi azokat elérhetővé a fiókirodáknak). Ha azonban lenne tartalék vonal, akkor ilyenkor arra áttérve zavartalanul folyhatna tovább a munka. A telepített tűzfalak egy ilyen topológia kialakítására lehetőséget adnak, csak a tartalék vonalakat kellene beszerezni és a tűzfalakat átkonfigurálni. A kiépített rendszer topológiája
Ahogy a fenti ábrán látható, az új infrastruktúrában az eddigi egyik fiókirodát kinevezték tartalék központnak. Normál működés esetén a többi fiókirodához hasonlóan ez is a fő központhoz csatlakozik. Katasztrófa helyzetben azonban átveszi a fő központ szerepét és a fiókirodák hozzá kapcsolódnak. Mivel az Extranet csak a fő központhoz csatlakozik, ezért katasztrófa helyzetben nem érhető el, de ez a pénzintézettől katasztrófa helyzet esetén megkövetelt működést nem akadályozza. A fentiekben bemutatott kialakítás hátrányai: Mivel egyik helyszínen sincsen tartalék külkapcsolat, ezért a pénzintézet IT-rendszerének folyamatos működése csak akkor biztosított, ha a fiókirodák és a központok külkapcsolatai működnek. Ráadásul a katasztrófa helyzetben történő munkavégzés is csak akkor lehetséges, ha a fiókirodák és a tartalék központ külkapcsolatai működnek. Ha olyan szerencsétlen eset fordulna elő, hogy mind a két központ külkapcsolata egyszerre hibásodik meg, akkor a fiókirodák addig nem tudnak számítógép hálózattal dolgozni, amíg legalább az egyik központ külkapcsolata fel nem épül.
Katasztrófa helyzet kezeléseA projekt előkészítése során – a pénzintézet munkafolyamatainak, a lehetséges hibahelyzeteknek, a törvényi és belső szabályzatok előírásainak vizsgálata és kiértékelése után – szakembereink és a pénzintézet szakemberei a következőben állapodtak meg: Ha a fő központ kapcsolata a külvilággal megszakad, akkor az még nem katasztrófa helyzet, amennyiben a szolgáltató a hibát a pénzintézet által elfogadható idő alatt képes kijavítani. Katasztrófa helyzet csak akkor következik be, ha a pénzintézet illetékesei valamiért – pl. a szolgáltató által vállalt, számukra elfogadhatatlan javítási idő; vis maior helyzet; belső szabályzat előírása; stb. miatt – a fő központ kiesését annak minősítik. Ebből adódóan, ha egy fiókiroda kapcsolata szakad meg a külvilággal, akkor az soha sem minősül katasztrófa helyzetnek, így soha nem kell áttérni VPN-kapcsolattal a tartalék központra! A kialakítandó VPN olyan kell legyen, hogy katasztrófa helyzetben minden fiókiroda rövid idő alatt elérhesse a tartalék központot. Azt azonban el kell kerülni, hogy valamilyen teljesen automatikus megoldás révén egy-egy fiókiroda a tartalék központhoz kapcsolódjon, miközben a fő központ is él és a többi fiókirodákat kiszolgálja. Vagyis az átállásnak a katasztrófa helyzet kihirdetése kell legyen az előfeltétele, így maximum fél automatikus lehet! A tartalék központban a fiókirodák felől érkező VPN forgalom blokkolva van, mely katasztrófa helyzet beállta esetén egy kattintással feloldható, katasztrófa helyzet megszűnése után pedig szintén egy kattintással visszaállítható. 
Mivel a tartalék és a fő központban működő szerverek IP-címe eltér egymástól, ezért a VPN-hálózat átállása után az alkalmazásokat is át kell állítani. Terminál szerveres környezetről révén szó ez pusztán annyit jelent, hogy normál esetben a fő, katasztrófa helyzetben a tartalék központ terminál szervereit kell elérni. Ezeken keresztül mindig az adott helyzetnek megfelelő alkalmazás (adatbázis) szerver érhető el, azaz például a tartalék központban működő terminál szerver által szolgáltatott asztalon lévő ikon a tartalék központban üzemelő alkalmazás szerverhez kapcsolja a klienst. Az alkalmazás átálláshoz minden fiókirodai számítógép asztalán két ikon lesz: egy a normál és egy a katasztrófa helyzetre. Mindegyik ahhoz a terminálszerverhez fog kapcsolódni, amihez az adott helyzetben kell. A rendszer kialakítása miatt, ha véletlenül a felhasználó rossz ikonra kattint, akkor nem történik baj: az adott felhasználó nem fogja tudni elérni a – tévedésből – kiválasztott terminál szervert. Ily módon a katasztrófa helyzet kezelés mind a felhasználók, mind az üzemeltető személyzet számára rendkívül egyszerű, könnyen elsajátítható és gyors. Maga a katasztrófa helyzet kezelési útmutató csak két oldal lett. VPNMivel a telephelyeknek az elvárásokhoz illeszkedő, költséghatékony összekötése az Interneten keresztül valósítható meg, ezért közöttük VPN-t kell kialakítani. A VPN-nek – a rajta átvitt érzékeny, pénzügyi adatok miatt – titkosítottnak kell lennie, emiatt (az általánosan elterjedt megoldások közül) nem lehet sem PPTP, sem L2TP, hanem IPSec, vagy L2TP over IPSec. Szakembereink IPSec VPN-t építettek ki. (Az IPSec egymáshoz kapcsolódó protokollok halmaza, amelyek kriptográfiailag biztonságos kommunikációt tesznek lehetővé az IP-csomagok szintjén.) A VPN kiépítésének és katasztrófa helyzethez való alkalmazkodásának feltétele, hogy a külkapcsolatok fix, nyilvános IP-címmel rendelkezzenek. Bár a megoldásunkban használt berendezések lehetővé tették volna, hogy csak a központoknak legyen fix IP-címe, pénzintézet minden telephelyének ezt kért. A korábban ismertetett multilink PPP beállítás a VPN megvalósítást is leegyszerűsítette. Egyrészt, mivel a központokban nem két-két nyilvános IP-címe van a tűzfalaknak, hanem egy, ami a multilink interfészhez van rendelve, ezért a fiókirodák tűzfalaiban mindegyik központhoz csak 1 IP-címet kellett beállítani a VPN-hez. Ez – az egyszerűbb konfiguráláson túl – azt is jelenti, hogy a fiókirodák tűzfalainak nem kell „törődnie” azzal, hogy a központok fizikai vonalai közül melyik él. Ráadásul a VPN forgalomnak a központok fizikai kapcsolatai közötti kezelése (terheléselosztás, forgalom átterelés) is megoldott. Az SSG eszközöket úgy állítottuk be, hogy a központok és a fiókirodák között tunnel módú, site-to-site IPSec VPN kapcsolatok épülnek ki, ESP protokollal. Automatikus kulcs szétosztó és kezelő megoldásként a legújabb IKEv2 protokollt használjuk, az egyszerűség végett pre-shared kulcsokkal. Az IKEv2 az IPSec pontok közti kulcscserének számos összetevőjét (NAT-T, XAuth, ISAKMP konfiguráció) egyetlen protokollban valósítja meg, mindamellett az előző verzió számos tulajdonságát (pl. identity hiding, PFS, 2 fázisú SA kiépítés, stb.) megtartja. Ezeken túl több újdonságot is bevezet, melyek közül jelen projektben azt használtuk ki, hogy az IKEv2 védett a DoS támadásokkal szemben. A telepített Juniper tűzfalak kétfajta, policy-based és route-based VPN tunnellek kiépítésére képesek. Jelen projektben route-based VPN tunnelleket alkalmaztunk, mert ez a technológia: Kevesebb tunnel erőforrást használhat, mint a policy-based változat. Lehetőséget ad a VPN-en átmenő forgalom részletes szabályozására. A VPN rendszer – a zökkenőmentes és gyors bevezetés végett – az általa kiváltott routeres rendszer forgalomszabályozását (policy) vette át. Mindazonáltal megoldható, hogy néhány hónap elteltével a tűzfalak naplóállományait elemezve a tényleges tevékenységhez és pénzintézet elvárásaihoz jobban igazodó rendszabályokat állítsanak be. Lehetőséget ad dinamikus routing protokollok VPN-en keresztüli (telephelyek közötti) használatára. Erre pedig a későbbiekben akár szükség is lehet. Egyszerűbb vele a pénzintézet által használt hub-and-spoke topológia újabb spoke-okkal (fiókirodákkal) való bővítése.
A route-based VPN kialakításban (ellentétben a policy-based megoldással) a forgalom szabályozása és továbbítása elválik egymástól. A forgalomszabályok (policy-k) a forgalomnak a tűzfalon (illetve VPN-en) való áthaladását szabályozzák, míg a forgalom továbbítását a route tábla vezérli. Amelyik IP-hálózatba tartó csomag esetében a használandó útvonalbejegyzés egy tunnel interfészre mutat, az a csomag bekerül a VPN-be (ha ezt egy policy is megengedi). A fentiekben ismertetett topológia, alkalmazási környezet és katasztrófa helyzet kezelés támogatásához a rendszert úgy alakítottuk ki, hogy mindegyik fiókiroda mindkét központhoz folyamatosan kapcsolódik VPN-nel, és a tartalék központ is folyamatos VPN kapcsolatban van a fő központtal. 
Fontos megjegyezni, hogy így a fiókirodák tűzfalainak kettő, a központokénak 13 egyidejű VPN kapcsolatot kell fenntartaniuk. Ez VPN kapcsolatonként a fiókirodákban egy-egy tunnel interfészt jelent. Habár az SSG-20-SH berendezés minden egyéb paraméterében megfelelt jelen projekt követelményeinek, de csak 10 tunnel interfészt támogat, ezért a szokásos – egy tunnel interfészhez egy VPN tunnel tartozik – konfigurációval nem lehetett volna használni, hanem egy nagyobb és drágább berendezést kellett volna helyette telepíteni. Azonban ezen tűzfalakon futó ScreenOS lehetővé teszi, hogy egy tunnel interfészhez több VPN tunnel tartozzon. Ezt az útvonaltábla (route tábla) és az NHTB tábla segítségével valósítja meg. 
Így mind a két központi tűzfalon csak két tunnel interfészt hoztunk létre és statikus NHTB beállítással oldottuk meg a feladatot. A VPN kialakítása során beállítottuk a VPN Monitort, ami folyamatosan figyeli az egyes site-to-site VPN-ek állapotát, így a rendszer bármelyik tűzfalába belépve azonnal látható, hogy az azon kialakított VPN-ek élnek-e. 
A VPN Monitor funkció úgy lett beállítva, hogy a VPN szakadását annak bekövetkeztétől számított 30 másodperc múlva jelzi. Ezen túl e funkció (a rekey opció bekapcsolásával) biztosítja, hogy a tunnellek felhasználói forgalom nélkül is mindig éljenek, így a felhasználóknak nem kell nagyobb válaszidőt elszenvedniük a VPN kiépítése miatt (pl. a reggeli munkakezdéskor), továbbá a központban üzemelő menedzsment rendszerek is folyamatosan elérik bármelyik telephelyet, és azokat is folyamatosan elérik a telephelyek hosztjai (pl. syslog üzenetet tudnak küldeni a központban üzemelő syslog szervernek). Ennek következtében a fiókirodák tűzfalai úgy lettek beállítva, hogy vonalbontás után nem próbálnak meg maguktól újra PPPoE kapcsolatot felépíteni. Ha azonban új 'outbound’ forgalmat kapnak, akkor megkísérlik felépíteni a PPPoE kapcsolatot. Mivel a VPN Monitor funkció ilyen 'outbound’ forgalmat generál, így vonalbontás után felhasználói forgalom nélkül is felépül – ha nem hibás az ADSL vonal – a PPPoE kapcsolat. RoutingMivel a pénzintézet hálózati rendszere elég állandó; a topológia „hub-and-spoke”, ahol a fiókirodák (spokes) csak a központtal (hub) kommunikálhatnak; nincsenek a telephelyek között alternatív (backup) útvonalak; kevés telephelyről és IP-hálózatról van szó, így a kapcsolatok minden eszközben néhány útvonalbejegyzéssel megadhatók, ezért statikus routingot használtunk. Megjegyezzük, hogy az SSG eszközök a következő IPv4 dinamikus routing protokollokat támogatják: RIPv1, RIPv2, OSPF, BGP. Ezek közül a régi rendszerben a RIP-et használták, és az átállás megkönnyítésére a fő központban telepített tűzfalon az átállás idejére mi is beállítottuk. Így ugyanis a központi tűzfalak telepítését követően lehetőség volt a fiókirodákat egyesével átállítani úgy, hogy egyszerre működött a régi és az új rendszer: a még át nem állt fiókirodák a régit használták, az átálltak pedig már az újat. Ehhez persze az is kellett, hogy pénzintézet a bérelt vonalait csak a sikeres átállást követően (e projekt befejezése után) mondja le. A route-based VPN megoldás és VPN Monitor funkció együttes használatának a következő biztonsági kockázata van. Ha a VPN Monitor szakadtnak érzékel egy VPN-t, akkor a hozzá tartozó tunnel interfész ’DOWN’ állapotba vált, aminek hatására az ezt használó útvonalbejegyzések inaktívvá válnak az útvonaltáblában. Emiatt viszont amikor az eszköz útvonalat keres egy normálisan VPN-ben elküldendő csomag számára, kihagyja a tunnel interfészre mutató, inaktív bejegyzéseket és az aktív bejegyzések közül a legjobban illeszkedőt választja. Ez pedig lehet akár a „default route” is. Így előfordulhat, hogy a forgalmat titkosítatlanul küldi el az Internetre, ami a pénzintézeti érzékeny adatok miatt elfogadhatatlan. Ennek kivédésére jelen projektben a „null route” módszert használtuk. Vagyis minden, tunnel interfészre mutató útvonalbejegyzés mellett létrehoztunk egy ugyanazon IP-hálózatra vonatkozó másik bejegyzést, ami azonban a „null” interfészre mutat és nagyobb a metrikája, mint a tunnel interfészre mutató útvonalbegyezésé. (A null interfész egy mindig ’UP’ állapotban lévő, logikai interfész, ami a rá küldött csomagokat eldobja.) Így VPN szakadáskor, a jelen projektben együttesen alkalmazott route-based VPN megoldás és VPN Monitor funkció esetén is, a VPN-ben elküldendő csomagok nem kerülnek titkosítatlanul elküldésre, hanem el lesznek dobva. NATA hálózati rendszerben, mivel az SSG berendezéseken keresztüli Internet elérés (split tunneling, vagy tunnel all) nincs, és a külvilág számára sem nyújtanak a központok szolgáltatásokat (pl. e-email, web), ezért csak a hálózati rendszer és az Extranet között van NAT. A fő központ hálózatából az Extranet felé menő forgalom interface-level NAT-src módszerrel van NAT-olva, kivéve a speciális hosztokat, amik MIP-pel NAT-olódnak. Az Extranet felől a fő központban elérni kívánt egyéb szolgáltatásokat VIP segítségével NAT-oljuk. Az Extranet felől az egyéb telephelyeken elérni kívánt hosztokat (pl. ATM-eket) NAT-dst módszerrel NAT-oljuk. Ezen telephelyek is elérhetik az Extranetet, viszont az Extranet üzemeltetői azt kérték, hogy egyértelmű megfelelés legyen a telephelyek hálózatai és a NAT-olt címek között. Azaz, ha az 1. fiókiroda NET1.GEP1 IP-című hosztja éri el az Extranetet, akkor mindig TR_NET1.GEP1 IP-címre legyen NAT-olva, ha pedig a 2. fiókiroda NET2.GEP1 IP-című hosztja éri el az Extranetet, akkor mindig TR_NET2.GEP1 IP-címre legyen NAT-olva, és így tovább. Ennek megvalósítására a ScreenOS „DIP shift” technológiáját használtuk az „extended interface” funkcióval, mivel a forrás IP-címeket a fő központ tűzfala Extranet interfészétől eltérő IP-hálózatokba kellett „fordítani”. PPPoEA fiókirodák tűzfalai közvetlenül ADSL modemre kapcsolódnak és PPPoE vel, PAP authentikációval teremtik meg az Internet kapcsolatot. A PPPoE profile-hoz tartozó interfészük (WAN interfész) dinamikusan kapja az IP adatait (cím, maszk, default gateway). A fix IP-címet a szolgáltató úgy biztosítja, hogy mindig ugyanazon IP-címet osztja ugyanazon eszközöknek. Vonalbontás után a VPN Monitor funkció segítségével épül fel ismét az Internet kapcsolat. Erről bővebben a VPN Monitor ismertetésénél írtunk. A tűzfalak 30 percnyi tétlenség után automatikusan bontanák az ADSL kapcsolatot. A VPN Monitor funkció használata miatt azonban erre soha nem kerül sor, mert a vonal soha nem tétlen, hiszen a VPN Monitor funkció akkor is forgalmat generál, ha nincs felhasználói forgalom. Mivel az ADSL modem és a tűzfal között ethernet kapcsolat van, ezért előfordulhat olyan eset, hogy e kapcsolat él ugyan, de az ADSL vonalban hiba van. Ennek érzékelésére a tűzfal támogatja az LCP pinget. A tűzfal 3 másodpercenként küld ’LCP echo request’ csomagokat. Ha 10 egymás után elküldött ’LCP echo request’ csomagra nem érkezik válasz, akkor a tűzfal bontja a kapcsolatot. Vagyis a fiókirodák tűzfalai az ADSL kapcsolat hibáit a bekövetkezésüktől számított 30 másodperc múlva lekezelik. Ez az időzítés egyébként eltér a gyári beállítástól és az adott környezetre lett szabva. EgyebekA VPN rendszer – a zökkenőmentes és gyors bevezetés végett – az általa kiváltott routeres rendszer forgalomszabályozását vette át. Mivel a végberendezések tűzfalak, ezért a fiókirodák és a központok, továbbá pénzintézet hálózati rendszere és az Extranet közötti forgalom a routeres megoldásnál sokkal finomabban és sokrétűbben szabályozható. A tűzfalak – saját maguk védelme érdekében – a tétlen kapcsolatokat az adott protokollhoz tartozó idő leteltével törlik állapottábláikból. Miután erről a terminál szerver nem értesül, ezért minden, a „session timeout” után generált terminál forgalom új kapcsolatként jelentkezik mind a tűzfalon, mind a szerveren. Mivel a pénzintézetnél gyakran előfordul, hogy egy terminál kapcsolaton órákig nincs forgalom, ezért az alapértelmezett beállítások mellett a terminál szerveren sok bejegyzés keletkezett. Ennek kivédésére az RDP protokoll session timeout értékét az adott környezethez igazítottuk. A tűzfalakban beállításra került a DNS, NTP, a menedzselhetőség (SSH, HTTPS) és az eseménykezelés (SNMP, syslog, stb.).
Kisvállalat összetett védelmi rendszerének megvalósításaAz esettanulmány elkészítése folyamatban van.
|
