News & Blog

Zóna alapú tűzfal

News & Blog

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:

  1. Zónák kijelölése, elnevezése
  2. Azon interfészek meghatározása, melyekkel a zónák a tűzfalfunkciót meghatározó forgalomirányítóhoz kapcsolódnak.
  3. Azon zónapárok meghatározása, melyek közötti forgalmat felügyelni kell.
  4. Azon forgalom meghatározása, melyeket a tűzfalnak figyelnie kell. (Ezek lesznek a Class-MAP-ek.)
  5. Azon tevékenységek meghatározása, melyeket a megfigyelt forgalommal kell elvégezni. (Ezek lesznek a Policy MAP-ek, vagyis a házirendek.)
  6. 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. 

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük