Access Control Lists

9.0 Access Control Lists

9.0.1 Introductie

Netwerkbeveiliging is een enorm onderwerp en veel ervan valt ver buiten het bestek van deze cursus. Een van de belangrijkste vaardigheden die een netwerkbeheerder nodig heeft, is echter het beheersen van toegangsbeheerlijsten (ACL’s).

Netwerkontwerpers gebruiken firewalls om netwerken te beschermen tegen ongeoorloofd gebruik. Firewalls zijn hardware- of softwareoplossingen die het netwerkbeveiligingsbeleid afdwingen. Denk aan een slot op een deur naar een kamer in een gebouw. Het slot laat alleen geautoriseerde gebruikers met een sleutel of toegangskaart door de deur. Evenzo filtert een firewall ongeautoriseerde of potentieel gevaarlijke pakketten uit het netwerk. Op een Cisco-router kunt u een eenvoudige firewall configureren die basisfuncties voor het filteren van verkeer biedt met behulp van ACL’s. Beheerders gebruiken ACL’s om verkeer te stoppen of alleen gespecificeerd verkeer op hun netwerken toe te staan.

Een ACL is een sequentiële lijst van verklaringen voor toestaan of weigeren die van toepassing zijn op adressen of protocollen op de bovenste laag. ACL’s bieden een krachtige manier om verkeer van en naar een netwerk te beheren. ACL’s kunnen worden geconfigureerd voor alle gerouteerde netwerkprotocollen.

De belangrijkste reden om ACL’s te configureren is om een netwerk te beveiligen. In dit hoofdstuk wordt uitgelegd hoe u standaard en uitgebreide ACL’s op een Cisco-router kunt gebruiken als onderdeel van een beveiligingsoplossing. Inbegrepen zijn tips, overwegingen, aanbevelingen en algemene richtlijnen voor het gebruik van ACL’s.

Dit hoofdstuk biedt de mogelijkheid om uw beheersing van ACL’s te ontwikkelen met een reeks lessen, activiteiten en laboratoriumoefeningen.

9.1. IP ACL werking

9.1.1. Doel van ACL’s

9.1.1.1. Wat is een ACL?

Een ACL is een reeks IOS-opdrachten die bepalen of een router pakketten doorstuurt of laat vallen op basis van informatie in de pakketheader. ACL’s behoren tot de meest gebruikte functies van Cisco IOS-software.

Indien geconfigureerd, voeren ACL’s de volgende taken uit:

Beperk netwerkverkeer om de netwerkprestaties te verbeteren. Als het bedrijfsbeleid bijvoorbeeld geen videoverkeer op het netwerk toestaat, kunnen ACL’s die videoverkeer blokkeren, worden geconfigureerd en toegepast. Dit zou de netwerkbelasting aanzienlijk verminderen en de netwerkprestaties verbeteren.
Zorg voor controle van de verkeersstroom. ACL’s kunnen de levering van routeringsupdates beperken. Als updates niet nodig zijn vanwege netwerkomstandigheden, blijft bandbreedte behouden.
Zorg voor een basisniveau van beveiliging voor netwerktoegang. ACL’s kunnen één host toegang geven tot een deel van het netwerk en voorkomen dat een andere host toegang krijgt tot hetzelfde gebied. Toegang tot het Human Resources-netwerk kan bijvoorbeeld worden beperkt tot geautoriseerde gebruikers.
Filter het verkeer op basis van het type verkeer. Een ACL kan bijvoorbeeld e-mailverkeer toestaan, maar al het Telnet-verkeer blokkeren.
Scherm hosts af om toegang tot netwerkdiensten toe te staan of te weigeren. ACL’s kunnen een gebruiker toestemming geven of weigeren om toegang te krijgen tot bestandstypen, zoals FTP of HTTP.

Een router heeft standaard geen ACL’s geconfigureerd; daarom filtert een router standaard geen verkeer. Verkeer dat de router binnenkomt, wordt uitsluitend gerouteerd op basis van informatie in de routeringstabel. Wanneer echter een ACL op een interface wordt toegepast, voert de router de extra taak uit om alle netwerkpakketten te evalueren terwijl ze door de interface gaan om te bepalen of het pakket kan worden doorgestuurd.

Naast het toestaan of weigeren van verkeer, kunnen ACL’s worden gebruikt voor het selecteren van typen verkeer die moeten worden geanalyseerd, doorgestuurd of op andere manieren verwerkt. ACL’s kunnen bijvoorbeeld worden gebruikt om verkeer te classificeren om prioriteitsverwerking mogelijk te maken. Deze mogelijkheid is vergelijkbaar met het hebben van een VIP-pas bij een concert of sportevenement. De VIP-pas geeft geselecteerde gasten privileges die niet worden aangeboden aan houders van een algemene toegangskaart, zoals toegang met voorrang of toegang tot een beperkt gebied.

De afbeelding toont een voorbeeldtopologie waarop ACL’s zijn toegepast.

9.1.1.2. Een TCP-gesprek

Met ACL’s kunnen beheerders het verkeer van en naar een netwerk beheren. Deze controle kan zo eenvoudig zijn als het toestaan of weigeren van verkeer op basis van netwerkadressen of zo complex als het controleren van netwerkverkeer op basis van de gevraagde TCP-poort. Het is gemakkelijker te begrijpen hoe een ACL verkeer filtert door de dialoog te onderzoeken die tijdens een TCP-gesprek plaatsvindt, zoals bij het opvragen van een webpagina.

TCP-communicatie

Wanneer een client gegevens opvraagt van een webserver, regelt IP de communicatie tussen de pc (bron) en de server (bestemming). TCP regelt de communicatie tussen de webbrowser (applicatie) en de netwerkserversoftware.

Wanneer u een e-mail verzendt, een webpagina bekijkt of een bestand downloadt, is TCP verantwoordelijk voor het opsplitsen van gegevens in segmenten voor IP voordat ze worden verzonden. TCP beheert ook het samenstellen van de gegevens van de segmenten wanneer ze aankomen. Het TCP-proces lijkt veel op een gesprek waarin twee knooppunten op een netwerk overeenkomen om gegevens tussen elkaar door te geven.

TCP biedt een verbindingsgerichte, betrouwbare bytestreamservice. Verbindingsgericht betekent dat de twee applicaties een TCP-verbinding tot stand moeten brengen voordat gegevens kunnen worden uitgewisseld. TCP is een full-duplex-protocol, wat betekent dat elke TCP-verbinding een paar bytestreams ondersteunt, waarbij elke stream in één richting stroomt. TCP bevat een stroomcontrolemechanisme voor elke bytestroom waarmee de ontvanger kan beperken hoeveel gegevens de afzender kan verzenden. TCP implementeert ook een congestiecontrolemechanisme.

De bovenstaande animatie illustreert hoe een TCP/IP-gesprek plaatsvindt. TCP-segmenten zijn gemarkeerd met vlaggen die hun doel aangeven: een SYN start (synchroniseert) de sessie; een ACK is een bevestiging dat een verwacht segment is ontvangen en een FIN beëindigt de sessie. Een SYN/ACK bevestigt dat de overdracht is gesynchroniseerd. TCP-gegevenssegmenten bevatten het protocol van een hoger niveau dat nodig is om de toepassingsgegevens naar de juiste toepassing te leiden.

Het TCP-gegevenssegment identificeert ook de poort die overeenkomt met de gevraagde service. HTTP is bijvoorbeeld poort 80, SMTP is poort 25 en FTP is poort 20 en poort 21. Volgende tabel toont het bereik van UDP- en TCP-poorten.

Poortnummerbereik	Poortgroep
0 – 1023	Bekende poorten
1024 – 49151	Geregistreerde poorten
49152 – 65535	Privé en/of dynamische poorten

TCP poorten

Geregistreerde TCP poorten	Bekende TCP poorten
1863 MSN Messenger 2000 Cisco SCCP (VoIP) 8008 Alternate HTTP 8080 Alternate HTTP	21 FTP 23 Telnet 25 SMTP 80 HTTP 143 IMAP 194 Internet Relay Chat (IRC) 443 Secure HTTP (HTTPS)

Geregistreerde UDP poorten	Bekende UDP poorten
1812 Radius Authentication Protocol 5004 RTP (Voice and Audio Transport Protocol) 5060 SIP (VoIP)	69 TFTP 520 RIP

Geregistreerde TCP/UDP poorten	Bekende TCP/UDP poorten
1433 MS SQL 2948 WAP (MMS)	53 DNS 161 SNMP 531 AOL Instant Messenger, IRC

9.1.1.3. Pakketfiltering

Dus hoe gebruikt een ACL de informatie die tijdens een TCP/IP-gesprek wordt doorgegeven om verkeer te filteren?

Pakketfiltering, ook wel statische pakketfiltering genoemd, regelt de toegang tot een netwerk door de inkomende en uitgaande pakketten te analyseren en deze door te geven of te laten vallen op basis van bepaalde criteria, zoals het bron-IP-adres, de bestemmings-IP-adressen en het protocol dat in het pakket wordt vervoerd.

Een router fungeert als pakketfilter wanneer hij pakketten doorstuurt of weigert volgens filterregels. Wanneer een pakket aankomt bij de pakketfilterende router, extraheert de router bepaalde informatie uit de pakketheader. Met behulp van deze informatie neemt de router beslissingen, op basis van geconfigureerde filterregels, of het pakket kan passeren of kan worden weggegooid. Zoals in de afbeelding te zien is, kan pakketfiltering werken op verschillende lagen van het OSI-model, of op de internetlaag van TCP/IP.

Een pakketfilterende router gebruikt regels om te bepalen of verkeer moet worden toegestaan of geweigerd. Een router kan ook pakketfiltering uitvoeren op Layer 4, de transportlaag. De router kan pakketten filteren op basis van de bronpoort en de bestemmingspoort van het TCP- of UDP-segment. Deze regels worden gedefinieerd met behulp van ACL’s.

Een ACL is een sequentiële lijst van toestemmings- of weigeringsverklaringen, ook wel toegangscontrole-items (ACE’s) genoemd. ACE’s worden ook vaak ACL-statements genoemd. ACE’s kunnen worden gemaakt om verkeer te filteren op basis van bepaalde criteria, zoals: het bronadres, het bestemmingsadres, het protocol en poortnummers. Wanneer netwerkverkeer een interface passeert die is geconfigureerd met een ACL, vergelijkt de router de informatie in het pakket met elke ACE, in sequentiële volgorde, om te bepalen of het pakket overeenkomt met een van de instructies. Als een overeenkomst wordt gevonden, wordt het pakket dienovereenkomstig verwerkt. Op deze manier kunnen ACL’s worden geconfigureerd om de toegang tot een netwerk of subnet te regelen.

Om netwerkverkeer te evalueren, extraheert de ACL de volgende informatie uit de Layer 3-pakketheader:

Bron IP adres
Bestemming IP Adres
ICMP-berichttype

De ACL kan ook informatie over de bovenste laag extraheren uit de Layer 4-header, waaronder:

TCP/UDP-bronpoort
TCP/UDP-bestemmingspoort

Voorbeeld van pakketfiltering

Om het concept te begrijpen van hoe een router pakketfiltering gebruikt, stelt u zich voor dat er een bewaker bij een gesloten deur is geplaatst. De bewaker heeft de opdracht om alleen mensen toe te laten wiens naam op een lijst staat door de deur te gaan. De bewaker filtert mensen op basis van het criterium dat hun naam op de geautoriseerde lijst staat. Een ACL werkt op een vergelijkbare manier en neemt beslissingen op basis van vastgestelde criteria.

Een ACL kan bijvoorbeeld worden geconfigureerd om logischerwijs “webtoegang toe te staan aan gebruikers van netwerk A, maar alle andere services aan gebruikers van netwerk A te weigeren. HTTP-toegang aan gebruikers van netwerk B te weigeren, maar netwerk B-gebruikers alle andere toegang toe te staan. ” Raadpleeg de afbeelding om het beslissingspad te onderzoeken dat de pakketfilter gebruikt om deze taak uit te voeren.

Voor dit scenario kijkt de pakketfilter als volgt naar elk pakket:

Als het pakket een TCP SYN is van netwerk A dat poort 80 gebruikt, mag het worden doorgelaten. Alle andere toegang wordt aan die gebruikers geweigerd.
Als het pakket een TCP SYN is van netwerk B dat poort 80 gebruikt, wordt het geblokkeerd. Alle andere toegang is echter toegestaan.

Dit is slechts een eenvoudig voorbeeld. Er kunnen meerdere regels worden geconfigureerd om services aan specifieke gebruikers verder toe te staan of te weigeren.

9.1.1.4. ACL-werking

ACL’s definiëren de set regels die extra controle geven over pakketten die inkomende interfaces binnenkomen, pakketten die door de router worden doorgegeven en pakketten die uitgaande interfaces van de router verlaten. ACL’s werken niet op pakketten die afkomstig zijn van de router zelf.

ACL’s zijn geconfigureerd om van toepassing te zijn op inkomend verkeer of om van toepassing te zijn op uitgaand verkeer, zoals weergegeven in de afbeelding.

Inkomende ACL’s – Inkomende pakketten worden verwerkt voordat ze naar de uitgaande interface worden gerouteerd. Een inkomende ACL is efficiënt omdat het de overhead van het routeren van zoekopdrachten bespaart als het pakket wordt weggegooid. Als het pakket door de tests wordt toegestaan, wordt het vervolgens verwerkt voor routering. Inkomende ACL’s worden het best gebruikt om pakketten te filteren wanneer het netwerk dat is aangesloten op een inkomende interface de enige bron is van de pakketten die moeten worden onderzocht.
Uitgaande ACL’s – Inkomende pakketten worden naar de uitgaande interface gerouteerd en vervolgens verwerkt via de uitgaande ACL. Uitgaande ACL’s kunnen het beste worden gebruikt wanneer hetzelfde filter wordt toegepast op pakketten die afkomstig zijn van meerdere inkomende interfaces voordat dezelfde uitgaande interface wordt verlaten.

De laatste vemelding van een ACL is altijd een impliciete ontkenning. Deze verklaring wordt automatisch aan het einde van elke ACL ingevoegd, ook al is deze niet fysiek aanwezig. De impliciete weigering blokkeert al het verkeer. Vanwege deze impliciete weigering blokkeert een ACL die niet ten minste één toestemmingsverklaring heeft al het verkeer.

9.1.2. Standaard versus uitgebreide IPv4 ACL’s

9.1.2.1. Typen Cisco IPv4-ACL’s

Standaard ACL’s

Standaard ACL’s kunnen worden gebruikt om alleen verkeer van bron-IPv4-adressen toe te staan of te weigeren. De bestemming van het pakket en de betrokken poorten worden niet geëvalueerd. Het voorbeeld in figuur 1 staat al het verkeer van het 192.168.30.0/24 netwerk toe. Vanwege de impliciete deny any aan het einde, wordt al het andere verkeer geblokkeerd met deze ACL. Standaard ACL’s worden gemaakt in de algemene configuratiemodus.

access-list 10 permit 192.168.30.0 0.0.0.255

Uitgebreide ACL’s

Uitgebreide ACL’s filteren IPv4-pakketten op basis van verschillende kenmerken:

Protocoltype:
Bron IPv4-adres
Bestemming IPv4-adres
Bron TCP- of UDP-poorten
Bestemmings-TCP- of UDP-poorten
Optionele informatie over het protocoltype voor fijnere controle

In Afbeelding 2 staat ACL 103 verkeer toe dat afkomstig is van elk adres op het 192.168.30.0/24-netwerk naar elk IPv4-netwerk als de hostpoort van de bestemming 80 (HTTP) is. Uitgebreide ACL’s worden gemaakt in de algemene configuratiemodus.

access-list 103 permit tcp 192.168.30.0 0.0.0.255 any eq 80

Opmerking: Standaard en uitgebreide ACL’s worden later in dit hoofdstuk in meer detail besproken.

9.1.2.2. ACL’s nummeren en benoemen

Standaard en uitgebreide ACL’s kunnen worden gemaakt met behulp van een nummer of een naam om de ACL en de lijst met instructies te identificeren.

Het gebruik van genummerde ACL’s is een effectieve methode om het ACL-type te bepalen op kleinere netwerken met meer homogeen gedefinieerd verkeer. Een nummer geeft echter geen informatie over het doel van de ACL. Om deze reden kan vanaf Cisco IOS Release 11.2, een naam worden gebruikt om een Cisco ACL te identificeren.

De afbeelding vat de regels samen die moeten worden gevolgd om genummerde ACL’s en benoemde ACL’s aan te wijzen.

Genumerlde ACL	Benoemde ACL
Wijs een nummer toe op basis van het te filteren protocol: – (1 tot 99) and (1300 and 1999): Standaard IP ACL – (100 tot 199) and (2000 to 2699): Uitgebreide IP ACL	Wijs een naam toe om de ACL te identificeren: – Namen kunnen alfanumerieke tekens bevatten. – Er wordt voorgesteld om de naam in HOOFDLETTERS te schrijven. – Namen mogen geen spaties of leestekens bevatten. – In de ACL kunnen vermeldingen worden toegevoegd of verwijderd.

Met betrekking tot genummerde ACL’s worden de nummers 200 tot 1299 overgeslagen omdat die nummers worden gebruikt door andere protocollen, waarvan er vele verouderd of verouderd zijn. Deze cursus richt zich alleen op IP ACL’s. Voorbeelden van legacy ACL-protocolnummers zijn 600 tot 699 gebruikt door AppleTalk en nummers 800 tot 899 gebruikt door IPX.

9.1.3. Wildcard Masks in ACL’s

9.1.3.1. Introductie van ACL-wildcardmaskering

Wildcardmaskering

IPv4-ACE’s omvatten het gebruik van jokertekenmaskers. Een wildcard-masker is een reeks van 32 binaire cijfers die door de router wordt gebruikt om te bepalen welke bits van het adres moeten worden onderzocht op een overeenkomst.

Opmerking: In tegenstelling tot IPv4-ACL’s gebruiken IPv6-ACL’s geen jokertekenmaskers. In plaats daarvan wordt de prefix-lengte gebruikt om aan te geven hoeveel van een IPv6-bron- of bestemmingsadres moet worden vergeleken. IPv6 ACL’s worden later in dit hoofdstuk besproken.

Net als bij subnetmaskers geven de cijfers 1 en 0 in het wildcardteken aan hoe de corresponderende IP-adresbits moeten worden behandeld. In een wildcard-masker worden deze bits echter voor verschillende doeleinden gebruikt en volgen ze verschillende regels.

Subnetmaskers gebruiken binaire enen en nullen om het netwerk-, subnet- en hostgedeelte van een IP-adres te identificeren. Wildcard-maskers gebruiken binaire enen en nullen om individuele IP-adressen of groepen IP-adressen te filteren om toegang tot bronnen toe te staan of te weigeren.

Wildcard-maskers en subnetmaskers verschillen in de manier waarop ze overeenkomen met binaire enen en nullen. Maskers met jokertekens gebruiken de volgende regels om binaire 1s en 0s te matchen:

Wildcard mask bit 0 – Match de corresponderende bitwaarde in het adres.
Wildcard mask bit 1 – Negeer de corresponderende bitwaarde in het adres.

De volgende afbeelding laat zien hoe verschillende wildcard-maskers IP-adressen filteren. Onthoud in het voorbeeld dat binair 0 een bit betekent dat moet overeenkomen, en binair 1 een bit betekent dat kan worden genegeerd.

Opmerking: Wildcard Masks worden vaak een omgekeerd masker genoemd. De reden is dat, in tegenstelling tot een subnetmasker waarin binair 1 gelijk is aan een overeenkomst en binair 0 geen overeenkomst, in een jokertekenmasker het omgekeerde waar is.

Een wildcardmasker gebruiken

De volgende tabel toont de resultaten van het toepassen van een 0,0.255.255 jokertekenmasker op een 32-bits IPv4-adres. Onthoud dat een binaire 0 een waarde aangeeft die overeenkomt.

	Decimaal adres	Binair adres
Te verwerken IP-adres	192.168.10.0	11000000.10101000.00001010.00000000
Wildcardmasker	0.0.255.255	00000000.00000000.11111111.11111111
Resulterend IP-adres	192.168.0.0	11000000.10101000.00000000.00000000

Wildcard-maskers worden ook gebruikt bij het configureren van sommige IPv4-routeringsprotocollen, zoals OSPF, om het protocol op specifieke interfaces in te schakelen.

9.1.3.2. Voorbeelden van Wilcard Masks

Wildcard masks die overeenkomen met IPv4-subnetten

Het berekenen van het wildcard mask kan enige oefening vergen.

In het eerste voorbeeld bepaalt het wildcard mask dat elke bit in de IPv4 192.168.1.1 exact overeen moet komen.

	Decimaal	Binair
IP-adres	192.168.1.1	11000000.10101000.00000001.00000001
Wildcardmasker	0.0.0.0	00000000.00000000.00000000.00000000
Resultaat	192.168.1.1	11000000.10101000.00000001.00000001

In het tweede voorbeeld bepaalt het wildcard mask dat alles overeenkomt.

	Decimaal	Binair
IP-adres	192.168.1.1	11000000.10101000.00000001.00000001
Wildcardmasker	255.255.255.255	11111111.11111111.11111111.11111111
Resultaat	0.0.0.0	00000000.00000000.00000000.00000000

In het derde voorbeeld bepaalt het wildcard mask dat elke host binnen het 192.168.1.0/24-netwerk overeenkomt.

	Decimaal	Binair
IP-adres	192.168.1.1	11000000.10101000.00000001.00000001
Wildcardmasker	0.0.0.255	00000000.00000000.00000000.11111111
Resultaat	192.168.1.0	11000000.10101000.00000001.00000000

Deze voorbeelden waren vrij eenvoudig en duidelijk. De berekening van wildcard masks kan echter complexer zijn.

Wildcard masks die overeenkomen met reeksen

De volgende twee voorbeelden zijn complexer. In het eerste voorbeeld moeten de eerste twee octetten en de eerste vier bits van het derde octet exact overeenkomen. De laatste vier bits in het derde octet en het laatste octet kunnen elk geldig getal zijn. Dit resulteert in een masker dat controleert op het bereik van netwerken 192.168.16.0 tot 192.168.31.0.

	Decimaal	Binair
IP-adres	192.168.16.0	11000000.10101000.00000001.00000001
Wildcardmasker	0.0.15.255	00000000.00000000.00000000.11111111
Resultaat	192.168.16.0 – 192.168.31.255	11000000.10101000.00000001.00000000

Het volgend voorbeeld toont een wildcard mask dat overeenkomt met de eerste twee octetten en de minst significante bit in het derde octet. Het laatste octet en de eerste zeven bits in het derde octet kunnen elk geldig getal zijn. Het resultaat is een masker dat alle hosts van oneven subnetten van het hoofdnetwerk 192.168.0.0 zou toestaan of weigeren.

	Decimaal	Binair
IP-adres	192.168.1.0	11000000.10101000.00000001.00000000
Wildcardmasker	0.0.254.255	00000000.00000000.11111110.11111111
Resultaat	192.168.1.0	11000000.10101000.00000001.00000000

9.1.3.3. De wildcard mask berekenen

Het berekenen van wildcardmaskers kan een uitdaging zijn. Een sneltoetsmethode is om het subnetmasker af te trekken van 255.255.255.255.

Berekening van een wildcard mask: voorbeeld 1

Neem in het eerste voorbeeld in de afbeelding aan dat u toegang wilt verlenen aan alle gebruikers in het 192.168.3.0-netwerk. Omdat het subnetmasker 255.255.255.0 is, kunt u de 255.255.255.255 nemen en het subnetmasker 255.255.255.0 aftrekken. De oplossing produceert het jokerteken 0.0.0.255.

255 . 255 . 255 . 255

- 255 . 255 . 255 . 255

000 . 000 . 000 . 000

Berekening van een wildcard mask: voorbeeld 2

Neem in het tweede voorbeeld in de afbeelding aan dat u netwerktoegang wilt toestaan voor de 14 gebruikers in het subnet 192.168.3.32/28. Het subnetmasker voor het IP-subnet is 255.255.255.240, neem daarom 255.255.255.255 en trek het subnetmasker 255.255.255.240 af. De oplossing levert dit keer het jokertekenmasker 0.0.0.15 op.

255 . 255 . 255 . 255

- 255 . 255 . 255 . 240

000 . 000 . 000 . 015

Berekening van een wildcard mask: voorbeeld 3

Neem in het derde voorbeeld in de afbeelding aan dat u alleen netwerken 192.168.10.0 en 192.168.11.0 wilt matchen. Nogmaals, je neemt de 255.255.255.255 en trekt het normale subnetmasker af, wat in dit geval 255.255.254.0 zou zijn. Het resultaat is 0.0.1.255.

255 . 255 . 255 . 255

- 255 . 255 . 254 . 000

000 . 000 . 001 . 255

U kunt hetzelfde resultaat bereiken met uitspraken zoals de twee hieronder weergegeven:

R1(config)# access-list 10 permit 192.168.10.0
R1(config)# access-list 10 permit 192.168.11.0

Het is veel efficiënter om de wildcard mask op de volgende manier te configureren:

R1(config)# access-list 10 permit 192.168.10.0 0.0.1.255

Overweeg de onderstaande configuratie om netwerken in het bereik tussen 192.168.16.0 tot 192.168.31.0 te matchen:

R1(config)# access-list 10 permit 192.168.16.0
R1(config)# access-list 10 permit 192.168.17.0
R1(config)# access-list 10 permit 192.168.18.0
R1(config)# access-list 10 permit 192.168.19.0
R1(config)# access-list 10 permit 192.168.20.0
R1(config)# access-list 10 permit 192.168.21.0
R1(config)# access-list 10 permit 192.168.22.0
R1(config)# access-list 10 permit 192.168.23.0
R1(config)# access-list 10 permit 192.168.24.0
R1(config)# access-list 10 permit 192.168.25.0
R1(config)# access-list 10 permit 192.168.26.0
R1(config)# access-list 10 permit 192.168.27.0
R1(config)# access-list 10 permit 192.168.28.0
R1(config)# access-list 10 permit 192.168.29.0
R1(config)# access-list 10 permit 192.168.30.0
R1(config)# access-list 10 permit 192.168.31.0

De vorige 16 configuratie-instructies kunnen worden teruggebracht tot een enkele instructie met behulp van het juiste widcard mask, zoals hieronder wordt weergegeven:

R1(config)# access-list 10 permit 192.168.16.0 0.0.15.255

9.1.3.4. Wilcard mask trefwoorden

Wildcard bit mask trefwoorden

Werken met decimale representaties van binaire wildcard mask bits kan vervelend zijn. Om deze taak te vereenvoudigen, bieden de trefwoorden host en any eventuele hulp bij het identificeren van de meest voorkomende toepassingen van wildcard masking. Deze trefwoorden elimineren het invoeren van wildcard masks bij het identificeren van een specifieke host of een heel netwerk. Deze trefwoorden maken het ook gemakkelijker om een ACL te lezen door visuele aanwijzingen te geven over de bron of bestemming van de criteria.

Het host-sleutelwoord vervangt het 0.0.0.0-masker. Dit masker geeft aan dat alle IPv4-adresbits moeten overeenkomen of dat slechts één host overeenkomt.

De optie any vervangt het IP-adres en het 255.255.255.255-masker. Dit masker zegt om het volledige IPv4-adres te negeren of om adressen te accepteren.

Voorbeeld 1: Werken met Wildcard masking met een enkel IP-adres

In het volgende voorbeeld kunt u in plaats van 192.168.10.10 0.0.0.0 in te voeren host 192.168.10.10 gebruiken.

Voorbeeld 2: Werken met Wildcard masking dat overeenkomt met een willekeurig IP-adres

In het volgende voorbeeld kunt u in plaats van 0.0.0.0 255.255.255.255 in te voeren het trefwoord any op zichzelf gebruiken.

Opmerking: De trefwoorden host en any kunnen ook worden gebruikt bij het configureren van een IPv6 ACL.

9.1.2.5. Voorbeelden van zoekwoorden met jokertekens

De any en host trefwoorden

Volgend voorbeeld laat zien hoe u het trefwoord any kunt gebruiken om het IPv4-adres 0.0.0.0 te vervangen door een jokerteken van 255.255.255.255.

R1(config)# access-list 1 permit 0.0.0.0 255.255.255.255
R1(config)# access-list 1 permit any

Volgend voorbeeld laat zien hoe u het hostsleutelwoord kunt gebruiken om het jokertekenmasker te vervangen bij het identificeren van een enkele host.

R1(config)# access-list 1 permit 192.168.10.10 0.0.0.0
R1(config)# access-list 1 permit host 192.168.10.10

9.1.4. Richtlijnen voor het maken van ACL’s

9.1.4.1. Algemene richtlijnen voor het maken van ACL’s

Het schrijven van ACL’s kan een complexe taak zijn. Voor elke interface kunnen er meerdere beleidsregels nodig zijn om het type verkeer te beheren dat die interface mag binnenkomen of verlaten. De router in de afbeelding heeft twee interfaces die zijn geconfigureerd voor IPv4 en IPv6. Als we ACL’s nodig hadden voor beide protocollen, op beide interfaces en in beide richtingen, zou dit acht afzonderlijke ACL’s vereisen. Elke interface zou vier ACL’s hebben; twee ACL’s voor IPv4 en twee ACL’s voor IPv6. Voor elk protocol is één ACL voor inkomend verkeer en één voor uitgaand verkeer.

Opmerking: ACL’s hoeven niet in beide richtingen te worden geconfigureerd. Het aantal ACL’s en de richting die op de interface wordt toegepast, is afhankelijk van de vereisten die worden geïmplementeerd.

Hier zijn enkele richtlijnen voor het gebruik van ACL’s:

Gebruik ACL’s in firewallrouters die zich tussen uw interne netwerk en een extern netwerk zoals internet bevinden.
Gebruik ACL’s op een router die tussen twee delen van uw netwerk is geplaatst om verkeer dat een specifiek deel van uw interne netwerk binnenkomt of verlaat, te regelen.
Configureer ACL’s op grensrouters, dat wil zeggen routers die zich aan de randen van uw netwerken bevinden. Dit zorgt voor een zeer basale buffer van het externe netwerk, of tussen een minder gecontroleerd gebied van uw eigen netwerk en een gevoeliger gebied van uw netwerk.
Configureer ACL’s voor elk netwerkprotocol dat is geconfigureerd op de grensrouterinterfaces.

De drie P’s

Een algemene regel voor het toepassen van ACL’s op een router kan worden opgeroepen door de drie P’s te onthouden. U kunt één ACL per protocol, per richting, per interface configureren:

Eén ACL per protocol – Om de verkeersstroom op een interface te regelen, moet een ACL worden gedefinieerd voor elk protocol dat op de interface is ingeschakeld.
Eén ACL per richting – ACL’s regelen het verkeer in één richting tegelijk op een interface. Er moeten twee afzonderlijke ACL’s worden gemaakt om inkomend en uitgaand verkeer te beheren.
Eén ACL per interface – ACL’s regelen het verkeer voor een interface, bijvoorbeeld GigabitEthernet 0/0.

9.1.4.2. ACL-best practices

Het gebruik van ACL’s vereist aandacht voor detail en grote zorg. Fouten kunnen kostbaar zijn in termen van uitvaltijd, probleemoplossing en slechte netwerkservice. Voordat u een ACL configureert, is een basisplanning vereist. Hieronder worden de richtlijnen weergegeven die de basis vormen van een lijst met best practices voor ACL’s.

Richtlijn	Voordeel
Baseer uw ACL’s op het beveiligingsbeleid van de organisatie.	Dit zorgt ervoor dat u de beveiligingsrichtlijnen van de organisatie implementeert.
Maak een beschrijving van wat u wilt dat uw ACL’s doen.	Dit zal u helpen voorkomen dat u per ongeluk potentiële toegangsproblemen veroorzaakt.
Gebruik een teksteditor om ACL’s te maken, te bewerken en op te slaan.	Dit zal u helpen bij het maken van een bibliotheek met herbruikbare ACL’s.
Test uw ACL’s op een ontwikkelingsnetwerk voordat u ze implementeert op een productienetwerk.	Zo voorkom je kostbare fouten.

ACL-best practices

9.1.5. Richtlijnen voor ACL-plaatsing

9.1.5.1. Waar ACL’s te plaatsen

Door de juiste plaatsing van een ACL kan het netwerk efficiënter werken. Een ACL kan worden geplaatst om onnodig verkeer te verminderen. Verkeer dat op een externe bestemming wordt geweigerd, mag bijvoorbeeld niet worden doorgestuurd via netwerkbronnen langs de route naar die bestemming.

Elke ACL moet daar worden geplaatst waar deze de grootste impact heeft op de efficiëntie. Zoals weergegeven in bovenstaande afbeelding, zijn de basisregels:

Uitgebreide ACL’s – Zoek uitgebreide ACL’s zo dicht mogelijk bij de bron van het te filteren verkeer. Op deze manier wordt ongewenst verkeer dicht bij het bronnetwerk geweigerd zonder de netwerkinfrastructuur te kruisen.
Standaard ACL’s – Omdat standaard ACL’s geen bestemmingsadressen specificeren, plaatst u ze zo dicht mogelijk bij de bestemming. Door een standaard ACL bij de bron van het verkeer te plaatsen, wordt effectief voorkomen dat dat verkeer andere netwerken bereikt via de interface waar de ACL wordt toegepast.

Plaatsing van de ACL en dus het type ACL dat wordt gebruikt, kan ook afhangen van:

De mate van controle van de netwerkbeheerder – De plaatsing van de ACL kan afhangen van het feit of de netwerkbeheerder al dan niet controle heeft over zowel het bron- als het doelnetwerk.
Bandbreedte van de betrokken netwerken – Door ongewenst verkeer bij de bron te filteren, wordt voorkomen dat het verkeer wordt verzonden voordat het bandbreedte verbruikt op het pad naar een bestemming. Dit is vooral belangrijk in netwerken met een lage bandbreedte.
Eenvoudige configuratie – Als een netwerkbeheerder verkeer van verschillende netwerken wil weigeren, is een optie om een enkele standaard ACL te gebruiken op de router die zich het dichtst bij de bestemming bevindt. Het nadeel is dat verkeer van deze netwerken onnodig bandbreedte verbruikt. Een uitgebreide ACL kan worden gebruikt op elke router waar het verkeer vandaan komt. Dit bespaart bandbreedte door het verkeer bij de bron te filteren, maar vereist het maken van uitgebreide ACL’s op meerdere routers.

Opmerking: voor CCNA-certificering is de algemene regel dat uitgebreide ACL’s zo dicht mogelijk bij de bron worden geplaatst en standaard ACL’s zo dicht mogelijk bij de bestemming.

9.1.5.2. Standaard ACL-plaatsing

Een standaard ACL kan alleen verkeer filteren op basis van een bronadres. De basisregel voor het plaatsen van een standaard ACL is om de ACL zo dicht mogelijk bij het doelnetwerk te plaatsen. Hierdoor kan het verkeer alle andere netwerken bereiken, behalve het netwerk waar de pakketten worden gefilterd.

In de bonvenstaande figuur wil de beheerder voorkomen dat verkeer afkomstig van het 192.168.10.0/24-netwerk het 192.168.30.0/24-netwerk bereikt.

Als de standaard ACL op de uitgaande interface van R1 wordt geplaatst, zou dit voorkomen dat verkeer op het 192.168.10.0/24-netwerk netwerken bereikt die bereikbaar zijn via de seriële 0/0/0-interface van R1.

Volgens de basisrichtlijnen voor plaatsing van de standaard ACL dicht bij de bestemming, toont de afbeelding twee mogelijke interfaces op R3 om de standaard ACL toe te passen:

R3 S0/0/1-interface – Door een standaard ACL toe te passen om te voorkomen dat verkeer van 192.168.10.0/24 de S0/0/1-interface binnenkomt, wordt voorkomen dat dit verkeer 192.168.30.0/24 bereikt en alle andere netwerken die bereikbaar zijn via R3. Dit omvat het 192.168.31.0/24-netwerk. Omdat het de bedoeling van de ACL is om verkeer te filteren dat alleen bestemd is voor 192.168.30.0/24, mag er geen standaard-ACL worden toegepast op deze interface.
R3 G0/0-interface – Door de standaard ACL toe te passen op verkeer dat de G0/0-interface verlaat, worden pakketten gefilterd van 192.168.10.0/24 tot 192.168.30.0/24. Dit heeft geen invloed op andere netwerken die bereikbaar zijn via R3. Pakketten van 192.168.10.0/24 kunnen nog steeds 192.168.31.0/24 bereiken.

9.1.5.3. Uitgebreide ACL-plaatsing

Net als een standaard ACL kan een uitgebreide ACL verkeer filteren op basis van het bronadres. Een uitgebreide ACL kan echter ook verkeer filteren op basis van het bestemmingsadres, het protocol en het poortnummer. Dit geeft netwerkbeheerders meer flexibiliteit in het type verkeer dat kan worden gefilterd en waar de ACL moet worden geplaatst. De basisregel voor het plaatsen van een uitgebreide ACL is om deze zo dicht mogelijk bij de bron te plaatsen. Dit voorkomt dat ongewenst verkeer over meerdere netwerken wordt verzonden en pas wordt geweigerd wanneer het zijn bestemming bereikt.

Netwerkbeheerders kunnen alleen ACL’s plaatsen op apparaten die zij beheren. Plaatsing moet daarom worden bepaald in de context van waar de controle van de netwerkbeheerder zich uitstrekt. In de afbeelding wil de beheerder van bedrijf A, dat de netwerken 192.168.10.0/24 en 192.168.11.0/24 omvat (in dit voorbeeld .10 en .11 genoemd), het verkeer naar bedrijf B regelen. wil Telnet- en FTP-verkeer van het .11-netwerk naar het 192.168.30.0/24 (.30, in dit voorbeeld) netwerk van bedrijf B weigeren. Tegelijkertijd moet al het overige verkeer van het .11-netwerk Bedrijf A onbeperkt kunnen verlaten.

Er zijn verschillende manieren om deze doelen te bereiken. Een uitgebreide ACL op R3 die Telnet en FTP blokkeert van het .11-netwerk zou de taak volbrengen, maar de beheerder heeft geen controle over R3. Bovendien zorgt deze oplossing ervoor dat ongewenst verkeer het hele netwerk kan doorkruisen, om vervolgens op de bestemming te worden geblokkeerd. Dit heeft invloed op de algehele netwerkefficiëntie.

Een betere oplossing is om een uitgebreide ACL op R1 te plaatsen die zowel bron- als bestemmingsadressen specificeert (respectievelijk .11-netwerk en .30-netwerk), en de regel afdwingt: “Telnet- en FTP-verkeer van het .11-netwerk mag niet gaan naar het .30-netwerk.” De afbeelding toont twee mogelijke interfaces op R1 om de uitgebreide ACL toe te passen:

R1 S0/0/0 interface (outbound) – Een mogelijkheid is om een uitgebreide ACL outbound toe te passen op de S0/0/0 interface. Omdat de uitgebreide ACL zowel bron- als bestemmingsadressen kan onderzoeken, worden alleen FTP- en Telnet-pakketten van 192.168.11.0/24 geweigerd. Ander verkeer van 192.168.11.0/24 en andere netwerken wordt doorgestuurd door R1. Het nadeel van het plaatsen van de uitgebreide ACL op deze interface is dat al het verkeer dat S0/0/0 verlaat, moet worden verwerkt door de ACL, inclusief pakketten van 192.168.10.0/24.
R1 G0/1-interface (inkomend) – Door een uitgebreide ACL toe te passen op verkeer dat de G0/1-interface binnenkomt, worden alleen pakketten van het 192.168.11.0/24-netwerk onderworpen aan ACL-verwerking op R1. Omdat het filter moet worden beperkt tot alleen die pakketten die het 192.168.11.0/24-netwerk verlaten, is het toepassen van de uitgebreide ACL op G0/1 de beste oplossing.

9.2. Standaard IPv4 ACL’s

9.2.1. Standaard IPv4 ACL’s configureren

9.2.1.1. Criteriavermeldingen invoeren

Wanneer verkeer de router binnenkomt, wordt het verkeer vergeleken met alle ACE’s in de volgorde waarin de vermeldingen in de ACL voorkomen. De router gaat door met het verwerken van de ACE’s totdat hij een match vindt. De router verwerkt het pakket op basis van de eerste gevonden overeenkomst en er worden geen andere ACE’s onderzocht.

Als er geen overeenkomsten worden gevonden wanneer de router het einde van de lijst bereikt, wordt het verkeer geweigerd. Dit komt omdat er standaard een impliciete weigering is aan het einde van alle ACL’s voor verkeer dat niet overeenkomt met een geconfigureerd item. Een ACL met één invoer met slechts één geweigerde invoer heeft tot gevolg dat al het verkeer wordt geweigerd. Er moet minimaal één ACE-vergunning zijn geconfigureerd in een ACL, anders wordt al het verkeer geblokkeerd.

Voor het netwerk in de afbeelding heeft het toepassen van ACL 1 of ACL 2 op de S0/0/0-interface van R1 in de uitgaande richting hetzelfde effect. Netwerk 192.168.10.0 krijgt toegang tot de netwerken die bereikbaar zijn via S0/0/0, terwijl 192.168.11.0 geen toegang krijgt tot die netwerken.

R1(config)# access-list 1 permit ip 192.168.10.0 0.0.0.255
R1(config)# access-list 2 permit ip 192.168.10.0 0.0.0.255
R1(config)# access-list 2 deny any
R1(config)#

9.2.1.2. Een standaard ACL configureren

In de volgende afbeelding worden pakketten die de router binnenkomen via interface G0/0 gecontroleerd op hun bronadressen op basis van de volgende vermeldingen:

access-list 2 deny 192.168.10.10

access-list 2 permit 192.168.10.0 0.0.0.255

access-list 2 deny 192.168.0.0 0.0.255.255

access-list 2 permit 192.0.0.0 0.255.255.255

Als pakketten zijn toegestaan, worden ze door de router naar een uitvoerinterface geleid. Als pakketten worden geweigerd, worden ze bij de inkomende interface gedropt.

Als u genummerde standaard-ACL’s op een Cisco-router wilt gebruiken, moet u eerst de standaard-ACL maken en vervolgens de ACL op een interface activeren.

De access-list globale configuratie opdracht definieert een standaard ACL met een nummer in het bereik van 1 tot en met 99. Cisco IOS Software Release 12.0.1 breidde deze nummers uit door 1300 tot 1999 te gebruiken voor standaard ACL’s. Dit zorgt voor maximaal 798 mogelijke standaard ACL’s. Deze extra nummers worden uitgebreide IP-ACL’s genoemd.

De volledige syntaxis van de standaard ACL-opdracht is als volgt:

Router(config)# access-list access-list-number {deny| permit| remark} source [ source-wildcard ][ log ]

De volgende tabel geeft een gedetailleerde uitleg van de syntaxis voor een standaard ACL.

Parameter	Beschrijving
access-list-number	Nummer van een ACL. Dit is een decimaal getal van 1 tot 99, of 1300 tot 1999 (voor standaard ACL).
deny	Weigert toegang als aan de voorwaarden wordt voldaan.
permit	Geeft toegang als aan de voorwaarden wordt voldaan.
remark	Voeg een opmerking toe over vermeldingen in een IP-toegangslijst om de lijst gemakkelijker te begrijpen en te scannen te maken.
source	Nummer van het netwerk of de host waarvandaan het pakket wordt verzonden. Er zijn twee manieren om de source te specificeren: – Gebruik een in vier delen gepunte 32-bits waarde. –
source-wildcard	Gebruik et sleutelwoord any voor een afkorkorting van een source en source-wildcard van 0.0.0.0 255.255.255.255
log	(Optioneel) Veroorzaakt een informatief logbericht over het pakket dat overeenkomt met het item dat naar de console moet worden verzonden. (Het niveau van berichten die op de console zijn gelogd, wordt bepaald door de

ACE’s kunnen een individuele host of een reeks hostadressen weigeren of toestaan. Om een hostverklaring aan te maken in genummerde ACL 10 die een specifieke host met het IP-adres 192.168.10.10 toestaat, voert u het volgende in:

R1(config)# access-list 10 permit host 192.168.10.10

Zoals weergegeven in het volgende voorbeeld, zou u, om een instructie te maken die een reeks IPv4-adressen in een genummerde ACL 10 toelaat die alle IPv4-adressen in het netwerk 192.168.10.0/24 toestaat, invoeren:

R1(config)# access-list 10 permit 192.168.10.0 0.0.0.255
R1(config)# exit
R1# show access-lists
Standard IP access list 10
    10 permit 192.168.10.0, wildcard bits 0.0.0.255
R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# no access-list 10
R1(config)# exit
R1# show access-lists
R1#

Om de ACL te verwijderen, wordt de globale configuratie no access-list opdracht gebruikt. Het geven van het commando show access-list bevestigt dat toegangslijst 10 is verwijderd.

Wanneer een beheerder een ACL maakt, is doorgaans het doel van elke instructie bekend en begrepen. Om er echter voor te zorgen dat de beheerder en anderen zich het doel van een vermelding herinneren, moeten opmerkingen worden opgenomen. Het trefwoord remark wordt gebruikt voor documentatie en maakt toegangslijsten een stuk gemakkelijker te begrijpen. Elke opmerking is beperkt tot 100 tekens. De ACL in figuur 3, hoewel vrij eenvoudig, wordt gebruikt om een voorbeeld te geven. Bij het bekijken van de ACL in de configuratie met het commando show running-config, wordt de opmerking ook weergegeven.

R1(config)# access-list 10 remark Permit hosts from the 192.168.10.0 LAN
R1(config)# access-list 10 permit 192.168.10.0 0.0.0.255
R1(config)# exit
R1# show running-config | include access-list 10
access-list 10 remark Permit hosts from the 192.168.10.0 LAN
access-list 10 permit 192.168.10.0 0.0.0.255
R1#

9.2.1.3. Interne logica

Cisco IOS past een interne logica toe bij het accepteren en verwerken van standaard ACE’s. Zoals eerder besproken, worden ACE’s opeenvolgend verwerkt. Daarom is de volgorde waarin ACE’s worden ingevoerd belangrijk.

In het volgende voorbeeld bevat ACL 3 bijvoorbeeld twee ACE’s. De eerste ACE gebruikt een wildcard-masker om een reeks adressen te weigeren, waaronder alle hosts in het 192.168.10.0/24-netwerk. De tweede ACE is een host-statement dat een specifieke host onderzoekt: 192.168.10.10. Dit is een host binnen het bereik van hosts die in de vorige instructie is geconfigureerd. Met andere woorden, 192.168.10.10 is een host in het 192.168.10.0/24 netwerk. De interne logica van IOS voor standaardtoegangslijsten verwerpt de tweede instructie en retourneert een foutbericht omdat het een subset is van de vorige instructie. In de afbeelding ziet u dat de router automatisch volgnummer 10 toewijst als het volgnummer dat is toegewezen aan de eerste instructie die in dit voorbeeld is ingevoerd. De output van de router bevat het bericht dat de regel “deel uitmaakt van de bestaande regel op reeksnummer 10” en de instructie niet accepteert.

R1(config)# access-list 3 deny 192.168.10.0 0.0.0.255
R1(config)# access-list 3 permit host 192.168.10.10
% Access rule can't be configured at higher sequence num as it is part of the existing rule at sequence num 10
R1(config)#

Opmerking: Op dit moment produceren uitgebreide ACL’s geen vergelijkbare fout.

De configuratie in het volgende voorbeeld van ACL 4 heeft dezelfde twee instructies, maar in omgekeerde volgorde. Dit is een geldige reeks instructies omdat de eerste instructie verwijst naar een specifieke host, niet naar een reeks hosts.

R1(config)# access-list 4 permit host 192.168.10.10
R1(config)# access-list 4 deny 192.168.10.0 0.0.0.255
R1(config)#

In het volgende voorbeeld laat ACL 5 zien dat een hostinstructie kan worden geconfigureerd na een instructie die een reeks hosts aangeeft. De host mag niet binnen het bereik vallen dat door een eerdere verklaring wordt gedekt. Het hostadres 192.168.11.10 is geen lid van het 192.168.10.0/24-netwerk, dus dit is een geldige verklaring.

R1(config)# access-list 5 deny 192.168.10.0 0.0.0.255
R1(config)# access-list 5 permit host 192.168.11.10
R1(config)#

Opmerking: de volgorde waarin standaard ACE’s worden ingevoerd, is mogelijk niet de volgorde waarin ze door de router worden opgeslagen, weergegeven of verwerkt. Dit zal in een later gedeelte worden besproken.

9.2.1.4. Standaard ACL’s toepassen op interfaces

Nadat een standaard ACL is geconfigureerd, wordt deze gekoppeld aan een interface met behulp van de opdracht ip access-group in de interfaceconfiguratiemodus:

Router(config-if)# ip access-group { access-list-number | access-list-name } { in | out }

Om een ACL van een interface te verwijderen, voert u eerst de opdracht no ip access-group in op de interface en voert u vervolgens de globale opdracht no access-list in om de volledige ACL te verwijderen.

Het volgende voorbeeld geeft een overzicht en syntaxis voor het configureren en toepassen van een genummerde standaard ACL op een router.

R1(config)# access-list 1 permit 192.168.10.0 0.0.0.255
R1(config)# interface serial 0/0/0
R1(config-if)# ip access-group 1 out
R1(config-if)#

Met deze ACL kan alleen verkeer van bronnetwerk 192.168.10.0 worden doorgestuurd vanuit interface S0/0/0. Verkeer van andere netwerken dan 192.168.10.0 wordt geblokkeerd.

De eerste regel identificeert de ACL als toegangslijst 1. Het staat verkeer toe dat overeenkomt met de geselecteerde parameters. In dit geval is het IPv4-adres en de wildcard mask dat het bronnetwerk identificeert 192.168.10.0 0.0.0.255. Bedenk dat er een impliciete deny all-instructie is die gelijk is aan het toevoegen van de regel access-list 1 deny 0.0.0.0 255.255.255.255.

De ip access-group 1 out interface-configuratieopdracht verbindt en verbindt ACL 1 met de seriële 0/0/0-interface als een uitgaand filter.

Daarom staat ACL 1 alleen hosts van het 192.168.10.0/24 netwerk toe om router R1 te verlaten. Het ontkent elk ander netwerk, inclusief het 192.168.11.0-netwerk.

Volgende afbeelding toont een voorbeeld van een ACL die een specifiek subnet toestaat, behalve voor een specifieke host op dat subnet.

R1(config)# no access-list 1
R1(config)# access-list 1 deny host 192.168.10.10
R1(config)# access-list 1 permit 192.168.10.0 0.0.0.255
R1(config)# interface s0/0/0
R1(config)# ip access-group 1 out
R1(config)#

Deze ACL vervangt het vorige voorbeeld, maar blokkeert ook verkeer van een specifiek adres. De eerste opdracht verwijdert de vorige versie van ACL 1. De volgende ACL-instructie ontkent de PC1-host die zich op 192.168.10.10 bevindt. Elke andere host op het 192.168.10.0/24-netwerk is toegestaan. Opnieuw komt de impliciete deny-instructie overeen met elk ander netwerk.

De ACL wordt opnieuw toegepast op interface S0/0/0 in een uitgaande richting.

De volgende afbeelding toont een voorbeeld van een ACL die een specifieke host weigert. Deze ACL vervangt het vorige voorbeeld. Dit voorbeeld blokkeert nog steeds het verkeer van host-PC1, maar staat al het andere verkeer toe.

R1(config)# no access-list 1
R1(config)# access-list 1 deny host 192.168.10.10
R1(config)# access-list 1 permit any
R1(config)# interface g0/0
R1(config)# ip access-group 1 in
R1(config)#

De eerste twee opdrachten zijn hetzelfde als in het vorige voorbeeld. De eerste opdracht verwijdert de vorige versie van ACL 1 en de volgende ACL-instructie ontkent de PC1-host die zich op 192.168.10.10 bevindt.

De derde regel is nieuw en laat alle andere hosts toe. Dit betekent dat alle hosts van het 192.168.10.0/24-netwerk zijn toegestaan, behalve PC1 die in de vorige verklaring werd geweigerd.

Deze ACL wordt toegepast op interface G0/0 in de inkomende richting. Omdat het filter alleen het 192.168.10.0/24 LAN op G0/0 beïnvloedt, is het efficiënter om de ACL toe te passen op de inkomende interface. De ACL zou kunnen worden toegepast op s0/0/0 in de uitgaande richting, maar dan zou R1 pakketten van alle netwerken moeten onderzoeken, inclusief 192.168.11.0/24.

9.2.1.5. Benoemde standaard ACL’s maken

Door een ACL een naam te geven, wordt het gemakkelijker om de functie ervan te begrijpen. Een ACL die is geconfigureerd om FTP te weigeren, kan bijvoorbeeld NO_FTP worden genoemd. Wanneer u uw ACL identificeert met een naam in plaats van met een nummer, zijn de configuratiemodus en de opdrachtsyntaxis iets anders.

Volgende toont de stappen die nodig zijn om een standaard met de naam ACL te maken.

Router(config)# ip access-list [standard | extended] name

Router(config-std-nacl)# [permit | deny | remark] {source [source-wildcard]} [log]

Router(config-if)# ip access-group name [in | out]

Stap 1. Gebruik vanuit de globale configuratiemodus de opdracht ip access-list om een benoemde ACL te maken. ACL-namen zijn alfanumeriek, hoofdlettergevoelig en moeten uniek zijn. De ip access-list standard name wordt gebruikt om een standaard met de naam ACL te maken, terwijl het commando ip accesslist extended name voor een uitgebreide toegangslijst is. Na het invoeren van de opdracht bevindt de router zich in de benoemde standaard ACL-configuratiemodus zoals aangegeven door de prompt.

Opmerking: Genummerde ACL’s gebruiken de globale configuratieopdracht access-list, terwijl benoemde IPv4-ACL’s de opdracht ip access-list gebruiken.

Stap 2. Gebruik in de benoemde ACL-configuratiemodus permit– of deny-instructies om een of meer voorwaarden op te geven om te bepalen of een pakket wordt doorgestuurd of verwijderd.

Stap 3. Pas de ACL toe op een interface met behulp van de opdracht ip access-group. Specificeer of de ACL moet worden toegepast op pakketten wanneer ze de interface binnenkomen (in) of toegepast worden op pakketten wanneer ze de interface verlaten (out).

Het volgend voorbeeld toont de opdrachten die worden gebruikt om een standaard met de naam ACL te configureren op router R1, interface G0/0 die host 192.168.11.10 geen toegang geeft tot het 192.168.10.0-netwerk. De ACL heet NO_ACCESS.

R1(config)# ip access-list standard NO_ACCESS
R1(config-std-nacl)# deny host 192.168.11.10
R1(config-std-nacl)# permit any
R1(config-std-nacl)# exit
R1(config)# interface g0/0
R1(config-if)# ip access-group NO_ACCESS out

Hoofdletters voor ACL-namen is niet vereist, maar zorgt ervoor dat ze opvallen bij het bekijken van de uitvoer van running-config. Het maakt het ook minder waarschijnlijk dat u per ongeluk twee verschillende ACL’s maakt met dezelfde naam maar met verschillend gebruik van hoofdletters.

9.2.1.6. ACL’s becommentariëren

U kunt het trefwoord remark gebruiken om opmerkingen (opmerkingen) op te nemen over vermeldingen in elke IP-standaard of uitgebreide ACL. De opmerkingen maken de ACL gemakkelijker voor u om te begrijpen en te scannen. Elke opmerkingsregel is beperkt tot 100 tekens.

De opmerking kan voor of na een permit of deny vermelding komen. U dient consequent te zijn in waar u de opmerking plaatst, zodat duidelijk is welke opmerking welke de permit of deny vermelding beschrijft. Het zou bijvoorbeeld verwarrend zijn om enkele opmerkingen vóór de bijbehorende vergunning- of afwijzingsverklaringen te hebben en enkele opmerkingen na de verklaringen.

Om een opmerking op te nemen voor IPv4-genummerde standaard of uitgebreide ACL’s, gebruikt u de opdracht access-list access-list_number remark remark global configuration command. Gebruik de no-vorm van deze opdracht om de opmerking te verwijderen.

In het eerste voorbeeld verbiedt de genummerde ACL het gastwerkstation 192.168.10.10 om S0/0/0 te verlaten, maar staat alle andere apparaten vanaf 192.168.0.0/16 toe.

R1(config)# access-list 1 remark Do not allow Guest workstation through
R1(config)# access-list 1 deny host 192.168.10.10
R1(config)# access-list 1 remark Allow devices from all other 192.168.x.x subnets
R1(config)# access-list 1 permit 192.168.0.0 0.0.255.255
R1(config)# interface s0/0/0
R1(config-if)# ip access-group 1 out
R1(config-if)#

Gebruik voor een vermelding in een benoemde standaard of uitgebreide ACL de opdracht remark access-list configuration. Gebruik de no-vorm van deze opdracht om de opmerking te verwijderen. Het volgende voorbeeld toont een standaard met de naam ACL. In dit voorbeeld geven de opmerkingen aan dat het lab-werkstation met het hostadres 192.168.11.10 wordt geweigerd, maar apparaten van alle andere netwerken zijn toegestaan.

R1(config)# ip access-list standard NO_ACCESS
R1(config-std-acl)# remark Do not allow access from Lab workstation
R1(config-std-acl)# deny host 192.168.11.10
R1(config-std-acl)# remark Allow access from all other networks
R1(config-std-acl)# permit any
R1(config-std-acl)# exit
R1(config)# interface g0/0
R1(config-if)# ip access-group NO_ACCESS out
R1(config-if)#

9.2.2. IPv4 ACL’s aanpassen

9.2.2.1. Standaard genummerde ACL’s bewerken

Bij het configureren van een standaard ACL worden de instructies toegevoegd aan de running-config. Er is echter geen ingebouwde bewerkingsfunctie waarmee u een wijziging in een ACL kunt bewerken.

Er zijn twee manieren waarop een standaard genummerde ACL kan worden bewerkt.

Methode 1: Een teksteditor gebruiken

Nadat iemand bekend is met het maken en bewerken van ACL’s, kan het gemakkelijker zijn om de ACL samen te stellen met een teksteditor zoals Microsoft Kladblok. Hiermee kunt u de ACL maken of bewerken en deze vervolgens in de router plakken. Voor een bestaande ACL kunt u de opdracht show running-config gebruiken om de ACL weer te geven, deze te kopiëren en in de teksteditor te plakken, de nodige wijzigingen aan te brengen en deze er weer in te plakken.

Configuratie: Neem bijvoorbeeld aan dat het host-IPv4-adres in de afbeelding onjuist is ingevoerd. In plaats van de 192.168.10.99-host had dit de 192.168.10.10-host moeten zijn. Hier zijn de stappen om ACL 1 te bewerken en te corrigeren:

Stap 1. Geef de ACL weer met de opdracht show running-config. Het voorbeeld in de afbeelding gebruikt het trefwoord include om alleen de ACE’s weer te geven.

Stap 2. Markeer de ACL, kopieer deze en plak deze in Microsoft Kladblok. Bewerk de lijst indien nodig. Nadat de ACL correct is weergegeven in Microsoft Kladblok, markeert u deze en kopieert u deze.

Stap 3. Verwijder in de globale configuratiemodus de toegangslijst met de opdracht no access-list 1. Anders zouden de nieuwe instructies worden toegevoegd aan de bestaande ACL. Plak vervolgens de nieuwe ACL in de configuratie van de router.

Stap 4. Gebruik de opdracht show running-config om de wijzigingen te verifiëren

R1(config)# access-list 1 deny host 192.168.10.99
R1(config)# access-list 1 permit 192.168.0.0 0.0.255.255
R1(config)# end
R1#

R1# show running-config | include access-list 1
access-list 1 deny host 192.168.10.99
access-list 1 permit 192.168.0.0 0.0.255.255
R1#

<text editor>
access-list 1 deny host 192.168.10.10
access-list 1 permit 192.168.0.0 0.0.255.255

R1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# no access-list 1
R1(config)# access-list 1 deny host 192.168.10.10
R1(config)# access-list 1 permit 192.168.0.0 0.0.255.255
R1(config)# end
R1#

R1# show running-config | include access-list 1
access-list 1 deny host 192.168.10.10
access-list 1 permit 192.168.0.0 0.0.255.255
R1#

Er moet worden vermeld dat bij het gebruik van de opdracht no access-list, verschillende IOS-softwareversies anders werken. Als de verwijderde ACL nog steeds op een interface wordt toegepast, werken sommige IOS-versies alsof er geen ACL is die uw netwerk beschermt, terwijl andere al het verkeer weigeren. Om deze reden is het een goede gewoonte om de verwijzing naar de toegangslijst uit de interface te verwijderen voordat u de toegangslijst wijzigt. Houd er ook rekening mee dat als er een fout in de nieuwe lijst staat, deze moet worden uitgeschakeld en het probleem moet worden opgelost. In dat geval heeft het netwerk opnieuw geen ACL tijdens het correctieproces.

Methode 2: Het volgnummer gebruiken

Zoals in het onderstaand voorbeeld te zien is, bevatte de initiële configuratie van ACL 1 een hoststatement voor host 192.168.10.99. Dit was fout. De host moet zijn geconfigureerd als 192.168.10.10. Volg deze stappen om de ACL te bewerken met volgnummers:

Stap 1. Geef de huidige ACL weer met de opdracht show access-lists 1. De uitvoer van deze opdracht zal later in deze sectie in meer detail worden besproken. Het volgnummer wordt aan het begin van elke instructie weergegeven. Het volgnummer werd automatisch toegekend bij het invoeren van de toegangslijst. Merk op dat de verkeerd geconfigureerde instructie het volgnummer 10 heeft.

Stap 2. Voer de ip access-lists standard opdracht in die wordt gebruikt om benoemde ACL’s te configureren. Het ACL-nummer, 1, wordt gebruikt als de naam. Eerst moet de verkeerd geconfigureerde instructie worden verwijderd met de opdracht no 10 waarbij 10 verwijst naar het volgnummer. Vervolgens wordt een nieuwe instructie met volgnummer 10 toegevoegd met het commando 10 deny host 192.168.10.10.

Opmerking: Verklaringen kunnen niet worden overschreven met hetzelfde volgnummer als een bestaande verklaring. De huidige verklaring moet eerst worden verwijderd en vervolgens kan de nieuwe worden toegevoegd.

Stap 3. Controleer de wijzigingen met de opdracht show access-lists.

R1(config)# access-list 1 deny host 192.168.10.99
R1(config)# access-list 1 permit 192.168.0.0 0.0.255.255
R1(config)# end
R1#

R1# show access-list 1
Standard IP access list 1
  10 deny   192.168.10.99
  20 permit 192.168.0.0, wildcard bits 0.0.255.255
R1#

R1# configure terminal
R1(config)# ip access-list standard 1
R1(config-std-acl)# no 10
R1(config-std-acl)# 10 deny host 192.168.10.10
R1(config-std-acl)# end 
R1#

R1# show access-lists
Standard IP access list 1
  10 deny   192.168.10.99
  20 permit 192.168.0.0, wildcard bits 0.0.255.255
R1#

Zoals eerder besproken, implementeert Cisco IOS een interne logica voor standaard toegangslijsten. De volgorde waarin standaard ACE’s worden ingevoerd, is mogelijk niet de volgorde waarin ze door de router worden opgeslagen, weergegeven of verwerkt. Het commando show access-lists geeft de ACE’s weer met hun volgnummers.

9.2.2.2. Standaard benoemde ACL’s bewerken

In een eerder voorbeeld werden volgnummers gebruikt om een standaard genummerde ACL te bewerken. Door te verwijzen naar de volgnummers van de afschriften kunnen afzonderlijke afschriften eenvoudig worden ingevoegd of verwijderd. Deze methode kan ook worden gebruikt om standaard ACL’s met de naam te bewerken.

De afbeelding toont een voorbeeld van het invoegen van een regel in een benoemde ACL.

In de eerste uitvoer van de opdracht show kunt u zien dat de ACL met de naam NO_ACCESS twee genummerde regels heeft die toegangsregels aangeven voor een werkstation met het IPv4-adres 192.168.11.10.
De ip access-list standard opdracht die wordt gebruikt om benoemde ACL’s te configureren. Vanuit de benoemde toegangslijst kunnen configuratiemodusstatements worden ingevoegd of verwijderd. De opdracht geen volgnummer wordt gebruikt om individuele instructies te verwijderen.
Als u een instructie wilt toevoegen om een ander werkstation te weigeren, moet u een genummerde regel invoegen. In het voorbeeld wordt het werkstation met het IPv4-adres 192.168.11.11 toegevoegd met een nieuw volgnummer van 15.
De laatste uitvoer van het show commando verifieert dat het nieuwe werkstation nu geen toegang heeft.

R1# show access-lists
Standard IP access list NO_ACCESS
    10 deny   192.168.11.10
    20 permit 192.168.11.0, wildcard bits 0.0.0.255
R1# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)# ip access-list standard NO_ACCESS
R1(config-std-nacl)#  15 deny host 192.168.11.11
R1(config-std-nacl)# end
R1# show access lists
Standard IP access list NO_ACCESS
  10 deny   192.168.11.10
  15 deny   192.168.11.11
  20 permit 192.168.11.0, wildcard bits 0.0.0.255
R1#

9.2.2.3. ACL’s verifiëren

Zoals weergegeven in het volgend voorbeeld wordt de opdracht show ip interface gebruikt om de ACL op de interface te verifiëren. De uitvoer van deze opdracht bevat het nummer of de naam van de toegangslijst en de richting waarin de ACL is toegepast. De uitvoer toont dat router R1 de toegangslijst 1 heeft toegepast op zijn S0/0/0 uitgaande interface en de toegangslijst NO_ACCESS is toegepast op zijn g0/0-interface, ook in de uitgaande richting.

R1# show ip interface s0/0/0
Serial0/0/0 is up, line protocol is up
Internet address is 10.1.1.1/30
<output omitted>
  Outgoing access list is 1
  Inbound  access list is not set
R1#
R1# show interface g0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 192.168.10.1/24
  Outgoing access list is NO_ACCESS
  Inbound  access list is not set
<output omitted>
R1#

Het volgend voorbeeld toont het resultaat van het geven van de opdracht show access-lists op router R1. Om een individuele toegangslijst te bekijken, gebruikt u de opdracht show access-lists gevolgd door het toegangslijstnummer of de naam. De NO_ACCESS-statements zien er misschien vreemd uit. Merk op dat volgnummer 15 wordt weergegeven vóór volgnummer 10. Dit is een resultaat van het interne proces van de router en zal later in deze sectie worden besproken.

R1# show access-lists
Standard IP access list 1
  10 deny   192.168.10.10
  20 permit 192.168.0.0, wildcard bits 0.0.255.255
Standard IP access list NO_ACCESS
  15 deny   192.168.11.11
  10 deny   192.168.11.10
  20 permit 192.168.11.0, wildcard bits 0.0.0.255
R1#

9.2.2.4. ACL-statistieken

Zodra de ACL is toegepast op een interface en er enige tests hebben plaatsgevonden, toont de opdracht show access-lists statistieken voor elke verklaring waaraan is voldaan. Merk in de uitvoer in in het volgend voorbeeld op dat sommige van de uitspraken zijn gematcht. Wanneer verkeer wordt gegenereerd dat moet overeenkomen met een ACL-instructie, moeten de overeenkomsten die worden weergegeven in de uitvoer van de opdracht show access-lists toenemen. Als in dit voorbeeld bijvoorbeeld een ping wordt uitgegeven van PC1 naar PC3 of PC4, zal de uitvoer een toename van de overeenkomsten voor de deny-instructie van ACL 1 laten zien.

R1# show access-lists
Standard IP access list 1
  10 deny   192.168.10.10 (4 match(es))
  20 permit 192.168.0.0, wildcard bits 0.0.255.255
Standard IP access list NO_ACCESS
  15 deny   192.168.11.11
  10 deny   192.168.11.10 (4 match(es))
  20 permit 192.168.11.0, wildcard bits 0.0.0.255
R1#
<output after pinging PC3 from PC1>
R1# show access-lists
Standard IP access list 1
  10 deny   192.168.10.10 (8 match(es))
  20 permit 192.168.0.0, wildcard bits 0.0.255.255
Standard IP access list NO_ACCESS
  15 deny   192.168.11.11
  10 deny   192.168.11.10 (4 match(es))
  20 permit 192.168.11.0, wildcard bits 0.0.0.255
R1#

Zowel permit als deny vermeldingen houden statistieken voor overeenkomsten bij, onthoud echter dat elke ACL een impliciete ontkenning heeft als de laatste verklaring. Deze verklaring zal niet verschijnen in de opdracht show access-lists, daarom zullen de statistieken voor die vermelding niet verschijnen. Om statistieken voor de impliciete deny any-instructie te bekijken, kan de verklaring handmatig worden geconfigureerd en in de uitvoer verschijnen. Uiterste voorzichtigheid moet worden betracht bij het handmatig configureren van de deny any-instructie, omdat deze overeenkomt met al het verkeer. Als deze instructie niet is geconfigureerd als de laatste instructie in de ACL, kan dit onverwachte resultaten veroorzaken.

Tijdens het testen van een ACL kunnen de tellers worden gewist met de opdracht clear access-list counters. Deze opdracht kan alleen of met het nummer of de naam van een specifieke ACL worden gebruikt. Zoals weergegeven in afbeelding 2 wist deze opdracht de statistische tellers voor een ACL.



R1# show access-lists
Standard IP access list 1
  10 deny   192.168.10.10 (4 match(es))
  20 permit 192.168.0.0, wildcard bits 0.0.255.255
Standard IP access list NO_ACCESS
  15 deny   192.168.11.11
  10 deny   192.168.11.10 (4 match(es))
  20 permit 192.168.11.0, wildcard bits 0.0.0.255
R1#
R1# clear access-list counters
R1#
R1# show access-lists
Standard IP access list 1
  10 deny   192.168.10.10
  20 permit 192.168.0.0, wildcard bits 0.0.255.255
Standard IP access list NO_ACCESS
  15 deny   192.168.11.11
  10 deny   192.168.11.10
  20 permit 192.168.11.0, wildcard bits 0.0.0.255
R1#

9.2.2.6. Standaard ACL-volgnummers

Cisco IOS implementeert een interne logica voor standaard ACL’s. Zoals eerder besproken, voorkomt een deel van deze logica dat hostinstructies worden geconfigureerd na een bereikinstructie als de host lid is van dat bereik, zoals weergegeven in het volgend voorbeeld.

R1(config)# access-list 3 deny 192.168.10.0 0.0.0.255
R!(config)# access-list 3 permit host 192.168.10.10
% Access rule can't be configured at higher sequence num as it is part of the existing rule at sequence num 10
R1(config)#

Een ander onderdeel van de interne logica van IOS betreft de interne sequencing van standaard ACE’s. Het volgend voorbeeld toont de configuratie van een standaard toegangslijst. Range-instructies die drie netwerken weigeren, worden eerst geconfigureerd, gevolgd door vijf host-statements. De host-statements zijn allemaal geldige statements omdat hun host-IP-adressen geen deel uitmaken van de eerder ingevoerde range-statements.

<range (network) statements>
R1(config)# access-list 1 deny 192.168.10.0 0.0.0.255
R1(config)# access-list 1 deny 192.168.20.0 0.0.0.255
R1(config)# access-list 1 deny 192.168.30.0 0.0.0.255
<host statements>
R1(config)# access-list 1 permit 10.0.0.1
R1(config)# access-list 1 permit 10.0.0.2
R1(config)# access-list 1 permit 10.0.0.3
R1(config)# access-list 1 permit 10.0.0.4
R1(config)# access-list 1 permit 10.0.0.5
R1(config)# end
R1# show running-config | include access-list 1
access-list 1 permit 10.0.0.2
access-list 1 permit 10.0.0.3
access-list 1 permit 10.0.0.1
access-list 1 permit 10.0.0.4
access-list 1 permit 10.0.0.5
access-list 1 deny   192.168.10.0 0.0.0.255
access-list 1 deny   192.168.20.0 0.0.0.255
access-list 1 deny   192.168.30.0 0.0.0.255
R1#

De opdracht show running-config wordt gebruikt om de ACL-configuratie te verifiëren. Merk op dat de verklaringen in een andere volgorde worden weergegeven dan ze zijn ingevoerd. We zullen het commando show access-lists gebruiken om de logica hierachter te begrijpen.

Zoals weergegeven in het onderstaand voorbeeld, geeft de opdracht show access-lists ACE’s weer samen met hun volgnummers. We zouden kunnen verwachten dat de volgorde van de uitspraken in de uitvoer overeenkomt met de volgorde waarin ze zijn ingevoerd. Echter, de output show access-lists laat zien dat dit niet het geval is.

De volgorde waarin de standaard ACE’s worden vermeld, is de volgorde die door de IOS wordt gebruikt om de lijst te verwerken. Merk op dat de instructies zijn gegroepeerd in twee secties, host-instructies gevolgd door range-instructies. Het volgnummer geeft de volgorde aan waarin het afschrift is ingevoerd, niet de volgorde waarin het afschrift wordt verwerkt.

De host-statements worden als eerste vermeld, maar niet noodzakelijkerwijs in de volgorde waarin ze zijn ingevoerd. De IOS plaatst host-statements in een volgorde met behulp van een speciale hash-functie. De resulterende volgorde optimaliseert het zoeken naar een host-ACL-item.

De range-statements worden weergegeven na de host-statements. Deze verklaringen worden weergegeven in de volgorde waarin ze zijn ingevoerd.

Bedenk dat standaard en genummerde ACL’s kunnen worden bewerkt met volgnummers. Het volgnummer dat wordt weergegeven in de uitvoer van de opdracht show access-lists is het nummer dat wordt gebruikt bij het verwijderen van een individuele instructie uit de lijst. Wanneer u een nieuwe ACL-instructie invoegt, heeft het volgnummer alleen invloed op de locatie van een bereikinstructie in de lijst. Host-statements worden altijd op volgorde gezet met behulp van de hash-functie.

Als we verder gaan met het voorbeeld, wordt de router na het opslaan van de running-configuratie opnieuw geladen (reboot). Zoals weergegeven in het volgend voorbeel, geeft de opdracht show access-lists de ACL in dezelfde volgorde weer, maar de instructies zijn opnieuw genummerd. De volgnummers staan nu in numerieke volgorde.

R1# show access-lists 1

Standard IP access list 1
<host statements are listed first in an order to be efficiently processed by the OS>

  50 permit 10.0.0.2
  60 permit 10.0.0.3
  40 permit 10.0.0.1
  70 permit 10.0.0.4
  80 permit 10.0.0.5
<range statements are listed after host statements, in the order they were entered>
  10 deny  192.168.10.0, wildcard bits 0.0.0.255
  20 deny  192.168.20.0, wildcard bits 0.0.0.255
  30 deny  192.168.30.0, wildcard bits 0.0.0.255
R1# copy running-config startup-config
R1# reload
R1# show access-lists 1
  10 permit 10.0.0.2
  20 permit 10.0.0.3
  30 permit 10.0.0.1
  40 permit 10.0.0.4
  50 permit 10.0.0.5
  60 deny  192.168.10.0, wildcard bits 0.0.0.255
  70 deny  192.168.20.0, wildcard bits 0.0.0.255
  80 deny  192.168.30.0, wildcard bits 0.0.0.255
R1#

Opmerking: de hash-functie wordt alleen toegepast op hostinstructies in een standaard IPv4-toegangslijst. Het algoritme wordt niet gebruikt voor IPv4 uitgebreide ACL’s of IPv6 ACL’s. Dit komt omdat uitgebreide en IPv6 ACL’s op meer dan alleen een enkel bronadres filteren. De details van de hashfunctie vallen buiten het bestek van deze cursus.

9.2.3. VTY poorten beveiligen met een standaard IPv4 ACL

9.2.3.1. Een standaard ACL configureren om een VTY-poort te beveiligen

Cisco raadt het gebruik van SSH aan voor administratieve verbindingen met routers en switches. Als de Cisco IOS-software-image op uw router geen SSH ondersteunt, kunt u de beveiliging van administratieve lijnen verbeteren door VTY-toegang te beperken. Het beperken van VTY-toegang is een techniek waarmee u kunt definiëren welke IP-adressen Telnet-toegang tot het EXEC-proces van de router hebben. U kunt bepalen welk administratief werkstation of netwerk uw router beheert met een ACL en een access-class vermelding die is geconfigureerd op uw VTY-lijnen. U kunt deze techniek ook gebruiken met SSH om de beheerderstoegangsbeveiliging verder te verbeteren.

De opdracht access-class die is geconfigureerd in de lijnconfiguratiemodus, beperkt inkomende en uitgaande verbindingen tussen een bepaalde VTY (naar een Cisco-apparaat) en de adressen in een toegangslijst.

Standaard- en uitgebreide toegangslijsten zijn van toepassing op pakketten die via een router reizen. Ze zijn niet ontworpen om pakketten te blokkeren die afkomstig zijn van de router. Een uitgaande Telnet uitgebreide ACL verhindert niet standaard door de router geïnitieerde Telnet-sessies.

Het filteren van Telnet- of SSH-verkeer wordt doorgaans beschouwd als een uitgebreide IP ACL-functie omdat het een protocol van een hoger niveau filtert. Omdat de opdracht access-class echter wordt gebruikt om inkomende of uitgaande Telnet/SSH-sessies op bronadres te filteren, kan een standaard ACL worden gebruikt.

De opdrachtsyntaxis van de opdracht access-class is:

Router(config-line)# access-class access-list-number { in [ vrf-out ] | out }

De parameter in beperkt inkomende verbindingen tussen de adressen in de toegangslijst en het Cisco-apparaat, terwijl de parameter out de uitgaande verbindingen tussen een bepaald Cisco-apparaat en de adressen in de toegangslijst beperkt.

Een voorbeeld waarbij een reeks adressen toegang krijgt tot VTY-lijnen 0 – 4 wordt getoond in Afbeelding 1. De ACL in de afbeelding is geconfigureerd om netwerk 192.168.10.0 toegang te geven tot VTY-lijnen 0 – 4 maar alle andere netwerken te weigeren.

Bij het configureren van toegangslijsten op VTY’s moet met het volgende rekening worden gehouden:

Zowel benoemde als genummerde toegangslijsten kunnen worden toegepast op VTY’s.
Er moeten identieke beperkingen worden ingesteld voor alle VTY’s, omdat een gebruiker kan proberen verbinding te maken met een van hen.

R1(config)# line vty 0 4
R1(config-line)# login local
R1(config-line)# transport input ssh
R1(config-line)# access-class 21 in
R1(config-line)# exit
R1(config)# access-list 21 permit 192.168.10.0 0.0.0.255
R1(config)# access-list 21 deny any
R1(config)#

9.2.3.2. Een standaard ACL verifiëren die wordt gebruikt om een VTY-poort te beveiligen

Nadat de ACL om de toegang tot de VTY-lijnen te beperken is geconfigureerd, is het belangrijk om te controleren of deze werkt zoals verwacht. De afbeelding toont twee apparaten die proberen verbinding te maken met R1 via SSH. Toegangslijst 21 is geconfigureerd op de VTY-lijnen op R1. PC1 is succesvol, terwijl PC2 geen SSH-verbinding tot stand kan brengen. Dit is het verwachte gedrag, aangezien de geconfigureerde toegangslijst VTY-toegang toestaat vanaf het 192.168.10.0/24-netwerk terwijl alle andere apparaten worden geweigerd.

De uitvoer voor R1 toont het resultaat van het geven van het commando show access-lists na de SSH-pogingen van PC1 en PC2. De match in de permit-regel van de output is het resultaat van een succesvolle SSH-verbinding door PC1. De overeenkomst in de deny-instructie is te wijten aan de mislukte poging om een SSH-verbinding tot stand te brengen door PC2, een apparaat op het 192.168.11.0/24-netwerk.

R1# show access-lists
Standard IP access list 21
10 permit 192.168.10.0, wildcard bits 0.0.0.255 (2 matches)
20 deny any (1 match)
R1#

PC1> ssh 192.168.10.1
Login as: admin
Password: *****
PC1>

PC2> ssh 192.168.11.1
ssh connect to host 192.168.11.1 port 22: Connection refused
PC2>

9.3. Uitgebreide IPv4 ACL’s

9.3.1. Structuur van een uitgebreide IPv4 ACL

9.3.1.1. Uitgebreide ACL’s

Voor een nauwkeuriger beheer van de verkeersfiltering kunnen uitgebreide IPv4-ACL’s worden gemaakt. Uitgebreide ACL’s zijn genummerd van 100 tot 199 en 2000 tot 2699, wat een totaal van 799 mogelijk verlengde genummerde ACL’s oplevert. Uitgebreide ACL’s kunnen ook een naam krijgen.

Uitgebreide ACL’s worden vaker gebruikt dan standaard ACL’s omdat ze een grotere mate van controle bieden. Zoals in de afbeelding te zien is, controleren uitgebreide ACL’s, net als standaard ACL’s, bronadressen van pakketten, maar ze controleren ook het bestemmingsadres, protocollen en poortnummers (of services). Dit biedt een groter aantal criteria waarop de ACL kan worden gebaseerd. Een uitgebreide ACL kan bijvoorbeeld tegelijkertijd e-mailverkeer van een netwerk naar een specifieke bestemming toestaan, terwijl bestandsoverdrachten en surfen op het web worden geweigerd.

De mogelijkheid om te filteren op protocol en poortnummer stelt netwerkbeheerders in staat zeer specifieke uitgebreide ACL’s te bouwen. Een toepassing kan worden gespecificeerd door het poortnummer of de naam van een bekende poort te configureren.

Het volgend voorbeeld toont enkele voorbeelden van hoe een beheerder een TCP- of UDP-poortnummer specificeert door dit aan het einde van de uitgebreide ACL-instructie te plaatsen. Logische bewerkingen kunnen worden gebruikt, zoals gelijk (eq), niet gelijk (neq), groter dan (gt) en kleiner dan (lt).

<met behulp van poortnummers>
access-list 114 permit tcp 192.168.20.0 0.0.0.255 any eq 23
access-list 114 permit tcp 192.168.20.0 0.0.0.255 any eq 21
access-list 114 permit tcp 192.168.20.0 0.0.0.255 any eq 20
<met behulp van sleutelwoorden>
access-list 114 permit tcp 192.168.20.0 0.0.0.255 any eq telnet
access-list 114 permit tcp 192.168.20.0 0.0.0.255 any eq ftp
access-list 114 permit tcp 192.168.20.0 0.0.0.255 any eq ftp-data

Het volgend voorbeeld laat zien hoe u een lijst met poortnummers en trefwoorden kunt weergeven die kunnen worden gebruikt bij het bouwen van een ACL met behulp van de opdracht:

R1(config)# access-list 101 permit tcp any any eq ?
   <0-65535>    Port number
   bgp          Border Gateway Protocol (179)
   chargen      Character generator (19)
   cmd          Remote commands (rcmd, 514)
   daytime      Daytime (13)
   discard      Discard (9)
   domain       Domain Name Service (53)
   drip         Dynamic Routing Information Protocol (3949)
   echo         Echo (7)
   exec         Exec (rsh, 512)
   finger       Finger (79)
   ftp          File Transfer Protocol (21)
   ftp-data     FTP data connections (20)
   gopher       Gopher (70)
   hostname     NIC hostname server (101)
   ident        Ident Protocol (113)
   irc          Internet Relay Chat (194)
   klogin       Kerberos login (543)
   kshell       Kerberos shell (544)
   login        Login (rlogin, 513)
   lpd          Printer service (515)
   nntp         Network News Transport Protocol (119)
   pim-auto-rp  PIM Auto-RP (496)
   pop2         Post Office Protocol v2 (109)
   pop3         Post Office Protocol v3 (110)
   smtp         Simple Mail Transport Protocol (25)
   sunrpc       Sun Remote Procedure Call (111)
   tacacs       TAC Access Control System (49)
   talk         Talk (517)
   telnet       Telnet (23)
   time         Time (37)
   uucp         Unix-to-Unix Copy Program (540)
   whois        Nicname (43)
   www          World Wide Web (HTTP, 80)
R1#

9.3.2. Uitgebreide IPv4 ACL’s configureren

9.3.2.1. Uitgebreide ACL’s configureren

De procedurele stappen voor het configureren van uitgebreide ACL’s zijn dezelfde als voor standaard ACL’s. De uitgebreide ACL wordt eerst geconfigureerd en vervolgens geactiveerd op een interface. De syntaxis en parameters van de opdracht zijn echter complexer om de extra functies van uitgebreide ACL’s te ondersteunen.

Opmerking: de interne logica die wordt toegepast op het bestellen van standaard ACL-instructies, is niet van toepassing op uitgebreide ACL’s. De volgorde waarin de afschriften tijdens de configuratie worden ingevoerd, is de volgorde waarin ze worden weergegeven en verwerkt.

Volgende tabel toont de uitleg van de algemene opdrachtsyntaxis voor uitgebreide IPv4-ACL’s. Merk op dat er veel trefwoorden en parameters zijn voor uitgebreide ACL’s. Het is niet nodig om alle trefwoorden en parameters te gebruiken bij het configureren van een uitgebreide ACL. Bedenk dat de ? kan worden gebruikt om hulp te krijgen bij het invoeren van complexe opdrachten.

access-list access-list-number {deny | permit | remark} protocol {source source-wildcard} [operator port [port-number or name]] {destination destination-wildcard} [ operator port [port-number or name]]

Parameter	Beschrijving
access-list-number	Identificeert de toegangslijst met een nummer in het bereik 100 tot 199 (voor een uitgebreide IP ACL) en 2000 tot 2699 (uitgebreide IP ACL’s).
deny	Weigert toegang als aan de voorwaarden wordt voldaan.
permit	Geeft toegang als aan de voorwaarden wordt voldaan.
remark	Wordt gebruikt om een opmerking of opmerking in te voeren.
protocol	Naam of nummer van een internetprotocol. Veelgebruikte zoekwoorden zijn onder meer: icmp, ip, tcp of udp. Om een internetprotocol (inclusief ICMP, TCP en UDP) te matchen, gebruikt u het ip sleutelwoord.
source	Nummer van het netwerk of de host waarvandaan het pakket wordt verzonden.
source-wildcard	Wildcard-bits die moeten worden toegepast op de bron.
destination	Nummer van het netwerk of de host waarnaar het pakket wordt verzonden.
destination-wildcard	Op de bestemming toe te passen jokertekens.
operator	(Optioneel) Vergelijkt bron- of doelpoorten. Mogelijke operanden omvatten: lt (kleiner dan), gt (groter dan), eq (gelijk aan), neq (niet gelijk aan) en range (inclusief bereik)
port	(Optioneel) Het decimale getal of de naam van een TCP- of UDP-poort.
establshed	(Optioneel) Alleen voor het TCP-protocol: Geeft een tot stand gebrachte verbinding aan.

Het volgend voorbeel toont een een uitgebreide ACL. In dit voorbeeld heeft de netwerkbeheerder ACL’s geconfigureerd om netwerktoegang te beperken, zodat browsen op websites alleen mogelijk is vanaf het LAN dat is aangesloten op interface G0/0 naar een extern netwerk. Met ACL 103 kan verkeer afkomstig van elk adres op het 192.168.10.0-netwerk naar elke bestemming gaan, met de beperking dat het verkeer alleen poorten 80 (HTTP) en 443 (HTTPS) gebruikt.

R1(config)# access-list 103 permit tcp 192.168.10.0 0.0.0.255 any eq 80
R1(config)# access-list 103 permit tcp 192.168.10.0 0.0.0.255 any eq 443
R1(config)# access-list 104 permit tcp any 192.168.10.0 0.0.0.255 any established

De aard van HTTP vereist dat verkeer terugstroomt naar het netwerk vanaf websites die toegankelijk zijn vanaf interne clients. De netwerkbeheerder wil dat retourverkeer naar HTTP-uitwisselingen van aangevraagde websites beperken, terwijl al het andere verkeer wordt geweigerd. ACL 104 doet dat door al het inkomende verkeer te blokkeren, behalve voor eerder gemaakte verbindingen. De vergunningverklaring in ACL 104 staat inkomend verkeer toe met behulp van de established parameter.

Met de established parameter kunnen alleen reacties op verkeer dat afkomstig is van het 192.168.10.0/24-netwerk naar dat netwerk terugkeren. Er vindt een overeenkomst plaats als het terugkerende TCP-segment de ACK- of reset-bits (RST) heeft ingesteld, wat aangeeft dat het pakket tot een bestaande verbinding behoort. Zonder de established parameter in de ACL-instructie, zouden clients verkeer naar een webserver kunnen sturen, maar geen verkeer ontvangen dat terugkeert van de webserver.

9.3.2.2. Uitgebreide ACL’s toepassen op interfaces

In het vorige voorbeeld heeft de netwerkbeheerder een ACL geconfigureerd zodat gebruikers van het 192.168.10.0/24-netwerk door zowel onveilige als beveiligde websites kunnen bladeren. Ook al is het geconfigureerd, de ACL filtert het verkeer pas nadat het op een interface is toegepast. Als u een ACL op een interface wilt toepassen, moet u eerst overwegen of het te filteren verkeer in- of uitgaat. Wanneer een gebruiker op het interne LAN een website op internet bezoekt, is verkeer verkeer dat naar internet gaat. Wanneer een interne gebruiker een e-mail van internet ontvangt, komt er verkeer naar de lokale router. Bij het toepassen van een ACL op een interface krijgen in en uit echter verschillende betekenissen. Vanuit een ACL-overweging hebben in en uit betrekking op de routerinterface.

In de topologie in de figuur heeft R1 drie interfaces. Het heeft een seriële interface, S0/0/0, en twee Gigabit Ethernet-interfaces, G0/0 en G0/1. Bedenk dat een uitgebreide ACL doorgaans dicht bij de bron moet worden toegepast. In deze topologie is de interface die het dichtst bij de bron van het doelverkeer ligt, de G0/0-interface.

Webverzoekverkeer van gebruikers op het 192.168.10.0/24 LAN is binnenkomend naar de G0/0-interface. Retourverkeer van bestaande verbindingen naar gebruikers op het LAN is uitgaand vanaf de G0/0-interface. Het voorbeeld past de ACL in beide richtingen toe op de G0/0-interface. De inkomende ACL, 103, controleert op het type verkeer. De uitgaande ACL, 104, controleert op retourverkeer van gevestigde verbindingen. Hierdoor wordt de internettoegang van 192.168.10.0 beperkt, zodat alleen browsen op de website mogelijk is.

Opmerking: de toegangslijsten kunnen zijn toegepast op de S0/0/0-interface, maar in dat geval zou het ACL-proces van de router alle pakketten moeten onderzoeken die de router binnenkomen, niet alleen het verkeer van en naar 192.168.11.0. Dit zou onnodige verwerking door de router veroorzaken.

9.3.2.3. Verkeer filteren met uitgebreide ACL’s

Het voorbeeld in figuur 1 ontkent FTP-verkeer van subnet 192.168.11.0 dat naar subnet 192.168.10.0 gaat, maar staat al het andere verkeer toe. Let op het gebruik van wildcard-maskers en de expliciete ontkenning van een verklaring. Onthoud dat FTP de TCP-poorten 20 en 21 gebruikt; daarom vereist de ACL beide poortnaamsleutelwoorden ftp en ftp-data of eq 20 en eq 21 om FTP te weigeren.

Als u poortnummers gebruikt in plaats van poortnamen, worden de opdrachten geschreven als:

access-list 101 deny tcp 192.168.11.0 0.0.0.255 192.168.10.0 0.0.0.255 eq 20
access-list 101 deny tcp 192.168.11.0 0.0.0.255 192.168.10.0 0.0.0.255 eq 21

Om te voorkomen dat de impliciete weiger elke instructie aan het einde van de ACL al het verkeer blokkeert, wordt de permit ip elke willekeurige instructie toegevoegd. Zonder ten minste één vergunningverklaring in een ACL zou al het verkeer op de interface waar die ACL is toegepast, worden verwijderd. De ACL moet inkomend worden toegepast op de G0/1-interface, zodat verkeer van het 192.168.11.0/24 LAN wordt gefilterd wanneer het de routerinterface binnenkomt.

In het voorbeeld in Afbeelding 2 wordt Telnet-verkeer van elke bron naar het 192.168.11.0/24 LAN geweigerd, maar wordt al het andere IP-verkeer toegestaan. Omdat verkeer dat bestemd is voor LAN 192.168.11.0/24 uitgaand is op interface G0/1, zou de ACL worden toegepast op G0/1 met het sleutelwoord out. Let op het gebruik van eventuele trefwoorden in de vergunningverklaring. Deze vergunningsverklaring wordt toegevoegd om ervoor te zorgen dat er geen ander verkeer wordt geblokkeerd.

Opmerking: De voorbeelden in de figuren 1 en 2 gebruiken beide de permit ip any any vermelding op het einde van de ACL. Voor meer veiligheid kan de permit 192.168.11.0 0.0.0.255 any commando worden gebruikt.

9.2.2.4. Benoemde uitgebreide ACL’s maken

Uitgebreide ACL’s met een naam worden in wezen op dezelfde manier gemaakt als standaard ACL’s met een naam. Volg deze stappen om een uitgebreide ACL te maken met namen:

Stap 1. Gebruik vanuit de globale configuratiemodus de opdracht ip access-list extended name om een naam voor de uitgebreide ACL te definiëren.

Stap 2. Geef in de benoemde ACL-configuratiemodus de voorwaarden permit of deny op.

Stap 3. Keer terug naar de bevoorrechte EXEC-modus en verifieer de ACL met de opdracht show access-lists name.

Stap 4. Sla de gegevens op in het configuratiebestand met de opdracht copy running-config startup-config.

Om een benoemde uitgebreide ACL te verwijderen, gebruikt u de globale configuratieopdracht no ip access-list extended name.

De afbeelding toont de benoemde versies van de ACL’s die in de vorige voorbeelden zijn gemaakt. De genoemde ACL, SURFING, geeft de gebruikers op het 192.168.10.0/24 LAN toegang tot websites. De genoemde ACL, BROWSING, staat het terugkerende verkeer van gevestigde verbindingen toe. Met behulp van de ACL-namen worden de regels inkomend en uitgaand toegepast op de G0/0-interface.

9.3.2.5. Uitgebreide ACL’s verifiëren

Nadat een ACL is geconfigureerd en toegepast op een interface, gebruikt u Cisco IOS show-opdrachten om de configuratie te verifiëren. In de afbeelding toont het bovenste voorbeeld de Cisco IOS-opdracht die wordt gebruikt om de inhoud van alle ACL’s weer te geven. Het onderste voorbeeld toont het resultaat van de opdracht show ip interface g0/0 op router R1.

In tegenstelling tot standaard ACL’s implementeren uitgebreide ACL’s niet dezelfde interne logica en hashing-functie. De uitvoer- en volgnummers die worden weergegeven in de uitvoer van het commando show access-list is de volgorde waarin de instructies zijn ingevoerd. Hostvermeldingen worden niet automatisch weergegeven vóór bereikvermeldingen.

De opdracht show ip interface wordt gebruikt om de ACL op de interface en de richting waarin deze is toegepast te verifiëren. De uitvoer van deze opdracht bevat het nummer of de naam van de toegangslijst en de richting waarin de ACL is toegepast. De ACL-namen met hoofdletters BROWSING en SURFING vallen op in de schermuitvoer.

Nadat een ACL-configuratie is geverifieerd, is de volgende stap om te bevestigen dat de ACL’s werken zoals gepland; verkeer blokkeren en toestaan zoals verwacht.

De richtlijnen die eerder in deze sectie zijn besproken, suggereren dat ACL’s op een testnetwerk moeten worden geconfigureerd en vervolgens op het productienetwerk moeten worden geïmplementeerd.

9.3.2.6. Uitgebreide ACL’s bewerken

Het bewerken van een uitgebreide ACL kan worden bereikt met hetzelfde proces als het bewerken van een standaard ACL, zoals besproken in een vorige sectie. Een uitgebreide ACL kan worden gewijzigd met:

Methode 1 Teksteditor – Met deze methode wordt de ACL gekopieerd en geplakt in de teksteditor waar de wijzigingen worden aangebracht. De huidige toegangslijst wordt verwijderd met het commando no access-list. De gewijzigde ACL wordt vervolgens weer in de configuratie geplakt.
Methode 2 Volgnummers – Volgnummers kunnen worden gebruikt om een ACL-instructie te verwijderen of in te voegen. De opdracht ip access-list extended name wordt gebruikt om naar de configuratiemodus voor ACL-namen te gaan. Als de ACL genummerd is in plaats van benoemd, wordt het ACL-nummer gebruikt in de naamparameter. ACE’s kunnen worden ingevoegd of verwijderd.

In de afbeelding moet de beheerder de ACL met de naam SURFING bewerken om een typefout in de bronnetwerkverklaring te corrigeren. Om de huidige volgnummers te bekijken, wordt het commando show access-lists gebruikt. De instructie die moet worden bewerkt, wordt geïdentificeerd als instructie 10. De oorspronkelijke instructie wordt verwijderd met de opdracht no sequence_#. De gecorrigeerde verklaring wordt toegevoegd ter vervanging van de oorspronkelijke verklaring.

9.4. Problemen met ACL’s oplossen

9.4.1. Pakketten verwerken met ACL’s

9.4.1.1. Inkomende en uitgaande ACL-logica

Inkomende ACL-logica

Afbeelding 1 toont de logica voor een inkomende ACL. Als de informatie in een pakketheader en een ACL-instructie overeenkomen, worden de rest van de instructies in de lijst overgeslagen en wordt het pakket toegestaan of geweigerd zoals gespecificeerd door de overeenkomende instructie. Als een pakketheader niet overeenkomt met een ACL-instructie, wordt het pakket getoetst aan de volgende instructie in de lijst. Dit matchingproces gaat door totdat het einde van de lijst is bereikt.

Aan het einde van elke ACL staat een statement is een impliciete ontkenning van een statement. Deze verklaring wordt niet weergegeven in de uitvoer. Deze laatste impliciete verklaring was van toepassing op alle pakketten waarvoor de voorwaarden niet waar waren. Deze laatste testconditie komt overeen met alle andere pakketten en resulteert in een “weigeren” -actie. In plaats van een interface in of uit te gaan, laat de router al deze resterende pakketten vallen. Deze laatste verklaring wordt vaak de “impliciete verklaring weigeren” of de verklaring “alle verkeer weigeren” genoemd. Vanwege deze verklaring moet een ACL ten minste één vergunningverklaring bevatten; anders blokkeert de ACL al het verkeer.

Uitgaande ACL-logica

Afbeelding 2 toont de logica voor een uitgaande ACL. Voordat een pakket wordt doorgestuurd naar een uitgaande interface, controleert de router de routeringstabel om te zien of het pakket routeerbaar is. Als het pakket niet routeerbaar is, wordt het verwijderd en niet getest tegen de ACE’s. Vervolgens controleert de router of de uitgaande interface is gegroepeerd in een ACL. Als de uitgaande interface niet is gegroepeerd in een ACL, kan het pakket naar de uitvoerbuffer worden verzonden. Voorbeelden van uitgaande ACL-bewerkingen zijn als volgt:

Geen ACL toegepast op de interface: Als de uitgaande interface niet is gegroepeerd in een uitgaande ACL, wordt het pakket rechtstreeks naar de uitgaande interface verzonden.
ACL toegepast op de interface: Als de uitgaande interface is gegroepeerd in een uitgaande ACL, wordt het pakket niet verzonden op de uitgaande interface totdat het is getest door de combinatie van ACE’s die aan die interface zijn gekoppeld. Op basis van de ACL-tests wordt het pakket toegestaan of geweigerd.

Voor uitgaande lijsten betekent “permit” om het pakket naar de uitvoerbuffer te sturen, en “deny” betekent het weggooien van het pakket.

9.4.1.2. ACL logische bewerkingen

ACL en routerings- en ACL-processen op een router

De afbeelding toont de logica van routering en ACL-processen. Wanneer een pakket bij een routerinterface aankomt, is het routerproces hetzelfde, of ACL’s nu worden gebruikt of niet. Als een frame een interface binnenkomt, controleert de router of het Layer 2-bestemmingsadres overeenkomt met het Layer 2-adres van de interface, of dat het frame een broadcastframe is.

Als het frame-adres wordt geaccepteerd, wordt de frame-informatie verwijderd en controleert de router op een ACL op de inkomende interface. Als er een ACL bestaat, wordt het pakket getest aan de hand van de instructies in de lijst.

Als het pakket overeenkomt met een instructie, is het pakket toegestaan of geweigerd. Als het pakket wordt geaccepteerd, wordt het vervolgens gecontroleerd aan de hand van invoer in de routeringstabel om de bestemmingsinterface te bepalen. Als er een routeringstabel voor de bestemming bestaat, wordt het pakket geschakeld naar de uitgaande interface, anders wordt het pakket verwijderd.

Vervolgens controleert de router of de uitgaande interface een ACL heeft. Als er een ACL bestaat, wordt het pakket getest aan de hand van de instructies in de lijst.

Als het pakket overeenkomt met een instructie, is het toegestaan of geweigerd.

Als er geen ACL is of het pakket is toegestaan, wordt het pakket ingekapseld in het nieuwe Layer 2-protocol en doorgestuurd via de interface naar het volgende apparaat.

9.4.1.3. Standaard ACL-beslissingsproces

Standaard ACL’s onderzoeken alleen het bron-IPv4-adres. Er wordt geen rekening gehouden met de bestemming van het pakket en de betrokken poorten.

Het beslissingsproces voor een standaard ACL is in kaart gebracht in de figuur. Cisco IOS-software toetst adressen één voor één aan de voorwaarden in de ACL. De eerste match bepaalt of de software het adres accepteert of weigert. Omdat de software stopt met het testen van voorwaarden na de eerste match, is de volgorde van de voorwaarden van cruciaal belang. Als er geen voorwaarden overeenkomen, wordt het adres afgewezen.

9.4.1.4. Uitgebreid ACL-beslissingsproces

De afbeelding toont het logische beslissingspad dat wordt gebruikt door een uitgebreide ACL die is gebouwd om te filteren op bron- en bestemmingsadressen, en protocol- en poortnummers. In dit voorbeeld filtert de ACL eerst op het bronadres, daarna op de poort en het protocol van de bron. Vervolgens filtert het op het bestemmingsadres, vervolgens op de poort en het protocol van de bestemming en neemt het een definitieve beslissing over toestemming of weigering.

Bedenk dat vermeldingen in ACL’s de een na de ander worden verwerkt, dus een ‘Nee’-beslissing hoeft niet noodzakelijk gelijk te zijn aan een ‘Deny’. Houd er bij het doorlopen van het logische beslissingspad rekening mee dat een ‘Nee’ betekent dat u naar het volgende item gaat totdat aan een voorwaarde is voldaan.

9.4.2. Algemene fouten met ACL’s

9.4.2.1. Problemen met veelvoorkomende ACL-fouten oplossen – Voorbeeld 1

Het gebruik van de eerder beschreven show-opdrachten onthult de meeste van de meest voorkomende ACL-fouten. De meest voorkomende fouten zijn het in de verkeerde volgorde invoeren van ACE’s en het niet toepassen van adequate criteria op de ACL-regels.

Fout Voorbeeld 1

In de afbeelding heeft host 192.168.10.10 geen verbinding met 192.168.30.12. Bij het bekijken van de uitvoer van de opdracht show access-lists worden overeenkomsten getoond voor de eerste deny-instructie. Dit is een indicatie dat deze verklaring is geëvenaard door het verkeer.

Oplossing – Kijk naar de volgorde van de ACE’s. Host 192.168.10.10 heeft geen verbinding met 192.168.30.12 vanwege de volgorde van regel 10 in de toegangslijst. Omdat de router ACL’s van boven naar beneden verwerkt, weigert instructie 10 host 192.168.10.10, dus statement 20 kan nooit worden geëvenaard. Stellingen 10 en 20 moeten worden omgedraaid. De laatste regel staat al het andere niet-TCP-verkeer toe dat onder IP valt (ICMP, UDP, etc.).

9.4.2.2. Problemen met veelvoorkomende ACL-fouten oplossen – Voorbeeld 2

Fout Voorbeeld 2

In de afbeelding kan het 192.168.10.0/24-netwerk geen TFTP gebruiken om verbinding te maken met het 192.168.30.0/24-netwerk.

Oplossing – Het 192.168.10.0/24-netwerk kan geen TFTP gebruiken om verbinding te maken met het 192.168.30.0/24-netwerk omdat TFTP het transportprotocol UDP gebruikt. Verklaring 30 in toegangslijst 120 staat al het andere TCP-verkeer toe. Omdat TFTP echter UDP gebruikt in plaats van TCP, wordt dit impliciet geweigerd. Bedenk dat de impliciete deny any-instructie niet voorkomt in de uitvoer van toegangslijsten en daarom worden geen overeenkomsten weergegeven.

Statement 30 moet ip any any zijn.

Deze ACL werkt ongeacht of deze wordt toegepast op G0/0 van R1, of S0/0/1 van R3, of S0/0/0 van R2 in de inkomende richting. Op basis van de regel over het plaatsen van uitgebreide ACL’s het dichtst bij de bron, is de beste optie om deze inkomend op G0/0 van R1 te plaatsen, omdat hierdoor ongewenst verkeer kan worden gefilterd zonder de netwerkinfrastructuur te kruisen.

9.4.2.3. Problemen met veelvoorkomende ACL-fouten oplossen – Voorbeeld 3

Fout Voorbeeld 3

In de afbeelding kan het 192.168.11.0/24-netwerk Telnet gebruiken om verbinding te maken met 192.168.30.0/24, maar volgens het bedrijfsbeleid mag deze verbinding niet worden toegestaan. De resultaten van het commando show access-lists 130 geven aan dat de permit-verklaring is gematcht.

Oplossing – Het 192.168.11.0/24-netwerk kan Telnet gebruiken om verbinding te maken met het 192.168.30.0/24-netwerk, omdat het Telnet-poortnummer in statement 10 van access-list 130 op de verkeerde positie staat in de ACL-statement. Statement 10 ontkent momenteel elk bronpakket met een poortnummer dat gelijk is aan Telnet. Om inkomend Telnet-verkeer op G0/1 te weigeren, weigert u het bestemmingspoortnummer dat gelijk is aan Telnet, bijvoorbeeld, deny tcp any any eq telnet.

9.4.2.4. Problemen met veelvoorkomende ACL-fouten oplossen – Voorbeeld 4

Fout Voorbeeld 4

In de afbeelding kan host 192.168.30.12 met Telnet verbinding maken met 192.168.31.12, maar het bedrijfsbeleid stelt dat deze verbinding niet mag worden toegestaan. Uitvoer van het commando show access-lists 140 geeft aan dat de permit-verklaring is gematcht.

Oplossing – Host 192.168.30.12 kan Telnet gebruiken om verbinding te maken met 192.168.31.12 omdat er geen regels zijn die host 192.168.30.12 of zijn netwerk als bron weigeren. Verklaring 10 van toegangslijst 140 ontkent de routerinterface waarop verkeer de router binnenkomt. Het host-IPv4-adres in instructie 10 moet 192.168.30.12 zijn.

9.2.4.5. Problemen met veelvoorkomende ACL-fouten oplossen – Voorbeeld 5

Fout Voorbeeld 5

In de afbeelding kan host 192.168.30.12 Telnet gebruiken om verbinding te maken met 192.168.31.12, maar volgens het beveiligingsbeleid mag deze verbinding niet worden toegestaan. Uitvoer van de opdracht show access-lists 150 geeft aan dat er geen overeenkomsten zijn opgetreden voor de deny-instructie zoals verwacht.

Oplossing – Host 192.168.30.12 kan Telnet gebruiken om verbinding te maken met 192.168.31.12 vanwege de richting waarin toegangslijst 150 wordt toegepast op de G0/1-interface. Verklaring 10 weigert elk bronadres om verbinding te maken met host 192.168.31.12 via telnet. Dit filter moet echter uitgaand worden toegepast op G0/1 om correct te filteren.

9.5. IPv6 ACL’s

9.5.1. IPv6 ACL maken

9.5.1.1. Type IPv6 ACL’s

IPv6 ACL’s lijken qua werking en configuratie sterk op IPv4 ACL’s. Door bekend te zijn met IPv4-toegangslijsten, zijn IPv6-ACL’s eenvoudig te begrijpen en te configureren.

In IPv4 zijn er twee soorten ACL’s, standaard en uitgebreid. Beide typen ACL’s kunnen genummerde of benoemde ACL’s zijn.

Met IPv6 is er slechts één type ACL, wat gelijk is aan een IPv4-uitgebreide ACL genaamd. Er zijn geen genummerde ACL’s in IPv6. Samenvattend zijn IPv6 ACL’s:

Alleen benoemde ACL’s
Gelijk aan de functionaliteit van een IPv4 Extended ACL

Een IPv4 ACL en een IPv6 ACL kunnen niet dezelfde naam hebben.

9.5.1.2. IPv4- en IPv6-ACL’s vergelijken

Hoewel IPv4- en IPv6-ACL’s erg op elkaar lijken, zijn er drie significante verschillen tussen hen.

Een IPv6 ACL toepassen

Het eerste verschil is de opdracht die wordt gebruikt om een IPv6 ACL op een interface toe te passen. IPv4 gebruikt het commando ip access-group om een IPv4 ACL toe te passen op een IPv4-interface. IPv6 gebruikt de opdracht ipv6 traffic-filter om dezelfde functie uit te voeren voor IPv6-interfaces.

Geen wildcard masks

In tegenstelling tot IPv4-ACL’s, gebruiken IPv6-ACL’s geen jokertekenmaskers. In plaats daarvan wordt de prefix-lengte gebruikt om aan te geven hoeveel van een IPv6-bron- of bestemmingsadres moet worden vergeleken.

Aanvullende standaardvermeldingen

Het laatste grote verschil heeft te maken met de toevoeging van twee impliciete permit-statements aan het einde van elke IPv6-toegangslijst. Aan het einde van elke IPv4-standaard of uitgebreide ACL staat een impliciete weigering of weigering van een ip. IPv6 bevat een soortgelijke weiger ipv6 elke instructie aan het einde van elke IPv6 ACL. Het verschil is dat IPv6 standaard ook twee andere impliciete verklaringen bevat:

permit icmp any any nd-na
permit icmp any any nd-ns

Met deze twee verklaringen kan de router deelnemen aan het IPv6-equivalent van ARP voor IPv4. Bedenk dat ARP in IPv4 wordt gebruikt om Layer 3-adressen om te zetten in Layer 2-MAC-adressen. Zoals te zien is in de afbeelding, gebruikt IPv6 ICMP Neighbor Discovery (ND)-berichten om hetzelfde te bereiken. ND gebruikt Neighbor Solicitation (NS) en Neighbor Advertisement (NA) berichten.

ND-berichten zijn ingekapseld in IPv6-pakketten en vereisen de services van de IPv6-netwerklaag, terwijl ARP voor IPv4 Layer 3 niet gebruikt. Omdat IPv6 de Layer 3-service gebruikt voor het detecteren van buren, moeten IPv6-ACL’s impliciet toestaan dat ND-pakketten worden verzonden en ontvangen op een interface. In het bijzonder zijn zowel Neighbor Discovery – Neighbor Advertisement (nd-na) als Neighbor Discovery – Neighbor Solicitation (nd-ns) berichten toegestaan.

9.5.2. IPv6 ACL’s configureren

9.5.2.1. IPv6-topologie configureren

Afbeelding 1 toont de topologie die zal worden gebruikt voor het configureren van IPv6 ACL’s. De topologie is vergelijkbaar met de vorige IPv4-topologie, behalve het IPv6-adresseringsschema. Er zijn drie 2001:DB8:CAFE::/64 subnetten: 2001:DB8:CAFE:10::/64, 2001:DB8:CAFE:11::/64 en 2001:DB8:CAFE:30::/64. Twee seriële netwerken verbinden de drie routers: 2001:DB8:FEED:1::/64 en 2001:DB8:FEED:2::/64.

Afbeelding 2, 3 en 4 tonen de IPv6-adresconfiguratie voor elke router. De opdracht show ipv6 interface korte wordt gebruikt om het adres en de status van de interface te verifiëren.

Opmerking: De opdracht no shutdown en de opdracht clock rate worden niet weergegeven.

9.5.2.2. IPv6 ACL’s configureren

In IPv6 zijn er alleen benoemde ACL’s. De configuratie is vergelijkbaar met die van een IPv4 extended genaamd ACL.

Afbeelding 1 toont de opdrachtsyntaxis voor IPv6 ACL’s. De syntaxis is vergelijkbaar met de syntaxis die wordt gebruikt voor een IPv4-uitgebreide ACL. Een significant verschil is het gebruik van de IPv6 prefix-lengte in plaats van een IPv4 wildcard mask.

Er zijn drie basisstappen om een IPv6 ACL te configureren:

Stap 1. Gebruik vanuit de globale configuratiemodus de opdracht ipv6 access-list name om een IPv6 ACL te maken. Net als IPv4 benoemde ACL’s, zijn IPv6-namen alfanumeriek, hoofdlettergevoelig en moeten ze uniek zijn. In tegenstelling tot IPv4 is er geen standaard of uitgebreide optie nodig.

Stap 2. Gebruik vanuit de genoemde ACL-configuratiemodus de permit- of deny-instructies om een of meer voorwaarden op te geven om te bepalen of een pakket wordt doorgestuurd of verwijderd.

Stap 3. Keer terug naar de bevoorrechte EXEC-modus met het eindcommando.

Afbeelding 2 toont de stappen om een IPv6 ACL te maken met een eenvoudig voorbeeld op basis van de vorige topologie. De eerste verklaring noemt de IPv6-toegangslijst NO-R3-LAN-ACCESS. Net als bij IPv4 benoemde ACL’s, is het niet vereist om IPv6 ACL-namen met een hoofdletter te schrijven, maar het zorgt ervoor dat ze opvallen bij het bekijken van de running-config-uitvoer.

De tweede verklaring ontkent alle IPv6-pakketten van 2001:DB8:CAFE:30::/64 die bestemd zijn voor een IPv6-netwerk. De derde verklaring staat alle andere IPv6-pakketten toe.

Figuur 3 toont de ACL in context met de topologie.

9.5.2.3. Een IPv6 ACL toepassen op een interface

Nadat een IPv6 ACL is geconfigureerd, wordt deze gekoppeld aan een interface met behulp van de opdracht ipv6 traffic-filter:

Router(config-if)# ipv6 traffic-filter access-list-name { in | out }

De afbeelding toont de NO-R3-LAN-ACCESS ACL die eerder is geconfigureerd en de opdrachten die zijn gebruikt om de IPv6 ACL inkomend toe te passen op de S0/0/0-interface. Als u de ACL toepast op de inkomende S0/0/0-interface, worden pakketten van 2001:DB8:CAFE:30::/64 naar beide LAN’s op R1 geweigerd.

Om een ACL van een interface te verwijderen, voert u eerst de opdracht no ipv6 traffic-filter in op de interface en voert u vervolgens de globale opdracht no ipv6 access-list in om de toegangslijst te verwijderen.

Opmerking: IPv4 en IPv6 gebruiken beide de opdracht access-class om een toegangslijst toe te passen op VTY-poorten.

9.5.2.4. IPv6 ACL-voorbeelden

FTP weigeren

De topologie voor de voorbeelden wordt getoond in figuur 1.

In het eerste voorbeeld in Afbeelding 2 is router R1 geconfigureerd met een IPv6-toegangslijst om FTP-verkeer naar 2001:DB8:CAFE:11::/64 te weigeren. Poorten voor zowel FTP-gegevens (poort 20) als FTP-controle (poort 21) moeten worden geblokkeerd. Omdat het filter inkomend wordt toegepast op de G0/0-interface op R1 wordt alleen verkeer van het 2001:DB8:CAFE:10::/64-netwerk geweigerd.

Beperkte toegang

In het tweede voorbeeld in Afbeelding 3 is een IPv6 ACL geconfigureerd om het LAN op R3 beperkte toegang te geven tot de LAN’s op R1. Opmerkingen worden toegevoegd aan de configuratie om de ACL te documenteren. De volgende functies zijn gelabeld in de ACL:

De eerste twee toestemmingsverklaringen bieden toegang vanaf elk apparaat tot de webserver op 2001:DB8:CAFE:10::10.
Alle andere apparaten krijgen geen toegang tot het 2001:DB8:CAFE:10::/64-netwerk.
PC3 op 2001:DB8:CAFE:30::12 is Telnet-toegang toegestaan tot PC2 met het IPv6-adres 2001:DB8:CAFE:11::11.
Alle andere apparaten krijgen geen Telnet-toegang tot PC2.
Al het overige IPv6-verkeer is toegestaan naar alle andere bestemmingen.
De IPv6-toegangslijst wordt toegepast op interface G0/0 in de inkomende richting, dus alleen het 2001:DB8:CAFE:30::/64-netwerk wordt beïnvloed.

9.5.2.5. IPv6 ACL’s verifiëren

De opdrachten die worden gebruikt om een IPv6-toegangslijst te verifiëren, zijn vergelijkbaar met die voor IPv4-ACL’s. Met behulp van deze opdrachten kan de eerder geconfigureerde IPv6-toegangslijst RESTRICTED-ACCESS worden geverifieerd. Afbeelding 1 toont de uitvoer van de opdracht show ipv6 interface. De uitvoer bevestigt dat ACL met beperkte toegang is geconfigureerd voor inkomend op de G0/0-interface.

Zoals weergegeven in afbeelding 2, geeft de opdracht show access-lists alle toegangslijsten op de router weer, inclusief zowel IPv4- als IPv6-ACL’s. Merk op dat bij IPv6 ACL’s de volgnummers aan het einde van de instructie staan en niet aan het begin zoals bij IPv4-toegangslijsten. Hoewel de uitspraken verschijnen in de volgorde waarin ze zijn ingevoerd, worden ze niet altijd met 10 verhoogd. Dit komt omdat de opmerkingen die zijn ingevoerd een volgnummer gebruiken, maar niet worden weergegeven in de uitvoer van het commando show access-lists.

Net als bij uitgebreide ACL’s voor IPv4, worden IPv6-toegangslijsten weergegeven en verwerkt in de volgorde waarin de instructies worden ingevoerd. Houd er rekening mee dat IPv4-standaard-ACL’s een interne logica gebruiken die hun volgorde en verwerkingsvolgorde verandert.

Zoals weergegeven in figuur 3, bevat de uitvoer van de opdracht show running-config alle ACE’s en opmerkingen. Opmerking-uitspraken kunnen voor of na toestemming- of afwijzingsverklaringen komen, maar moeten consistent zijn in hun plaatsing.

9.6. Samenvatting

Standaard filtert een router het verkeer niet. Verkeer dat de router binnenkomt, wordt uitsluitend gerouteerd op basis van informatie in de routeringstabel.

Pakketfiltering regelt de toegang tot een netwerk door de inkomende en uitgaande pakketten te analyseren en deze door te geven of te laten vallen op basis van criteria zoals het bron-IP-adres, de bestemmings-IP-adressen en het protocol dat in het pakket wordt vervoerd. Een pakketfilterende router gebruikt regels om te bepalen of verkeer wordt toegestaan of geweigerd. Een router kan ook pakketfiltering uitvoeren op Layer 4, de transportlaag.

Een ACL is een opeenvolgende lijst van verklaringen voor toestemming of weigering. De laatste instructie van een ACL is altijd een impliciete weigering die al het verkeer blokkeert. Om te voorkomen dat de impliciete weiger elke instructie aan het einde van de ACL al het verkeer blokkeert, kan de permit ip any any willekeurige instructie worden toegevoegd.

Wanneer netwerkverkeer een interface passeert die is geconfigureerd met een ACL, vergelijkt de router de informatie in het pakket met elk item, in sequentiële volgorde, om te bepalen of het pakket overeenkomt met een van de instructies. Als een overeenkomst wordt gevonden, wordt het pakket dienovereenkomstig verwerkt.

ACL’s zijn geconfigureerd om van toepassing te zijn op inkomend verkeer of om van toepassing te zijn op uitgaand verkeer.

Standaard ACL’s kunnen worden gebruikt om alleen verkeer van een bron-IPv4-adres toe te staan of te weigeren. De bestemming van het pakket en de betrokken poorten worden niet geëvalueerd. De basisregel voor het plaatsen van een standaard ACL is om deze dicht bij de bestemming te plaatsen.

Uitgebreide ACL’s filteren pakketten op basis van verschillende kenmerken: protocoltype, bron- of bestemmings-IPv4-adres en bron- of bestemmingspoorten. De basisregel voor het plaatsen van een uitgebreide ACL is om deze zo dicht mogelijk bij de bron te plaatsen.

Het globale configuratiecommando access-list definieert een standaard ACL met een nummer in het bereik van 1 tot 99 of een uitgebreide ACL met nummers in het bereik van 100 tot 199 en 2000 tot 2699. Zowel standaard als uitgebreide ACL’s kunnen ook worden benoemd. De ip-access-list standard name wordt gebruikt om een standaard benoemde ACL te maken, terwijl de opdracht ip-access-list extended name voor een uitgebreide toegangslijst is. IPv4-ACE’s omvatten het gebruik van jokertekenmaskers.

Nadat een ACL is geconfigureerd, wordt deze gekoppeld aan een interface met behulp van de opdracht ip access-group in de interfaceconfiguratiemodus. Denk aan de drie P’s, één ACL per protocol, per richting, per interface.

Om een ACL van een interface te verwijderen, voert u eerst de opdracht no ip access-group in op de interface en voert u vervolgens de globale opdracht no access-list in om de volledige ACL te verwijderen.

De opdrachten show running-config en show access-lists worden gebruikt om de ACL-configuratie te verifiëren. De opdracht show ip interface wordt gebruikt om de ACL op de interface en de richting waarin deze is toegepast te verifiëren.

De opdracht access-class die is geconfigureerd in de lijnconfiguratiemodus, beperkt inkomende en uitgaande verbindingen tussen een bepaalde VTY en de adressen in een toegangslijst.

Net als IPv4 benoemde ACL’s, zijn IPv6-namen alfanumeriek, hoofdlettergevoelig en moeten ze uniek zijn. In tegenstelling tot IPv4 is er geen standaard of uitgebreide optie nodig.

Gebruik vanuit de globale configuratiemodus de opdracht ipv6 access-list name om een IPv6 ACL te maken. In tegenstelling tot IPv4-ACL’s, gebruiken IPv6-ACL’s geen jokertekenmaskers. In plaats daarvan wordt de prefix-lengte gebruikt om aan te geven hoeveel van een IPv6-bron- of bestemmingsadres moet worden vergeleken.

Nadat een IPv6 ACL is geconfigureerd, wordt deze gekoppeld aan een interface met behulp van de opdracht ipv6 traffic-filter.

Access Control Lists

9.0 Access Control Lists

9.0.1 Introductie

9.1. IP ACL werking

9.1.1. Doel van ACL’s

9.1.1.1. Wat is een ACL?

9.1.1.2. Een TCP-gesprek

9.1.1.3. Pakketfiltering

9.1.2. Standaard versus uitgebreide IPv4 ACL’s

9.1.2.1. Typen Cisco IPv4-ACL’s

9.1.2.2. ACL’s nummeren en benoemen

9.1.3. Wildcard Masks in ACL’s

9.1.3.1. Introductie van ACL-wildcardmaskering

9.1.3.2. Voorbeelden van Wilcard Masks

9.1.3.3. De wildcard mask berekenen

9.1.3.4. Wilcard mask trefwoorden

9.1.4. Richtlijnen voor het maken van ACL’s

9.1.4.1. Algemene richtlijnen voor het maken van ACL’s

9.1.4.2. ACL-best practices

9.1.5. Richtlijnen voor ACL-plaatsing

9.1.5.1. Waar ACL’s te plaatsen

9.2. Standaard IPv4 ACL’s

9.2.1. Standaard IPv4 ACL’s configureren

9.2.1.1. Criteriavermeldingen invoeren

9.2.1.2. Een standaard ACL configureren

9.2.2. IPv4 ACL’s aanpassen

9.2.2.1. Standaard genummerde ACL’s bewerken

9.2.3. VTY poorten beveiligen met een standaard IPv4 ACL

9.2.3.1. Een standaard ACL configureren om een ​​VTY-poort te beveiligen

9.2.3.2. Een standaard ACL verifiëren die wordt gebruikt om een VTY-poort te beveiligen

9.3. Uitgebreide IPv4 ACL’s

9.3.1. Structuur van een uitgebreide IPv4 ACL

9.3.1.1. Uitgebreide ACL’s

9.3.2. Uitgebreide IPv4 ACL’s configureren

9.3.2.1. Uitgebreide ACL’s configureren

9.3.2.2. Uitgebreide ACL’s toepassen op interfaces

9.3.2.3. Verkeer filteren met uitgebreide ACL’s

9.2.2.4. Benoemde uitgebreide ACL’s maken

9.3.2.5. Uitgebreide ACL’s verifiëren

9.3.2.6. Uitgebreide ACL’s bewerken

9.4. Problemen met ACL’s oplossen

9.4.1. Pakketten verwerken met ACL’s

9.4.1.1. Inkomende en uitgaande ACL-logica

9.4.1.2. ACL logische bewerkingen

9.4.1.3. Standaard ACL-beslissingsproces

9.4.1.4. Uitgebreid ACL-beslissingsproces

9.4.2. Algemene fouten met ACL’s

9.4.2.1. Problemen met veelvoorkomende ACL-fouten oplossen – Voorbeeld 1

9.4.2.2. Problemen met veelvoorkomende ACL-fouten oplossen – Voorbeeld 2

9.4.2.3. Problemen met veelvoorkomende ACL-fouten oplossen – Voorbeeld 3

9.4.2.4. Problemen met veelvoorkomende ACL-fouten oplossen – Voorbeeld 4

9.2.4.5. Problemen met veelvoorkomende ACL-fouten oplossen – Voorbeeld 5

9.5. IPv6 ACL’s

9.5.1. IPv6 ACL maken

9.5.1.1. Type IPv6 ACL’s

9.5.1.2. IPv4- en IPv6-ACL’s vergelijken

9.5.2. IPv6 ACL’s configureren

9.5.2.1. IPv6-topologie configureren

9.5.2.2. IPv6 ACL’s configureren

9.5.2.3. Een IPv6 ACL toepassen op een interface

9.5.2.4. IPv6 ACL-voorbeelden

9.5.2.5. IPv6 ACL’s verifiëren

9.6. Samenvatting

9.2.3.1. Een standaard ACL configureren om een VTY-poort te beveiligen