Begrijp het Zone-Based Policy Firewall-ontwerp

Inleiding

Dit document beschrijft het configuratiemodel voor de Cisco IOS® Firewall feature set, Zone-based Policy Firewall (ZFW).

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Dit nieuwe configuratiemodel biedt intuïtief beleid voor routers met meerdere interfaces, een verhoogde granulariteit van firewallbeleidsapplicaties en een standaard weigeringsbeleid dat verkeer tussen firewallbeveiligingszones verbiedt totdat een expliciet beleid is toegepast om gewenst verkeer mogelijk te maken.

Bijna alle klassieke Cisco IOS Firewall-functies die zijn geïmplementeerd vóór Cisco IOS Software Release 12.4(6)T worden ondersteund in de nieuwe zone-gebaseerde interface voor beleidsinspectie:

• Stateful packet inspection

• VRF-aware Cisco IOS Firewall

• URL-filtering 

• Beperking van Denial-of-Service (DoS)

Cisco IOS Software Release 12.4(9)T voegde ZFW-ondersteuning toe voor sessie-/verbinding- en doorvoerlimieten per klasse, evenals inspectie en controle van toepassingen:

• HTTP

• Post Office Protocol (POP3), Internet Mail Access Protocol (IMAP), Simple Mail Transfer Protocol/Enhanced Simple Mail Transfer Protocol (SMTP/ESMTP)

• Sun Remote Procedure Call (RPC)

• Instant Messaging (IM)-toepassingen:

  • Microsoft Messenger

  • Yahoo! boodschapper

  • AOL Instant Messenger

• Peer-to-Peer (P2P) Bestanden delen:

  • Bittorrent

  • KaZa

  • Gnutella

  • ezel

Cisco IOS Software Release 12.4(11)T voegde statistieken toe voor een eenvoudigere DoS-afstemming.

Sommige Cisco IOS Classic Firewall-functies en -mogelijkheden worden nog niet ondersteund in een ZFW in Cisco IOS Software Release 12.4(15)T:

• Verificatieproxy

• Stateful firewall failover

• Unified firewall MIB

• Stateful IPv6-inspectie

• Out-of-order TCP-ondersteuning

ZFW verbetert over het algemeen de IOS-prestaties van Cisco voor de meeste firewall-inspectieactiviteiten. Cisco IOS ZFW en Classic Firewall bieden geen stateful inspectie-ondersteuning voor multicast-verkeer.

Zone-gebaseerd beleidsoverzicht

Cisco IOS Classic Firewall stateful inspection (voorheen bekend als Context-Based Access Control, of CBAC) maakte gebruik van een interface-gebaseerd configuratiemodel, waarin een stateful inspectiebeleid werd toegepast op een interface. Al het verkeer dat door die interface gaat, heeft hetzelfde inspectiebeleid ontvangen. Dit configuratiemodel beperkte de gedetailleerdheid van het firewallbeleid en veroorzaakte verwarring over de juiste toepassing van het firewallbeleid, met name in scenario's waarin het firewallbeleid tussen meerdere interfaces moet worden toegepast.

Zone-Based Policy Firewall (ook bekend als Zone-Policy Firewall, of ZFW) verandert de firewallconfiguratie van het oudere op interface gebaseerde model naar een flexibeler, gemakkelijker te begrijpen op zone gebaseerd model. Interfaces worden toegewezen aan zones en het inspectiebeleid wordt toegepast op verkeer dat tussen de zones beweegt. Beleid tussen zones biedt aanzienlijke flexibiliteit en granulariteit, zodat verschillende inspectiebeleidslijnen kunnen worden toegepast op meerdere hostgroepen die zijn verbonden met dezelfde routerinterface.

Firewallbeleid wordt geconfigureerd met de Cisco Policy Language (CPL), die een hiërarchische structuur gebruikt om de inspectie voor netwerkprotocollen en de groepen hosts waarop de inspectie kan worden toegepast, te definiëren.

zonegebaseerd beleidsconfiguratiemodel

ZFW verandert volledig de manier waarop u een Cisco IOS Firewall-inspectie configureert, in vergelijking met de Cisco IOS Classic Firewall.

De eerste grote verandering in de firewallconfiguratie is de introductie van een zone-gebaseerde configuratie. Cisco IOS Firewall is de eerste Cisco IOS Software threat defence-functie die een zoneconfiguratiemodel implementeert. Andere functies kunnen het zonemodel in de loop van de tijd overnemen. Cisco IOS Classic Firewall stateful inspection (of CBAC) op interface gebaseerd configuratiemodel dat gebruikmaakt van de IP inspect-opdrachtset wordt gedurende een bepaalde periode onderhouden. Er zijn echter weinig of geen nieuwe functies configureerbaar met de klassieke opdrachtregelinterface (CLI). ZFW gebruikt geen stateful inspection of CBAC-opdrachten. De twee configuratiemodellen kunnen gelijktijdig worden gebruikt op routers, maar niet gecombineerd op interfaces. Een interface kan niet worden geconfigureerd als een lid van de beveiligingszone en tegelijkertijd worden geconfigureerd voor IP-inspectie.

Zones bepalen de beveiligingsgrenzen van uw netwerk. Een zone definieert een grens waar het verkeer wordt onderworpen aan beleidsbeperkingen als het naar een andere regio van uw netwerk gaat. Het standaardbeleid van ZFW tussen zones is Alles weigeren. Als er geen beleid expliciet is geconfigureerd, wordt al het verkeer dat tussen zones wordt verplaatst, geblokkeerd. Dit is een belangrijke afwijking van het stateful inspectiemodel waarbij verkeer impliciet werd toegestaan totdat het expliciet werd geblokkeerd met een toegangscontrolelijst (ACL).

De tweede grote verandering is de introductie van een nieuwe configuratiebeleidstaal, bekend als CPL. Gebruikers die bekend zijn met de Cisco IOS Software Modular quality-of-service (QoS) CLI (MQC) kunnen herkennen dat het formaat vergelijkbaar is met het gebruik van QoS-klassenkaarten om aan te geven welk verkeer wordt beïnvloed door de actie die wordt toegepast in een beleidskaart.

Regels voor Zone-Based Policy Firewall-toepassing

Lidmaatschappen van routernetwerkinterfaces in zones zijn onderworpen aan verschillende regels die het interfacegedrag regelen, evenals het verkeer dat tussen de lidinterfaces van de zone beweegt:

• Er moet een zone worden geconfigureerd voordat interfaces aan de zone kunnen worden toegewezen.

• Een interface kan aan slechts één beveiligingszone worden toegewezen.

• Alle verkeer van en naar een bepaalde interface wordt impliciet geblokkeerd wanneer de interface aan een zone wordt toegewezen, behalve verkeer van en naar andere interfaces in dezelfde zone en verkeer naar elke interface op de router.

• Verkeer mag impliciet standaard stromen tussen interfaces die lid zijn van dezelfde zone.

• Om verkeer van en naar een zone-ledeninterface toe te staan, moet een beleid worden geconfigureerd dat verkeer tussen die zone en een andere zone toestaat of inspecteert.

• De zelfzone is de enige uitzondering op het standaard alle beleid weigeren. Al het verkeer naar elke routerinterface is toegestaan totdat het verkeer expliciet wordt geweigerd.

• Er kan geen verkeer stromen tussen een zone-lidinterface en een interface die geen zone-lid is. Acties voor doorgeven, inspecteren en neerzetten kunnen alleen tussen twee zones worden toegepast.

• Interfaces die niet aan een zone zijn toegewezen, functioneren als klassieke routerpoorten en kunnen nog steeds gebruikmaken van klassieke stateful inspection/CBAC-configuratie.

• Als het nodig is dat een interface op de doos geen deel uitmaakt van het zone-/firewallbeleid. Het kan nog steeds nodig zijn om die interface in een zone te plaatsen en een pas-all-beleid (een soort dummy-beleid) te configureren tussen die zone en elke andere zone waarnaar de verkeersstroom gewenst is.

• Uit het vorige gedrag wordt uitgelegd dat, als verkeer tussen alle interfaces in een router moet stromen, alle interfaces deel moeten uitmaken van het zonemodel (elke interface moet lid zijn van een of andere zone).

• De enige uitzondering op het vorige gedrag, ontkennen standaard aanpak is het verkeer van en naar de router, die standaard is toegestaan. Een expliciet beleid kan worden geconfigureerd om dergelijk verkeer te beperken.

Netwerkbeveiliging op basis van ontwerpzone

Er moet een beveiligingszone worden geconfigureerd voor elke regio met relatieve beveiliging binnen het netwerk, zodat alle interfaces die aan dezelfde zone zijn toegewezen, worden beschermd met een vergelijkbaar beveiligingsniveau. Denk bijvoorbeeld aan een toegangsrouter met drie interfaces:

• Eén interface verbonden met het openbare internet.

• Eén interface die is verbonden met een privé-LAN dat niet toegankelijk mag zijn via het openbare internet.

• Eén interface die is verbonden met een gedemilitariseerde zone voor internetdiensten (DMZ), waarbij een webserver, een DNS-server (Domain Name System) en een e-mailserver toegankelijk moeten zijn voor het openbare internet.

Elke interface in dit netwerk is toegewezen aan een eigen zone, hoewel u kunt kiezen voor een gevarieerde toegang vanaf het openbare internet tot specifieke hosts in de DMZ en voor een gevarieerd beleid voor het gebruik van toepassingen voor hosts in het beveiligde LAN (zie afbeelding 1).

Afbeelding 1: Basistopologie van de beveiligingszone

Basistopologie beveiligingszone

In dit voorbeeld heeft elke zone slechts één interface. Als een extra interface wordt toegevoegd aan de privézone, kunnen de hosts die zijn verbonden met de nieuwe interface in de zone verkeer doorgeven aan alle hosts op de huidige interface in dezelfde zone. Bovendien wordt het hostverkeer naar hosts in andere zones op dezelfde manier beïnvloed door het huidige beleid.

Doorgaans heeft het voorbeeldnetwerk drie hoofdbeleidslijnen:

• Private zone connectiviteit met het internet

• Private zone-connectiviteit met DMZ-hosts

• Internetzoneconnectiviteit met DMZ-hosts

Omdat de DMZ wordt blootgesteld aan het openbare internet, kunnen de DMZ-hosts worden onderworpen aan ongewenste activiteiten van kwaadwillende personen die erin slagen om een of meer DMZ-hosts te beschadigen. Als er geen toegangsbeleid is voorzien voor DMZ-hosts om privézonehosts of internetzonehosts te bereiken, kunnen de personen die de DMZ-hosts hebben gecompromitteerd, de DMZ-hosts niet gebruiken om verdere aanvallen uit te voeren tegen privé- of internethosts. ZFW legt een prohibitieve standaardbeveiligingshouding op. Tenzij de DMZ-hosts specifiek toegang krijgen tot andere netwerken, worden andere netwerken beveiligd tegen verbindingen van de DMZ-hosts. Evenzo is er geen toegang voor internethosts om toegang te krijgen tot de hosts in de privézone, zodat hosts in de privézone veilig zijn voor ongewenste toegang door internethosts.

IPSec VPN gebruiken met een op zones gebaseerde firewall voor beleidsregels

Recente verbeteringen aan IPSec VPN vereenvoudigen de configuratie van het firewallbeleid voor VPN-connectiviteit. IPSec Virtual Tunnel Interface (VTI) en GRE+IPSec maken het mogelijk om VPN-site-to-site- en clientverbindingen te beperken tot een specifieke beveiligingszone door de tunnelinterfaces in een specifieke beveiligingszone te plaatsen. Verbindingen kunnen worden geïsoleerd in een VPN DMZ als de connectiviteit moet worden beperkt door een specifiek beleid. Of, als VPN-connectiviteit impliciet wordt vertrouwd, kan VPN-connectiviteit in dezelfde beveiligingszone worden geplaatst als het vertrouwde netwerk binnen het netwerk.

Als een niet-VTI IPSec wordt toegepast, moet het firewallbeleid voor VPN-connectiviteit nauwlettend worden gecontroleerd om de beveiliging te handhaven. Het zonebeleid moet specifiek toegang via een IP-adres mogelijk maken voor externe site-hosts of VPN-clients als beveiligde hosts zich in een andere zone bevinden dan de VPN-client gecodeerde verbinding met de router. Als het toegangsbeleid niet goed is geconfigureerd, kunnen hosts die moeten worden beveiligd, worden blootgesteld aan ongewenste, mogelijk vijandige hosts. Zie VPN gebruiken met Zone-Based Policy Firewall voor meer concept- en configuratiebesprekingen.

Configuratie Cisco Policy Language (CPL)

Deze procedure kan worden gebruikt om een ZFW te configureren. De volgorde van stappen is niet belangrijk, maar sommige gebeurtenissen moeten in volgorde worden voltooid. U moet bijvoorbeeld een klassentoewijzing configureren voordat u een klassentoewijzing toewijst aan een beleidstoewijzing. Evenzo kunt u geen beleidskaart toewijzen aan een zonepaar totdat u het beleid hebt geconfigureerd. Als u probeert een sectie te configureren die afhankelijk is van een ander deel van de configuratie dat u niet hebt geconfigureerd, reageert de router met een foutbericht.

1. Definieer zones.

2. Definieer zone-paren.

3. Definieer klassenkaarten die verkeer beschrijven waarvoor beleid moet worden toegepast wanneer het een zone-paar overschrijdt.

4. Definieer beleidskaarten om actie toe te passen op uw klassenverkeer.

5. Pas beleidskaarten toe op zoneparen.

6. Wijs interfaces toe aan zones.

Klassiekaarten voor op zones gebaseerde beleidsfirewall configureren

Class-maps definiëren het verkeer dat de firewall selecteert voor de toepassing van het beleid. Layer 4 class-maps sorteren het verkeer op basis van deze criteria die hier worden vermeld. Deze criteria worden gespecificeerd met de opdracht Match in een klassentoewijzing:

• Toegangsgroep — Een standaard, uitgebreide of benoemde ACL kan verkeer filteren op basis van het IP-adres van de bron en bestemming en de bron- en bestemmingspoort.

• Protocol — De Layer 4-protocollen (TCP, UDP en ICMP) en toepassingsservices zoals HTTP, SMTP, DNS, enzovoort. Elke bekende of door de gebruiker gedefinieerde service die bekend is bij Port-Application Mapping, kan worden opgegeven.

• Klasse-map — Een ondergeschikte klasse-map die aanvullende matchcriteria biedt, kan worden genest in een andere klasse-map.

• Niet — Het criterium geeft niet aan dat verkeer dat niet overeenkomt met een opgegeven service (protocol), toegangsgroep of ondergeschikte klassentoewijzing is geselecteerd voor de klassentoewijzing.

Combineer wedstrijdcriteria: Match-Any versus Match-All

Class-maps kunnen match-any of match-all operators toepassen om te bepalen hoe de matchcriteria moeten worden toegepast. Als match-any is opgegeven, moet het verkeer alleen voldoen aan een van de overeenkomende criteria in de klassenkaart. Als match-all is opgegeven, moet het verkeer voldoen aan alle klassecriteria om tot die specifieke klasse te behoren.

Wedstrijdcriteria moeten worden toegepast om van specifieker naar minder specifiek te zijn als het verkeer aan meerdere criteria voldoet. Denk bijvoorbeeld aan deze class-map:

class-map type inspect match-any my-test-cmap
 match protocol http
 match protocol tcp

HTTP-verkeer moet eerst het overeenkomende protocol http tegenkomen om ervoor te zorgen dat het verkeer wordt afgehandeld door de servicespecifieke mogelijkheden van HTTP-inspectie. Als de overeenkomende regels worden omgekeerd, zodat het verkeer de overeenkomende TCP-instructie tegenkomt voordat deze wordt vergeleken met http-protocol, wordt het verkeer eenvoudig geclassificeerd als TCP-verkeer en geïnspecteerd op basis van de mogelijkheden van de TCP-inspectiecomponent van Firewall. Dit is een probleem voor bepaalde diensten zoals FTP, TFTP en verschillende multimedia- en spraaksignaleringsdiensten zoals H.323, SIP, Skinny, RTSP en anderen. Deze diensten vereisen extra inspectiecapaciteiten om de meer complexe activiteiten van deze diensten te herkennen.

Een ACL toepassen als matchcriteria

Class-maps kunnen een ACL toepassen als een van de matchcriteria voor beleidstoepassing. Als een class-map alleen overeenkomt met een ACL-criterium en de class-map is gekoppeld aan een policy-map die de inspectieactie toepast, past de router basis TCP- of UDP-inspectie toe voor al het verkeer dat is toegestaan door de ACL, behalve dat waarvoor ZFW toepassingsbewuste inspectie biedt. Dit omvat (maar is niet beperkt tot) FTP, SIP, Skinny (SCCP), H.323, Sun RPC en TFTP. Als toepassingsspecifieke inspectie beschikbaar is en de ACL het primaire of controlekanaal toestaat, is elk secundair of mediakanaal dat is gekoppeld aan de primaire / controlekanaal toegestaan, ongeacht of de ACL het verkeer toestaat.

Als een klasse-map alleen ACL 101 als matchcriteria toepast, wordt een ACL 101 als volgt weergegeven:

access-list 101 permit ip any any

Al het verkeer is toegestaan in de richting van het servicebeleid dat op een bepaald zonepaar wordt toegepast, en het retourverkeer dat hiermee overeenkomt, is toegestaan in de tegenovergestelde richting. Daarom moet de ACL de beperking toepassen om het verkeer te beperken tot specifieke gewenste typen. De PAM-lijst bevat toepassingsservices zoals HTTP, NetBIOS, H.323 en DNS. Ondanks de kennis van PAM over het specifieke toepassingsgebruik van een bepaalde poort, past de firewall echter alleen voldoende toepassingsspecifieke mogelijkheden toe om tegemoet te komen aan de bekende vereisten van het toepassingsverkeer. Eenvoudig applicatieverkeer zoals telnet, SSH en andere single-channel applicaties worden dus geïnspecteerd als TCP en hun statistieken worden gecombineerd in de show command output. Als toepassingsspecifieke zichtbaarheid in netwerkactiviteiten gewenst is, moet u de inspectieservices configureren op basis van de naam van de toepassing (overeenkomend protocol HTTP configureren, overeenkomend protocol telnet, enzovoort).

Vergelijk de statistieken die beschikbaar zijn in de uitvoer van de opdracht voor het weergeven van het type beleidskaart, inspecteer zone-pair, met het explicietere firewallbeleid dat verderop op de pagina wordt weergegeven. Deze configuratie wordt gebruikt om verkeer van een Cisco IP Phone te inspecteren, evenals verschillende werkstations die een verscheidenheid aan verkeer gebruiken, waaronder HTTP, FTP, NetBIOS, SSH en DNS:

class-map type inspect match-all all-private
 match access-group 101
!         
policy-map type inspect priv-pub-pmap
 class type inspect all-private
  inspect
 class class-default
!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect priv-pub-pmap
! 
interface FastEthernet4
 ip address 172.16.108.44 255.255.255.0
 zone-member security public
!
interface Vlan1
 ip address 192.168.108.1 255.255.255.0
 zone-member security private
!
access-list 101 permit ip 192.168.108.0 0.0.0.255 any

Hoewel deze configuratie eenvoudig te definiëren is en geschikt is voor al het verkeer dat afkomstig is uit de privézone (zolang het verkeer de standaard, PAM-erkende bestemmingspoorten in acht neemt), biedt deze beperkte zichtbaarheid in de serviceactiviteit en biedt deze niet de mogelijkheid om de bandbreedte- en sessielimieten van ZFW toe te passen voor specifieke soorten verkeer. Deze uitvoer van het type beleidskaart inspect zone-pair priv-pub-opdracht is het resultaat van de vorige eenvoudige configuratie die alleen een vergunning IP [subnet] gebruikt voor elke ACL tussen zone-paren. Zoals u kunt zien, wordt het grootste deel van het werkstationverkeer geteld in de basis TCP- of UDP-statistieken:

stg-871-L#show policy-map type insp zone-pair priv-pub
Zone-pair: priv-pub
 
  Service-policy inspect : priv-pub-pmap
 
    Class-map: all-private (match-all)
      Match: access-group 101
      Inspect
        Packet inspection statistics [process switch:fast switch]
        tcp packets: [413:51589]
        udp packets: [74:28]
        icmp packets: [0:8]
        ftp packets: [23:0]
        tftp packets: [3:0]
        tftp-data packets: [6:28]
        skinny packets: [238:0]
 
        Session creations since subsystem startup or last reset 39
        Current session counts (estab/half-open/terminating) [3:0:0]
        Maxever session counts (estab/half-open/terminating) [3:4:1]
        Last session created 00:00:20
        Last statistic reset never
        Last session creation rate 2
        Maxever session creation rate 7
        Last half-open session total 0
 
    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        0 packets, 0 bytes

Een vergelijkbare configuratie die toepassingsspecifieke klassen toevoegt, biedt daarentegen meer gedetailleerde toepassingsstatistieken en -besturing en biedt nog steeds dezelfde breedte van services die in het eerste voorbeeld werd weergegeven wanneer u de klassentoewijzing voor de laatste kans definieert die alleen overeenkomt met de ACL als de laatste kans in de beleidskaart:

class-map type inspect match-all all-private
 match access-group 101
class-map type inspect match-all private-ftp
 match protocol ftp
 match access-group 101
class-map type inspect match-any netbios
 match protocol msrpc
 match protocol netbios-dgm
 match protocol netbios-ns
 match protocol netbios-ssn
class-map type inspect match-all private-netbios
 match class-map netbios
 match access-group 101
class-map type inspect match-all private-ssh
 match protocol ssh
 match access-group 101
class-map type inspect match-all private-http
 match protocol http
 match access-group 101
!
policy-map type inspect priv-pub-pmap
 class type inspect private-http
  inspect
 class type inspect private-ftp
  inspect
 class type inspect private-ssh
  inspect
 class type inspect private-netbios
  inspect
 class type inspect all-private
  inspect
 class class-default!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect priv-pub-pmap
! 
interface FastEthernet4
 ip address 172.16.108.44 255.255.255.0
 zone-member security public
!
interface Vlan1
 ip address 192.168.108.1 255.255.255.0
 zone-member security private
!
access-list 101 permit ip 192.168.108.0 0.0.0.255 any

De meer specifieke configuratie biedt deze substantiële granulaire uitvoer voor de opdracht show policy-map type inspect zone-pair priv-pub:

stg-871-L#sh policy-map type insp zone-pair priv-pub
 Zone-pair: priv-pub

   Service-policy inspect : priv-pub-pmap

     Class-map: private-http (match-all)
       Match: protocol http
       Match: access-group 101
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [0:2193]

         Session creations since subsystem startup or last reset 731
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [0:3:0]
         Last session created 00:29:25
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 4
         Last half-open session total 0

     Class-map: private-ftp (match-all)
       Match: protocol ftp
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [86:167400]
         ftp packets: [43:0]

         Session creations since subsystem startup or last reset 7
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [2:1:1]
         Last session created 00:42:49
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 4
         Last half-open session total 0

     Class-map: private-ssh (match-all)
       Match: protocol ssh
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [0:62]

         Session creations since subsystem startup or last reset 4
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [1:1:1]
         Last session created 00:34:18
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 2
         Last half-open session total 0

     Class-map: private-netbios (match-all)
       Match: access-group 101
       Match: class-map match-any netbios
         Match: protocol msrpc
           0 packets, 0 bytes
           30 second rate 0 bps
         Match: protocol netbios-dgm
           0 packets, 0 bytes
           30 second rate 0 bps
         Match: protocol netbios-ns
           0 packets, 0 bytes
           30 second rate 0 bps
         Match: protocol netbios-ssn
           2 packets, 56 bytes
           30 second rate 0 bps
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [0:236]
 
         Session creations since subsystem startup or last reset 2
         Current session counts (estab/half-open/terminating) [0:0:0]
         Maxever session counts (estab/half-open/terminating) [1:1:1]
         Last session created 00:31:32
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 1
         Last half-open session total 0

     Class-map: all-private (match-all)
       Match: access-group 101
       Inspect
         Packet inspection statistics [process switch:fast switch]
         tcp packets: [51725:158156]
         udp packets: [8800:70]
         tftp packets: [8:0]
         tftp-data packets: [15:70]
         skinny packets: [33791:0]

         Session creations since subsystem startup or last reset 2759
         Current session counts (estab/half-open/terminating) [2:0:0]
         Maxever session counts (estab/half-open/terminating) [2:6:1]
         Last session created 00:22:21
         Last statistic reset never
         Last session creation rate 0
         Maxever session creation rate 12
         Last half-open session total 0
 
     Class-map: class-default (match-any)
       Match: any 
       Drop (default action)
         4 packets, 112 bytes

Een ander bijkomend voordeel bij het gebruik van een meer gedetailleerde class-map en policy-map configuratie, zoals eerder vermeld, is een mogelijkheid om klassenspecifieke limieten toe te passen op sessie- en snelheidswaarden; en, om inspectieparameters specifiek aan te passen door de toepassing van een parameter-map om elk klasseninspectiegedrag aan te passen.

Firewallbeleidskaarten op basis van zones configureren

De policy-map past firewallbeleidsacties toe op een of meer class-maps om het servicebeleid te definiëren dat wordt toegepast op een beveiligingszonepaar. Wanneer een beleidskaart van het type inspect wordt gemaakt, wordt aan het einde van de klasse een standaardklasse met de naam class-default toegepast. De standaardactie voor het klassestandaardbeleid is drop, maar kan worden gewijzigd in pass. De logoptie kan worden toegevoegd met de actie neerzetten. Inspect kan niet worden toegepast op klasse-standaard.

Zone-gebaseerde beleidsfirewallacties

ZFW biedt drie acties voor verkeer dat van de ene zone naar de andere gaat:

• Drop — Dit is de standaardactie voor al het verkeer, zoals toegepast door de klasse-standaard die elke inspect-type policy-map beëindigt. Andere klassenkaarten binnen een beleidskaart kunnen ook worden geconfigureerd om ongewenst verkeer te laten vallen. Verkeer dat wordt afgehandeld door de drop-actie wordt stilletjes weggelaten (dat wil zeggen, er wordt geen melding van de drop verzonden naar de relevante end-host) door de ZFW, in tegenstelling tot een ACL-gedrag wanneer het een ICMP-host onbereikbaar bericht stuurt naar de host die het geweigerde verkeer heeft verzonden. Op dit moment is er geen optie om het stille dropgedrag te wijzigen. De logoptie kan worden toegevoegd met drop voor syslog-melding dat het verkeer is weggevallen door de firewall.

• Pass — Met deze actie kan de router het verkeer van de ene zone naar de andere doorsturen. Met de actie Pass wordt de status van verbindingen of sessies in het verkeer niet gevolgd. De pas staat het verkeer slechts in één richting toe. Er moet een parallel beleid worden gevoerd om het terugkeerverkeer in de tegenovergestelde richting te laten passeren. De pasactie is handig voor protocollen zoals IPSec ESP, IPSec AH, ISAKMP en andere inherent veilige protocollen met voorspelbaar gedrag. Het meeste applicatieverkeer wordt echter beter afgehandeld in de ZFW met de inspectieactie.

• Inspecteren — De inspectieactie biedt verkeerscontrole op basis van de staat. Als bijvoorbeeld het verkeer van de privézone naar de internetzone in het eerdere voorbeeldnetwerk wordt geïnspecteerd, behoudt de router de verbinding- of sessiegegevens voor TCP- en UDP-verkeer (User Datagram Protocol). Daarom staat de router retourverkeer toe dat wordt verzonden door hosts in de internetzone als antwoord op verzoeken om een verbinding met een privézone. Inspect kan ook toepassingsinspectie en -controle bieden voor bepaalde serviceprotocollen die kwetsbaar of gevoelig toepassingsverkeer kunnen vervoeren. Audit-trail kan worden toegepast met een parameter-map om verbinding/sessie start, stop, duur, het overgedragen datavolume en bron- en bestemmingsadressen op te nemen.

Acties worden geassocieerd met class-maps in policy-maps:

configure terminal
 policy-map type inspect z1-z2-pmap
  class type inspect service-cmap
   inspect|drop|allow [service-parameter-map]

Parameter-maps bieden opties voor het wijzigen van de verbindingsparameters voor een bepaald inspectiebeleid voor klassetoewijzingen.

Parameterkaarten voor zone-beleid configureren

Parameter-maps specificeren inspectiegedrag voor ZFW, voor parameters zoals DoS-beveiliging, TCP-verbinding/UDP-sessietimers en registratie van audittrails. Parameter-maps worden ook toegepast met klasse Layer 7 en beleidskaarten om toepassingsspecifiek gedrag te definiëren, zoals HTTP-objecten, POP3- en IMAP-verificatievereisten en andere toepassingsspecifieke informatie.

Inspectieparameterkaarten voor ZFW worden geconfigureerd als type inspect, vergelijkbaar met andere ZFW-klasse- en beleidsobjecten:

stg-871-L(config)#parameter-map type inspect z1-z2-pmap 
stg-871-L(config-profile)#?
parameter-map commands:
  alert           Turn on/off alert
  audit-trail     Turn on/off audit trail
  dns-timeout     Specify timeout for DNS
  exit            Exit from parameter-map
  icmp            Config timeout values for icmp
  max-incomplete  Specify maximum number of incomplete connections before
                  clamping
  no              Negate or set default values of a command
  one-minute      Specify one-minute-sample watermarks for clamping
  sessions        Maximum number of inspect sessions
  tcp             Config timeout values for tcp connections
  udp             Config timeout values for udp flows

Specifieke typen parameterkaarten specificeren parameters die worden toegepast door Layer 7-toepassingsinspectiebeleid. Regex-type parameter-maps definiëren een reguliere expressie voor gebruik met HTTP-toepassingsinspectie die verkeer filtert met een reguliere expressie:

parameter-map type regex [parameter-map-name]

Protocol-info-type parameter-maps definiëren servernamen voor gebruik met IM-toepassingsinspectie:

parameter-map type protocol-info [parameter-map-name]

Volledige configuratiedetails voor HTTP- en IM-toepassingsinspectie zijn te vinden in de respectievelijke secties voor toepassingsinspectie in dit document.

Logboekregistratie toepassen voor firewallbeleid op basis van zones

ZFW biedt logboekopties voor verkeer dat standaard wordt gedropt of geïnspecteerd of voor geconfigureerde firewallbeleidsacties. Audit-trail logging is beschikbaar voor verkeer dat de ZFW inspecteert. Audit-trail wordt toegepast wanneer een audit-trail is gedefinieerd in een parameter-map en de parameter-map met de inspectieactie wordt toegepast in een policy-map:

configure terminal
 policy-map type inspect z1-z2-pmap
  class type inspect service-cmap
   inspect|drop|allow [parameter-map-name (optional)]

Drop-logging is beschikbaar voor verkeer dat de ZFW laat vallen. Drop-logging wordt geconfigureerd door wanneer u een log toevoegt met de dropactie in een policy-map:

configure terminal
 policy-map type inspect z1-z2-pmap
  class type inspect service-cmap
   inspect|drop|allow [service-parameter-map]

Zone-Policy Firewall Class-Maps en Policy-Maps bewerken

ZFW bevat momenteel geen editor die de verschillende ZFW-structuren zoals policy-maps, class-maps en parameter-maps kan wijzigen. Om overeenkomende statements in een class-map of actie-applicatie te herschikken naar verschillende class-maps die deel uitmaken van een policy-map, moet u de volgende stappen uitvoeren:

1. Kopieer de huidige structuur naar een teksteditor zoals Microsoft Windows Notepad of een editor zoals vi op Linux / Unix-platforms.

2. Verwijder de huidige structuur uit de routerconfiguratie.

3. Bewerk de structuur in de teksteditor.

4. Kopieer de structuur terug naar de router CLI.

Configuratievoorbeelden

Dit configuratievoorbeeld maakt gebruik van een Cisco 1811 Integrated Services Router. Een basisconfiguratie met IP-connectiviteit, VLAN-configuratie en transparante bridging tussen twee privé Ethernet LAN-segmenten is beschikbaar in Bijlage A. De router is onderverdeeld in vijf zones:

• Het openbare internet is verbonden met FastEthernet 0 (internetzone)

• Twee internetservers zijn verbonden met FastEthernet 1 (DMZ-zone)

• De Ethernet-switch is geconfigureerd met twee VLAN's:

  • Werkstations zijn aangesloten op VLAN1 (clientzone).

  • Servers zijn verbonden met VLAN2 (serverzone).

  • De client- en serverzones bevinden zich in hetzelfde subnet. Tussen de zones wordt een transparante firewall toegepast, zodat het interzonebeleid op die twee interfaces alleen van invloed kan zijn op het verkeer tussen de client- en serverzones.

• De VLAN1- en VLAN2-interfaces communiceren met andere netwerken via de virtuele bruginterface (BVI1). Deze interface wordt toegewezen aan de privézone. (Zie figuur 2.)

Afbeelding 2: Detail van de topologie van de zone

Zone-topologiedetail

Deze beleidsregels worden toegepast, waarbij de netwerkzones eerder zijn gedefinieerd:

• Hosts in de internetzone kunnen DNS-, SMTP- en SSH-services bereiken op één server in de DMZ. De andere server biedt SMTP-, HTTP- en HTTPS-services. Het firewallbeleid beperkt de toegang tot de specifieke services die op elke host beschikbaar zijn.

• De DMZ-hosts kunnen geen verbinding maken met hosts in een andere zone.

• Hosts in de clientzone kunnen verbinding maken met hosts in de serverzone op alle TCP-, UDP- en ICMP-services.

• Hosts in de serverzone kunnen geen verbinding maken met hosts in de clientzone, behalve dat een op UNIX gebaseerde toepassingsserver X Windows-cliensessies kan openen naar X Windows-servers op desktop-pc's in de clientzone op poorten 6900 tot 6910.

• Alle hosts in de privézone (combinatie van clients en servers) hebben toegang tot hosts in de DMZ op SSH-, FTP-, POP-, IMAP-, ESMTP- en HTTP-services en in de internetzone op HTTP-, HTTPS- en DNS-services en ICMP. Bovendien wordt applicatie-inspectie toegepast op HTTP-verbindingen van de privézone naar de internetzone om ervoor te zorgen dat ondersteunde IM- en P2P-toepassingen niet worden uitgevoerd op poort 80. (Zie afbeelding 3.)

Afbeelding 3: Zone-Pair-servicemachtigingen die moeten worden toegepast in het configuratievoorbeeld

Zone-Pair-servicemachtigingen die moeten worden toegepast in het configuratievoorbeeld

Deze firewallbeleidsregels zijn geconfigureerd in volgorde van complexiteit:

1. TCP/UDP/ICMP-inspectie van clients en servers

2. Private-DMZ SSH/FTP/POP/IMAP/ESMTP/HTTP-inspectie

3. Internet-DMZ SMTP/HTTP/DNS-inspectie beperkt door hostadres

4. Servers-Clients X Windows-inspectie met een voor Port-Application Mapping (PAM) gespecificeerde service

5. Private-Internet HTTP/HTTPS/DNS/ICMP met HTTP-toepassingsinspectie

Omdat u delen van de configuratie op verschillende netwerksegmenten op verschillende tijdstippen toepast, is het belangrijk om te onthouden dat een netwerksegment de connectiviteit met andere segmenten verliest wanneer het in een zone wordt geplaatst. Wanneer de privézone is geconfigureerd, verliezen hosts in de privézone bijvoorbeeld de connectiviteit met de DMZ- en internetzones totdat hun respectieve beleidsregels zijn gedefinieerd.

Stateful Inspection Routing Firewall

Privaat internetbeleid configureren

De afbeelding 4 illustreert de configuratie van het privé-internetbeleid.

Afbeelding 4: Service-inspectie van privézone naar internetzone

Service inspectie van privé zone naar internetzone

Het privé-internetbeleid past Layer 4-inspectie toe op HTTP-, HTTPS-, DNS- en Layer 4-inspectie voor ICMP van de privézone naar de internetzone. Dit maakt verbindingen mogelijk van de privézone naar de internetzone en maakt het retourverkeer mogelijk. Layer 7-inspectie biedt de voordelen van een strakkere toepassingscontrole, betere beveiliging en ondersteuning voor toepassingen die reparatie vereisen. Layer 7-inspectie vereist echter een beter begrip van netwerkactiviteit, omdat Layer 7-protocollen die niet zijn geconfigureerd voor inspectie, niet zijn toegestaan tussen zones.

1. Definieer klassenkaarten die het verkeer beschrijven dat u tussen zones wilt toestaan, op basis van het beleid dat eerder is beschreven:

   configure terminal
    class-map type inspect match-any internet-traffic-class
     match protocol http
     match protocol https
     match protocol dns
     match protocol icmp

2. Configureer een beleidskaart om verkeer te inspecteren op de klassenkaarten die u zojuist hebt gedefinieerd:

   configure terminal
    policy-map type inspect private-internet-policy
     class type inspect internet-traffic-class
      inspect

3. Configureer de privé- en internetzones en wijs routerinterfaces toe aan hun respectieve zones:

   configure terminal
    zone security private
    zone security internet
    int bvi1            
     zone-member security private
    int fastethernet 0
     zone-member security internet

Configureer het zone-paar en pas de juiste beleidskaart toe.

Opmerking: u hoeft alleen het private internetzonepaar te configureren om verbindingen te inspecteren die zijn afkomstig uit de private zone die naar de internetzone reist, zoals hieronder weergegeven:

configure terminal
 zone-pair security private-internet source private destination internet
  service-policy type inspect private-internet-policy

Hiermee wordt de configuratie van het Layer 7-inspectiebeleid voor het private internetzonepaar voltooid, zodat HTTP-, HTTPS-, DNS- en ICMP-verbindingen vanuit de clientzone naar de serverzone kunnen worden uitgevoerd en toepassingsinspectie op HTTP-verkeer kan worden toegepast om ervoor te zorgen dat ongewenst verkeer geen TCP 80, de servicepoort van HTTP, mag doorgeven.

Privaat DMZ-beleid configureren

De afbeelding 5 illustreert de configuratie van het private DMZ-beleid.

Afbeelding 5: Servicecontrole van privézone naar DMZ-zone

Service inspectie van privé zone naar DMZ zone

Het private DMZ-beleid voegt complexiteit toe omdat het een beter begrip van het netwerkverkeer tussen zones vereist. Dit beleid is van toepassing op Layer 7-inspectie vanuit de privézone naar de DMZ. Dit maakt verbindingen mogelijk van de privézone naar de DMZ en maakt het retourverkeer mogelijk. Layer 7-inspectie biedt de voordelen van een strakkere toepassingscontrole, betere beveiliging en ondersteuning voor toepassingen die reparatie vereisen. Layer 7-inspectie vereist echter een beter begrip van netwerkactiviteit, omdat Layer 7-protocollen die niet zijn geconfigureerd voor inspectie, niet zijn toegestaan tussen zones.

1. Definieer klassenkaarten die het verkeer beschrijven dat u tussen zones wilt toestaan, op basis van het beleid dat eerder is beschreven:

   configure terminal
    class-map type inspect match-any L7-inspect-class
     match protocol ssh
     match protocol ftp
     match protocol pop
     match protocol imap
     match protocol esmtp
     match protocol http

2. Configureer beleidskaarten om verkeer te inspecteren op de klassenkaarten die u zojuist hebt gedefinieerd:

   configure terminal
    policy-map type inspect private-dmz-policy
     class type inspect L7-inspect-class
      inspect

3. Configureer de privé- en DMZ-zones en wijs routerinterfaces toe aan hun respectieve zones:

   configure terminal
    zone security private
    zone security dmz
    int bvi1            
     zone-member security private
    int fastethernet 1
     zone-member security dmz

4. Configureer het zone-paar en pas de juiste beleidskaart toe.

Opmerking: u hoeft alleen het private DMZ-zonepaar te configureren om verbindingen te inspecteren die zijn afkomstig uit de private zone die naar de DMZ reist, zoals hieronder weergegeven:

configure terminal
 zone-pair security private-dmz source private destination dmz
  service-policy type inspect private-dmz-policy

Hiermee wordt de configuratie van het Layer 7-inspectiebeleid op de particuliere DMZ voltooid, zodat alle TCP-, UDP- en ICMP-verbindingen van de clientzone naar de serverzone kunnen worden uitgevoerd. Het beleid is niet van toepassing op de correctie voor ondergeschikte kanalen, maar biedt een voorbeeld van eenvoudig beleid voor de meeste toepassingsverbindingen.

Internet DMZ-beleid configureren

De afbeelding 6 illustreert de configuratie van het Internet DMZ beleid.

Afbeelding 6: Servicecontrole van internetzone naar DMZ-zone

Service inspectie van Internet Zone naar DMZ Zone

Dit beleid is van toepassing op Layer 7-inspectie vanuit de internetzone naar de DMZ. Hierdoor kunnen verbindingen van de internetzone naar de DMZ worden gemaakt en kan verkeer van de DMZ-hosts worden geretourneerd naar de internethosts die de verbinding hebben gemaakt. Het Internet DMZ-beleid combineert Layer 7-inspectie met adresgroepen die door ACL's zijn gedefinieerd om de toegang tot specifieke services op specifieke hosts, groepen hosts of subnetten te beperken. Om dit te bereiken nesten een klasse-map die diensten binnen een andere klasse-map die verwijst naar een ACL om IP-adressen op te geven geeft.

1. Definieer klassenkaarten en ACL's die het verkeer beschrijven dat u tussen zones wilt toestaan, op basis van het beleid dat eerder is beschreven.

   Er moeten meerdere klassenkaarten voor services worden gebruikt, omdat er verschillende toegangsbeleidsregels worden toegepast voor toegang tot twee verschillende servers. Internethosts zijn toegestaan DNS- en HTTP-verbindingen met 172.16.2.2 en SMTP-verbindingen zijn toegestaan met 172.16.2.3. Merk het verschil op in de klassenkaarten. De class-maps die services specificeren, gebruiken het gereserveerde woord match-any om een van de vermelde services toe te staan. De klassenkaarten die ACL's koppelen aan de service class-maps gebruiken het trefwoord match-all om te vereisen dat aan beide voorwaarden in de klassenkaart moet worden voldaan om verkeer mogelijk te maken:

   configure terminal
    access-list 110 permit ip any host 172.16.2.2
    access-list 111 permit ip any host 172.16.2.3
    class-map type inspect match-any dns-http-class
     match protocol dns
     match protocol http
    class-map type inspect match-any smtp-class
     match protocol smtp
    class-map type inspect match-all dns-http-acl-class
     match access-group 110
     match class-map dns-http-class
    class-map type inspect match-all smtp-acl-class
     match access-group 111
     match class-map smtp-class

2. Configureer beleidskaarten om verkeer te inspecteren op de klassenkaarten die u zojuist hebt gedefinieerd:

   configure terminal
    policy-map type inspect internet-dmz-policy
     class type inspect dns-http-acl-class
      inspect
     class type inspect smtp-acl-class
      inspect

3. Configureer de internet- en DMZ-zones en wijs routerinterfaces toe aan hun respectieve zones. Sla de DMZ-configuratie over als u deze in de vorige sectie hebt ingesteld:

   configure terminal
   zone security internet
   zone security dmz
   int fastethernet 0            
    zone-member security internet
   int fastethernet 1
    zone-member security dmz

4. Configureer het zone-paar en pas de juiste beleidskaart toe.

   Opmerking: U hoeft op dit moment alleen het Internet DMZ-zonepaar te configureren om verbindingen te inspecteren die zijn afkomstig uit de internetzone die naar de DMZ-zone reist, zoals hieronder wordt weergegeven:

   configure terminal
    zone-pair security internet-dmz source internet destination dmz
     service-policy type inspect internet-dmz-policy

   Hiermee wordt de configuratie van het adresspecifieke Layer 7-inspectiebeleid op het Internet DMZ-zonepaar voltooid.

Stateful Inspection Transparent Firewall

Servers-clientbeleid configureren

Deze volgende afbeelding illustreert de configuratie van het server-clientbeleid.

Afbeelding 7: Servicecontrole van serverzone naar clientzone

Servicecontrole van serverzone naar clientzone

Het beleid voor servers en clients is van toepassing op inspectie met een door de gebruiker gedefinieerde service. Layer 7-inspectie wordt toegepast van de serverzone naar de clientzone. Hierdoor kunnen Windows X-verbindingen worden gemaakt met een specifiek poortbereik van de serverzone tot de clientzone en kan het retourverkeer worden uitgevoerd. X Windows is geen native-ondersteund protocol in PAM, dus een door de gebruiker geconfigureerde service in PAM moet worden gedefinieerd, zodat de ZFW het juiste verkeer kan herkennen en inspecteren.

Twee of meer routerinterfaces zijn geconfigureerd in een IEEE bridge-group om Integrated Routing and Bridging (IRB) te bieden om overbrugging tussen de interfaces in de bridge-group te bieden en om via de Bridge Virtual Interface (BVI) naar andere subnetten te routeren. Het transparante firewallbeleid is van toepassing op firewall-inspectie voor verkeer dat de brug oversteekt, maar niet voor verkeer dat de bruggroep via de BVI verlaat. Het inspectiebeleid is alleen van toepassing op verkeer dat de bruggroep oversteekt. Daarom wordt de inspectie in dit scenario alleen toegepast op verkeer dat zich verplaatst tussen de clients- en serverzones, die zich binnen de privézone bevinden. Het beleid dat wordt toegepast tussen de private zone, en de publieke en DMZ zones, komt alleen in het spel wanneer het verkeer de brug-groep verlaat via de BVI. Wanneer het verkeer via de BVI vanuit de clients- of serverzones vertrekt, wordt het transparante firewallbeleid niet aangeroepen.

1. PAM configureren met een door de gebruiker gedefinieerde vermelding voor Windows X.

   X Windows-clients (waar toepassingen worden gehost) openen verbindingen voor het weergeven van informatie aan clients (waar de gebruiker werkt) in een bereik dat begint bij poort 6900.

   Elke extra verbinding maakt gebruik van opeenvolgende poorten, dus als een client 10 verschillende sessies op één host weergeeft, gebruikt de server poorten 6900-6909. Als u daarom het poortbereik van 6900 tot 6909 inspecteert, mislukken verbindingen die zijn geopend naar poorten buiten 6909:

   configure terminal
    ip port-map user-Xwindows port tcp from 6900 to 6910

2. Controleer PAM-documenten om aanvullende PAM-vragen te beantwoorden of controleer gedetailleerde documentatie voor protocolinspectie voor informatie over de details van de interoperabiliteit tussen PAM en Cisco IOS Firewall stateful inspection.

3. Definieer klassenkaarten die het verkeer beschrijven dat u tussen zones wilt toestaan, op basis van het beleid dat eerder is beschreven:

   configure terminal
    class-map type inspect match-any Xwindows-class
     match protocol user-Xwindows

4. Configureer beleidskaarten om verkeer te inspecteren op de klassenkaarten die u zojuist hebt gedefinieerd:

   configure terminal
    policy-map type inspect servers-clients-policy
     class type inspect Xwindows-class
      inspect

5. Configureer de client- en serverzones en wijs routerinterfaces toe aan hun respectieve zones.

   Als u deze zones en toegewezen interfaces hebt geconfigureerd in het gedeelte Client-Servers Policy Configuration (Beleidsconfiguratie clients-servers), kunt u overstappen naar de definitie van het zonepaar. De IRB-configuratie is beschikbaar voor volledigheid:

   configure terminal
   bridge irb
   bridge 1 protocol ieee
   bridge 1 route ip
   zone security clients
   zone security servers
    int vlan 1
    bridge-group 1
    zone-member security clients
   int vlan 2
    bridge-group 1
    zone-member security servers

6. Configureer het zone-paar en pas de juiste beleidskaart toe.

   Opmerking: u hoeft alleen het zonepaar van de servers en clients te configureren om verbindingen te inspecteren die afkomstig zijn uit de serverzone die naar de clientzone gaat, zoals hieronder wordt weergegeven:

   configure terminal
    zone-pair security servers-clients source servers destination clients
     service-policy type inspect servers-clients-policy

   Hiermee wordt de configuratie van het door de gebruiker gedefinieerde inspectiebeleid in het zonepaar servers-clients voltooid, zodat X Windows-verbindingen van de serverzone naar de clientzone mogelijk zijn.

Beleid voor clients-servers configureren

Afbeelding 8 illustreert de configuratie van het client-serverbeleid.

Afbeelding 8: Servicecontrole van clientzone naar serverzone

Servicecontrole van clientzone naar serverzone

Het client-serverbeleid is minder complex dan de andere. Layer 4-inspectie wordt toegepast van de clientzone naar de serverzone. Dit maakt verbindingen mogelijk van de clientzone naar de serverzone en maakt retourverkeer mogelijk. Layer 4-inspectie heeft het voordeel van eenvoud in de firewallconfiguratie, in die zin dat er slechts een paar regels nodig zijn om het meeste toepassingsverkeer mogelijk te maken. De Layer 4-inspectie heeft echter ook twee grote nadelen:

• Toepassingen zoals FTP of mediadiensten onderhandelen vaak over een extra ondergeschikt kanaal van de server naar de client. Deze functionaliteit wordt meestal ondergebracht in een service-fix-up die het dialoogvenster van het besturingskanaal bewaakt en het ondergeschikte kanaal toestaat. Deze mogelijkheid is niet beschikbaar in Layer 4-inspectie.

• Layer 4-inspectie maakt bijna al het verkeer op de toepassingslaag mogelijk. Als het gebruik van het netwerk moet worden gecontroleerd, zodat slechts een paar toepassingen zijn toegestaan via de firewall, moet een ACL worden geconfigureerd op uitgaande verkeer om de services te beperken die zijn toegestaan via de firewall.

Beide routerinterfaces zijn geconfigureerd in een IEEE-bridgegroep, dus dit firewallbeleid past transparante firewallinspectie toe. Dit beleid wordt toegepast op twee interfaces in een IEEE IP-bruggroep. Het inspectiebeleid is alleen van toepassing op verkeer dat de bruggroep overschrijdt. Dit verklaart waarom de clients en serverzones binnen de privézone zijn genest.

1. Definieer klassenkaarten die het verkeer beschrijven dat u tussen zones wilt toestaan, op basis van het beleid dat eerder is beschreven:

   configure terminal
    class-map type inspect match-any L4-inspect-class
    match protocol tcp
    match protocol udp
    match protocol icmp

2. Configureer beleidskaarten om verkeer te inspecteren op de klassenkaarten die u zojuist hebt gedefinieerd:

   configure terminal
    policy-map type inspect clients-servers-policy
    class type inspect L4-inspect-class
     inspect

3. Configureer de clients- en serverzones en wijs routerinterfaces toe aan hun respectieve zones:

   configure terminal
    zone security clients
    zone security servers
    interface vlan 1            
     zone-member security clients
    interface vlan 2
     zone-member security servers

4. Configureer het zone-paar en pas de juiste beleidskaart toe.

   Opmerking: u hoeft momenteel alleen het zonepaar clients-servers te configureren om verbindingen te inspecteren die afkomstig zijn uit de clientzone die naar de serverzone gaat, zoals hieronder wordt weergegeven:

   configure terminal
    zone-pair security clients-servers source clients destination servers
     service-policy type inspect clients-servers-policy

   Hiermee wordt de configuratie van het Layer 4-inspectiebeleid voor het zonepaar clients-servers voltooid, zodat alle TCP-, UDP- en ICMP-verbindingen van de clientzone naar de serverzone mogelijk zijn. Het beleid is niet van toepassing op correctie voor ondergeschikte kanalen, maar biedt een voorbeeld van eenvoudig beleid voor de meeste toepassingsverbindingen.

Tariefbeleid voor zone-gebaseerde beleidsfirewall

Datanetwerken profiteren vaak van de mogelijkheid om de transmissiesnelheid van specifieke soorten netwerkverkeer te beperken en de impact van verkeer met lagere prioriteit te beperken tot meer zakelijk essentieel verkeer. Cisco IOS-software biedt deze mogelijkheid met verkeerspolitie, die de nominale verkeersintensiteit en burst beperkt. Cisco IOS Software ondersteunt sinds Cisco IOS Release 12.1(5)T het toezicht op het verkeer.

Cisco IOS Software Release 12.4(9)T breidt ZFW uit met snelheidsbeperking wanneer u de mogelijkheid toevoegt aan politieverkeer dat overeenkomt met de definities van een specifieke klassenkaart terwijl het de firewall van de ene beveiligingszone naar de andere doorkruist. Dit biedt het gemak van één configuratiepunt om specifiek verkeer te beschrijven, firewallbeleid toe te passen en het verbruik van verkeersbandbreedte te bewaken. ZFW verschilt van interface-gebaseerd in dat het alleen de acties biedt voor het verzenden van beleidsconformiteit en drop voor beleidsovertreding. ZFW kan geen verkeer markeren voor DSCP.

ZFW kan alleen bandbreedtegebruik in bytes/seconde opgeven, pakket/seconde en bandbreedtepercentage worden niet aangeboden. ZFW kan worden toegepast met of zonder interface-gebaseerd. Als er dus extra mogelijkheden nodig zijn, kunnen deze functies worden toegepast op basis van een interface. Als interface-gebaseerd wordt gebruikt in combinatie met firewall, moet u ervoor zorgen dat het beleid niet conflicteert.

ZFW-beleid configureren

ZFW-beleid beperkt het verkeer in een klassentoewijzing voor beleidskaarten tot een door de gebruiker gedefinieerde snelheidswaarde tussen 8.000 en 2.000.000.000 bits per seconde, met een configureerbare burstwaarde in het bereik van 1.000 tot 512.000.000 bytes.

ZFW-policing wordt geconfigureerd door een extra regel van configuratie in de policy-map, die wordt toegepast na de beleidsactie:

policy-map type inspect private-allowed-policy
 class type inspect http-class
  inspect
  police rate [bps rate value <8000-2000000000>] burst [value in bytes <1000-512000000>]

sessiecontrole

ZFW-beleid introduceerde ook sessiecontrole om het aantal sessies voor verkeer te beperken in een beleidskaart die van toepassing is en overeenkomt met een klassentoewijzing. Dit draagt bij aan de huidige mogelijkheid om DoS-beveiligingsbeleid per klassentoewijzing toe te passen. In feite maakt dit gedetailleerde controle mogelijk over het aantal sessies dat van toepassing is en dat overeenkomt met een gegeven klassentoewijzing die een zone-paar kruist. Als dezelfde klassentoewijzing wordt gebruikt op meerdere beleidskaarten of zoneparen, kunnen verschillende sessielimieten worden toegepast op de verschillende klassenmaptoepassingen.

Sessiecontrole wordt toegepast wanneer een parameter-map wordt geconfigureerd die het gewenste sessievolume bevat, waarna de parameter-map wordt toegevoegd aan de inspectieactie die onder een beleidskaart op een klassentoewijzing wordt toegepast:

parameter-map type inspect my-parameters
 sessions maximum [1-2147483647]

policy-map type inspect private-allowed-policy
 class type inspect http-class
  inspect my-parameters

Parameter-maps kunnen alleen worden toegepast op de inspectieactie en zijn niet beschikbaar op pass- of dropacties.

ZFW-sessiecontrole- en politieactiviteiten zijn zichtbaar met deze opdracht:

show policy-map type inspect zone-pair

Toepassingsinspectie

Toepassingsinspectie introduceert extra mogelijkheden voor ZFW. Toepassingsinspectiebeleid wordt toegepast op laag 7 van het OSI-model, waar gebruikerstoepassingen berichten verzenden en ontvangen waarmee de toepassingen nuttige mogelijkheden kunnen bieden. Sommige toepassingen kunnen ongewenste of kwetsbare mogelijkheden bieden, dus de berichten die aan deze mogelijkheden zijn gekoppeld, moeten worden gefilterd om activiteiten op de toepassingsservices te beperken.

Cisco IOS Software ZFW biedt applicatie-inspectie en controle op deze applicatieservices:

• HTTP

• SMTP

• POP3

• IMAP

• Sun RPC

• P2P-toepassingsverkeer

• IM-toepassingen

Toepassingsinspectie en -controle (AIC) varieert in capaciteit per service. HTTP-inspectie biedt granulaire filtering op verschillende soorten toepassingsactiviteiten en biedt mogelijkheden om de overdrachtsomvang, de lengte van het webadres en de browseractiviteit te beperken om naleving van de normen voor toepassingsgedrag af te dwingen en om soorten inhoud te beperken die over de service worden overgedragen. AIC voor SMTP kan de lengte van de inhoud beperken en naleving van het protocol afdwingen. POP3- en IMAP-inspectie kunnen ervoor zorgen dat gebruikers veilige verificatiemechanismen gebruiken om te voorkomen dat gebruikersreferenties in het gedrang komen.

Toepassingsinspectie wordt geconfigureerd als een extra set toepassingsspecifieke klassenkaarten en beleidskaarten, die vervolgens worden toegepast op de huidige inspectieklassenkaarten en beleidskaarten wanneer u het toepassingsservicebeleid in de inspectiebeleidskaart definieert.

HTTP-toepassingsinspectie

Toepassingsinspectie kan worden toegepast op HTTP-verkeer om ongewenst gebruik van HTTP-servicepoort te controleren voor andere toepassingen zoals IM, P2P-bestandsdeling en tunneltoepassingen die anders firewalltoepassingen kunnen omleiden via TCP 80.

Configureer een klassentoewijzing voor toepassingsinspectie om verkeer te beschrijven dat het toegestane HTTP-verkeer schendt:

! configure the actions that are not permitted
class-map type inspect http match-any http-aic-cmap
 match request port-misuse any
 match req-resp protocol-violation 
! define actions to be applied to unwanted traffic
policy-map type inspect http http-aic-pmap
 class type insp http http-aic-cmap
  reset
  log
! define class-map for stateful http inspection
class-map type inspect match-any http-cmap
 match protocol http
! define class-map for stateful inspection for other traffic
class-map type inspect match-any other-traffic-cmap
 match protocol smtp
 match protocol dns
 match protocol ftp
! define policy-map, associate class-maps and actions
policy-map type inspect priv-pub-pmap
 class type inspect http-cmap
  inspect
  service-policy http http-aic-pmap
 class type inspect other-traffic-cmap
  inspect

Verbeteringen in HTTP-toepassingsinspectie

Cisco IOS Software Release 12.4(9)T introduceert verbeteringen aan de ZFW HTTP-inspectiemogelijkheden. Cisco IOS Firewall introduceerde HTTP Application Inspection in Cisco IOS Software Release 12.3(14)T. Cisco IOS Software Release 12.4(9)T vergroot de huidige mogelijkheden wanneer u toevoegt:

• Mogelijkheid om verzoeken en antwoorden toe te staan, te weigeren en te bewaken op basis van de naam van de header en de waarden van de header. Dit is handig om verzoeken en antwoorden te blokkeren die kwetsbare kopvelden bevatten.

• Mogelijkheid om de grootte van verschillende elementen in de HTTP-verzoek- en antwoordkoppen te beperken, zoals maximale URL-lengte, maximale koplengte, maximaal aantal koppen, maximale koplijnlengte, enzovoort.

• Mogelijkheid om verzoeken en antwoorden te blokkeren die meerdere headers van hetzelfde type bevatten; bijvoorbeeld een verzoek met twee headers met inhoudslengte.

• Mogelijkheid om verzoeken en antwoorden te blokkeren met niet-ASCII-headers. Dit is handig om verschillende aanvallen te voorkomen die binaire en andere niet-ASCII-tekens gebruiken om wormen en andere schadelijke inhoud aan webservers te leveren.

• Mogelijkheid om HTTP-methoden te groeperen in door de gebruiker gespecificeerde categorieën en flexibiliteit om elk van de groepen te blokkeren / toestaan / bewaken wordt aangeboden. De HTTP RFC staat een beperkte set HTTP-methoden toe. Sommige standaardmethoden worden als onveilig beschouwd omdat ze kunnen worden gebruikt om kwetsbaarheden op een webserver te misbruiken. Veel van de niet-standaard methoden hebben een slechte beveiliging record.

• Methode om specifieke URI's te blokkeren op basis van een door de gebruiker geconfigureerde reguliere expressie. Deze functie geeft een gebruiker de mogelijkheid om aangepaste URI en query's te blokkeren.

• Mogelijkheid om headertypen te vervalsen (met name het type serverheader) met door de gebruiker aanpasbare tekenreeksen. Dit is handig in een geval waarin een aanvaller de reacties van de webserver analyseert en zoveel mogelijk informatie leert, en vervolgens een aanval uitvoert die zwakke punten in die specifieke webserver exploiteert.

• Mogelijkheid om een HTTP-verbinding te blokkeren of een waarschuwing te geven als een of meer HTTP-parameterwaarden overeenkomen met waarden die de gebruiker als reguliere expressie heeft ingevoerd. Enkele van de mogelijke HTTP-waardecontexten zijn header, body, gebruikersnaam, wachtwoord, user agent, verzoekregel, statusregel en gedecodeerde CGI-variabelen.

Configuratievoorbeelden voor verbeteringen in HTTP-toepassingsinspectie gaan uit van een eenvoudig netwerk, zoals weergegeven in afbeelding 9.

Afbeelding 9: Toepassingsinspectie veronderstelt een eenvoudig netwerk

Toepassingsinspectie veronderstelt een eenvoudig netwerk

De firewall groepeert het verkeer in twee klassen:

1. HTTP-verkeer
2. Al het andere single-channel TCP-, UDP- en ICMP-verkeer

HTTP is gescheiden om specifieke inspectie van webverkeer mogelijk te maken. Hiermee kunt u in het eerste gedeelte van dit document de controle configureren en in het tweede gedeelte de HTTP Application Inspection. U kunt specifieke klassenkaarten en beleidskaarten configureren voor P2P- en IM-verkeer in het derde deel van dit document. Connectiviteit is toegestaan van de privézone naar de openbare zone. Er wordt geen connectiviteit aangeboden van de openbare zone naar de privézone.

Zie Bijlage C voor een volledige configuratie die het initiële beleid implementeert.

Verbeteringen voor HTTP-toepassingsinspectie configureren

HTTP Application Inspection (evenals andere applicatie-inspectiebeleidsregels) vereist een complexere configuratie dan de standaard Layer 4-configuratie. U moet Layer 7-verkeersclassificatie en -beleid configureren om specifiek verkeer te herkennen dat u wilt beheren en om de gewenste actie toe te passen op gewenst en ongewenst verkeer.

HTTP Application Inspection (vergelijkbaar met andere soorten Application Inspection) kan alleen worden toegepast op HTTP-verkeer. U moet dus Layer 7-klassenkaarten en beleidskaarten definiëren voor specifiek HTTP-verkeer, vervolgens een Layer-4-klassenkaart specifiek voor HTTP definiëren en het Layer-7-beleid toepassen op HTTP-inspectie in een Layer-4-beleidskaart, zoals:

!configure the layer-7 traffic characteristics:
class-map type inspect http match-any http-l7-cmap
 match  req-resp protocol-violation
 match  request body length gt 4096
!
!configure the action to be applied to the traffic 
!matching the specific characteristics:
policy-map type inspect http http-l7-pmap
 class type inspect http http-l7-cmap
  reset
  log 
!
!define the layer-4 inspection policy
class-map type inspect match-all http-l4-cmap
 match protocol http
!
!associate layer-4 class and layer-7 policy-map
!in the layer-4 policy-map:
policy-map type inspect private-allowed-policy
 class type inspect http-l4-cmap
  inspect
  service-policy http http-l7-pmap

Al deze HTTP Application Inspection-verkeerskenmerken zijn gedefinieerd in een Layer 7-klassekaart:

• De opdracht Header Inspection biedt de mogelijkheid om verzoeken of antwoorden waarvan de header overeenkomt met de geconfigureerde reguliere expressie toe te staan/te weigeren/te bewaken. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

  APPFW-6-HTTP_HDR_REGEX_MATCHED

  Opdrachtgebruik:

match {request|response|req-resp} header regex <parameter-map-name>

Voorbeelden van gebruiksscenario's

• Configureer een http appfw-beleid om verzoeken of antwoorden te blokkeren waarvan de header niet-ASCII-tekens bevat.

parameter-map type regex non_ascii_regex
   pattern “[^\x00-\x80]”
class-map type inspect http non_ascii_cm
   match req-resp header regex non_ascii_regex
policy-map type inspect http non_ascii_pm
   class type inspect http non_ascii_cm
      reset

Controle van de lengte van de koptekst — Met deze opdracht wordt de lengte van een verzoek- of antwoordkoptekst gecontroleerd en wordt actie uitgevoerd als de lengte de geconfigureerde drempelwaarde overschrijdt. Actie is toegestaan of opnieuw ingesteld. Toevoeging van de logactie veroorzaakt een syslog-bericht:

APPFW-4- HTTP_HEADER_LENGTH

Opdrachtgebruik:

match {request|response|req-resp} header length gt <bytes>

Voorbeelden van gebruiksscenario's

Configureer een http appfw-beleid om verzoeken en antwoorden met een header lengte van meer dan 4096 bytes te blokkeren.

class-map type inspect http hdr_len_cm
   match req-resp header length gt 4096

policy-map type inspect http hdr_len_pm
   class type inspect http hdr_len_cm
      reset

Controle van het aantal kopregels — Met deze opdracht wordt het aantal kopregels (velden) in een verzoek/antwoord gecontroleerd en wordt actie uitgevoerd wanneer het aantal de geconfigureerde drempelwaarde overschrijdt. Actie is toegestaan of opnieuw ingesteld. Toevoeging van de logactie veroorzaakt een syslog-bericht:

APPFW-6- HTTP_HEADER_COUNT

Opdrachtgebruik:

match {request|response|req-resp} header count gt <number>

Voorbeelden van gebruiksscenario's

Configureer een http appfw-beleid om een aanvraag met meer dan 16 kopvelden te blokkeren.

class-map type inspect http hdr_cnt_cm
   match request header count gt 16

policy-map type inspect http hdr_cnt_pm
   class type inspect http hdr_cnt_cm
      reset

Header field inspection — Deze opdracht biedt de mogelijkheid om verzoeken/antwoorden die een specifiek HTTP header veld en waarde bevatten, toe te staan/te weigeren/te controleren. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. De toevoeging van de logboekactie veroorzaakt een syslog-bericht:

APPFW-6- HTTP_HDR_FIELD_REGEX_MATCHED

Opdrachtgebruik:

match {request|response|req-resp} header <header-name>

Voorbeelden van gebruiksscenario's

Configureer een HTTP-toepassingsinspectiebeleid om spyware/adware te blokkeren:

parameter-map type regex ref_regex
   pattern “\.delfinproject\.com”
   pattern “\.looksmart\.com”

parameter-map type regex host_regex
   pattern “secure\.keenvalue\.com”
   pattern “\.looksmart\.com”

parameter-map type regex usragnt_regex
   pattern “Peer Points Manager”

class-map type inspect http spy_adwr_cm
   match request header refer regex ref_regex 
   match request header host regex host_regex
   match request header user-agent regex usragnt_regex

policy-map type inspect http spy_adwr_pm
   class type inspect http spy_adwr_cm
      reset

Inspectie van veldlengte van koptekst — Deze opdracht biedt de mogelijkheid om de lengte van een veldregel voor koptekst te beperken. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. De toevoeging van de logboekactie veroorzaakt een syslog-bericht:

APPFW-6- HTTP_HDR_FIELD_LENGTH

Opdrachtgebruik:

match {request|response|req-resp} header <header-name> length gt <bytes>

Voorbeelden van gebruiksscenario's

Configureer een http-appfw-beleid om een verzoek te blokkeren waarvan de veldlengte van de cookie en de user-agent respectievelijk meer dan 256 en 128 bedraagt.

class-map type inspect http hdrline_len_cm
   match request header cookie length gt 256
   match request header user-agnet length gt 128

policy-map type inspect http hdrline_len_pm
   class type inspect http hdrline_len_cm
      reset

Inspectie van de herhaling van het koptekstveld — Met deze opdracht wordt gecontroleerd of een verzoek of antwoord koptekstvelden heeft herhaald. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Als deze optie is ingeschakeld, wordt een syslog-bericht weergegeven:

APPFW-6- HTTP_REPEATED_HDR_FIELDS

Opdrachtgebruik:

match {request|response|req-resp} header <header-name>

Voorbeelden van gebruiksscenario's

Configureer een http appfw-beleid om een verzoek of antwoord met meerdere kopregels voor de lengte van de inhoud te blokkeren. Dit is een van de meest nuttige functies die wordt gebruikt om sessiesmokkel te voorkomen.

class-map type inspect http multi_occrns_cm
   match req-resp header content-length count gt 1

policy-map type inspect http multi_occrns_pm
   class type inspect http multi_occrns_cm
      reset

• Methode-inspectie — De HTTP RFC maakt een beperkte set HTTP-methoden mogelijk. Echter, zelfs sommige van de standaardmethoden worden als onveilig beschouwd, omdat sommige methoden kunnen worden gebruikt om kwetsbaarheden op een webserver te misbruiken. Veel van de niet-standaard methoden worden vaak gebruikt voor kwaadaardige activiteiten. Dit vereist een noodzaak om de methoden in verschillende categorieën te groeperen en de gebruiker de actie voor elke categorie te laten kiezen. Deze opdracht biedt de gebruiker een flexibele manier om de methoden in verschillende categorieën te groeperen, zoals veilige methoden, onveilige methoden, webdav-methoden, RFC-methoden en uitgebreide methoden. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

APPFW-6-HTTP_METHOD

Opdrachtgebruik:

match request method <method>

Voorbeelden van gebruiksscenario's

Configureer een http appfw-beleid dat de HTTP-methoden in drie categorieën groepeert: veilig, onveilig en webdav. Deze worden weergegeven in de volgende tabel. Configureer acties zoals:

• Alle veilige methoden zijn toegestaan zonder log.

• Alle onveilige methoden zijn toegestaan met log.

• Alle webdav-methoden worden geblokkeerd met log.

http policy:

class-map type inspect http safe_methods_cm
   match request method get
   match request method head
   match request method option
   
class-map type inspect http unsafe_methods_cm
   match request method post
   match request method put
   match request method connect
   match request method trace

class-map type inspect http webdav_methods_cm
   match request method bcopy
   match request method bdelete
   match request method bmove

policy-map type inspect http methods_pm
   class type inspect http safe_methods_cm
      allow
   class type inspect http unsafe_methods_cm
      allow log
      class type inspect http webdav_methods_cm
      reset log

URI-inspectie — Deze opdracht biedt de mogelijkheid om verzoeken waarvan de URI overeenkomt met de geconfigureerde regelmatige inspectie toe te staan/te weigeren/te bewaken. Dit geeft de gebruiker de mogelijkheid om aangepaste URL's en query's te blokkeren. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

APPFW-6- HTTP_URI_REGEX_MATCHED

Opdrachtgebruik:

match request uri regex <parameter-map-name>

Voorbeelden van gebruiksscenario's

Configureer een http appfw-beleid om een verzoek te blokkeren waarvan de URI overeenkomt met een van deze reguliere expressies:

• .*cmd.exe 

• .*sex 

• .*gokken  

parameter-map type regex uri_regex_cm
   pattern “.*cmd.exe”
   pattern “.*sex”
   pattern “.*gambling”

class-map type inspect http uri_check_cm
   match request uri regex uri_regex_cm

policy-map type inspect http uri_check_pm
   class type inspect http uri_check_cm
      reset

• URI-lengteinspectie — Deze opdracht verifieert de lengte van de URI die in een verzoek wordt verzonden en past de geconfigureerde actie toe wanneer de lengte de geconfigureerde drempel overschrijdt. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

  APPFW-6- HTTP_URI_LENGTH

  Opdrachtgebruik:

  match request uri length gt <bytes>

  Voorbeelden van gebruiksscenario's

Configureer een http appfw-beleid om een alarm te starten wanneer de URI-lengte van een verzoek meer dan 3076 bytes bedraagt.

class-map type inspect http uri_len_cm
   match request uri length gt 3076

policy-map type inspect http uri_len_pm
   class type inspect http uri_len_cm
      log

Argument inspectie — Deze opdracht biedt de mogelijkheid om aanvragen toe te staan, te weigeren of te controleren waarvan de argumenten (parameters) overeenkomen met de geconfigureerde reguliere inspectie. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

APPFW-6- HTTP_ARG_REGEX_MATCHED

Opdrachtgebruik:

match request arg regex <parameter-map-name>

Configureer een http appfw-beleid om een verzoek te blokkeren waarvan de argumenten overeenkomen met een van deze reguliere expressies:

• .*gecodeerd 

• .* aanval 

parameter-map type regex arg_regex_cm
   pattern “.*codered”
   pattern “.*attack”

class-map type inspect http arg_check_cm
   match request arg regex arg_regex_cm

policy-map type inspect http arg_check_pm
   class type inspect http arg_check_cm
      reset

• Controle van de argumentlengte — Met deze opdracht wordt de lengte van de argumenten die in een verzoek worden verzonden geverifieerd en wordt de geconfigureerde actie toegepast wanneer de lengte de geconfigureerde drempelwaarde overschrijdt. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

  APPFW-6- HTTP_ARG_LENGTH

  Opdrachtgebruik:

  match request arg length gt <bytes>

  Voorbeelden van gebruiksscenario's

Configureer een http appfw-beleid om een alarm te starten wanneer de argumentlengte van een verzoek meer dan 512 bytes bedraagt.

class-map type inspect http arg_len_cm
   match request arg length gt 512

policy-map type inspect http arg_len_pm
   class type inspect http arg_len_cm
      log

• Lichaamsinspectie — Met deze CLI kan de gebruiker een lijst met reguliere expressies opgeven die moeten worden afgestemd op de hoofdtekst van het verzoek of antwoord. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

  APPFW-6- HTTP_BODY_REGEX_MATCHED

  Opdrachtgebruik:

  match {request|response|reg-resp} body regex <parameter-map-name>

  Voorbeelden van gebruiksscenario's

Configureer een http appfw om een respons te blokkeren waarvan de body het patroon bevat .*[Aa][Tt][Tt][Aa][Cc][Kk]

parameter-map type regex body_regex
   pattern “.*[Aa][Tt][Tt][Aa][Cc][Kk]”

class-map type inspect http body_match_cm
   match response body regex body_regex

policy-map type inspect http body_match_pm
   class type inspect http body_match_cm
      reset

Lichaamsinspectie (inhoud) - Met deze opdracht wordt de grootte van het bericht geverifieerd dat via verzoek of reactie wordt verzonden. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

APPFW-4- HTTP_CONTENT_LENGTH

Opdrachtgebruik:

match {request|response|req-resp} body length lt <bytes> gt <bytes>

Voorbeelden van gebruiksscenario's

Configureer een http appfw-beleid om een http-sessie te blokkeren die meer dan 10K-bytes bevat in een verzoek of antwoord.

class-map type inspect http cont_len_cm
   match req-resp header content-length gt 10240

policy-map type inspect http cont_len_pm
   class type inspect http cont_len_cm
      reset

Statuslijninspectie — Met de opdracht kan de gebruiker een lijst met reguliere expressies opgeven die moeten worden vergeleken met de statusregel van een antwoord. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

APPFW-6-HTTP_STLINE_REGEX_MATCHED

Opdrachtgebruik:

match response status-line regex <class-map-name>

Voorbeelden van gebruiksscenario's

Configureer een http-appfw om een alarm te registreren wanneer een poging wordt gedaan om toegang te krijgen tot een verboden pagina. Een verboden pagina bevat meestal een 403-statuscode en de statusregel ziet eruit als HTTP / 1.0 403 page forbidden\r\n.

parameter-map type regex status_line_regex
   pattern “[Hh][Tt][Tt][Pp][/][0-9][.][0-9][ \t]+403”

class-map type inspect http status_line_cm
   match response status-line regex status_line_regex

policy-map type inspect http status_line_pm
   class type inspect http status_line_cm
      log

• Inhoudstype inspectie — Met deze opdracht wordt gecontroleerd of het inhoudstype van de berichtkop in de lijst met ondersteunde inhoudstypen staat. Het controleert ook of het inhoudstype van de header overeenkomt met de inhoud van de berichtgegevens of het entiteitslichaamsgedeelte. Als de keyword mismatch is geconfigureerd, verifieert de opdracht het inhoudstype van het antwoordbericht aan de hand van de geaccepteerde veldwaarde van het aanvraagbericht. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logboekactie veroorzaakt het juiste syslog-bericht:

  APPFW-4- HTTP_CONT_TYPE_VIOLATION 
  APPFW-4- HTTP_CONT_TYPE_MISMATCH
  APPFW-4- HTTP_CONT_TYPE_UNKNOWN

  Opdrachtgebruik:

  match {request|response|req-resp} header content-type [mismatch|unknown|violation]

  Voorbeelden van gebruiksscenario's

  Configureer een http appfw-beleid om een http-sessie te blokkeren die verzoeken en antwoorden bevat met een onbekend inhoudstype.

  class-map type inspect http cont_type_cm
     match req-resp header content-type unknown
  
  policy-map type inspect http cont_type_pm
     class type inspect http cont_type_cm
        reset

Inspectie van misbruik van poorten — Deze opdracht wordt gebruikt om te voorkomen dat de http-poort (80) wordt misbruikt voor andere toepassingen zoals IM, P2P, Tunneling, enzovoort. Actie voor toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat voldoet aan de criteria voor klassentoewijzing. Toevoeging van de logboekactie veroorzaakt het juiste syslog-bericht:

APPFW-4- HTTP_PORT_MISUSE_TYPE_IM
APPFW-4-HTTP_PORT_MISUSE_TYPE_P2P
APPFW-4-HTTP_PORT_MISUSE_TYPE_TUNNEL

Opdrachtgebruik:

match request port-misuse {im|p2p|tunneling|any}

Voorbeelden van gebruiksscenario's

Configureer een http appfw-beleid om een http-sessie te blokkeren die wordt misbruikt voor IM-toepassingen.

class-map type inspect http port_misuse_cm
   match request port-misuse im

policy-map type inspect http port_misuse_pm
   class type inspect http port_misuse_cm
      reset

• Strenge http-inspectie — Met deze opdracht kunt u de conformiteit van het protocol controleren aan de hand van HTTP-verzoeken en -antwoorden. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

  APPFW-4- HTTP_PROTOCOL_VIOLATION

  Opdrachtgebruik:

  match req-resp protocol-violation

  Voorbeelden van gebruiksscenario's

  Configureer een http appfw-beleid om verzoeken of antwoorden te blokkeren die in strijd zijn met RFC 2616:

  class-map type inspect http proto-viol_cm 
     match req-resp protocol-violation 
  
  policy-map type inspect http proto-viol_pm 
     class type inspect http proto-viol_cm 
        reset

• Overdracht- Coderingsinspectie — Deze opdracht biedt de mogelijkheid om verzoeken/antwoorden waarvan het coderingstype overeenkomt met het geconfigureerde type, toe te staan, te weigeren of te controleren. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

  APPFW-6- HTTP_TRANSFER_ENCODING

  Opdrachtgebruik:

  match {request|response|req-resp} header transfer-encoding 
  {regex <parameter-map-name> |gzip|deflate|chunked|identity|all}

  Voorbeelden van gebruiksscenario's

  Configureer een http appfw-beleid om een verzoek of antwoord te blokkeren met codering van het type compressie.

  class-map type inspect http trans_encoding_cm
     match req-resp header transfer-encoding type compress
  
  policy-map type inspect http trans_encoding_pm
     class type inspect http trans_encoding_cm
        reset

• Java Applet inspectie — Deze opdracht controleert of een reactie Java applet heeft en past de geconfigureerde actie toe bij detectie van applet. Actie toestaan of opnieuw instellen kan worden toegepast op een verzoek of antwoord dat overeenkomt met de criteria voor klassentoewijzing. Toevoeging van de logactie veroorzaakt een syslog-bericht:

  APPFW-4- HTTP_JAVA_APPLET 

  Opdrachtgebruik:

  match response body java-applet

  Voorbeelden van gebruiksscenario's

  Configureer een http appfw-beleid om Java-applets te blokkeren.

  class-map type inspect http java_applet_cm
     match response body java-applet
  
  policy-map type inspect http java_applet_pm
     class type inspect http java_applet_cm
        reset

ZFW-ondersteuning voor instant messaging en peer-to-peer toepassingsbeheer

Cisco IOS Software Release 12.4(9)T introduceerde ZFW-ondersteuning voor IM- en P2P-toepassingen

Cisco IOS Software bood voor het eerst ondersteuning voor IM-toepassingsbesturing in Cisco IOS Software Release 12.4(4)T. De eerste versie van ZFW ondersteunde geen IM-toepassing in de ZFW-interface. Als IM-toepassingsbesturing gewenst was, konden gebruikers niet migreren naar de ZFW-configuratie-interface. Cisco IOS Software Release 12.4(9)T introduceert ZFW-ondersteuning voor IM Inspection, dat Yahoo ondersteunt! Messenger (YM), MSN Messenger (MSN) en AOL Instant Messenger (AIM). Cisco IOS Software Release 12.4(9)T is de eerste versie van Cisco IOS Software die native Cisco IOS Firewall-ondersteuning biedt voor P2P-toepassingen voor het delen van bestanden.

Zowel IM- als P2P-inspectie bieden Layer 4- en Layer 7-beleid voor toepassingsverkeer. Dit betekent dat ZFW kan voorzien in basis stateful inspectie om het verkeer toe te staan of te weigeren, evenals granulaire Layer 7-controle op specifieke activiteiten in de verschillende protocollen, zodat bepaalde toepassingsactiviteiten zijn toegestaan terwijl andere worden geweigerd.

P2P-toepassingsinspectie en -controle

SDM 2.2 introduceerde P2P Application control in zijn Firewall-configuratiegedeelte. SDM paste een Network-Based Application Recognition (NBAR)- en QoS-beleid toe om P2P-toepassingsactiviteiten te detecteren en te controleren tot een regelsnelheid van nul en om al het P2P-verkeer te blokkeren. Hierdoor ontstond het probleem dat CLI-gebruikers, die P2P-ondersteuning verwachtten in de Cisco IOS Firewall CLI, geen P2P-blokkering in de CLI konden configureren, tenzij zij op de hoogte waren van de noodzakelijke NBAR/QoS-configuratie. Cisco IOS Software Release 12.4(9)T introduceert native P2P-controle in de ZFW CLI, om NBAR te gebruiken om P2P-toepassingsactiviteit te detecteren. Deze softwarerelease ondersteunt verschillende P2P-toepassingsprotocollen:

• BitTorrent

• ezel

• FastTrack

• Gnutella

• KaZaA / KaZaA2

• WinMX

P2P-applicaties zijn bijzonder moeilijk te detecteren, als gevolg van port-hopping gedrag en andere trucs om detectie te voorkomen, evenals problemen die worden veroorzaakt door frequente veranderingen en updates van P2P-applicaties die het gedrag van de protocollen wijzigen. ZFW combineert native firewall stateful inspection met NBAR's mogelijkheden voor verkeersherkenning om P2P-toepassingscontrole te leveren in de CPL-configuratieinterface van ZFW. NBAR biedt twee uitstekende voordelen:

1. Optionele herkenning van toepassingen op basis van heuristiek om toepassingen te herkennen ondanks complex, moeilijk te detecteren gedrag

2. Uitbreidbare infrastructuur die een updatemechanisme biedt om op de hoogte te blijven van protocolupdates en -wijzigingen

P2P-inspectie configureren

Zoals eerder vermeld, biedt P2P-inspectie en -controle zowel Layer 4 Stateful Inspection als Layer 7 Application Control. Layer 4-inspectie is op dezelfde manier geconfigureerd als andere toepassingsservices, als de inspectie van de servicepoorten van de native toepassing toereikend is:

class-map type inspect match-any my-p2p-class
match protocol [bittorrent | edonkey | fasttrack | gnutella | kazaa | kazaa2 | winmx ] 
[signature (optional)]
!
policy-map type inspect private-allowed-policy
 class type inspect my-p2p-class
  [drop | inspect | pass]

Let op de extra handtekeningoptie in het overeenkomende protocol [servicenaam]. Wanneer de handtekeningoptie wordt toegevoegd aan het einde van de overeenkomende protocolinstructie, worden NBAR-heuristieken toegepast op het verkeer om te zoeken naar verklikkerlichten in het verkeer die specifieke P2P-toepassingsactiviteit aangeven. Dit omvat port-hopping en andere veranderingen in het gedrag van toepassingen om verkeersdetectie te voorkomen. Dit niveau van verkeersinspectie gaat ten koste van een verhoogd CPU-gebruik en een verminderde capaciteit voor netwerkdoorvoer. Als de handtekeningoptie niet wordt toegepast, wordt op NBAR gebaseerde heuristische analyse niet toegepast om poortspringgedrag te detecteren en wordt het CPU-gebruik niet in dezelfde mate beïnvloed.

Native service-inspectie heeft het nadeel dat het niet in staat is om controle te houden over P2P-toepassingen in het geval dat de toepassing naar een niet-standaard bron- en bestemmingspoort springt, of als de toepassing wordt bijgewerkt om zijn actie te starten op een niet-herkend poortnummer:

Als u P2P-verkeer wilt toestaan (inspecteren), moet u extra configuratie opgeven. Sommige toepassingen kunnen meerdere P2P-netwerken gebruiken of specifieke gedragingen implementeren die u in uw firewallconfiguratie moet opnemen om de toepassing te laten werken:

• BitTorrent-clients communiceren meestal met trackers (peer directory-servers) via http die op een niet-standaard poort wordt uitgevoerd. Dit is meestal TCP 6969, maar u moet de torrent-specifieke trackerpoort controleren. Als u BitTorrent wilt toestaan, is de beste methode om de extra poort aan te passen HTTP configureren als een van de overeenkomende protocollen en TCP 6969 toevoegen aan HTTP met de opdracht ip-poort-map:

  ip port-map http port tcp 6969
  

  U moet http en bittorrent definiëren als de overeenkomende criteria die worden toegepast in de klassentoewijzing.

• eDonkey lijkt verbindingen te initiëren die worden gedetecteerd als zowel eDonkey als Gnutella.

• KaZaA-inspectie is volledig afhankelijk van NBAR-signaaldetectie.

Layer 7 (Application) Inspection breidt Layer 4 Inspection uit met de mogelijkheid om servicespecifieke acties te herkennen en toe te passen, zoals het selectief blokkeren of toestaan van bestandszoekopdrachten, bestandsoverdracht en tekstchatmogelijkheden. Servicespecifieke mogelijkheden verschillen per service.

P2P Application Inspection is vergelijkbaar met HTTP Application Inspection:

!configure the layer-7 traffic characteristics:
class-map type inspect [p2p protocol] match-any p2p-l7-cmap
 match action
!
!configure the action to be applied to the traffic 
!matching the specific characteristics:
policy-map type inspect [p2p protocol] p2p-l7-pmap
 class type inspect p2p p2p-l7-cmap
  [ reset | allow ]
  log
!
!define the layer-4 inspection policy
class-map type inspect match-all p2p-l4-cmap
 match protocol [p2p protocol]
!
!associate layer-4 class and layer-7 policy-map
!in the layer-4 policy-map:
policy-map type inspect private-allowed-policy
 class type inspect p2p-l4-cmap
  [ inspect | drop | pass ]
  service-policy p2p p2p-l7-pmap

P2P Application Inspection biedt toepassingsspecifieke mogelijkheden voor een subset van de toepassingen die worden ondersteund door Layer 4 Inspection:

• deponkey

• snelspoor

• gnutella

• kazaa2

Elk van deze toepassingen biedt opties voor variabele toepassingsspecifieke matchcriteria:

deponkey

router(config)#class-map type inspect edonkey match-any edonkey-l7-cmap
router(config-cmap)#match ?
  file-transfer     Match file transfer stream
  flow              Flow based QoS parameters
  search-file-name  Match file name
  text-chat         Match text-chat

snelspoor

router(config)#class-map type inspect fasttrack match-any ftrak-l7-cmap
router(config-cmap)#match ?
  file-transfer  File transfer stream
  flow           Flow based QoS parameters

gnutella

router(config)#class-map type inspect gnutella match-any gtella-l7-cmap
router(config-cmap)#

kazaa2

router(config)#class-map type inspect kazaa2 match-any kazaa2-l7-cmap
router(config-cmap)#match ?
  file-transfer  Match file transfer stream
  flow           Flow based QoS parameters

Nieuwe P2P-protocoldefinities of updates van de huidige P2P-protocollen kunnen worden geladen met de dynamische PDLM-updatefunctionaliteit van NBAR. Dit is de configuratieopdracht voor het laden van de nieuwe PDLM:

ip nbar pdlm <file-location>

Het nieuwe protocol is beschikbaar in overeenkomende protocolopdrachten voor klassetype inspect. Als het nieuwe P2P-protocol services (subprotocollen) heeft, worden de nieuwe Layer 7-inspectklassetypen en de Layer 7-matchcriteria beschikbaar.

IM Toepassing Inspectie en Controle

Cisco IOS Software Release 12.4(4)T introduceerde IM Application Inspection and Control. IM-ondersteuning werd niet geïntroduceerd met ZFW in 12.4(6)T, zodat gebruikers IM-besturing en ZFW niet in hetzelfde firewallbeleid konden toepassen, omdat ZFW en oudere firewallfuncties niet naast elkaar kunnen bestaan op een bepaalde interface.

Cisco IOS Software Release 12.4(9)T ondersteunt stateful inspectie en applicatiecontrole voor deze IM-services:

• AOL Instant Messenger

• MSN Messenger

• Yahoo! boodschapper

IM-inspectie verschilt enigszins van de meeste services, omdat IM-inspectie de toegang tot een specifieke groep hosts voor elke gegeven service controleert. IM-diensten zijn over het algemeen afhankelijk van een relatief permanente groep directory-servers, waarmee clients contact moeten kunnen opnemen om toegang te krijgen tot de IM-service. IM-toepassingen zijn vaak erg moeilijk te besturen vanuit een protocol- of servicestandpunt. De meest effectieve manier om deze toepassingen te beheren, is door de toegang tot de vaste IM-servers te beperken.

IM-inspectie configureren

IM-inspectie en -controle biedt zowel Layer 4 Stateful Inspection

en Layer 7 Application Control.

Layer 4-inspectie is op dezelfde manier geconfigureerd als andere toepassingsservices:

class-map type inspect match-any my-im-class
match protocol [aol | msnmsgr | ymsgr ]
!
policy-map type inspect private-allowed-policy
 class type inspect my-im-class
  [drop | inspect | pass

IM-toepassingen kunnen via meerdere poorten contact opnemen met hun servers om hun functionaliteit te behouden. Als u een bepaalde IM-service wilt toestaan met de inspectieactie, hebt u geen serverlijst nodig om toegestane toegang tot de servers van de IM-service te definiëren. Wanneer u echter een klassentoewijzing configureert die een bepaalde IM-service opgeeft, zoals AOL Instant Messenger, en de dropactie toepast in de bijbehorende beleidskaart, kan de IM-client proberen een andere poort te vinden waar verbinding met internet is toegestaan. Als u geen verbinding met een bepaalde service wilt toestaan of als u de IM-servicemogelijkheden wilt beperken tot tekstchat, moet u een serverlijst definiëren zodat de ZFW verkeer kan identificeren dat is gekoppeld aan de IM-toepassing:

!configure the server-list parameter-map:
parameter-map type protocol-info <name>
  server name <name> 
  server ip a.b.c.d
  server ip range a.b.c.d a.b.c.d

De lijst met Yahoo IM-servers is bijvoorbeeld als volgt gedefinieerd:

parameter-map type protocol-info ymsgr-pmap
  server name scs.msg.example.com
  server name scsd.msg.example.com
  server ip 10.0.77.88
  server ip range 172.16.0.77 172.16.0.99

U moet de serverlijst toepassen op de protocoldefinitie:

class-map type inspect match-any ym-l4-cmap
 match protocol ymsgr ymsgr-pmap

U moet de opdrachten ip domain lookup en ip name-server ip.ad.re.ss configureren om de naamresolutie in te schakelen.

IM-servernamen zijn redelijk dynamisch. U moet regelmatig controleren of de geconfigureerde IM-serverlijsten volledig en correct zijn.

Layer 7 (Application) Inspection breidt Layer 4 Inspection uit met de mogelijkheid om servicespecifieke acties te herkennen en toe te passen, zoals het selectief blokkeren of toestaan van tekstchatmogelijkheden en het weigeren van andere servicemogelijkheden.

IM Application Inspection biedt momenteel de mogelijkheid om onderscheid te maken tussen tekst-chatactiviteiten en alle andere toepassingsservices. Om de IM-activiteit te beperken tot tekstchat, configureert u een Layer 7-beleid:

class-map type inspect ymsgr match-any ymsgr-text-cmap
  match service text-chat

class-map type inspect ymsgr match-any ymsgr-default-cmap
  match service any

policy-map type inspect im ymsgr-l7-pmap
  class type inspect im ymsgr-text-cmap
    allow
    [log]
  class type inspect im ymsgr-text-cmap
    reset
    [log]

Pas het Layer 7-beleid toe op Yahoo! Messenger-beleid eerder geconfigureerd:

class-map type inspect match-any my-im-class
match protocol ymsgr
!
policy-map type inspect private-allowed-policy
 class type inspect my-im-class
  inspect
  service-policy im ymsgr-l7-pmap

URL-filters

ZFW biedt URL-filtermogelijkheden om de toegang tot webinhoud te beperken tot de inhoud die is opgegeven door een witte of zwarte lijst die op de router is gedefinieerd, of door domeinnamen door te sturen naar een URL-filterserver om de toegang tot specifieke domeinen te verifiëren. ZFW URL-filtering in Cisco IOS Software Releases 12.4(6)T tot 12.4(15)T wordt toegepast als een aanvullende beleidsactie, vergelijkbaar met applicatie-inspectie.

Voor servergebaseerde URL-filtering moet u een parametertoewijzing definiëren die de configuratie van de urlfilter-server beschrijft:

parameter-map type urlfilter websense-parmap
 server vendor [n2h2 | websense] 10.1.1.1

Als statische witte of zwarte lijsten de voorkeur hebben, kunt u een lijst definiëren met domeinen of subdomeinen die specifiek zijn toegestaan of geweigerd, terwijl de omgekeerde actie wordt toegepast op verkeer dat niet overeenkomt met de lijst:

parameter-map type urlfilter websense-parmap
 exclusive-domain deny .example.com
 exclusive-domain permit .cisco.com

Als een zwarte lijst met URL's is gedefinieerd met weigeringsopties in de definities voor exclusieve domeinen, zijn alle andere domeinen toegestaan. Als er definities van "vergunning" zijn gedefinieerd, moeten alle domeinen die zijn toegestaan expliciet worden opgegeven, vergelijkbaar met de functie van IP-toegangscontrolelijsten.

Stel een klassenkaart in die overeenkomt met HTTP-verkeer:

class-map type inspect match-any http-cmap
 match protocol http

Definieer een beleidskaart die uw klassentoewijzing koppelt aan acties voor inspecteren en urlfilter:

policy-map type inspect http-filter-pmap
 class type inspect http-cmap
  inspect 
  urlfilter websense-parmap

Hiermee configureert u de minimale vereiste voor communicatie met een URL-filterserver. Er zijn verschillende opties beschikbaar om extra URL-filtergedrag te definiëren.

Sommige netwerkimplementaties willen URL-filtering toepassen voor sommige hosts of subnetten en URL-filtering omzeilen voor andere hosts. In afbeelding 9 moet bijvoorbeeld alle hosts in de privézone HTTP-verkeer laten controleren door een URL-filterserver, behalve voor de specifieke host 192.168.1.101.

Afbeelding 10: Voorbeeldtopologie URL-filtering

Voorbeeldtopologie URL-filtering

Dit kan worden bereikt als u twee verschillende klassenkaarten definieert:

• Eén klassentoewijzing die alleen overeenkomt met HTTP-verkeer voor de grotere groep hosts, die URL-filtering ontvangen.

• Eén klassentoewijzing voor de kleinere groep hosts, die geen URL-filtering ontvangen. De tweede klasse-map komt overeen met HTTP-verkeer, evenals een lijst met hosts die zijn vrijgesteld van het URL-filterbeleid.

Beide class-maps zijn geconfigureerd in een policy-map, maar slechts één ontvangt de actie urlfilter:

class-map type inspect match-any http-cmap
 match protocol http
class-map type inspect match-all http-no-urlf-cmap
 match protocol http
 match access-group 101
!
policy-map type inspect http-filter-pmap
 class type inspect http-no-urlf-cmap
  inspect
 class type inspect http-cmap
  inspect 
  urlfilter websense-parmap
!
access-list 101 permit ip 192.168.1.101 any

Toegang tot de router regelen

De meeste netwerkbeveiligingsingenieurs voelen zich ongemakkelijk als ze de beheerinterfaces van de router (bijvoorbeeld SSH, Telnet, HTTP, HTTPS, SNMP, enzovoort) blootstellen aan het openbare internet en onder bepaalde omstandigheden is ook controle nodig voor LAN-toegang tot de router. Cisco IOS Software biedt een aantal opties om de toegang tot de verschillende interfaces te beperken, waaronder de Network Foundation Protection (NFP) -functiefamilie, verschillende toegangscontrolemechanismen voor beheerinterfaces en de zelfzone van ZFW. U moet andere functies bekijken, zoals VTY-toegangscontrole, beheervliegtuigbeveiliging en SNMP-toegangscontrole om te bepalen welke combinatie van routerbesturingsfuncties het beste werkt voor uw specifieke toepassing.

Over het algemeen is de NFP-functiefamilie het meest geschikt voor de controle van verkeer dat is bestemd voor de router zelf. Raadpleeg het Overzicht van de beveiliging van het controlevlak in Cisco IOS-software voor informatie over routerbeveiliging met de NFP-functies.

Als u besluit ZFW toe te passen om het verkeer van en naar de IP-adressen op de router zelf te regelen, moet u begrijpen dat het standaardbeleid en de standaardmogelijkheden van de firewall verschillen van die welke beschikbaar zijn voor doorvoerverkeer. Transitverkeer wordt gedefinieerd als netwerkverkeer waarvan de bron- en bestemmings-IP-adressen niet overeenkomen met IP-adressen die op een van de routerinterfaces zijn toegepast, en het verkeer zorgt er niet voor dat de router bijvoorbeeld netwerkcontroleberichten zoals ICMP TTL-vervaldatum of netwerk / host onbereikbare berichten verzendt.

ZFW past een standaard weigeringsbeleid toe op verkeer dat tussen zones beweegt, behalve, zoals vermeld in de algemene regels, verkeer in elke zone die rechtstreeks naar de adressen van de interfaces van de router stroomt, is impliciet toegestaan. Dit zorgt ervoor dat de connectiviteit met de beheerinterfaces van de router behouden blijft wanneer een zone-firewallconfiguratie op de router wordt toegepast. Als hetzelfde uitsluitingsbeleid de connectiviteit rechtstreeks op de router beïnvloedt, moet een volledige configuratie van het beheerbeleid worden toegepast voordat zones op de router worden geconfigureerd. Dit zou waarschijnlijk de connectiviteit van het beheer verstoren als het beleid onjuist werd uitgevoerd of in de verkeerde volgorde werd toegepast.

Wanneer een interface is geconfigureerd als een lid van de zone, worden de hosts die zijn verbonden met de interface opgenomen in de zone. Het verkeer dat van en naar de IP-adressen van de interfaces van de router stroomt, wordt echter niet geregeld door het zonebeleid (met uitzondering van omstandigheden die worden beschreven in de opmerking in afbeelding 10). In plaats daarvan worden alle IP-interfaces op de router automatisch onderdeel van de zelfzone wanneer ZFW is geconfigureerd. Om IP-verkeer te beheren dat zich verplaatst naar de interfaces van de router vanuit de verschillende zones op een router, moet beleid worden toegepast om verkeer tussen de zone en de zelfzone van de router te blokkeren of toe te staan / te inspecteren, en vice versa (zie afbeelding 11).

Afbeelding 11: Beleid toepassen tussen netwerkzones en zelfzone van router

eBeleid toepassen tussen netwerkzones en zelfzone van router

Hoewel de router een standaard-allow-beleid biedt tussen alle zones en de zelfzone, als een beleid is geconfigureerd van elke zone naar de zelfzone en er geen beleid is geconfigureerd van zelf naar de door de gebruiker configureerbare interface-verbonden zones van de router, komt al het door de router gegenereerde verkeer het beleid van de verbonden zone naar zelfzone tegen bij het retourneren van de router en wordt geblokkeerd. Het routerverkeer moet dus worden geïnspecteerd om het terug te laten keren naar de zelfzone.

Opmerking: Cisco IOS Software gebruikt altijd het IP-adres dat is gekoppeld aan een interface met de dichtstbijzijnde bestemmingshosts voor verkeer zoals syslog, tftp, telnet en andere controleplanediensten en onderwerpt dit verkeer aan het firewallbeleid voor zelfzone. Als een service echter een specifieke interface definieert als de source-interface met opdrachten die omvatten, maar niet beperkt zijn tot, het registreren van de source-interface [typenummer], de ip-tftp-source-interface [typenummer] en de ip-telnet-source-interface [typenummer], wordt het verkeer onderworpen aan de self-zone.

Opmerking: Sommige services (met name routers voor voice-over-IP-services) maken gebruik van tijdelijke of niet-configureerbare interfaces die niet aan beveiligingszones kunnen worden toegewezen. Deze services kunnen niet goed functioneren als hun verkeer niet kan worden gekoppeld aan een geconfigureerde beveiligingszone.

Beleidsbeperkingen zelfzone

Self-zone beleid heeft beperkte functionaliteit in vergelijking met het beleid beschikbaar voor transit-verkeer zone-paren:

• Zoals het geval was met klassieke stateful inspectie, is het door de router gegenereerde verkeer beperkt tot TCP, UDP, ICMP en complex-protocol inspectie voor H.323.

• Toepassingsinspectie is niet beschikbaar voor zelfzonebeleid.

• Sessie- en snelheidsbeperking kunnen niet worden geconfigureerd op basis van zelf-zone beleid.

Beleidsconfiguratie zelfzone

Onder de meeste omstandigheden zijn dit wenselijke toegangsbeleid voor routerbeheerservices:

• Ontzeg alle Telnet-connectiviteit, omdat het duidelijke tekstprotocol van Telnet gemakkelijk gebruikersreferenties en andere gevoelige informatie blootlegt.

• Sta SSH-verbindingen toe van elke gebruiker in elke zone. SSH versleutelt gebruikersreferenties en sessiegegevens, wat bescherming biedt tegen kwaadwillende gebruikers die packet-capture-tools gebruiken om te snuffelen op gebruikersactiviteiten en gebruikersreferenties of gevoelige informatie zoals routerconfiguratie in gevaar te brengen. SSH versie 2 biedt betere bescherming en pakt specifieke kwetsbaarheden aan die inherent zijn aan SSH versie 1.

• Sta HTTP-connectiviteit toe met de router vanuit de privézones als de privézone betrouwbaar is. Anders, als de private zone herbergt het potentieel voor kwaadwillende gebruikers om informatie in gevaar te brengen, HTTP maakt geen gebruik van encryptie om het beheer van het verkeer te beschermen, en kan gevoelige informatie zoals gebruikersreferenties of configuratie onthullen.

• Sta HTTPS-connectiviteit toe vanuit elke zone. Net als bij SSH versleutelt HTTPS sessiegegevens en gebruikersreferenties.

• SNMP-toegang beperken tot een specifieke host of subnet. SNMP kan worden gebruikt om routerconfiguratie aan te passen en configuratiegegevens te onthullen. SNMP moet worden geconfigureerd met toegangscontrole op de verschillende communities.

• Blokkeer ICMP-verzoeken van het openbare internet naar het privézoneadres (dit veronderstelt dat het privézoneadres routeerbaar is). Indien nodig kunnen een of meer openbare adressen worden weergegeven voor ICMP-verkeer voor het oplossen van netwerkproblemen. Verschillende ICMP-aanvallen kunnen worden gebruikt om routerbronnen te overweldigen of netwerktopologie en -architectuur te herkennen.

Een router kan dit soort beleid toepassen met de toevoeging van twee zone-paren voor elke zone die moet worden gecontroleerd. Elk zone-paar voor verkeer dat binnenkomt naar of vertrekt vanuit de zelfzone van de router moet worden afgestemd op het respectieve beleid in de tegenovergestelde richting, tenzij het verkeer niet in de tegenovergestelde richting is ontstaan. Er kan één beleidskaart voor elk inkomende en uitgaande zoneparen worden toegepast die al het verkeer beschrijft, of er kunnen specifieke beleidskaarten per zonepaar worden toegepast. Configuratie van specifieke zoneparen per beleidskaart biedt granulariteit om activiteiten te bekijken die overeenkomen met elke beleidskaart.

Een voorbeeldnetwerk met een SNMP-beheerstation op 172.17.100.11 en een TFTP-server op 172.17.100.17. Deze uitvoer is een voorbeeld van het toegangsbeleid voor de beheerinterface:

class-map type inspect match-any self—service-cmap
 match protocol tcp
 match protocol udp
 match protocol icmp
 match protocol h323
!
class-map type inspect match-all to-self-cmap
 match class-map self—service-cmap
 match access-group 120
!
class-map type inspect match-all from-self-cmap
 match class-map self—service-cmap
!
class-map type inspect match-all tftp-in-cmap
 match access-group 121
!
class-map type inspect match-all tftp-out-cmap
 match access-group 122
!
policy-map type inspect to-self-pmap
 class type inspect to-self-cmap
  inspect
 class type inspect tftp-in-cmap
  pass
!
policy-map type inspect from-self-pmap
 class type inspect from-self-cmap
  inspect
 class type inspect tftp-out-cmap
  pass
!
zone security private
zone security internet
zone-pair security priv-self source private destination self
 service-policy type inspect to-self-pmap
zone-pair security net-self source internet destination self
 service-policy type inspect to-self-pmap
zone-pair security self-priv source self destination private 
 service-policy type inspect from-self-pmap
zone-pair security self-net source self destination internet
 service-policy type inspect from-self-pmap

!
interface FastEthernet 0/0
 ip address 172.16.100.10
 zone-member security internet
!
interface FastEthernet 0/1
 ip address 172.17.100.10
 zone-member security private
!
access-list 120 permit icmp 172.17.100.0 0.0.0.255 any
access-list 120 permit icmp any host 172.17.100.10 echo
access-list 120 deny icmp any any
access-list 120 permit tcp 172.17.100.0 0.0.0.255 host 172.17.100.10 eq www
access-list 120 permit tcp any any eq 443
access-list 120 permit tcp any any eq 22
access-list 120 permit udp any host 172.17.100.10 eq snmp
access-list 121 permit udp host 172.17.100.17 host 172.17.100.10 
access-list 122 permit udp host 172.17.100.10 host 172.17.100.17

Helaas biedt het self-zone-beleid niet de mogelijkheid om TFTP-overdrachten te inspecteren. De firewall moet dus al het verkeer van en naar de TFTP-server doorgeven als TFTP door de firewall moet gaan.

Als de router IPSec VPN-verbindingen beëindigt, moet u ook een beleid definiëren om IPSec ESP, IPSec AH, ISAKMP en NAT-TIPSec (UDP 4500) door te geven. Dit is afhankelijk van de diensten die u gebruikt. Dit volgende beleid kan worden toegepast in aanvulling op het bovenstaande beleid. Let op de wijziging in de policy-maps waar een class-map voor VPN-verkeer is ingevoegd met een pass-actie. Gewoonlijk is gecodeerd verkeer betrouwbaar, tenzij uw beveiligingsbeleid bepaalt dat u gecodeerd verkeer van en naar bepaalde eindpunten moet toestaan.

class-map type inspect match-all crypto-cmap
 match access-group 123
!
policy-map type inspect to-self-pmap
 class type inspect crypto-cmap
  pass
 class type inspect to-self-cmap
  inspect
 class type inspect tftp-in-cmap
  pass
!
policy-map type inspect from-self-pmap
 class type inspect crypto-cmap
  pass
 class type inspect from-self-cmap
  inspect
 class type inspect tftp-out-cmap
  pass
!
access-list 123 permit esp any any
access-list 123 permit udp any any eq 4500
access-list 123 permit ah any any 
access-list 123 permit udp any any eq 500

Zone-gebaseerde firewall en Wide-Area Application Services

Raadpleeg Release Note for Cisco Wide Area Application Services (Softwareversie 4.0.13) - Nieuwe functies voor Softwareversie 4.0.13 voor een toepassingsnotitie met configuratievoorbeelden en gebruiksrichtlijnen

Zone-Based Policy Firewall bewaken met tonen en foutopsporingsopdrachten

ZFW introduceert nieuwe opdrachten om de beleidsconfiguratie te bekijken en de firewallactiviteit te bewaken.

Beschrijving van de weergavezone en de interfaces in een bepaalde zone:

show zone security [<zone-name>]

Als de zonenaam niet is opgenomen, geeft de opdracht de informatie van alle geconfigureerde zones weer.

Router#show zone security z1
zone z1
  Description: this is test zone1
  Member Interfaces:
    Ethernet0/0

Geef de bronzone, bestemmingszone en het beleid weer die aan het zonepaar zijn gekoppeld:

show zone-pair security [source <source-zone-name>] [destination <destination-zone-name>]

Als er geen bron of bestemming is opgegeven, worden alle zoneparen met bron, bestemming en het bijbehorende beleid weergegeven. Wanneer alleen de bron/bestemming zone wordt vermeld, worden alle zone-paren weergegeven die deze zone als bron/bestemming bevatten.

Router#show zone-pair security   
zone-pair name zp
  Source-Zone z1  Destination-Zone z2 
  service-policy p1

Geeft een opgegeven beleidskaart weer:

show policy-map type inspect [<policy-map-name> [class <class-map-name]]

Wanneer de naam van een beleidskaart niet is opgegeven, worden alle beleidskaarten van het type inspect weergegeven (samen met Layer 7-beleidskaarten die een subtype bevatten).

Router#show policy-map type inspect p1
 Policy Map type inspect p1
   Class c1
    Inspect

Geeft de statistieken van de beleidskaart voor runtime-inspectie weer die zich momenteel op een opgegeven zonepaar bevinden.

show policy-map type inspect zone-pair [zone-pair-name] [sessions]

Wanneer geen naam voor een zonepaar wordt vermeld, worden beleidskaarten op alle zoneparen weergegeven.

De optie Sessies geeft de inspectiesessies weer die zijn gemaakt door de toepassing voor beleidskaarten op het opgegeven zonepaar.

Router#show policy-map type inspect zone-pair zp
 Zone-pair: zp

  Service-policy : p1

    Class-map: c1 (match-all)
      Match: protocol tcp
      Inspect
        Session creations since subsystem startup or last reset 0
        Current session counts (estab/half-open/terminating) [0:0:0]
        Maxever session counts (estab/half-open/terminating) [0:0:0]
        Last session created never
        Last statistic reset never
        Last session creation rate 0
        Last half-open session total 0   

    Class-map: c2 (match-all)
      Match: protocol udp
      Pass
        0 packets, 0 bytes

    Class-map: class-default (match-any)
      Match: any
      Drop
        0 packets, 0 bytes

Het trefwoord urlfilter geeft de statistieken weer die betrekking hebben op de opgegeven beleidskaart (of beleidskaarten op alle doelen wanneer geen naam voor een zonepaar is opgegeven):

show policy-map type inspect zone-pair [zone-pair-name] [urlfilter [cache]]

Wanneer het cachezoekwoord samen met urlfilter wordt opgegeven, wordt de cache van het urlfilter (van IP-adressen) weergegeven.

Overzicht van de opdracht voor het weergeven van beleidskaarten voor het inspecteren van beleidskaarten:

show policy-map type inspect inspect { <policy name> [class <class name>] |
	                  zone-pair [<zone-pair name>] [sessions | urlfilter cache] }

Firewall-bescherming tegen weigering van service op basis van Tune Zone-beleid

ZFW biedt DoS-bescherming om netwerktechnici te waarschuwen voor dramatische veranderingen in netwerkactiviteit en om ongewenste activiteit te beperken om de impact van veranderingen in netwerkactiviteit te verminderen. ZFW onderhoudt een aparte teller voor de klassenindeling van elke beleidskaart. Als één klasse-map wordt gebruikt voor de beleidskaarten van twee verschillende zoneparen, worden twee verschillende sets DoS-beveiligingstellers toegepast.

ZFW biedt DoS-aanvalmitigatie als standaard op Cisco IOS Software releases vóór 12.4(11)T. Het standaardgedrag voor DoS-beveiliging is gewijzigd met Cisco IOS Software Release 12.4(11)T. 

Raadpleeg Strategieën definiëren om te beschermen tegen TCP SYN Denial of Service-aanvallen voor meer informatie over TCP SYN DoS-aanvallen.

Aanhangsels

Bijlage A: Basisconfiguratie

ip subnet-zero
ip cef
!
bridge irb
!
interface FastEthernet0
 ip address 172.16.1.88 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet1
 ip address 172.16.2.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet2
 switchport access vlan 2
!
interface FastEthernet3
 switchport access vlan 2
!
interface FastEthernet4 
 switchport access vlan 1
!
interface FastEthernet5 
 switchport access vlan 1
!
interface FastEthernet6 
 switchport access vlan 1
!
interface FastEthernet7 
 switchport access vlan 1
!
interface Vlan1
 no ip address
 bridge-group 1
!
interface Vlan2
 no ip address
 bridge-group 1
!
interface BVI1
 ip address 192.168.1.254 255.255.255.0
 ip route-cache flow
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
bridge 1 protocol ieee
bridge 1 route ip
!
end

Bijlage B: Definitieve (volledige) configuratie

ip subnet-zero
ip cef
!
ip port-map user-Xwindows port tcp from 6900 to 6910
!
class-map type inspect match-any L4-inspect-class
 match protocol tcp
 match protocol udp
 match protocol icmp
class-map type inspect match-any L7-inspect-class
  match protocol ssh
  match protocol ftp
  match protocol pop
  match protocol imap
  match protocol esmtp
  match protocol http
class-map type inspect match-any dns-http-class
 match protocol dns
 match protocol http
class-map type inspect match-any smtp-class
 match protocol smtp
class-map type inspect match-all dns-http-acl-class
 match access-group 110
 match class-map dns-http-class
class-map type inspect match-all smtp-acl-class
 match access-group 111
 match class-map smtp-class
class-map type inspect match-any Xwindows-class
 match protocol user-Xwindows
class-map type inspect match-any internet-traffic-class
 match protocol http
 match protocol https
 match protocol dns
 match protocol icmp
class-map type inspect http match-any bad-http-class
 match  port-misuse all
 match  strict-http
!
policy-map type inspect clients-servers-policy
 class type inspect L4-inspect-class
  inspect
policy-map type inspect private-dmz-policy
  class type inspect L7-inspect-class
   inspect
policy-map type inspect internet-dmz-policy
 class type inspect dns-http-acl-class
  inspect
 class type inspect smtp-acl-class
  inspect
policy-map type inspect servers-clients-policy
 class type inspect Xwindows-class
  inspect
policy-map type inspect private-internet-policy
  class type inspect internet-traffic-class
   inspect
  class type inspect bad-http-class
   drop
!
zone security clients
zone security servers
zone security private
zone security internet
zone security dmz
zone-pair security private-internet source private destination internet
  service-policy type inspect private-internet-policy
zone-pair security servers-clients source servers destination clients
  service-policy type inspect servers-clients-policy
zone-pair security clients-servers source clients destination servers
  service-policy type inspect clients-servers-policy
zone-pair security private-dmz source private destination dmz
  service-policy type inspect private-dmz-policy
zone-pair security internet-dmz source internet destination dmz
  service-policy type inspect internet-dmz-policy
!
bridge irb
!
interface FastEthernet0
 ip address 172.16.1.88 255.255.255.0
 zone-member internet
!
interface FastEthernet1
 ip address 172.16.2.1 255.255.255.0
 zone-member dmz
!
interface FastEthernet2
 switchport access vlan 2
!
interface FastEthernet3
 switchport access vlan 2
!
interface FastEthernet4 
 switchport access vlan 1
!
interface FastEthernet5 
 switchport access vlan 1
!
interface FastEthernet6 
 switchport access vlan 1
!
interface FastEthernet7 
 switchport access vlan 1
!
interface Vlan1
 no ip address
 zone-member clients 
 bridge-group 1
!
interface Vlan2
 no ip address
 zone-member servers
 bridge-group 1
!
interface BVI1
 ip address 192.168.1.254 255.255.255.0
 zone-member private
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.1.1
!
access-list 110 permit ip any host 172.16.2.2
access-list 111 permit ip any host 172.16.2.3
!
bridge 1 protocol ieee
bridge 1 route ip
!
End

Bijlage C: Basic Zone-Policy Firewall Configuration for Two Zones

Dit voorbeeld biedt een eenvoudige configuratie als basis om functies te testen voor verbeteringen aan de Cisco IOS Software ZFW. Deze configuratie is een modelconfiguratie voor twee zones, zoals geconfigureerd op een 1811-router. De private zone wordt toegepast op de vaste switch-poorten van de router, zodat alle hosts op de switch-poorten zijn verbonden met VLAN 1. De openbare zone wordt toegepast op FastEthernet 0 (zie afbeelding 12).

Afbeelding 12: Openbare zone toegepast op FastEthernet 0

Public Zone toegepast op FastEthernet 0

class-map type inspect match-any private-allowed-class
 match protocol tcp
 match protocol udp
 match protocol icmp
class-map type inspect match-all http-class
 match protocol http
!
policy-map type inspect private-allowed-policy
 class type inspect http-class
  inspect my-parameters
 class type inspect private-allowed-class
  inspect
!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect private-allowed-policy
!
interface fastethernet 0
 zone-member security public
!
interface VLAN 1
 zone-member security private

Gerelateerde informatie

• Technische ondersteuning en documentatie – Cisco Systems