Cisco forgalomirányítók interfészei közötti forgalom szabályozására elterjedt módszer a hozzáférési listák (ACL-ek) használata. Számos fajtája létezik, de mindegyik tervezésekor szembesülünk azzal a ténnyel, hogy az ACL-ek direkt módon a forrás és a cél IP címekre épülnek, így ha a későbbiekben egy új címzési struktúrát kell kialakítanunk, akkor sorról sorra át kell írnunk valamennyi listát. Sokkal átgondoltabb tervezési módszert nyújt a 12.4(6)T verziójú IOS-től elérhető zóna alapú tűzfalak koncepciója, ismerkedjünk most meg ennek az alapjaival.
A zóna alapú tűzfalak tervezésekor a hálózatunkat zónákra osztjuk, és meghatározzuk, hogy ezek a zónák milyen feltételek mellett tarthatják egymással a kapcsolatot, milyen adatokat forgalmazhatnak egymás között. A tervezésüket a következő lépésekben fogjuk végrehajtani:
- Zónák kijelölése, elnevezése
- Azon interfészek meghatározása, melyekkel a zónák a tűzfalfunkciót meghatározó forgalomirányítóhoz kapcsolódnak.
- Azon zónapárok meghatározása, melyek közötti forgalmat felügyelni kell.
- Azon forgalom meghatározása, melyeket a tűzfalnak figyelnie kell. (Ezek lesznek a Class-MAP-ek.)
- Azon tevékenységek meghatározása, melyeket a megfigyelt forgalommal kell elvégezni. (Ezek lesznek a Policy MAP-ek, vagyis a házirendek.)
- A zónapárok és a Policy-MAP-ek összerendelése.
Induljunk ki a következő topológiából. Tegyük fel, hogy az IP címeket és az OSPF forgalomirányítást már konfiguráltuk. A hálózat egy klasszikus elrendezés. Egy olyan cég hálózatát modellezi, amely cégen belül a dolgozók az INSIDE zónákból érik el a cég szervereit, amelyek a SERVER zónában találhatók, illetve az internetet, melyet az OUTSIDE zóna szimulál. Az OUTSIDE zónából bizonyos feltételek esetén a cég SERVER zónában található szerverei is elérhetők. (Meg kell jegyezni, hogy az OUTSIDE zónában R5-öt tipikusan alapértelmezett átjárón keresztül kellene elérni, mely átjárót belül hirdet az OSPF, de itt most annak érdekében, hogy minél több dolgot tudjunk bemutatni, R5-öt is bevettük az OSPF irányítási területbe.)
A zónaalapú tűzfal konfigurálását az R1 forgalomirányítón végezzük. Először hozzuk létre a zónákat:
R1(config)#zone security INSIDE
R1(config)#zone security SERVER
R1(config)#zone security OUTSIDE
Mielőtt tovább haladnánk, ellenőrizzük le, hogy a forgalomirányítók elérik-e egymást. R2-ről megpingetjük R1 interfészeit, és a többi forgalomirányító mögötti hálózatokat, és R1-ről az R2 mögöttit. (Természetesen az OSPF protokoll működik.) Azt tapasztaljuk, hogy a pingek sikeresek, tehát a zónák létrehozása nem befolyásolja a hálózat működését, a forgalomirányítók elérik egymást.
R2#ping 11.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/20 ms
R2#
R2#ping 12.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/32/52 ms
R2#ping 13.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/20 ms
R2#
R1#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/36 ms
R2#ping 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/25/44 ms
R2#ping 192.168.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/30/40 ms
R2#ping 192.168.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/21/36 ms
Rendeljük most a megfelelő interfészekhez a zónákat:
R1(config-sec-zone)#int fa0/0
R1(config-if)#zone-member security INSIDE
R1(config-sec-zone)#int fa0/1
R1(config-if)#zone-member security INSIDE
R1(config-sec-zone)#int fa1/0
R1(config-if)#zone-member security SERVER
R1(config-sec-zone)#int s2/0
R1(config-if)#zone-member security OUTSIDE
Értelemszerűen egy interfész csak egy zónához rendelhető, de egy zónához több interfész is rendelhető.
Jelenítsük meg az eddigi munkák eredményét.
R1#sh zone security
zone self
Description: System defined zone
zone INSIDE
Member Interfaces:
FastEthernet0/0
FastEthernet0/1
zone OUTSIDE
Member Interfaces:
Serial2/0
zone GUEST
Member Interfaces:
FastEthernet1/0
Jól látható, hogy melyik interfész melyik zónához van rendelve. Mint láthatjuk, automatikusan létrejött egy self nevezetű biztonsági zóna, melyet a forgalomirányító saját magára értelmez. Minden olyan forgalom vizsgálható benne, melynek a forgalomirányító a forrása illetve a célja. (Ha például telnettel bejelentkezünk a forgalomirányítóra, akkor ez a forgalom a self zónába irányul, ha pedig R1-ről pingetünk kifelé, az a self zónából indul ki.) A self zóna tetszőleges forgalom számára megadható forrás és cél zónaként. A self zónához nem rendelünk manuálisan interfészeket, de a forgalomirányító valamennyi IP címmel ellátott interfésze hozzá tartozik.
Vizsgáljuk meg most az előző pingeket. Az egyértelmű, hogy a következők példákban az R2-n kiadott ping ICMP csomagok forrás IP címe minden esetben az R2 fa0/0 interfészének 10.0.0.2 címe. Most nem mindenhol az előző eredményt kapjuk.
R2#ping 11.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/20 ms
R2#ping 12.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/20 ms
R2#ping 13.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 13.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/18/24 ms
R2#ping 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/37/48 ms
R2#ping 192.168.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R2#ping 192.168.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
Az utolsó két ping most sikertelen. Ahhoz, hogy megértsük az eredményt, nézzük meg a következő ábrát, mely a zónákat, és a hozzájuk tartozó IP címeket tartalmazza.
A zóna alapú tűzfalak a szűrést akkor végzik el, amikor a forgalom az egyik zónából áthalad a másik zónába, így fontos látni pontosan, hogy az egyes forgalmak mikor melyik zónát érintik. Nézzünk pár példát. (Természetesen nem az összes IP cím kombinációt vizsgáljuk.)
- A 192.168.1.1 címről megpingetjük a 10.0.0.1 címet. Mivel a 10.0.0.1 cím az R1 forgalomirányító egyik interfészének IP címe, így ez a SELF zónához tartozik, vagyis az INSIDE zónából a SELF zónába tart a csomag.
- A 10.0.0.2 címről megpingetjük a 10.0.0.1 címet. Mivel a 10.0.0.1 cím az R1 forgalomirányító egyik interfészének IP címe, így ez a SELF zónához tartozik, vagyis az INSIDE zónából a SELF zónába tart a csomag.
- A 192.168.1.1 címről megpingetjük a 11.0.0.1 címet. Mivel a 11.0.0.1 cím az R1 forgalomirányító egyik interfészének IP címe, így ez a SELF zónához tartozik, vagyis az INSIDE zónából a SELF zónába tart a csomag.
- A 192.168.1.1 címről megpingetjük a 11.0.0.2 címet. Mivel mind a forrás, mind a cél IP cím az INSIDE zónához tartozik, így a csomag az INSIDE zónában marad.
- A 192.168.1.1 címről megpingetjük a 12.0.0.2 címet. Mivel a forrás az INSIDE zónához tartozik, a cél pedig a SERVER zónához, így a csomag az INSIDE-ból a SERVER zónába halad. Fontos, hogy nem érinti a SELF zónát! A SELF zónát csak az R1 forgalomirányító valamelyik IP címére, vagy az arról kiinduló csomagok érintik.
Ennyi példa elég is, hogy értelmezhessük a pingek eredményeit, és levonjuk a következtetéseket.
- A 10.0.0.2 címről a 11.0.0.1 címre irányuló ping sikeres, mert a két IP cím azonos zónában van. Azonos zónában haladó forgalmat alapértelmezetten nem szűri a tűzfal.
- A 10.0.0.2 címről a 12.0.0.1 és a 13.0.0.1 címekre irányuló ping sikeres, mert a csomag kiindulási zónája az INSIDE, a cél zónája a SELF, és a SELF zóna speciális tulajdonsága, hogy a hozzá tartozó IP címek elérhetők az adott forgalomirányítón definiált más zónákból.
- A 10.0.0.2 címről a 192.168.3.1 címre irányuló ping sikertelen, mert az ICMP csomagnak az INSIDE zónából a SERVER zónába kell átmennie, ez pedig alapértelmezetten tiltott. (A csomag nem érintette a SELF zónát, mert nem a SELF zónához tartozó IP cím a célja!) A különböző (nem SELF) zónák közötti forgalom tehát alapértelmezetten tiltottak a zóna alapú tűzfalnál.
- A 10.0.0.1 címről a 192.168.4.1 címre irányuló ping szinten sikertelen, mert az ICMP csomagnak az INSIDE zónából az OUTSIDE zónába kell átmennie, ez pedig az előzőek szerint alapértelmezetten tiltott.
Nézzük még egy kicsit a SELF zónát. Ez az egyetlen zóna, amelyik alapértelmezetten tagadja az összes házirendet. (Vagyis a SELF zónába irányuló, illetve az onnan érkező forgalom, tehát a forgalomirányító IP címmel ellátott interfészeinek forgalma korlátozás nélkül engedélyezett, míg explicit módon szabályokkal nem korlátozzuk. Viszont ha bármilyen olyan tűzfalszabályt megfogalmazunk, amelyben szerepel a SELF zóna, akkor a SELF zónát érintő forgalom azonnal korlátozásra kerül, tehát újabb szabályokkal kell engedélyezni azt.) A SELF zónát érintő tűzfalszabályokban az inspect műveletet (ezzel majd később foglalkozunk) nem alkalmazhatjuk. Ügyeljünk arra, hogy milyen forgalmat korlátozunk a SELF zónára. Ha például csak a telnetet engedjük meg, akkor a dinamikus útvonalválasztó protokollok útvonalfrissítéseit sem lesz képes feldolgozni a forgalomirányító.
A SELF zónán kívüli (általunk definiált) zónák a forgalomirányítón átmenő forgalom forrása és célja.
Ahogyan már említettük, a zóna alapú tűzfalak használata esetén a forgalmat akkor tudjuk vizsgálni, és végeredményben engedni vagy eldobni, amikor az egyik zónából kilépve átlépnek egy másik zónába. Tehát a forgalmat a zónahatárokon szűrjük. Alapértelmezetten a zónák közötti forgalom tiltva van, (kivéve az előbb emlétett SELF), vagyis ahhoz, hogy forgalom haladhasson a zónák között, megfelelő szabályokkal engedélyeznünk kell azt. Ahhoz, hogy továbblépjünk, definiálnunk kell azokat a zónapárokat, amelyek határain a forgalmat vizsgálni szeretnénk. Minden ilyen zónapárnak nevet adunk, mely névvel a későbbiekben hivatkozhatunk rá. Definiáljunk most 4 ilyen zónapárt:
R1(config)#zone-pair security INSIDE-TO-INSIDE source INSIDE destination INSIDE
R1(config)#zone-pair security INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE
R1(config)#zone-pair security INSIDE-TO-SERVER source INSIDE destination SERVER
R1(config)#zone-pair security OUTSIDE-TO-SERVER source OUTSIDE destination SERVER
A zónapárokat a következő ábrán is láthatjuk:
A konfigurált zónapárok le is kérdezhetők:
R1#sh zone-pair security
Zone-pair name INSIDE-TO-INSIDE
Source-Zone INSIDE Destination-Zone INSIDE
service-policy not configured
Zone-pair name INSIDE-TO-OUTSIDE
Source-Zone INSIDE Destination-Zone OUTSIDE
service-policy not configured
Zone-pair name INSIDE-TO-SERVER
Source-Zone INSIDE Destination-Zone SERVER
service-policy not configured
Zone-pair name OUTSIDE-TO-SERVER
Source-Zone OUTSIDE Destination-Zone SERVER
service-policy not configured
Ha most leellenőrizzük, már nem tudjuk R2-ről megpingetni az R3 mögötti 192.168.2.1 hálózatot. Ennek oka az, hogy létrehoztuk az INSIDE-INSIDE zónapárt, és ezzel automatikusan tiltottuk az adatforgalmat az R2 és R3 forgalomirányítók között.
R2#ping 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
A későbbiekben tehát azokat a forgalmakat szűrhetjük, amelyek az INSIDE és az OUTSIDE, az INSIDE és a SERVER, az OUTSIDE és a SERVER zónák, illetve a két INSIDE-ba tartozó forgalomirányító között között halad. Ezeket a zónapárokat mutatja a következő ábra:
A zónapárok közötti szűrést három lépésben valósítjuk meg.
- Első lépésben létrehozzuk azokat a Class-MAP-eket, amelyek a vizsgálandó forgalmat tartalmazzák. A Class-MAP-ek nem tartalmazzák azt, hogy mit kell tenni a vizsgált forgalommal.
- Második lépésben létrehozzuk azokat a Policy-MAP-eket (vagyis házirendeket), amelyek meghatározzák, hogy az egyes vizsgált forgalmakkal (vagyis Class-MAP-ekkel) mit kell tenni.
- A harmadik lépésben ezeket a Policy-MAP-eket a zónapárokhoz rendeljük.
Kezdjük is el. Tegyük fel, hogy a SERVER zónában egy WEB szervert, és egy belső levelező szervert üzemeltetünk. Az INSIDE zónából szeretnénk ezt a két szolgáltatást elérni. Az OUTSIDE zónából viszont csak a WEB szerver elérését szeretnénk engedélyezni a SERVER zónában. Azt szeretnénk, hogy az INSIDE zóna két LAN-ja (a 192.168.1.0/24 és a 192.168.2.0/24) elérje egymást. Az INSIDE zónából az OUTSIDE zónába csak a WEB és a DNS forgalmat szeretnénk engedélyezni, míg a ping forgalmát csak az INSIDE és a SERVER zóna között engedélyezzük.
Készítsük el az ilyen forgalomra illeszkedő Class-MAP-eket a class-map paranccsal. Minden Class-MAP-et névvel nevezünk el, így ha különböző zónák között ugyanazt a forgalmat szeretnénk vizsgálni, akkor csak egyszer kell az adott Class-MAP-et elkészíteni. Nézzük először az INSIDE-SERVER zónapárra alkalmazandó Class-MAP-et. (Ennek a Class-MAP-nek a nevébe most megadjuk a zónapár nevét is. Amennyibe a Class-MAP-et több zónapárra is alkalmazni szeretnénk, érdemesebb a MAP tartalmára vonatkozó nevet keresni.)
R1(config)#class-map type inspect match-any CMAP-INSIDE-TO-SERVER
R1(config-cmap)#match protocol http
R1(config-cmap)#match protocol icmp
R1(config-cmap)#match protocol pop3
R1(config-cmap)#match protocol smtp
R1(config-cmap)#match protocol imap
Vizsgáljuk meg a parancsot. A Class-MAP típusa inspect, ami lehetővé teszi, hogy a forgalmat mélyebb szinten is vizsgálhassuk. (Például ha az FTP forgalmat szeretnénk vizsgálni, akkor azt is meghatározhatjuk, hogy LIST vagy DELETE parancsot adtak ki.) A match-any kulcsszóval előírjuk, hogy a MAP illeszkedni fog, ha a benne felsorolt kritériumok valamelyike illeszkedik a forgalomra. Egy másik itt használható kulcsszó a match-all, mely azt írná elő, hogy a MAP-ben felsorolt valamennyi kritérium illeszkedjen. Itt ennek nincsen értelme (egyszerre egy protokoll nem lehet http és pop3 is), de ha például olyan IP csomagokra írunk elő illeszkedést, amelyeknél a forráscím egy meghatározott IP cím, akkor ennek a két kritériumnak (legyen IP csomag, és legyen meghatározott a cél IP cím) egyszerre kell teljesülnie, tehát akkor a match-all kulcsszót használjuk. (Egyébként alapértelmezett a match-all.) Érdemes különben lekérdezni, hogy milyen sok lehetőség van a kritériumok meghatározására:
R1(config-cmap)#match ?
access-group Access group
any Any packets
application Application to match
class-map Class map
cos IEEE 802.1Q/ISL class of service/user priority values
destination-address Destination address
discard-class Discard behavior identifier
dscp Match DSCP in IPv4 and IPv6 packets
fr-de Match on Frame-relay DE bit
fr-dlci Match on fr-dlci
input-interface Select an input interface to match
ip IP specific values
metadata Metadata to match
mpls Multi Protocol Label Switching specific values
not Negate this match result
packet Layer 3 Packet length
precedence Match Precedence in IPv4 and IPv6 packets
protocol Protocol
qos-group Qos-group
source-address Source address
vlan VLANs to match
Készítsük most el a biztonsági házirendet (Policy-MAP-et) az INSIDE-SERVER zónapárra. Ebben határozzuk meg, hogy az illeszkedő forgalommal mit tegyünk. Nézzünk meg néhány műveletet, melyek végrehajthatók az illeszkedő forgalmon (ez nem az összes):
- drop . az illeszkedő fogalom eldobásra kerül (mint az ACL-eknél a deny)
- pass – az illeszkedő forgalom elfogadásra kerül (mint az ACL-eknél a permit)
- inspect – az illeszkedő forgalom és a válaszforgalma elfogadásra kerül (mint az ACL-eknél az established)
- reset – a tűzfal egy RST üzenettel megszakítja a kapcsolatot
- log – naplózza az illeszkedő forgalmat (mint az ACL-eknél a log)
Készítsük el a házirendet az INSIDE és a SERVER zóna közötti CMAP-INSIDE-TO-SERVER forgalom szűrésére a policy-map paranccsal. A házirend neve PMAP-INSIDE-TO-SERVER lesz. A parancs használata egyértelmű. A Policy-MAP-hez hozzárendeljük a korábban elkészített Class-MAP-et, vagyis azt, hogy milyen forgalmat vizsgáljon. Az illeszkedő forgalomra pedig előírjuk az inspect műveletet, tehát engedje ki, és engedje vissza a válaszforgalmat.
R1(config)#policy-map type inspect PMAP-INSIDE-TO-SERVER
R1(config-pmap)#class type inspect CMAP-INSIDE-TO-SERVER
R1(config-pmap-c)#inspect
Az utolsó lépésként már csak az elkészített Policy-MAP-et a zónapárhoz kell rendelnünk. Ehhez belépünk a zónapárba, majd a service-policy paranccsal hozzárendeljük a házirendet.
R1(config)#zone-pair security INSIDE-TO-SERVER
R1(config-sec-zone-pair)#service-policy type inspect PMAP-INSIDE-TO-SERVER
Nézzük meg, hogy működik-e a tűzfalunk. Ehhez pingessük meg R2-ről az R4 mögötti hálózatot. Örömmel tapasztaljuk, hogy működik!
R2#ping 192.168.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/40/92 ms
A többi szolgáltatás letesztelése már egy kicsit problémásabb, hiszen a szerverszolgáltatásokat a GNS3 környezetében nem tudjuk könnyedén telepíteni. (Noha a GNS3 alkalmas arra, hogy a gépre telepített szolgáltatásokat, vagy akár valós hardverkörnyezetben kialakított szolgáltatásokat is elérjünk belőle, de ezek telepítése és konfigurálása sok időt venne igénybe. Arra is van lehetőség, hogy bizonyos szolgáltatásokat a forgalomirányítóban aktiváljunk, de akkor a kliens oldalon kellene megoldani az elérésüket.) Hívjuk segítségül a telnet protokollt és a WireShark-ot. A telnet-nek megadhatjuk, hogy melyik portra próbáljon bejelentkezni, a Wireshark-kal pedig nyomon követjük, hogy a kapcsolatot kezdeményező csomag átment-e a tűzfalon. (A célállomás természetesen egy RST/ACK-t fog visszaküldeni, hiszen a port mögött nem lesz élő szolgáltatás.) Nézzük meg például a http szolgáltatás elérését:
R2#telnet 192.168.3.1 80
Trying 192.168.3.1, 80 …
% Connection refused by remote host
És a Wireshark-kal elfogott csomagban láthatjuk, hogy a kapcsolatot kezdeményező csomag átment a tűzfalon, a válasz pedig visszajutott, hiszen a telnet egy % Connection refused by remote host üzenetet írt ki. Amennyiben a tűzfal nem engedte volna át, akkor egy időzítő letelte után a telnet a % Connection timed out; remote host not responding üzenetet írta volna ki.
Hasonlóan a többi engedélyezett szolgáltatásra is az RST választ kapjuk. (Vagyis a tűzfal ezeket is átengedi.) A portszámok helyett használhatjuk a protokollok nevét is.
R2#telnet 192.168.3.1 110
Trying 192.168.3.1, 110 …
% Connection refused by remote host
R2#telnet 192.168.3.1 143
Trying 192.168.3.1, 143 …
% Connection refused by remote host
R2#telnet 192.168.3.1 25
Trying 192.168.3.1, 25 …
% Connection refused by remote host
Ellenőrizzük le a zónapárhoz rendelt házirendet. (Ha csak a sh zone-pair security parancsot adnánk ki, valamennyi zónapárhoz rendelt házirendet látnánk.)
R1#sh zone-pair security source INSIDE destination SERVER
Zone-pair name INSIDE-TO-SERVER
Source-Zone INSIDE Destination-Zone SERVER
service-policy PMAP-INSIDE-TO-SERVER
Nézzük meg a házirendeket is. Láthatjuk, hogy egyetlen házirend van, de abban két Class-MAP. Az egyiket mi definiáltuk, a másik egy alapértelmezett, amely eldobja az összes forgalmat.
R1#sh policy-map type inspect
Policy Map type inspect PMAP-INSIDE-TO-SERVER
Class CMAP-INSIDE-TO-SERVER
Inspect
Class class-default
Drop
Jelenítsük meg a mi általunk konfigurált Class_MAP-et, látható, hogy milyen forgalomra illeszkedik.
R1#sh class-map type inspect
Class Map type inspect match-all CMAP-INSIDE-TO-SERVER (id 1)
Match protocol http
Match protocol icmp
Match protocol pop3
Match protocol smtp
Match protocol imap
Jelenítsük meg az alapértelmezett Class-MAP-et. Láthatjuk, hogy minden forgalomra illeszkedik, ezért dobja el az összes olyan forgalmat a Policy-MAP-ünk, amelyre nem illeszkedik a CMAP-INSIDE-TO-SERVER Class-MAP.
R1#show class-map class-default
Class Map match-any class-default (id 0)
Match any
Konfiguráljuk most a többi zóna közötti Class-MAP-eket és Policy-MAP-eket, valamint rendeljük azokat a zónapárokhoz:
R1(config)#class-map type inspect match-any CMAP-INSIDE-TO-OUTSIDE
R1(config-cmap)#match protocol http
R1(config-cmap)#match protocol dns
R1(config)#class-map type inspect match-any CMAP-OUTSIDE-TO-SERVER
R1(config-cmap)#match protocol http
R1(config)#policy-map type inspect PMAP-INSIDE-TO-OUTSIDE
R1(config-pmap)#class type inspect CMAP-INSIDE-TO-OUTSIDE
R1(config-pmap-c)#inspect
R1(config)#policy-map type inspect PMAP-OUTSIDE-TO-SERVER
R1(config-pmap)#class type inspect CMAP-OUTSIDE-TO-SERVER
R1(config-pmap-c)#inspect
R1(config)#policy-map type inspect PMAP-INSIDE-TO-INSIDE
R1(config-pmap)#class class-default
R1(config-pmap-c)#pass
R1(config)#zone-pair security INSIDE-TO-OUTSIDE
R1(config-sec-zone-pair)#service-policy type inspect PMAP-INSIDE-TO-OUTSIDE
R1(config)#zone-pair security OUTSIDE-TO-SERVER
R1(config-sec-zone-pair)#service-policy type inspect PMAP-OUTSIDE-TO-SERVER
R1(config)#zone-pair security INSIDE-TO-INSIDE
R1(config-sec-zone-pair)#service-policy type inspect PMAP-INSIDE-TO-INSIDE
Magyarázatra talán csak az INSIDE zónán belüli forgalom házirendje szorul. Mivel itt minden forgalmat engedélyezni szeretnénk, ezért olyan Class-MAP-re van szükség, amely minden forgalomra illeszkedik. Ez pedig pontosan a class-default, így ezt használjuk fel. (Ezért nem készítettünk CMAP-INSIDE-TO-INSIDE Class-MAP-et.)
Készen is vagyunk. Bátran próbálkozzunk a különböző protokollok próbálgatásával, a zóna alapú tűzfalunk rendületlenül szűri a forgalmat a házirendekben előírtaknak megfelelően.
A rendszer rendkívül rugalmas, hiszen ha például szeretnénk, hogy az INSIDE zónából elérhetők legyenek a SERVER zónában található levelező szerveren a levelek, de csak IMAP protokollal, akkor csupán ezzel a protokollal kell kiegészíteni a CMAP-OUTSIDE-TO-SERVER Class-MAP-et. Vagy ha szeretnénk, hogy az INSIDE zónában található 2 forgalomirányító ne érhesse el egymást, akkor csak a pass műveletet kell drop-ra cserélni a PMAP-INSIDE-TO-INSIDE házirendben.
Vegyük észre, hogy a nagy tűzfalkonfigurációnk közepette R1-et védtelenül hagytuk. Próbáljunk például betelnetelni R5-ről (OUTSIDE) R1-re, és azt látjuk, hogy a telnet forgalma eléri R1-et. (Persze a bejelentkezéshez R1-en konfigurálni is kell a telnet protokollt.) Tiltsuk le az OUTSIDE zónából az R1-re érkező mindennemű forgalmat. Ehhez R1 SELF zónája, és az OUTSIDE zóna között kell tiltó házirendet létrehoznunk:
R1(config)#zone-pair security OUTSIDE-TO-SELF source OUTSIDE destination SELF
R1(config)#policy-map type inspect PMAP-OUTSIDE-TO-SELF
R1(config-pmap)#class class-default
R1(config-pmap-c)#drop
R1(config)#zone-pair security OUTSIDE-TO-SELF
R1(config-sec-zone-pair)#service-policy type inspect PMAP-OUTSIDE-TO-SELF
Most már védve van R1, de túlságosan is, hiszen noha például nem tudunk R4-ről telnet kapcsolatot létrehozni felé, de hamar kapunk egy olyan üzenetet, hogy R1 elveszítette az OSPF szomszédságát R5-tel, és az útvonalakból el is tűnik a 192.168.4.0/24 felé vezető. Persze, hiszen a többivel együtt az OSPF üzeneteket is letiltottuk. Próbáljuk ezt a hibát helyrehozni. Olyan lehetőséget nem találunk a Class-MAP konfigurálásakor, hogy az OSPF protokollra illeszkedjen, így más megoldást kell keresni. (Itt kell megemlítenem, hogy a későbbiekben, amikor ezt a konfigurációt újra elkészítettem egy másik IOS verzióval, már lehetett OSPF protokollra illeszkedni. A cikket viszont nem írtam át, mert így legalább ez a technika is bemutatásra került.) Térjünk vissza a jó öreg ACL-ekhez. Készítsünk egy olyan nevesített kiterjesztett ACL-t, amely engedélyezi az OSPF forgalmat. (A könnyebbség kedvéért most bárhonnan bárhová engedélyezzük, úgyis csak az OUTSIDE-TO-SERVER zónapárra alkalmazzuk. Természetesen pontosítható az ACL, hogy csak R1 és R5 között engedélyezze az OSPF-et, de akkor például ugyanezt az ACL-t nem alkalmazhatjuk a többi zónapárra, ha ott is szűrni kellene. Érdemes inkább az OSPF hitelesítéssel biztosítani a biztonságot, így kevesebb címet drótozunk a konfigurációba. Erre a konfigurációra viszont nem terjed ki ez a cikk.)
R1(config)#ip access-list extended ACL_OSPF_ENABLE
R1(config-ext-nacl)#permit ospf any any
Ezután készítünk egy olyan Class-MAP-et, mely ezt az ACL-t tartalmazza. Ehhez a Class-MAP access-group alparancsát alkalmazzuk. (Ugyanezzel a paranccsal rendeltük annak idején az interfészhez az ACL-t, így könnyű megjegyezni.)
R1(config)#class-map type inspect CMAP_OSPF-ENABLE
R1(config-cmap)#match access-group name ACL_OSPF_ENABLE
Már csak a Class-MAP-et hozzá kell rendelnünk a PMAP-OUTSIDE-TO-SELF házirendhez a szokásos módon:
R1(config)#policy-map type inspect PMAP-OUTSIDE-TO-SELF
R1(config-pmap)#class type inspect CMAP_OSPF-ENABLE
Ha mindent jól csinálunk, R1 és R5 felveszi a szomszédossági kapcsolatot, és a hiányzó útvonal ismét megjelenik az irányítótáblákban.
A kiinduló gondolatunk az volt, hogy ne kelljen minden IP címet bedrótozni a tűzfal szabályokba. Ez túl jól is sikerült, hiszen egyetlen IP cím beírása nélkül sikerült konfigurálnunk a zóna alapú tűzfalunkat. Az valós feladatokban azonban szükség van IP cím alapú szűrésre. Tegyük fel például, hogy az INSIDE zónában kijelölünk egy fix IP című állomást, ahonnan engedélyezni szeretnénk R4-ra a távoli bejelentkezést telnet-tel. Legyen ez a fix forrás IP cím a 192.168.1.254. Amennyiben az OSPF engedélyezését megértettük, akkor már sejthetjük a megoldást: Létre kell hozni egy olyan ACL-t, mely ezt a forgalmat engedélyezi, utána el kell helyezni a CMAP-INSIDE-TO-SERVER Class-MAP-ben, és már működik is.
R1(config)#ip access-list extended ACL-TELNET-ENABLE
R1(config-ext-nacl)#permit tcp host 192.168.1.254 host 12.0.0.1 eq telnet
R1(config)#class-map type inspect CMAP_INSIDE-TO-SERVER
R1(config-cmap)#match access-group name ACL_TELNET_ENABLE
Ahhoz, hogy le tudjuk tesztelni a bejelentkezést, változtassuk meg R2-n az lo0 IP címét 192.168.1.254-re, és adjuk ki ezt a parancsot: (A telnet szolgáltatást persze érdemes konfigurálni R3-on.)
R2#telnet 12.0.0.2 /source-interface loopback 0
Még egy ilyen egyszerű hálózatban is terjedelmes lehet a tűzfal konfigurációja, így az átláthatóság kedvéért következetesen használjuk az elnevezéseket. A hozzáférési listákat az ACL-lel (a sorszámozottakat felejtsük el, noha lehetne azokat is használni), a Class-MAP-eket CMAP-pel, a házirendeket pedig PMAP-pel kezdtük. Ahol érdemes volt, ott a nevekben szerepeltettük, hogy melyik zónapárra vonatkoznak. Természetesen saját elnevezési szokásokat is kialakíthatunk, csak mindenképpen hatékonyan segítsék a hibakeresést.
Nézzük meg milyen show parancsokkal ellenőrizhetjük le a tűzfal állapotát. Jelenítsük meg először a hozzáférési listákat:
R1#sh access-lists
Extended IP access list ACL-OSPF-ENABLE
10 permit ospf any any
Extended IP access list ACL-TELNET-ENABLE
10 permit tcp host 192.168.1.254 host 12.0.0.2 eq telnet
Jelenítsük meg a Class-MAP-eket:
R1#sh class-map type inspect
Class Map type inspect match-all CMAP-OSPF-ENABLE (id 1)
Match access-group name ACL-OSPF-ENABLE
Class Map type inspect match-any CMAP-INSIDE-TO-INSIDE (id 2)
Match none
Class Map type inspect match-any CMAP-INSIDE-TO-SERVER (id 3)
Match protocol http
Match protocol icmp
Match protocol pop3
Match protocol smtp
Match protocol imap
Match access-group name ACL-TELNET-ENABLE
Class Map type inspect match-any CMAP-INSIDE-TO-OUTSIDE (id 4)
Match protocol http
Match protocol dns
Class Map type inspect match-any CMAP-OUTSIDE-TO-SERVER (id 5)
Match protocol http
Jelenítsük meg a házirendeket:
R1#sh policy-map type inspect
Policy Map type inspect PMAP-INSIDE-TO-SERVER
Class CMAP-INSIDE-TO-SERVER
Inspect
Class class-default
Drop
Policy Map type inspect PMAP-OUTSIDE-TO-SERVER
Class CMAP-OUTSIDE-TO-SERVER
Inspect
Class class-default
Drop
Policy Map type inspect PMAP-INSIDE-TO-OUTSIDE
Class CMAP-INSIDE-TO-OUTSIDE
Inspect
Class class-default
Drop
Policy Map type inspect PMAP-OUTSIDE-TO-SELF
Class CMAP-OSPF-ENABLE
Class class-default
Drop
Policy Map type inspect PMAP-INSIDE-TO-INSIDE
Class class-default
Pass
Végül pedig a zónapárokat:
R1#sh zone-pair security
Zone-pair name INSIDE-TO-INSIDE
Source-Zone INSIDE Destination-Zone INSIDE
service-policy PMAP-INSIDE-TO-INSIDE
Zone-pair name INSIDE-TO-OUTSIDE
Source-Zone INSIDE Destination-Zone OUTSIDE
service-policy PMAP-INSIDE-TO-OUTSIDE
Zone-pair name INSIDE-TO-SERVER
Source-Zone INSIDE Destination-Zone SERVER
service-policy PMAP-INSIDE-TO-SERVER
Zone-pair name OUTSIDE-TO-SERVER
Source-Zone OUTSIDE Destination-Zone SERVER
service-policy PMAP-OUTSIDE-TO-SERVER
Zone-pair name OUTSIDE-TO-SELF
Source-Zone OUTSIDE Destination-Zone self
service-policy PMAP-OUTSIDE-TO-SELF
A nevek következetes használata esetén elég könnyű megérteni, hogy hol, milyen tűzfalszabályok érvényesek.
Ennyi első nekifutásra talán ennyi elég is. Remélem látható, hogy a tűzfalak zóna alapú tervezésének koncepciója mennyire átgondolt, és hierarchikusan építkező megoldás hálózataink védelmének kialakításában. Noha első ránézésre talán bonyolultabbnak tűnik, mint a hagyományos hozzáférési listákkal való konfiguráció, de nagyobb hálózatokban azonnal megjelennek az előnyei, és amikor a számos konfigurációs lehetőségét is megismerjük, már nem is nagyon akarunk visszatérni a hagyományos megoldásokhoz.
