De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft het configuratiemodel voor de functieset Cisco IOS® Firewall, Zone-based Policy Firewall (ZFW).
Er zijn geen specifieke vereisten van toepassing op dit document.
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.
Dit nieuwe configuratiemodel biedt intuïtief beleid voor meerdere interfacerouters, verhoogde granulariteit van de toepassing van het firewallbeleid, en een standaard deny-all beleid dat verkeer tussen firewall-beveiligingszones verbiedt totdat een expliciet beleid wordt toegepast om gewenst verkeer toe te staan.
Bijna alle klassieke Cisco IOS-firewallfuncties die zijn geïmplementeerd voordat Cisco IOS-softwarerelease 12.4(6)T worden ondersteund in de nieuwe op zones gebaseerde beleidsinspectieinterface:
Stateful pakketinspectie
VRF-bewuste Cisco IOS-firewall
URL-filtering
Beperking van weigeringen van services (DoS)
Cisco IOS-softwarerelease 12.4(9)T heeft ZFW-ondersteuning toegevoegd voor sessies/verbindingen en doorvoerbeperkingen per klasse, evenals toepassingsinspectie en controle:
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)
IM-toepassingen (Instant Messaging):
Microsoft Messenger
Yahoo! Messenger
AOL Instant Messenger
Peer-to-peer (P2P) bestanden delen:
bittorrent
KaZa
Gnutella
eDonkey
Cisco IOS-softwarerelease 12.4(11)T heeft statistieken toegevoegd voor een eenvoudiger afstemming van DoS-bescherming.
Sommige functies en mogelijkheden van Cisco IOS Classic Firewall worden nog niet ondersteund in een ZFW in Cisco IOS-softwarerelease 12.4(15)T:
Verificatieproxy
Stateful firewall-failover
Unified firewall MIB
IPv6-stateful inspectie
Ondersteuning van TCP buiten bedrijf
ZFW verbetert over het algemeen Cisco IOS-prestaties voor de meeste firewallinspectieactiviteiten. Noch Cisco IOS ZFW noch Classic Firewall biedt stateful inspection ondersteuning voor multicast verkeer.
Stateful inspection voor Cisco IOS Classic Firewall (voorheen bekend als Context-Based Access Control of CBAC) maakte gebruik van een op interfaces gebaseerd configuratiemodel, waarin een stateful inspection beleid is toegepast op een interface. Alle verkeerspassen door die interface kregen hetzelfde inspectiebeleid. Dit configuratiemodel beperkte de granulariteit van het firewallbeleid en veroorzaakte verwarring van de juiste toepassing van firewallbeleid, in het bijzonder in scenario's wanneer het firewallbeleid tussen meerdere interfaces moet worden toegepast.
Zone-Based Policy Firewall (ook bekend als Zone-Policy Firewall, of ZFW) wijzigt de firewallconfiguratie van het oudere op interfaces gebaseerde model in een flexibeler, gemakkelijker te begrijpen op zones gebaseerd model. De interfaces worden toegewezen aan zones, en het inspectiebeleid wordt toegepast op verkeer dat zich tussen de zones beweegt. Het beleid tussen zones biedt aanzienlijke flexibiliteit en granulariteit, zodat er verschillende inspectiemaatregelen kunnen worden toegepast op meerdere hostgroepen die op dezelfde routerinterface zijn aangesloten.
Het firewallbeleid wordt geconfigureerd met Cisco Policy Language (CPL), die een hiërarchische structuur gebruikt om inspectie te definiëren voor netwerkprotocollen en de groepen hosts waarop de inspectie kan worden toegepast.
ZFW wijzigt de manier waarop u een Cisco IOS-firewall-inspectie configureert volledig in vergelijking met de Cisco IOS Classic Firewall.
De eerste belangrijke verandering in de firewallconfiguratie is de introductie van op zone gebaseerde configuratie. Cisco IOS Firewall is de eerste eigenschap van de de bedreigingsdefensie van de Software van Cisco IOS om een model van de streekconfiguratie uit te voeren. Andere kenmerken kunnen het zonemodel in de loop der tijd overnemen. Het op Cisco IOS Classic Firewall-gebaseerde configuratiemodel met stateful inspection (of CBAC) dat gebruikmaakt van de opdrachtset voor IP-inspectie, wordt gedurende een bepaalde periode behouden. Er zijn echter maar weinig, zo niet geen, nieuwe functies configureerbaar met de klassieke opdrachtregelinterface (CLI). ZFW gebruikt geen stateful inspection of CBAC commando's. De twee configuratiemodellen kunnen gelijktijdig op routers worden gebruikt, maar niet op interfaces worden gecombineerd. Een interface kan niet worden geconfigureerd als een security zone lid en tegelijkertijd worden geconfigureerd voor IP-inspectie .
Zones stellen de beveiligingsgrenzen van uw netwerk in. Een zone definieert een grens waar verkeer aan beleidsbeperkingen wordt onderworpen wanneer het naar een ander gebied van uw netwerk gaat. Het standaardbeleid van ZFW tussen zones is ontkennen allen. Als geen beleid uitdrukkelijk wordt gevormd, wordt al verkeer dat zich tussen streken beweegt geblokkeerd. Dit is een belangrijke afwijking van stateful inspection model waarbij verkeer impliciet werd toegestaan tot expliciet geblokkeerd met een toegangscontrolelijst (ACL).
De tweede grote verandering is de introductie van een nieuwe taal voor configuratiebeleid die bekend staat als CPL. Gebruikers die bekend zijn met de Cisco IOS-softwarerelease Modular Quality-of-Service (QoS) CLI (MQC) kunnen herkennen dat het formaat vergelijkbaar is met het gebruik van QoS-klassekaarten om aan te geven welk verkeer wordt beïnvloed door de actie die in een beleidskaart wordt toegepast.
Het lidmaatschap van de netwerkinterface van de router in streken is onderworpen aan verscheidene regels die interfacegedrag regeren, zoals het verkeer is dat zich tussen de interfaces van het streeklid beweegt:
Een zone moet worden geconfigureerd voordat interfaces aan de zone kunnen worden toegewezen.
Een interface kan aan slechts één veiligheidszone worden toegewezen.
Al verkeer aan en van een bepaalde interface wordt impliciet geblokkeerd wanneer de interface aan een streek, behalve verkeer aan en van andere interfaces in de zelfde streek, en verkeer aan om het even welke interface op de router wordt toegewezen.
Het verkeer is impliciet toegestaan om standaard te stromen tussen interfaces die lid zijn van dezelfde zone.
Om verkeer van en naar een interface van een zonelid toe te laten, moet een beleid dat verkeer toestaat of inspecteert tussen die zone en een andere zone worden geconfigureerd.
De zelfzone is de enige uitzondering op de standaard ontkennen alle beleid. Al verkeer aan om het even welke routerinterface wordt toegestaan tot het verkeer uitdrukkelijk wordt ontkend.
Het verkeer kan niet tussen een interface van het streeklid en om het even welke interface stromen die geen streeklid is. Pas, inspecteer, en laat vallen acties kan slechts tussen twee zones worden toegepast.
Interfaces die niet aan een zone zijn toegewezen, fungeren als klassieke routerpoorten en kunnen nog steeds klassieke stateful inspection/CBAC-configuratie gebruiken.
Als het vereist is dat een interface op de box geen deel uitmaakt van het zone/firewall beleid. Het kan nog steeds noodzakelijk zijn om die interface in een zone te plaatsen en een pas te vormen al beleid (een soort dummy beleid) tussen die zone en een andere zone waaraan verkeersstroom wordt gewenst.
Van het vorige gedrag, wordt verklaard dat, als het verkeer tussen alle interfaces in een router moet stromen, alle interfaces deel van het zoning model moeten uitmaken (elke interface moet een lid van één streek of een andere zijn).
De enige uitzondering op het vorige gedrag, ontken door gebrek benadering is het verkeer aan en van de router, die door gebrek wordt toegelaten. Een expliciet beleid kan worden geconfigureerd om dergelijk verkeer te beperken.
Een veiligheidszone moet voor elk gebied van relatieve veiligheid binnen het netwerk worden geconfigureerd, zodat alle interfaces die aan dezelfde zone zijn toegewezen, met een vergelijkbaar beveiligingsniveau worden beschermd. Neem bijvoorbeeld een toegangsrouter met drie interfaces:
Eén interface met het openbare internet.
Eén interface die is aangesloten op een privaat LAN dat niet via het openbare internet toegankelijk mag zijn.
Eén interface die is verbonden met een gedemilitariseerde zone voor internetdiensten (DMZ), waar een webserver, een DNS-server (Domain Name System) en een e-mailserver toegankelijk moeten zijn voor het openbare internet.
Elke interface in dit netwerk wordt toegewezen aan zijn eigen zone, hoewel u gevarieerde toegang van het openbare internet naar specifieke hosts in de DMZ en gevarieerd toepassingsgebruiksbeleid voor hosts in het beveiligde LAN kunt toestaan (zie afbeelding 1).
Afbeelding 1: Basis Security Zone-topologie
In dit voorbeeld heeft elke zone slechts één interface. Als een extra interface wordt toegevoegd aan de privé-zone, kunnen de hosts die zijn aangesloten op 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.
Typisch, heeft het voorbeeldnetwerk drie belangrijke beleid:
Privézone-verbinding met het internet
Private zone connectiviteit naar DMZ-hosts
Internetzone-connectiviteit met DMZ-hosts
Omdat DMZ wordt blootgesteld aan het openbare internet, kunnen de DMZ-hosts worden blootgesteld aan ongewenste activiteit van kwaadwillige individuen die er in kunnen slagen om één of meerdere DMZ-hosts te beschadigen. Als er geen toegangsbeleid is voorzien voor DMZ-hosts om zowel privézone-hosts als internetzone-hosts te bereiken, dan kunnen de personen die de DMZ-hosts hebben gecompromitteerd de DMZ-hosts niet gebruiken om verdere aanvallen uit te voeren tegen private of internet-hosts. ZFW legt een prohibitieve standaardveiligheidshouding op. Daarom, tenzij de gastheren DMZ specifiek worden verleend toegang tot andere netwerken, worden andere netwerken beschermd tegen om het even welke verbindingen van de gastheren DMZ. Op dezelfde manier wordt geen toegang voor de gastheren van Internet verstrekt om tot de privé zonegastheren toegang te hebben, zodat zijn de privé zonegastheren veilig van ongewenste toegang door de gastheren van Internet.
Recente verbeteringen van IPSec VPN vereenvoudigen de configuratie van het firewallbeleid voor VPN-connectiviteit. Met IPSec Virtual Tunnel Interface (VTI) en GRE+IPSec kunt u VPN site-to-site- en clientverbindingen beperken tot een specifieke beveiligingszone door de tunnelinterfaces in een gespecificeerde beveiligingszone te plaatsen. De verbindingen kunnen in VPN DMZ worden geïsoleerd als de connectiviteit door een specifiek beleid moet worden beperkt. Of, als de connectiviteit van VPN impliciet wordt vertrouwd op, kan de connectiviteit van VPN in de zelfde veiligheidszone worden geplaatst zoals het vertrouwde binnen netwerk.
Als een niet-VTI IPSec wordt toegepast, vereist het beleid van de de connectiviteitsfirewall van VPN nauwkeurig toezicht om veiligheid te handhaven. Het gebiedsbeleid moet specifiek toegang door een IP adres voor verre plaatsgastheren of de cliënten van VPN toestaan als de veilige gastheren in een verschillende streek dan de VPN cliënt gecodeerde verbinding aan de router zijn. Als het toegangsbeleid niet goed is geconfigureerd, kunnen hosts die moeten worden beschermd worden blootgesteld aan ongewenste, potentieel vijandige hosts. Raadpleeg VPN gebruiken met Zone-Based Policy Firewall voor verdere concept- en configuratiediscussies.
Deze procedure kan worden gebruikt om een ZFW te configureren. De opeenvolging van stappen is niet belangrijk, maar sommige gebeurtenissen moeten in orde worden voltooid. Bijvoorbeeld, moet u een klasse-kaart vormen alvorens u een klasse-kaart aan een beleid-kaart toewijst. Op dezelfde manier kunt u geen beleid-kaart aan een streek-paar toewijzen tot u het beleid hebt gevormd. Als u probeert om een sectie te vormen die zich op een ander gedeelte van de configuratie baseert dat u niet hebt gevormd, antwoordt de router met een foutenmelding.
Definieer zones.
Bepaal zone-paren.
Definieer klasse-kaarten die verkeer beschrijven dat beleid moet hebben toegepast aangezien het een zone-paar kruist.
Definieer beleidskaarten om actie toe te passen op uw class-maps verkeer.
Pas beleidskaarten toe op zoneparen.
Wijs interfaces toe aan zones.
Class-maps definiëren het verkeer dat door de firewall wordt geselecteerd voor de beleidsapplicatie. Layer 4 class-maps sorteren het verkeer op basis van deze hier genoemde criteria. Deze criteria worden gespecificeerd met het matchbevel in een klasse-kaart:
Toegangsgroep — Met een standaard, uitgebreide of benoemde ACL kan verkeer worden gefilterd op basis van IP-adres van de bron en de bestemming en de bron- en doelpoort.
Protocol — Layer 4-protocollen (TCP, UDP en ICMP) en toepassingsservices zoals HTTP, SMTP, DNS en dergelijke, kunnen worden gespecificeerd voor elke bekende of door de gebruiker gedefinieerde service die bekend is bij poorttoewijzingen.
Class-map — Een ondergeschikte class-map die extra matchcriteria biedt, kan worden genest binnen een andere class-map.
Niet — Het criterium Not specificeert dat verkeer dat niet overeenkomt met een gespecificeerde service (protocol), toegangsgroep of ondergeschikte class-map is geselecteerd voor de class-map.
Klasse-maps kunnen match-any of match-all operatoren toepassen om te bepalen hoe de match criteria moeten worden toegepast. Als match-any is opgegeven moet traffic aan slechts één van de matchcriteria in de class-map voldoen. Als match-all is opgegeven moet traffic voldoen aan alle class-map criteria om tot die bepaalde class te behoren.
De criteria van de overeenkomst moeten worden toegepast in volgorde van specifieker naar minder specifiek als het verkeer aan meerdere criteria voldoet. Neem bijvoorbeeld deze class-map:
class-map type inspect match-any my-test-cmap match protocol http match protocol tcp
HTTP-verkeer moet het matchprotocol http eerst ontmoeten om er zeker van te zijn dat het verkeer wordt verwerkt door de servicespecifieke functies van HTTP-inspectie. Als de matchlijnen worden omgekeerd, zodat het verkeer de verklaring van TCP van het matchprotocol ontmoet alvorens het om protocol http te vergelijken, wordt het verkeer eenvoudig geclassificeerd als verkeer van TCP, en geïnspecteerd gebaseerd op de mogelijkheden van de component van de Inspectie van TCP van de Firewall. Dit is een probleem voor bepaalde services zoals FTP, TFTP en verschillende multimedia- en spraaksignaleringsservices zoals H.323, SIP, Skinny, RTSP en anderen. Deze diensten vereisen extra inspectiecapaciteit om de complexere activiteiten van deze diensten te kunnen herkennen.
Klasse-maps kunnen een ACL toepassen als een van de matchcriteria voor de beleidstoepassing. Als een class-map alleen met criterium overeenkomt een ACL is en de class-map is gekoppeld aan een policy-map die de inspectie-actie toepast, past de router TCP- of UDP-basisinspectie toe voor al het verkeer dat door de ACL is toegestaan, behalve dat welke ZFW een applicatie-bewuste 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, wordt om het even welk secundair of mediakanaal verbonden aan de primaire/controle toegestaan, ongeacht of de ACL het verkeer toestaat.
Als een class-map alleen ACL 101 toepast als de matchcriteria, wordt een ACL 101 als volgt weergegeven:
access-list 101 permit ip any any
Al verkeer wordt toegestaan in de richting van het dienst-beleid dat op een bepaald streek-paar wordt toegepast, en het terugkeerverkeer dat aan dit beantwoordt wordt toegestaan in de tegenovergestelde richting. Daarom moet ACL de beperking toepassen om verkeer tot specifieke gewenste types te beperken. Bericht dat de PAM- lijst toepassingsdiensten zoals HTTP, NetBIOS, H.323, en DNS omvat. Ondanks de kennis van PAM van het specifieke toepassingsgebruik van een bepaalde haven, past de firewall echter alleen voldoende toepassingsspecifieke capaciteit toe om aan de bekende eisen van het toepassingsverkeer te voldoen. Aldus, worden het eenvoudige toepassingsverkeer zoals telnet, SSH, en andere enig-kanaals toepassingen geïnspecteerd als TCP, en hun statistieken worden gecombineerd in de output van het showbevel. Als applicatie-specifieke zichtbaarheid in netwerkactiviteit gewenst is, moet u inspectie voor services configureren op naam van de applicatie (configureer match protocol HTTP, match protocol telnet, enzovoort).
Vergelijk de statistieken die beschikbaar zijn in de show policy-map type inspecteren zone-paar opdrachtoutput van deze configuratie met het meer expliciete firewallbeleid dat verderop op op de pagina wordt getoond. Deze configuratie wordt gebruikt om verkeer vanaf een Cisco IP-telefoon te controleren en om verschillende werkstations te selecteren die gebruik maken van een scala aan verkeer, 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, door PAM herkende bestemmingshavens in acht neemt), biedt het beperkte zichtbaarheid in de serviceactiviteit en biedt het geen mogelijkheid om de bandbreedte- en sessielimieten van ZFW toe te passen voor specifieke soorten verkeer. Deze show beleid-map type inspect zone-paar priv-pub opdrachtoutput is het resultaat van de vorige eenvoudige configuratie die alleen een vergunning IP [sub] elke ACL tussen zone-paren gebruikt. Zoals u kunt zien, wordt het meeste 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
In tegenstelling, een gelijkaardige configuratie die toepassing-specifieke klassen toevoegt verstrekt meer korrelige toepassingsstatistieken en controle, en past nog de zelfde breedte van de diensten aan die in het eerste voorbeeld werd getoond wanneer u de laatste-kans klasse-kaart bepaalt die slechts ACL als laatste kans in beleid-kaart aanpast:
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 verstrekt deze wezenlijke korrelige output voor het show beleid-kaart type inspecteren zone-paar priv-pub bevel:
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 aan wanneer een meer granulaire klasse-kaart en beleid-kaart configuratie wordt gebruikt, zoals eerder vermeld, is een kans om klasse-specifieke grenzen op zitting en snelheidswaarden toe te passen; en, om specifiek inspectie parameters door de toepassing van een parameter-kaart aan te passen om elk klasse inspectie gedrag aan te passen.
De policy-map past firewallbeleidsacties op een of meer class-maps toe om het service-beleid te definiëren dat wordt toegepast op een security zone-paar. Wanneer een inspect-type policy-map wordt gemaakt, wordt een standaardklasse met de naam class-default toegepast aan het einde van de klasse. De class-default beleidsactie is drop maar kan veranderd worden om over te gaan. De logoptie kan met de dalingsactie worden toegevoegd. Inspecteren kan niet toegepast worden bij class-default.
ZFW voorziet in drie acties voor verkeer dat van de ene zone naar de andere verloopt:
Drop — Dit is de standaardactie voor al het verkeer, zoals toegepast door de class-default die elke inspect-type policy-map beëindigt. Andere class-maps binnen een policy-map kunnen ook worden geconfigureerd om ongewenste verkeer te laten vallen. Het verkeer dat door de dalingsactie wordt behandeld wordt stil gelaten vallen (d.w.z., wordt geen bericht van de daling verzonden naar de relevante eind-gastheer) door ZFW, in tegenstelling tot een gedrag ACL wanneer het een gastheer ICMP onbereikbaar bericht naar de gastheer verzendt die het ontkende verkeer verzond. Op dit moment is er geen optie om het stille druppelgedrag te wijzigen. De logoptie kan met daling voor syslog bericht worden toegevoegd dat het verkeer door de firewall werd gelaten vallen.
Pas - Deze actie staat de router toe om verkeer van één streek aan een andere door:sturen. De passactie volgt de status van de verbindingen of sessies binnen het verkeer niet. Pas staat slechts het verkeer in één richting toe. Er moet een parallel beleid worden toegepast om het terugkeerverkeer in de tegenovergestelde richting te laten passeren. De pass actie is nuttig voor protocollen zoals IPSec ESP, IPSec AH, ISAKMP en andere inherent beveiligde protocollen met voorspelbaar gedrag. Het meeste toepassingsverkeer kan echter beter in de ZFW worden afgehandeld met de controleactie.
Inspecteren — De inspectiemaatregel biedt een op de staat gebaseerde verkeerscontrole. Als bijvoorbeeld het verkeer van de privézone naar de internetzone in het eerdere voorbeeldnetwerk wordt geïnspecteerd, onderhoudt de router verbinding- of sessieinformatie voor TCP- en User Datagram Protocol (UDP)-verkeer. Daarom laat de router terugkeerverkeer toe dat van internet-zone hosts wordt verzonden in antwoord op aanvragen van een privé-zone verbinding. Ook, kan inspecteren toepassingsinspectie en controle voor bepaalde de dienstprotocollen verstrekken die kwetsbaar of gevoelig toepassingsverkeer kunnen dragen. Audit-trail kan worden toegepast met een parameter-kaart om verbinding/sessiestart, stop, duur, het overgedragen gegevensvolume en bron- en doeladressen 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-kaarten bieden opties om de verbindingsparameters voor een bepaald klasse-kaart inspectiebeleid te wijzigen.
Parameter-kaarten specificeren inspectiegedrag voor ZFW, voor parameters zoals DoS-bescherming, TCP-verbinding/UDP-sessietimers en instellingen voor audit-trailvastlegging. Parameter-kaarten worden ook toegepast met Layer 7-klasse en beleidskaarten om toepassingsspecifiek gedrag te definiëren, zoals HTTP-objecten, POP3- en IMAP-verificatievereisten en andere toepassingsspecifieke informatie.
Inspectie parameter-kaarten voor ZFW zijn geconfigureerd als type inspectie, vergelijkbaar met andere ZFW klasse en beleid-objecten:
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
De specifieke types van parameter-kaarten specificeren parameters die door Layer 7 het beleid van de toepassingsinspectie worden toegepast. Regex-type parameter-kaarten definiëren een reguliere expressie voor gebruik met HTTP-toepassingsinspectie die verkeer met een reguliere expressie filtert:
parameter-map type regex [parameter-map-name]
Protocol-info-type parameter-maps definiëren servernamen voor gebruik met IM Application inspection:
parameter-map type protocol-info [parameter-map-name]
De volledige configuratiedetails voor HTTP- en IM-toepassingsinspectie worden gegeven in de respectieve secties van de toepassingsinspectie van dit document.
ZFW biedt registratieopties voor verkeer dat standaard wordt gedropt of geïnspecteerd of dat ingesteld is op acties in het kader van firewallbeleid. Audit-trail logboekregistratie is beschikbaar voor verkeer dat door de ZFW wordt geïnspecteerd. Audit-trail wordt toegepast wanneer een audittrail wordt gedefinieerd in een parameter-kaart en de parameter-kaart met de inspectieactie wordt toegepast in een beleidskaart:
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 daalt. Drop logging is ingesteld door wanneer u een log toevoegt met de drop-actie in een policy-map:
configure terminal policy-map type inspect z1-z2-pmap class type inspect service-cmap inspect|drop|allow [service-parameter-map]
ZFW bevat momenteel geen editor die de verschillende ZFW-structuren kan wijzigen, zoals policy-maps, class-maps en parameter-maps. Om overeenkomende verklaringen in een klasse-kaart of actietoepassing aan diverse klasse-kaarten in een beleid-kaart te herschikken, moet u deze stappen voltooien:
Kopieer de huidige structuur naar een teksteditor zoals Microsoft Windows Notepad of een editor zoals vi op Linux/Unix-platforms.
Verwijder de huidige structuur uit de routerconfiguratie.
Bewerk de structuur in de teksteditor.
Kopieer de structuur terug naar de router CLI.
Dit configuratievoorbeeld maakt gebruik van een Cisco 1811 geïntegreerde services router. Een basisconfiguratie met IP-connectiviteit, VLAN-configuratie en transparante overbrugging tussen twee particuliere Ethernet LAN-segmenten is beschikbaar in Bijlage A. De router wordt gescheiden in vijf zones:
Het openbare internet is verbonden met Fast Ethernet 0 (internetzone)
Twee internetservers zijn aangesloten op Fast Ethernet 1 (DMZ-zone)
De Ethernet-switch is geconfigureerd met twee VLAN’s:
De werkstations zijn verbonden met VLAN1 (clientzone).
De servers zijn verbonden met VLAN2 (serverzone).
De client- en serverzones bevinden zich in hetzelfde subsysteem. Een transparante firewall wordt toegepast tussen de zones, zodat het beleid tussen de zones op die twee interfaces alleen het verkeer tussen de client- en serverzones kan beïnvloeden.
De VLAN1- en VLAN2-interfaces communiceren met andere netwerken via de virtuele interface van de brug (BVI1). Deze interface wordt toegewezen aan de privé-zone. (Zie figuur 2.)
Afbeelding 2: Gebiedstopologie Detail
Dit beleid wordt 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 toegang tot de specifieke diensten 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-clientsessies 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) kunnen toegang krijgen 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 de applicatie-inspectie toegepast op HTTP-verbindingen van de privézone naar de internetzone om te garanderen dat ondersteunde IM- en P2P-toepassingen niet worden uitgevoerd op poort 80 (zie afbeelding 3).
Afbeelding 3: Toepassingsrechten voor zone-paar-services die in het configuratievoorbeeld moeten worden toegepast
Dit firewallbeleid wordt geconfigureerd in volgorde van complexiteit:
Clients-servers, TCP/UDP/ICMP-inspectie
Private-DMZ SSH/FTP/POP/IMAP/ESMTP/HTTP-inspectie
Internet -DMZ SMTP/HTTP/DNS-inspectie beperkt door hostadres
Servers-Clients X Windows-inspectie met een poortapplicatie-mapping (PAM)-gespecificeerde service
Private-Internet HTTP/HTTPS/DNS/ICMP met HTTP-toepassingsinspectie
Omdat u delen van de configuratie op verschillende netwerksegmenten op verschillende tijden toepast, is het belangrijk om te onthouden dat een netwerksegment connectiviteit aan andere segmenten verliest wanneer het in een zone wordt geplaatst. Bijvoorbeeld, wanneer de privé zone wordt gevormd, verliezen de gastheren in de privé-zone connectiviteit aan de DMZ en de streken van Internet tot hun respectieve beleid wordt bepaald.
Afbeelding 4 illustreert de configuratie van het beleid voor privaat internet.
Afbeelding 4: Service-inspectie van Private Zone naar Internet Zone
Het privé internetbeleid past Layer 4-inspectie toe op HTTP, HTTPS, DNS en Layer 4-inspectie voor ICMP van de private zone naar de internetzone. Dit staat verbindingen van de privé streek aan de streek van Internet toe en staat het terugkeerverkeer toe. Layer 7-inspectie biedt de voordelen van een striktere toepassingscontrole, betere beveiliging en ondersteuning voor toepassingen die een oplossing vereisen. Layer 7-inspectie, zoals vermeld, vereist echter een beter begrip van netwerkactiviteit, aangezien Layer 7-protocollen die niet voor inspectie zijn geconfigureerd niet tussen zones zijn toegestaan.
Definieer class-maps die het verkeer beschrijven dat u wilt toestaan tussen zones, gebaseerd op het eerder beschreven beleid:
configure terminal class-map type inspect match-any internet-traffic-class match protocol http match protocol https match protocol dns match protocol icmp
Configureer een policy-map om verkeer op de class-maps te inspecteren die u zojuist hebt gedefinieerd:
configure terminal policy-map type inspect private-internet-policy class type inspect internet-traffic-class inspect
Configureer de privé- en internetzones en wijs routerinterfaces toe aan hun respectievelijke zones:
configure terminal zone security private zone security internet int bvi1 zone-member security private int fastethernet 0 zone-member security internet
Configureer de zone-pair en pas de juiste policy-map toe.
Opmerking: u hoeft momenteel alleen het privaat internetzonepaar te configureren om verbindingen te inspecteren die afkomstig zijn uit de privé-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
Dit voltooit de configuratie van Layer 7-inspectiebeleid op het privaat internet-zone-paar om HTTP-, HTTPS-, DNS- en ICMP-verbindingen van de clientzone naar de serverzone toe te staan en toepassingsinspectie op HTTP-verkeer toe te passen om ervoor te zorgen dat ongewenst verkeer geen TCP 80, HTTP-servicepoort kan doorgeven.
Afbeelding 5 illustreert de configuratie van het private DMZ-beleid.
Afbeelding 5: Service Inspection van Private Zone naar DMZ Zone
Het privé DMZ beleid voegt complexiteit toe omdat het een beter begrip van het netwerkverkeer tussen streken vereist. Dit beleid past Layer 7-inspectie toe vanaf de private zone op de DMZ. Dit staat verbindingen van de privé-zone aan DMZ toe en staat het terugkeerverkeer toe. Layer 7-inspectie biedt de voordelen van een striktere toepassingscontrole, betere beveiliging en ondersteuning voor toepassingen die een oplossing vereisen. Layer 7-inspectie, zoals vermeld, vereist echter een beter begrip van netwerkactiviteit, aangezien Layer 7-protocollen die niet voor inspectie zijn geconfigureerd niet tussen zones zijn toegestaan.
Definieer class-maps die het verkeer beschrijven dat u wilt toestaan tussen zones, gebaseerd op het eerder beschreven beleid:
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
Configureer beleid-kaarten om verkeer op de klasse-kaarten te inspecteren u net bepaalde:
configure terminal policy-map type inspect private-dmz-policy class type inspect L7-inspect-class inspect
Configureer de privé- en DMZ-zones en wijs routerinterfaces toe aan hun respectievelijke zones:
configure terminal zone security private zone security dmz int bvi1 zone-member security private int fastethernet 1 zone-member security dmz
Opmerking: u hoeft op dit moment alleen het privé-DMZ-zonepaar te configureren om verbindingen te inspecteren die afkomstig zijn uit de privé-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 is de configuratie van Layer 7-inspectiebeleid op de private DMZ voltooid om alle TCP-, UDP- en ICMP-verbindingen van de clientzone naar de serverzone toe te staan. Het beleid past geen correctie toe voor ondergeschikte kanalen, maar biedt een voorbeeld van eenvoudig beleid om de meeste toepassingsverbindingen aan te passen.
Afbeelding 6 illustreert de configuratie van Internet DMZ-beleid.
Afbeelding 6: Servicecontrole van Internet Zone naar DMZ Zone
Dit beleid past Layer 7-inspectie toe vanaf de internetzone op de DMZ. Dit staat verbindingen van de zone van Internet aan DMZ toe en staat het terugkeerverkeer van de gastheren DMZ aan de gastheren van Internet toe die de verbinding voortkwamen. 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 verwezenlijken nesten een klasse-kaart die de diensten binnen een andere klasse-kaart specificeert die verwijzingen een ACL om IP adressen te specificeren.
Definieer class-maps en ACL’s die het verkeer beschrijven dat u wilt toestaan tussen zones, gebaseerd op het eerder beschreven beleid.
Er moeten meerdere class-maps voor services worden gebruikt, aangezien 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. Let op het verschil in de klassekaarten. De klasse-kaarten die de diensten specificeren gebruiken het gelijke-om het even welk sleutelwoord om het even welke vermelde diensten toe te staan. De class-maps die ACL’s koppelen aan de service class-maps gebruiken het trefwoord match-all om te eisen dat aan beide voorwaarden in de class map moet worden voldaan om verkeer toe te staan:
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
Configureer beleid-kaarten om verkeer op de klasse-kaarten te inspecteren u net bepaalde:
configure terminal policy-map type inspect internet-dmz-policy class type inspect dns-http-acl-class inspect class type inspect smtp-acl-class inspect
Configureer de internet- en DMZ-zones en wijs routerinterfaces toe aan hun respectievelijke 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
Configureer de zone-pair en pas de juiste policy-map toe.
Opmerking: u hoeft momenteel alleen het internet DMZ-zonepaar te configureren, om verbindingen te inspecteren die afkomstig zijn uit de internetzone die naar de DMZ-zone reist, zoals hieronder weergegeven:
configure terminal zone-pair security internet-dmz source internet destination dmz service-policy type inspect internet-dmz-policy
Dit voltooit de configuratie van het adrespecifieke Layer 7-inspectiebeleid op het internet DMZ-zone-paar.
Deze volgende afbeelding illustreert de configuratie van het server-client beleid.
Afbeelding 7: Servicecontrole van servers Zone naar clients Zone
Het server-clients beleid past inspectie toe met een door de gebruiker gedefinieerde service. Layer 7-inspectie wordt toegepast vanaf de serverzone op de clientzone. Dit maakt X Windows verbindingen met een specifieke poortbereik van de serverzone tot de clientzone mogelijk en laat het retourverkeer toe. X Windows is geen native-ondersteund protocol in PAM, zodat 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 in een IEEE-bridge-groep geconfigureerd om geïntegreerde routing en bridging (IRB) te bieden voor overbrugging tussen de interfaces in de bridge-groep en voor routing naar andere subnetten via de virtuele interface van de bridge (BVI). Het transparante firewallbeleid past firewallinspectie voor verkeer toe dat de brug oversteekt, maar niet voor verkeer dat de brug-groep via BVI verlaat. Het inspectiebeleid is alleen van toepassing op verkeer dat de bruggroep oversteekt. Daarom in dit scenario, wordt de inspectie slechts toegepast op verkeer dat zich tussen de cliënten en de serverzones beweegt, die binnen de privé zone worden genesteld. Het beleid dat wordt toegepast tussen de privézone, de openbare zone en de DMZ-zone, komt alleen in het spel als het verkeer de bruggroep verlaat via de BVI. Wanneer het verkeer via de BVI vertrekt vanuit de client- of serverzones, wordt het transparante firewallbeleid niet aangeroepen.
Configureer PAM met een door de gebruiker gedefinieerde ingang voor X Windows.
X Windows-clients (waar toepassingen worden gehost) open verbindingen voor weergave informatie aan clients (waar de gebruiker werkt) in een bereik dat begint bij poort 6900.
Elke extra verbinding gebruikt opeenvolgende poorten, dus als een client 10 verschillende sessies op één host weergeeft, gebruikt de server poorten 6900-6909. Daarom als u het poortbereik van 6900 tot 6909 inspecteert, mislukken verbindingen die zijn geopend naar poorten na 6909:
configure terminal ip port-map user-Xwindows port tcp from 6900 to 6910
Bekijk PAM-documenten om extra PAM-vragen te beantwoorden of controleer de documentatie van de granulaire protocolinspectie voor informatie over de details van interoperabiliteit tussen PAM en Cisco IOS Firewall stateful inspection.
Definieer class-maps die het verkeer beschrijven dat u wilt toestaan tussen zones, gebaseerd op het eerder beschreven beleid:
configure terminal class-map type inspect match-any Xwindows-class match protocol user-Xwindows
Configureer beleid-kaarten om verkeer op de klasse-kaarten te inspecteren u net bepaalde:
configure terminal policy-map type inspect servers-clients-policy class type inspect Xwindows-class inspect
Configureer de client- en serverzones en wijs routerinterfaces toe aan hun respectievelijke zones.
Als u deze zones en toegewezen interfaces in de sectie Clients-Servers Policy Configuration hebt geconfigureerd, kunt u overslaan naar de zone-paardefinitie. Voor de volledigheid wordt overbrugging van de IRB-configuratie verstrekt:
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
Configureer de zone-pair en pas de juiste policy-map toe.
Opmerking: u hoeft momenteel alleen het zone-paar van de servers-clients te configureren om de verbindingen te inspecteren die in de serverzone zijn opgeslagen en die naar de clientzone gaan, zoals hieronder wordt getoond:
configure terminal zone-pair security servers-clients source servers destination clients service-policy type inspect servers-clients-policy
Hiermee is de configuratie van het door de gebruiker gedefinieerde inspectiebeleid in het zone-paar van de servers-clients voltooid, zodat X Windows-verbindingen van de serverzone naar de clientzone mogelijk zijn.
Afbeelding 8 illustreert de configuratie van het clientserverbeleid.
Afbeelding 8: Servicecontrole van Clients Zone naar servers
Het client-servers beleid is minder complex dan de anderen. Layer 4-inspectie wordt toegepast vanaf de clientzone op de serverzone. Dit maakt verbindingen mogelijk van de clientzone naar de serverzone en geeft verkeer terug. Layer 4-inspectie biedt het voordeel van eenvoud in de firewallconfiguratie, in die zin dat er slechts een paar regels nodig zijn om het meeste toepassingsverkeer toe te staan. 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 controlekanaal 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 netwerkgebruik moet worden gecontroleerd zodat slechts een paar toepassingen door de firewall worden toegestaan, moet ACL op uitgaand verkeer worden gevormd om de diensten te beperken die door de firewall worden toegestaan.
Beide routerinterfaces worden geconfigureerd in een IEEE-bruggroep, zodat dit firewallbeleid transparante firewallinspectie toepast. Dit beleid wordt toegepast op twee interfaces in een IEEE IP-bruggroep. Het inspectiebeleid is alleen van toepassing op verkeer dat de bruggroep doorkruist. Dit verklaart waarom de cliënten en de serverzones binnen de privé-zone worden genesteld.
Definieer class-maps die het verkeer beschrijven dat u wilt toestaan tussen zones, gebaseerd op het eerder beschreven beleid:
configure terminal class-map type inspect match-any L4-inspect-class match protocol tcp match protocol udp match protocol icmp
Configureer beleid-kaarten om verkeer op de klasse-kaarten te inspecteren u net bepaalde:
configure terminal policy-map type inspect clients-servers-policy class type inspect L4-inspect-class inspect
Configureer de clients en servers zones en wijs routerinterfaces toe aan hun respectievelijke zones:
configure terminal zone security clients zone security servers interface vlan 1 zone-member security clients interface vlan 2 zone-member security servers
Configureer de zone-pair en pas de juiste policy-map toe.
Opmerking: U hoeft momenteel alleen het zone-paar van de client-servers te configureren, om verbindingen te inspecteren die zijn gesourcet in de clientzone die naar de serverzone gaat, zoals hieronder getoond:
configure terminal zone-pair security clients-servers source clients destination servers service-policy type inspect clients-servers-policy
Hiermee is de configuratie van Layer 4-inspectiebeleid voor het zone-paar van de clientservers voltooid, zodat alle TCP-, UDP- en ICMP-verbindingen van de clientzone naar de serverzone mogelijk zijn. Het beleid is niet van toepassing fixup voor ondergeschikte kanalen maar biedt een voorbeeld van eenvoudig beleid om de meeste toepassingsverbindingen aan te passen.
Gegevensnetwerken profiteren vaak van de mogelijkheid om het transmissietarief van specifieke soorten netwerkverkeer te beperken en de impact van verkeer met een lagere prioriteit te beperken tot meer zaken-essentieel verkeer. Cisco IOS-software biedt deze mogelijkheid met traffic policing (verkeerspolitie), die de nominale snelheid en burst van het verkeer beperkt. Cisco IOS-software ondersteunt traffic policing sinds Cisco IOS-softwarerelease 12.1(5)T.
Cisco IOS-softwarerelease 12.4(9)T verbetert ZFW met snelheidsbeperking wanneer u de mogelijkheid toevoegt om verkeer te controleren dat overeenkomt met de definities van een specifieke klasse-kaart wanneer de firewall van de ene naar de andere veiligheidszone wordt gepasseerd. Dit biedt het gemak van één configuratiepunt om specifiek verkeer te beschrijven, firewallbeleid toe te passen, en politie dat de consumptie van de verkeersbandbreedte. ZFW verschilt van interface-based in die zin dat het alleen de acties overbrengt voor beleidsconformiteit en drop voor beleidsschending. ZFW kan geen verkeer voor DSCP markeren.
ZFW kan alleen bandbreedtegebruik in bytes/seconde, pakket/seconde en bandbreedtepercentage worden niet aangeboden specificeren. ZFW kan met of zonder interface-based worden toegepast. Daarom als extra mogelijkheden worden vereist, kunnen deze eigenschappen door interface-based worden toegepast. Als de interface-based wordt gebruikt in combinatie met een firewall, zorg er dan voor dat het beleid niet tegenstrijdig is.
ZFW-toezicht beperkt verkeer in een policy-map class-map tot een door de gebruiker gedefinieerde snelheidswaarde tussen 8.000 en 2.000.000.000 bits per seconde, met een configureerbare burstwaarde binnen het bereik van 1.000 tot 512.000.000 bytes.
ZFW-toezicht wordt geconfigureerd via een extra configuratielijn in de beleidskaart, 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>]
ZFW-beleid introduceerde ook sessiecontrole om de sessietelling voor verkeer te beperken in een beleidskaart die van toepassing is en overeenkomt met een klasse-map. Dit maakt het mogelijk om het Dos-beschermingsbeleid per klasse-map toe te passen. Effectief, dit staat granulaire controle op het aantal sessies toe die van toepassing is dat aanpast om het even welke bepaalde klasse-kaart die een streek-paar kruist. Als dezelfde class-map wordt gebruikt op meerdere policy-maps of zone-paren, kunnen verschillende sessielimieten worden toegepast op de verschillende class-map applicaties.
Session control wordt toegepast wanneer een parameter-map is geconfigureerd die het gewenste sessievolume bevat, dan wordt de parameter-map toegevoegd aan de inspectieactie die is toegepast op een klasse-map onder een policy-map:
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-kaarten kunnen alleen worden toegepast op de inspect actie en zijn niet beschikbaar op pas of drop acties.
ZFW-sessiecontrole- en -politieactiviteiten zijn zichtbaar met deze opdracht:
show policy-map type inspect zone-pair
Toepassingsinspectie biedt ZFW extra mogelijkheden. Het beleid van de toepassingsinspectie wordt toegepast bij Layer 7 van het OSI model, waar de gebruikerstoepassingen berichten verzenden en ontvangen die de toepassingen toestaan om nuttige mogelijkheden aan te bieden. Sommige toepassingen kunnen ongewenste of kwetsbare mogelijkheden bieden, zodat de berichten die aan deze mogelijkheden zijn gekoppeld, moeten worden gefilterd om activiteiten op de toepassingsservices te beperken.
Cisco IOS-softwarerelease ZFW biedt toepassingsinspectie en -controle op deze toepassingsservices:
HTTP
SMTP
POP3
IMAP
Sun RPC
P2P-toepassingsverkeer
IM-toepassingen
Toepassingsinspectie en -controle (AIC) varieert in capaciteit per dienst. HTTP-inspectie biedt granulaire filtering op verschillende soorten toepassingsactiviteit en biedt mogelijkheden om de overdrachtgrootte, de lengte van webadressen en browseractiviteit te beperken om naleving van toepassingsgedragsnormen af te dwingen en soorten inhoud te beperken die via de service worden overgedragen. AIC voor SMTP kan inhoudslengte beperken en protocolnaleving afdwingen. POP3- en IMAP-inspectie kunnen ervoor zorgen dat gebruikers beveiligde verificatiemechanismen gebruiken om te voorkomen dat er problemen met gebruikersreferenties ontstaan.
Toepassingsinspectie is ingesteld als een extra set van applicatiespecifieke klassekaarten en beleidskaarten, die vervolgens worden toegepast op de huidige inspectie klassekaarten en beleidskaarten door het bepalen van het toepassingsservicebeleid in de inspectie beleid-kaart.
Toepassingsinspectie kan worden toegepast op HTTP-verkeer om ongewenst gebruik van HTTP-servicepoort te controleren voor andere toepassingen zoals IM, P2P-bestandsdeling en tunneling toepassingen die andere firewalltoepassingen kunnen omleiden via TCP 80.
Configureer een klasse-kaart van toepassingsinspectie om verkeer te beschrijven dat toegestaan 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
Cisco IOS-softwarerelease 12.4(9)T introduceert verbeteringen in ZFW HTTP-inspectiemogelijkheden. Cisco IOS Firewall introduceerde HTTP-toepassingsinspectie in Cisco IOS-softwarerelease 12.3(14)T. Cisco IOS-softwarerelease 12.4(9)T vergroot de huidige mogelijkheden wanneer u toevoegt:
Mogelijk om verzoeken en antwoorden toe te staan, te weigeren en te bewaken op basis van de naam van de kop en de headerwaarden. Dit is handig om verzoeken en antwoorden te blokkeren die kwetsbare headervelden dragen.
Mogelijkheid om de grootte van verschillende elementen in de HTTP-aanvraag en reactiekoppen te beperken zoals maximale URL-lengte, maximale header-lengte, maximaal aantal headers, maximale header-line lengte, enzovoort. Dit is handig om bufferoverloop te voorkomen.
Mogelijkheid om verzoeken en antwoorden te blokkeren die meerdere headers van hetzelfde type bij zich hebben; bijvoorbeeld een verzoek met twee contentlengteheaders.
Mogelijkheid om verzoeken en antwoorden te blokkeren met niet-ASCII-headers. Dit is nuttig om verschillende aanvallen te voorkomen die binaire en andere niet-ASCII tekens gebruiken om wormen en andere schadelijke inhoud aan webservers te leveren.
De mogelijkheid om HTTP-methoden in door de gebruiker opgegeven categorieën te groeperen en de flexibiliteit om elk van de groepen te blokkeren/toestaan/bewaken, wordt aangeboden. 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 exploiteren. Veel van de niet-standaard methoden hebben een slecht beveiligingsrecord.
Methode om specifieke URI’s te blokkeren op basis van een door de gebruiker ingestelde reguliere expressie. Deze functie geeft een gebruiker de mogelijkheid om aangepaste URI en queries te blokkeren.
Mogelijkheid om spof header types (vooral server header type) met aangepaste strings. Dit is nuttig in een geval waar een aanvaller de reacties van de webserver analyseert en zoveel mogelijk informatie leert, dan lanceert een aanval die zwakheden in die bepaalde webserver exploiteert.
Mogelijk om een waarschuwing te blokkeren of uit te geven op een HTTP-verbinding als een of meer HTTP-parameterwaarden overeenkomen met waarden die door de gebruiker als reguliere expressie zijn ingevoerd. Enkele van de mogelijke HTTP-waardecontexten zijn header, body, gebruikersnaam, wachtwoord, gebruikersagent, aanvraagregel, statusregel en gedecodeerde CGI-variabelen.
De voorbeelden van de configuratie voor de verbeteringen van de toepassingsinspectie van HTTP veronderstellen een eenvoudig netwerk, dat in Beeld 9 wordt getoond.
Afbeelding 9: Toepassingsinspectie veronderstelt een eenvoudig netwerk
De firewall groepeert verkeer in twee klassen:
HTTP is gescheiden om specifieke inspectie van webverkeer mogelijk te maken. Hiermee kunt u toezicht configureren in de eerste sectie van dit document en HTTP-toepassingsinspectie in de tweede sectie. U kunt specifieke class-maps en policy-maps configureren voor P2P- en IM-verkeer in de derde sectie van dit document. Connectiviteit is toegestaan van de privé-zone naar de openbare zone. Van de openbare zone naar de privézone wordt geen verbinding tot stand gebracht.
Raadpleeg Bijlage C voor een volledige configuratie waarin het initiële beleid wordt geïmplementeerd.
HTTP-toepassingsinspectie (en ander beleid voor toepassingsinspectie) vereist een complexere configuratie dan de basisconfiguratie van Layer 4. U moet Layer 7-verkeersclassificatie en -beleid configureren om specifiek verkeer te herkennen dat u wilt besturen en om de gewenste actie toe te passen op gewenst en ongewenst verkeer.
HTTP-toepassingsinspectie (vergelijkbaar met andere soorten toepassingsinspectie) kan alleen worden toegepast op HTTP-verkeer. Aldus, moet u Layer 7 class-maps en policy-maps voor specifiek HTTP-verkeer definiëren, vervolgens een Layer-4 class-map specifiek voor HTTP definiëren en het Layer-7-beleid toepassen op HTTP-inspectie in een Layer-4 policy-map, als zodanig:
!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 verkeerskenmerken van HTTP-toepassingsinspectie worden gedefinieerd in een Layer 7-klasse-kaart:
De opdracht voor headerinspectie biedt de mogelijkheid om verzoeken of antwoorden waarvan de header overeenkomt met de geconfigureerde reguliere expressie toe te staan/te weigeren/te monitoren. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. 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>
Voorbeeld van gebruikscase
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
Kop lengte inspectie — Dit commando controleert de lengte van een verzoek of antwoord header en past actie toe als de lengte de ingestelde drempel overschrijdt. Handeling 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>
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om verzoeken en antwoorden te blokkeren die een headerlengte hebben groter dan 4096 bytes.
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
Kop tellen inspectie — Deze opdracht verifieert het aantal kop-lijnen (velden) in een verzoek/antwoord en past actie toe wanneer de telling de ingestelde drempel overschrijdt. Handeling 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>
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om een verzoek te blokkeren dat meer dan 16 headervelden heeft.
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
Kop veldinspectie — Dit commando biedt de mogelijkheid om verzoeken/antwoorden toe te staan/te weigeren/te monitoren die een specifiek HTTP-headerveld en een specifieke waarde bevatten. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. De toevoeging van de logactie veroorzaakt een syslog bericht:
APPFW-6- HTTP_HDR_FIELD_REGEX_MATCHED
Opdrachtgebruik:
match {request|response|req-resp} header <header-name>
Voorbeeld van gebruikscase
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 kop — Deze opdracht biedt de mogelijkheid om de lengte van een veldlijn van kop te beperken. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. De toevoeging van de logactie veroorzaakt een syslog bericht:
APPFW-6- HTTP_HDR_FIELD_LENGTH
Opdrachtgebruik:
match {request|response|req-resp} header <header-name> length gt <bytes>
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om een verzoek te blokkeren waarvan de cookie- en user-agent-veldlengte respectievelijk groter is dan 256 en 128.
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 veldherhaling van de header — Deze opdracht controleert of een verzoek of antwoord meerdere veldvelden heeft herhaald. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. Als deze optie is ingeschakeld, veroorzaakt de logactie een syslog-bericht:
APPFW-6- HTTP_REPEATED_HDR_FIELDS
Opdrachtgebruik:
match {request|response|req-resp} header <header-name>
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om een verzoek of antwoord te blokkeren dat meerdere veldheaderlijnen heeft. Dit is een van de nuttigste functionaliteiten 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
APPFW-6-HTTP_METHOD
Opdrachtgebruik:
match request method <method>
Voorbeeld van gebruikscase
Configureer een http appfw-beleid dat de HTTP-methoden in drie categorieën groepeert: veilig, onveilig en webdav. Deze worden in de volgende tabel getoond. Configureer handelingen zodanig dat:
Alle veilige methoden zijn toegestaan zonder log.
Alle onveilige methoden zijn toegestaan met log.
Alle webdav methoden worden geblokkeerd met log.
Veilige |
onveilig |
Webex DAV |
---|---|---|
KRIJG, HOOFD, OPTIE |
POST, PUT, CONNECT, TRACE |
BCOPY, BDELETE, BMOVE |
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 inspection— Dit commando biedt de mogelijkheid om verzoeken toe te staan/te weigeren/te monitoren waarvan de URI overeenkomt met de ingestelde reguliere inspectie. Dit geeft de gebruiker de mogelijkheid om aangepaste URL's en vragen te blokkeren. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. Toevoeging van de logactie veroorzaakt een syslog bericht:
APPFW-6- HTTP_URI_REGEX_MATCHED
Opdrachtgebruik:
match request uri regex <parameter-map-name>
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om een verzoek te blokkeren waarvan de URI overeenkomt met een van deze reguliere expressies:
.*cmd.exe
.*geslacht
.*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 length inspection — Deze opdracht verifieert de lengte van de URI die in een verzoek wordt verzonden en past de geconfigureerde actie toe wanneer de lengte de ingestelde drempel overschrijdt. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. Toevoeging van de logactie veroorzaakt een syslog bericht:
APPFW-6- HTTP_URI_LENGTH
Opdrachtgebruik:
match request uri length gt <bytes>
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om een alarm te activeren 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 inspection — Dit commando biedt de mogelijkheid om een verzoek waarvan de argumenten (parameters) overeenkomen met de ingestelde reguliere inspectie toe te laten, te ontkennen of te controleren. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. Toevoeging van de logactie veroorzaakt een syslog bericht:
APPFW-6- HTTP_ARG_REGEX_MATCHED
Opdrachtgebruik:
match request arg regex <parameter-map-name>
Configuratie van 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
Inspectie van de lengte van het argument — Dit bevel verifieert de lengte van de argumenten die in een verzoek worden verzonden en past de gevormde actie toe wanneer de lengte gevormde drempel overschrijdt. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. Toevoeging van de logactie veroorzaakt een syslog bericht:
APPFW-6- HTTP_ARG_LENGTH
Opdrachtgebruik:
match request arg length gt <bytes>
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om een alarm te activeren wanneer de lengte van een argument groter is dan 512 bytes.
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 van reguliere expressies opgeven die moeten worden gekoppeld aan de inhoud van het verzoek of antwoord. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. 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>
Voorbeeld van gebruikscase
Configureer een http appfw om een respons te blokkeren waarvan het lichaam 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
Lichaamslengteconspectie (Content) — Met deze opdracht wordt de omvang van het bericht geverifieerd dat via verzoek of antwoord wordt verstuurd. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. 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>
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om een http-sessie te blokkeren die meer dan 10K bytes in een verzoek of antwoord bevat.
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 deze opdracht kan de gebruiker een lijst opgeven van reguliere expressies die moeten worden gematcht tegen de statusregel van een respons. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. Toevoeging van de logactie veroorzaakt een syslog bericht:
APPFW-6-HTTP_STLINE_REGEX_MATCHED
Opdrachtgebruik:
match response status-line regex <class-map-name>
Voorbeeld van gebruikscase
Configureer een http-app om een alarm te registreren wanneer wordt geprobeerd een verboden pagina te openen. Een verboden pagina bevat meestal een 403-statuscode en de statusregel ziet eruit als HTTP/1.0 403-pagina verboden\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
Content-type inspectie — Deze opdracht verifieert of het content-type van de berichtkop in de lijst met ondersteunde inhoudstypen staat. Het verifieert ook dat de inhoud-type van de kopbal de inhoud van de berichtgegevens of het gedeelte van het entiteitlichaam aanpast. Als de sleutelwoordwanverhouding wordt gevormd, verifieert het bevel het inhoudstype van het reactiebericht tegen de toegelaten gebiedswaarde van het verzoekbericht. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. Toevoeging van de logactie veroorzaakt het aangewezen 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]
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om een http-sessie te blokkeren die verzoeken en antwoorden bevat die een onbekend inhoudstype hebben.
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
Poortmisbruikinspectie — Deze opdracht wordt gebruikt om te voorkomen dat http poort (80) wordt misbruikt voor andere toepassingen zoals IM, P2P, tunneling, enzovoort. Kan actie toestaan of resetten worden toegepast op een verzoek of antwoord dat voldoet aan de klasse-kaartcriteria. Toevoeging van de logactie veroorzaakt het aangewezen 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}
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om een http-sessie te blokkeren die voor IM-toepassing wordt misbruikt.
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
Strict-http inspection — Deze opdracht maakt strikte controle van de protocolconformiteit tegen HTTP-verzoeken en antwoorden mogelijk. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. Toevoeging van de logactie veroorzaakt een syslog bericht:
APPFW-4- HTTP_PROTOCOL_VIOLATION
Opdrachtgebruik:
match req-resp protocol-violation
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om verzoeken of antwoorden te blokkeren die inbreuk maken op 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
Transfer-Encoding Inspection — Deze opdracht biedt de mogelijkheid om verzoek/antwoord toe te laten, te ontkennen of te monitoren, waarvan de overdracht encodering type overeenkomt met geconfigureerd type. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. 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}
Voorbeeld van gebruikscase
Configureer een http appfw-beleid om een verzoek of antwoord te blokkeren dat comprimeren bij type codering bevat.
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 inspection — Deze opdracht controleert of een antwoord Java-applet heeft en past de ingestelde actie toe bij detectie van applet. Sta toe of stel actie terug kan worden toegepast op een verzoek of een reactie die de klasse-kaart criteria aanpassen. Toevoeging van de logactie veroorzaakt een syslog bericht:
APPFW-4- HTTP_JAVA_APPLET
Opdrachtgebruik:
match response body java-applet
Voorbeeld van gebruikscase
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
Cisco IOS-softwarerelease 12.4(4)T biedt eerst ondersteuning voor IBM-toepassingscontrole. De eerste release van ZFW heeft IM Application in de ZFW interface niet ondersteund. Als IM applicatiecontrole gewenst was, konden gebruikers niet migreren naar de ZFW configuratie interface. Cisco IOS-softwarerelease 12.4(9)T introduceert ZFW-ondersteuning voor IM-inspectie, die Yahoo ondersteunt! Messenger (YM), MSN Messenger (MSN) en AOL Instant Messenger (AIM). Cisco IOS-softwarerelease 12.4(9)T is de eerste versie van Cisco IOS-software die native Cisco IOS-firewallondersteuning 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 fundamentele stateful inspection kan bieden om het verkeer toe te laten of te ontkennen, evenals granulaire Layer 7-controle op specifieke activiteiten in de verschillende protocollen, zodat bepaalde toepassingsactiviteiten zijn toegestaan terwijl anderen worden geweigerd.
SDM 2.2 introduceerde P2P-toepassingscontrole in het gedeelte Firewallconfiguratie. SDM paste een Network-Based Application Recognition (NBAR)- en QoS-beleid toe om P2P-toepassingsactiviteit te detecteren en te bewaken tot een lijnsnelheid van nul, en om al P2P-verkeer te blokkeren. Dit riep het probleem op dat CLI-gebruikers, die P2P-ondersteuning in de Cisco IOS-firewall CLI verwachtten, P2P-blokkering in de CLI niet konden configureren, tenzij ze op de hoogte waren van de benodigde NBAR/QoS-configuratie. Cisco IOS-softwarerelease 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
eDonkey
FastTrack
Gnutella
KaZaA / KaZaA2
WinMX
P2P-toepassingen zijn bijzonder moeilijk te detecteren als gevolg van poorthoppinggedrag en andere trucs om detectie te vermijden, evenals problemen die worden geïntroduceerd door frequente veranderingen en updates van P2P-toepassingen die het gedrag van de protocollen wijzigen. ZFW combineert stateful inspection voor native firewalls met de traffic-recognition-functies van NBAR om P2P-toepassingscontrole te leveren in de CPL-configuratieinterface van ZFW. NBAR biedt twee uitstekende voordelen:
Optionele heuristische toepassingsherkenning om toepassingen te herkennen ondanks complex, moeilijk te detecteren gedrag
Uitbreidbare infrastructuur die een updatemechanisme biedt om op de hoogte te blijven van protocolupdates en wijzigingen
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 native Application Service-poorten 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 handtekeningsoptie in het matchprotocol [service-name]. Wanneer de handtekeningsoptie aan het eind van de verklaring van het matchprotocol wordt toegevoegd, wordt de heuristiek NBAR toegepast op het verkeer om naar tabellen in verkeer te zoeken die op specifieke P2P toepassingsactiviteit wijzen. Dit omvat port-hopping en andere veranderingen in toepassingsgedrag om verkeersopsporing te vermijden. Dit niveau van traffic inspection staat voor een verhoogd CPU-gebruik en een verminderde doorvoersnelheid voor het netwerk. Als de handtekeningsoptie niet wordt toegepast, wordt de op NBAR-gebaseerde heuristische analyse niet toegepast om haven-hoppinggedrag te ontdekken, en het gebruik van cpu in niet in de zelfde mate beïnvloed.
Native service inspectie brengt het nadeel dat het niet in staat is om de controle over P2P applicaties te behouden in het geval dat de applicatie naar een niet-standaard bron en bestemmingshaven gaat, of als de applicatie wordt bijgewerkt om te beginnen met actie op een niet-herkend poortnummer:
Toepassing | Native poorten (zoals herkend in 12.4(15)T PAM-lijst) |
---|---|
bittorrent | TCP 6881-689 |
edonkey | TCP-netwerkmodule 4662 |
vast spoor | TCP-netwerkmodule 1214 |
gnutella | TCP 6346-6349 TCP 6355.5634 UDP 6346-6348 |
kazaa2 | Afhankelijk van PAM |
vensterbank | TCP-netwerkmodule 699 |
Als u P2P-verkeer wilt toestaan (inspecteren), kunt u aanvullende configuratie nodig hebben. Sommige toepassingen kunnen meerdere P2P-netwerken gebruiken of specifieke gedragingen implementeren die u in uw firewallconfiguratie moet aanpassen om de toepassing te laten werken:
BitTorrent-clients communiceren meestal met trackers (peer directory servers) via http dat draait op een niet-standaard poort. Dit is meestal TCP 6969, maar je moet de torrent-specifieke tracker poort controleren. Als u BitTorrent wilt toestaan, is de beste methode om de extra poort aan te passen om HTTP te configureren als een van de overeenkomende protocollen en TCP 6969 toe te voegen aan HTTP met de opdracht ip port-map:
ip port-map http port tcp 6969
Je moet http en bittorrent definiëren als de matchcriteria toegepast in de class-map.
eDonkey lijkt verbindingen te initiëren die worden gedetecteerd als zowel eDonkey als Gnutella.
KaZaA-inspectie is volledig afhankelijk van NBAR-handtekeningsdetectie.
Layer 7 (Application) Inspection verbetert Layer 4 Inspection, met de mogelijkheid om servicespecifieke acties te herkennen en toe te passen, zoals selectief blokkeren of toestaan van bestandsdoorzoeking, bestandsoverdracht en tekstchat-mogelijkheden. Service-specifieke mogelijkheden variëren 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:
edonkey
vast spoor
gnutella
kazaa2
Elk van deze toepassingen biedt variabele applicatiespecifieke opties voor matchcriteria:
edonkey
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
vast spoor
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 huidige P2P protocollen kunnen worden geladen met de dynamische pdlm update functionaliteit van NBAR. Dit is de configuratieopdracht om de nieuwe PDLM te laden:
ip nbar pdlm <file-location>
Het nieuwe protocol is beschikbaar in overeenkomende protocolopdrachten voor klassetype inspecteren. Als het nieuwe P2P protocol diensten (sub-protocollen) heeft, inspecteert de nieuwe Layer 7 klasse-map-types, evenals Layer 7-matchcriteria, worden beschikbaar.
Cisco IOS-softwarerelease 12.4(4)T introduceerde IM-toepassingsinspectie en -controle. IM-ondersteuning is niet met ZFW geïntroduceerd in 12.4(6)T, zodat gebruikers geen IM-controle en ZFW in hetzelfde firewallbeleid konden toepassen, omdat ZFW en oudere firewallfuncties niet op een bepaalde interface kunnen samengaan.
Cisco IOS-softwarerelease 12.4(9)T ondersteunt stateful inspection en toepassingscontrole voor deze IM-services:
AOL Instant Messenger
MSN Messenger
Yahoo! Messenger
De IM-inspectie verschilt enigszins van de meeste diensten, aangezien de IM-inspectie de toegang tot een specifieke groep hosts voor elke gegeven dienst controleert. De IM-diensten baseren zich over het algemeen op een relatief permanente groep directory servers, die cliënten moeten kunnen contacteren om toegang te krijgen tot de IM-dienst. IM-toepassingen zijn vaak zeer moeilijk te controleren vanuit een protocol- of servicemodel. De meest effectieve manier om deze applicaties te controleren is het beperken van de toegang tot de vaste IM servers.
IM inspectie en controle biedt zowel Layer 4 Stateful inspection
en Layer 7-toepassingscontrole.
Layer 4 inspection 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 op meerdere poorten contact opnemen met hun servers om hun functionaliteit te behouden. Om een bepaalde IM-dienst met de actie inspecteren toe te staan, hebt u geen serverlijst nodig om de toegestane toegang tot de servers van de IM-dienst te definiëren. Wanneer u echter een class-map configureert die een bepaalde IM-service, zoals AOL Instant Messenger, specificeert en de drop-actie toepast in de bijbehorende policy-map, kan de IM-client veroorzaken om te proberen en een andere poort te vinden waar verbinding met het 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 aan de IM-toepassing is gekoppeld:
!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 Yahoo IM-serverlijst 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 dient de serverlijst toe te passen 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 naamresolutie in te schakelen.
IM-servernamen zijn vrij dynamisch. U moet periodiek controleren dat uw geconfigureerde IM-serverlijsten volledig en correct zijn.
Layer 7 (Application) Inspection verbetert Layer 4 Inspection, met de mogelijkheid om servicespecifieke acties te herkennen en toe te passen, zoals selectief te blokkeren of toe te staan tekstchat-mogelijkheden en ontkent andere servicemogelijkheden.
IM Application Inspection biedt momenteel de mogelijkheid om onderscheid te maken tussen tekstchat-activiteiten en alle andere applicatiediensten. Om IM-activiteit tot tekstchat te beperken, configureer je 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 de 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
ZFW biedt URL-filtermogelijkheden om de toegang tot webcontent te beperken tot wat is gespecificeerd door een witte of zwarte lijst die op de router is gedefinieerd, of door domeinnamen door te sturen naar een URL-filtreerserver om de toegang tot specifieke domeinen te verifiëren. ZFW URL-filtering in Cisco IOS-softwarereleases 12.4(6)T tot 12.4(15)T wordt toegepast als een extra beleidsactie die vergelijkbaar is met toepassingsinspectie.
Voor server-based URL filtering, moet u een parameter-kaart bepalen die de urlfilter serverconfiguratie 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 van domeinen of subdomeinen bepalen die specifiek worden toegestaan of ontkend, terwijl de omgekeerde actie wordt toegepast op verkeer dat niet de lijst aanpast:
parameter-map type urlfilter websense-parmap exclusive-domain deny .example.com exclusive-domain permit .cisco.com
Als een zwarte lijst URL is gedefinieerd met opties voor ontkennen in de definities van exclusieve domeinen, zijn alle andere domeinen toegestaan. Als er "vergunningen" zijn gedefinieerd, moeten alle toegestane domeinen expliciet worden gespecificeerd, vergelijkbaar met de functie van IP-toegangscontrolelijsten.
Stel een class-map in die overeenkomt met HTTP-verkeer:
class-map type inspect match-any http-cmap match protocol http
Definieer een policy-map die uw class-map associeert met inspect en urlfilter acties:
policy-map type inspect http-filter-pmap class type inspect http-cmap inspect urlfilter websense-parmap
Dit vormt de minimumvereiste om met een URL-filtreerserver te communiceren. Er zijn verschillende opties beschikbaar om aanvullend URL-filtergedrag te definiëren.
Sommige netwerkimplementaties willen URL-filtering toepassen voor sommige hosts of subnetten en URL-filtering voor andere hosts omzeilen. Bijvoorbeeld, in Afbeelding 9, moeten alle hosts in de privé-zone HTTP-verkeer gecontroleerd door een URL-filterserver, behalve de specifieke host 192.168.1.101.
Afbeelding 10: URL-filtering van voorbeeldtopologie
Dit kan worden bereikt als u twee verschillende klasse-kaart kaarten definieert:
Eén class-map die alleen HTTP-verkeer aanpast voor de grotere groep hosts die URL-filtering ontvangen.
Eén class-map voor de kleinere groep hosts, die geen URL-filtering ontvangen. De tweede klasse-kaart komt overeen met HTTP-verkeer en een lijst met hosts die zijn vrijgesteld van het URL-filterbeleid.
Beide class-maps worden geconfigureerd in een policy-map, maar slechts één ontvangt de urlfilter-actie:
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
De meeste ingenieurs van de netwerkveiligheid zijn oncomfortabel als zij de het beheersinterfaces van de router (bijvoorbeeld, SSH, Telnet, HTTP, HTTPS, SNMP, etc.) aan openbaar Internet blootstellen, en onder bepaalde omstandigheden, is de controle nodig voor LAN toegang tot de router eveneens. Cisco IOS-software biedt een aantal opties om de toegang tot de verschillende interfaces te beperken, waaronder de functiefamilie Network Foundation Protection (NFP), verschillende toegangscontrolemechanismen voor beheerinterfaces en de zelfzone van ZFW. U moet andere functies, zoals VTY-toegangscontrole, bescherming van het beheervliegtuig en SNMP-toegangscontrole bekijken om te bepalen welke combinatie van routerbeheerfuncties het beste werkt voor uw specifieke toepassing.
Over het algemeen, is de NFP eigenschapfamilie meest geschikt voor controle van verkeer dat voor de router zelf wordt bestemd. Raadpleeg Control Plane Security Overzicht in Cisco IOS-software voor informatie over routerbescherming met de NFP-functies.
Als u besluit om ZFW toe te passen om verkeer te besturen van en naar de IP-adressen op de router zelf, moet u begrijpen dat het standaard firewallbeleid en de functies verschillen van die welke beschikbaar zijn voor transitverkeer. Transit verkeer wordt gedefinieerd als netwerkverkeer waarvan de bron- en bestemmings-IP-adressen niet overeenkomen met IP-adressen die op een van de routerinterfaces worden toegepast, en het verkeer veroorzaakt niet dat de router bijvoorbeeld netwerkcontroleberichten zoals verloopdatums van ICMP TTL of onbereikbare berichten voor netwerk/host verstuurt.
ZFW past een standaard deny-all beleid toe op verkeer dat zich tussen zones beweegt, behalve, zoals vermeld in de algemene regels, verkeer in elke zone die direct naar de adressen van de interfaces van de router stroomt impliciet is toegestaan. Dit verzekert dat de connectiviteit aan de beheersinterfaces van de router wordt gehandhaafd wanneer een configuratie van de streekfirewall op de router wordt toegepast. Als de zelfde ontkennen-alle beleid beïnvloedde connectiviteit rechtstreeks aan de router, zou een volledige configuratie van het beheersbeleid moeten worden toegepast alvorens de streken op de router worden gevormd. Dit zou waarschijnlijk de beheersconnectiviteit verstoren als het beleid verkeerd werd geïmplementeerd of in de verkeerde volgorde werd toegepast.
Wanneer een interface wordt geconfigureerd om een zone lid te zijn, zijn de hosts die zijn aangesloten op de interface inbegrepen in de zone. Verkeer dat naar en van de IP-adressen van de interfaces van de router stroomt, wordt echter niet bepaald door het zonebeleid (met uitzondering van de omstandigheden die in de opmerking in afbeelding 10 worden beschreven). In plaats daarvan, worden alle IP interfaces op de router automatisch gemaakt deel van de zelf-streek wanneer ZFW wordt gevormd. Om IP-verkeer te controleren dat zich naar de interfaces van de router verplaatst 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 omgekeerd (zie afbeelding 11).
Afbeelding 11: Beleid toepassen tussen netwerkzones en routerzelfzone
Hoewel de router een standaard-sta beleid tussen alle zones en de zelf-zone aanbiedt, als een beleid van om het even welke zone aan de zelf-zone wordt gevormd, en geen beleid van zelf aan de gebruiker-configureerbare interface-connected zones van de router wordt gevormd, ontmoet al router-voortgekomen verkeer de verbonden-zone aan zelf-streek beleid bij zijn terugkeer van de router en wordt geblokkeerd. Aldus, moet het router-voortgekomen verkeer worden geïnspecteerd om zijn terugkeer naar de zelf-streek toe te staan.
Opmerking: Cisco IOS-software gebruikt altijd het IP-adres dat is gekoppeld aan een interface met de dichtstbijzijnde doelhosts voor verkeer, zoals syslog, tftp, telnet en andere besturingsplane-services, en onderwerpt dit verkeer aan een firewallbeleid met zelfzone. Als een service echter een specifieke interface definieert als de bron-interface met opdrachten die bestaan uit, maar niet beperkt zijn tot, het vastleggen van de bron-interface [type nummer], de ip tftp bron-interface [type nummer] en de ip telnet bron-interface [type nummer] , wordt het verkeer onderworpen aan de zelfzone.
Opmerking: sommige services (met name routers 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.
Zelfzonebeleid heeft een beperkte functionaliteit in vergelijking met het beleid dat beschikbaar is voor transitoverkeerszoneparen:
Zoals het geval was met klassieke stateful inspection, is het routerverkeer beperkt tot TCP, UDP, ICMP en complexe protocolinspectie voor H.323.
Application Inspection is niet beschikbaar voor beleid in zelfzones.
Sessiebeperkingen en snelheidsbeperkingen kunnen niet worden geconfigureerd op basis van zelfzonebeleid.
Onder de meeste omstandigheden, zijn dit wenselijke toegangsbeleid voor de diensten van het routerbeheer:
Ontken alle connectiviteit van Telnet, aangezien het duidelijke tekstprotocol van Telnet gebruikersgeloofsbrieven en andere gevoelige informatie gemakkelijk blootstelt.
Sta SSH-verbindingen toe van elke gebruiker in elke zone. SSH versleutelt gebruikersreferenties en sessiegegevens, die bescherming bieden tegen kwaadaardige gebruikers die pakketopnametools gebruiken om te kijken naar gebruikersactiviteit en gebruikersreferenties of gevoelige informatie zoals routerconfiguratie te compromitteren. SSH versie 2 biedt een sterkere bescherming en pakt specifieke kwetsbaarheden aan die inherent zijn aan SSH versie 1.
Sta HTTP connectiviteit aan de router van de privé zones toe als de privé zone betrouwbaar is. Anders, als de privé zone het potentieel voor kwaadwillige gebruikers om informatie te compromitteren herbergt, gebruikt HTTP geen encryptie om beheersverkeer te beschermen, en kan gevoelige informatie zoals gebruikersgeloofsbrieven of configuratie openbaren.
HTTPS-connectiviteit vanuit elke zone toestaan. Overeenkomstig met SSH versleutelt HTTPS sessiegegevens en gebruikersreferenties.
Beperk SNMP-toegang tot een specifieke host of subnetverbinding. SNMP kan worden gebruikt om routerconfiguratie aan te passen en configuratieinformatie te onthullen. SNMP moet worden geconfigureerd met toegangscontrole voor de verschillende gemeenschappen.
Blokkeer ICMP-verzoeken van het openbare internet naar het privaat-zoneadres (hierbij wordt aangenomen dat het privaat-zoneadres routable is). Eén of meer openbare adressen kunnen indien nodig worden blootgesteld aan ICMP-verkeer voor probleemoplossing in het netwerk. Verschillende ICMP-aanvallen kunnen worden gebruikt om routerbronnen te overweldigen of netwerktopologie en architectuur te herkennen.
Een router kan dit type van beleid met de toevoeging van twee streek-paren voor elke streek toepassen die moet worden gecontroleerd. Elk zone-paar voor verkeer naar of vanuit de router zelf-zone moet worden aangepast door het respectievelijke beleid in de tegenovergestelde richting, tenzij verkeer niet in de tegenovergestelde richting wordt gegenereerd. Er kan één policy-map voor zowel inkomende als uitgaande zone-paren worden toegepast die al het verkeer beschrijft, of er kunnen specifieke policy-maps per zone-paar worden toegepast. De configuratie van specifieke zone-paren per beleid-kaart verstrekt granularity om activiteit te bekijken die elke beleid-kaart aanpast.
Een voorbeeldnetwerk met een SNMP-beheerstation op 172.17.100.11 en een TFTP-server op 172.17.100.17, deze uitvoer biedt een voorbeeld van het gehele toegangsbeleid voor de beheer-interface:
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 zelfzonebeleid niet de mogelijkheid om TFTP-overdrachten te inspecteren. Aldus, moet de firewall al verkeer aan en van de server van TFTP overgaan als TFTP door de firewall moet overgaan.
Als de router IPsec VPN-verbindingen beëindigt, moet u ook een beleid definiëren om IPSec ESP, IPSec AH, ISAKMP en NAT-T IPSec (UDP 4500) over te gaan. Dit hangt af van welke diensten nodig zijn op basis van uw gebruik. Dit volgende beleid kan worden toegepast naast het hierboven genoemde beleid. Merk de verandering in de beleid-kaarten waar een klasse-kaart voor het verkeer van VPN met een pasactie is opgenomen op. Typisch, is het gecodeerde verkeer betrouwbaar, tenzij uw veiligheidsbeleid verklaart dat u gecodeerd verkeer aan en van gespecificeerde endpoints 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
Raadpleeg Releaseopmerking voor Cisco Wide Area Application Services (Software versie 4.0.13) - Nieuwe functies voor Software versie 4.0.13 voor een toepassingsopmerking die configuratievoorbeelden en gebruikshandleidingen biedt
ZFW introduceert nieuwe opdrachten om de beleidsconfiguratie te bekijken en de firewallactiviteit te bewaken.
Beschrijving van weergavezone en de interfaces in een bepaalde zone:
show zone security [<zone-name>]
Wanneer de zonenaam niet inbegrepen is, toont het bevel de informatie van alle gevormde streken.
Router#show zone security z1 zone z1 Description: this is test zone1 Member Interfaces: Ethernet0/0
Toont de bronzone, de bestemmingszone en het beleid in bijlage aan het zone-paar:
show zone-pair security [source <source-zone-name>] [destination <destination-zone-name>]
Wanneer geen bron of bestemming wordt gespecificeerd, worden alle zone-paren met bron, bestemming, en het bijbehorende beleid getoond. Wanneer alleen de bron/bestemming zone wordt vermeld, worden alle zone-paren die deze zone bevatten als de bron/bestemming weergegeven.
Router#show zone-pair security zone-pair name zp Source-Zone z1 Destination-Zone z2 service-policy p1
Toont een gespecificeerde beleidskaart:
show policy-map type inspect [<policy-map-name> [class <class-map-name]]
Wanneer de naam van een policy-map niet is gespecificeerd, worden alle policy-maps van het type geïnspecteerd (samen met Layer 7 policy-maps die een subtype bevatten).
Router#show policy-map type inspect p1 Policy Map type inspect p1 Class c1 Inspect
Toont de runtime inspecteren type beleid-kaart statistieken momenteel op een gespecificeerde streek-paar.
show policy-map type inspect zone-pair [zone-pair-name] [sessions]
Wanneer geen zone-paar naam wordt vermeld, worden beleidskaarten op alle zone-paren weergegeven.
De sessiesoptie geeft de inspectiesessies weer die door de policy-map-toepassing op de opgegeven zone-paar zijn gemaakt.
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 sleutelwoord urlfilter toont de urlfilter-gerelateerde statistieken die betrekking hebben op de gespecificeerde beleid-kaart (of beleid-kaarten op alle doelstellingen wanneer geen zone-paar naam wordt gespecificeerd):
show policy-map type inspect zone-pair [zone-pair-name] [urlfilter [cache]]
Wanneer het cachesleutelwoord samen met urlfilter wordt gespecificeerd, toont het het urlfiltercachegeheugen (van IP adressen).
Samenvatting van de opdracht beleidskaart voor show voor inspecteren van beleidskaarten:
show policy-map type inspect inspect { <policy name> [class <class name>] | zone-pair [<zone-pair name>] [sessions | urlfilter cache] }
ZFW biedt DoS-bescherming om netwerkengineers te waarschuwen voor dramatische veranderingen in netwerkactiviteit en om ongewenste activiteit te beperken om de impact van veranderingen in netwerkactiviteit te verminderen. ZFW houdt een aparte teller aan voor de klassenkaart van elke beleidskaart. Dus, als één klasse-kaart wordt gebruikt voor twee verschillende zone-paren' beleid-kaarten, worden twee verschillende reeksen van DoS-beschermingstellers toegepast.
ZFW biedt standaard DoS-aanvalsbeperking op Cisco IOS-softwarereleases vóór 12.4(11)T. Het standaardgedrag voor DoS-bescherming is gewijzigd met Cisco IOS-softwarerelease 12.4(11)T.
Raadpleeg Defining Strategies to Protect Against TCP SYN Denial of Service Attacks voor meer informatie over TCP SYN DoS-aanvallen.
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
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
Dit voorbeeld biedt een eenvoudige configuratie als basis om functies te testen voor verbeteringen van de Cisco IOS-software ZFW. Deze configuratie is een modelconfiguratie voor twee zones, zoals geconfigureerd op een 1811-router. De privé-zone wordt toegepast op de vaste routerpoorten van de switch, zodat alle hosts op de switch poorten zijn verbonden met VLAN 1. De openbare zone wordt toegepast op Fast Ethernet 0 (zie afbeelding 12).
Afbeelding 12: Public Zone toegepast op Fast Ethernet 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
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
3.0 |
02-Apr-2024 |
Bijgewerkt PDF, beeldonderschrift, grammatica en opmaak. |
2.0 |
28-Sep-2022 |
Hercertificering |
1.0 |
28-Aug-2007 |
Eerste vrijgave |