Esettanulmány. Pénzintézet 14 telephelyének összekötése IKEv2 IPSec VPN-nel, redundáns központtal 1.1 verzió

Esettanulmány Pénzintézet 14 telephelyének összekötése IKEv2 IPSec VPN-nel, redundáns központtal 1.1 verzió 2012.11.10.

Készítette Telvice Szolgáltató és Kereskedelmi Kft. 2040 Budaörs, Szabadság út 135. Tel.: 23/889-107 Fax: 23/889-108 E-mail: [email protected] Web: http://www.telvice.hu/

Pénzintézet 14 telephelyének összekötése IKEv2 IPSec VPN-nel, redundáns központtal

2. oldal

Ü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 – e dokumentum írásakor – még folyamatban van. Feladat: pénzintézet 12 fiókirodájának és 2 központjának összekötése VPN1-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ás Internet hozzáférés A 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 Provider-ek) á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.)

1

VPN: Virtual Private Network.

Telvice Szolgáltató és Kereskedelmi Kft. 2040 Budaörs, Szabadság út 135. Tel.: 23/889-107, Fax: 23/889-108 E-mail: [email protected], Web: http://www.telvice.hu/


3. oldal

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 ADSL2-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ések Az 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 (Data Terminal Equipment, adatvég-berendezés), vagy DCE (Data Circuit-terminating Equipment, adatáramkör-végződtető berendezés) 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.

2

ADSL: Asymmetric Digital Subscriber Line.



4. oldal

Topológia A központokban lévő Internet csatlakozás 2 db 2 Mbps-os bérelt vonalát „multilink PPP3” 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.

3

PPP: Point-to-Point Protocol.



5. oldal

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



6. oldal

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ése A 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ó. Telvice Szolgáltató és Kereskedelmi Kft. 2040 Budaörs, Szabadság út 135. Tel.: 23/889-107, Fax: 23/889-108 E-mail: [email protected], Web: http://www.telvice.hu/


7. oldal

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.



8. oldal

VPN Mivel 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 L2TP4, hanem IPSec5, 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, ESP6 protokollal. Automatikus kulcs szétosztó és kezelő megoldásként a legújabb IKE7v2 protokollt használjuk, az egyszerűség végett pre-shared kulcsokkal.

4

L2TP: Layer 2 Tunneling Protocol. IPSec: IP Security. 6 ESP: Encapsulating Security Payload. 7 IKE: Internet Key Exchange protocol. 5



9. oldal

Az IKEv2 az IPSec pontok közti kulcscserének számos összetevőjét (NAT-T8, XAuth9, ISAKMP10 konfiguráció) egyetlen protokollban valósítja meg, mindamellett az előző verzió számos tulajdonságát (pl. identity hiding, PFS11, 2 fázisú SA12 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 DoS13 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:  





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 az útvonaltábla (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.

8

NAT-T: NAT-Traversal. XAuth: Extended Authentication. 10 ISAKMP: Internet Security Association and Key Management Protocol. 11 PFS: Perfect Forward Secrecy. 12 SA: Security Association. 13 DoS: Denial of Service. 9



10. oldal

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 a route tábla és az NHTB14 tábla segítségével valósítja meg.

14

NHTB: Next-Hop Tunnel Binding.



11. oldal

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



12. oldal

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 PPPoE15 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. Routing Mivel 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: RIP16v1, RIPv2, OSPF17, BGP18. 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.

15

PPPoE: Point-to-Point Protocol over Ethernet. RIP: Routing Information Protocol. 17 OSPF: Open Shortest Path First. 18 BGP: Border Gateway Protocol. 16



13. oldal

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. NAT19 A 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-src20 módszerrel van NAT-olva, kivéve a speciális hosztokat, amik MIP21-pel NAT-olódnak. Az Extranet felől a fő központban elérni kívánt egyéb szolgáltatásokat VIP22 segítségével NAT-oljuk.

19

NAT: Network Address Translation. NAT-src: Source NAT. 21 MIP: Mapped IP. 22 VIP: Virtual IP. 20



14. oldal

Az Extranet felől az egyéb telephelyeken elérni kívánt hosztokat (pl. ATM-eket) NAT-dst23 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 „DIP24 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”. PPPoE A fiókirodák tűzfalai közvetlenül ADSL modemre kapcsolódnak és PPPoE-vel, PAP25 authentikációval teremtik meg az Internet kapcsolatot. A PPPoE profile-hoz tartozó interfészük (WAN26 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 LCP27 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.

23

NAT-dst: Destination NAT. DIP: Dynamic IP. 25 PAP: Password Authentication Protocol. 26 WAN: Wide Area Network. 27 LCP: Link Control Protocol. 24



15. oldal

Egyebek A 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 RDP28 protokoll session timeout értékét az adott környezethez igazítottuk. A tűzfalakban beállításra került a DNS29, NTP30, a menedzselhetőség (SSH31, HTTPS32) és az eseménykezelés (SNMP33, syslog, stb.).

28

RDP: Remote Desktop Protocol. DNS: Domain Name System. 30 NTP: Network Time Protocol. 31 SSH: Secure Shell. 32 HTTPS: Hypertext Transfer Protocol with Secure Socket Layer (SSL) 33 SNMP: Simple Network Management Protocol. 29


Esettanulmány. Pénzintézet 14 telephelyének összekötése IKEv2 IPSec VPN-nel, redundáns központtal 1.1 verzió

Recommend Documents