Transit Access Control Lists: filtering aan uw rand

Inleiding

Dit document bevat richtlijnen en aanbevolen implementatietechnieken voor het filteren van transit- en randverkeer op uw netwerktoegangspunten. Transit Access Control Lists (ACL’s) worden gebruikt om de netwerkbeveiliging te verhogen door expliciet alleen vereist verkeer naar uw netwerk of netwerken toe te staan.

Doorvoerfilters

Standaard installatie

In de meeste netwerkomgevingen aan de rand, zoals een internetpunt van aanwezigheid in een typisch ondernemingsnetwerk, moet toegangsfiltering worden gebruikt om onbevoegd verkeer aan de rand van het netwerk te laten vallen. Bij bepaalde implementaties van serviceproviders kan deze vorm van edge of transit traffic filtering ook effectief worden gebruikt om de stroom van transitverkeer naar en van klanten te beperken tot alleen specifieke toegestane protocollen. Dit document concentreert zich op een model voor de implementatie van ondernemingen.

Dit voorbeeld toont een typisch bedrijfsontwerp voor internetconnectiviteit. Twee randrouters, IR1 en IR2, bieden directe connectiviteit met het internet. Achter deze twee routers biedt een paar firewalls (Cisco PIXes in dit voorbeeld) stateful inspection mogelijkheden en toegang tot zowel het interne netwerk als de gedemilitariseerde zone (DMZ). De DMZ bevat openbare diensten zoals DNS en web; dit is het enige netwerk dat direct vanaf het openbare internet toegankelijk is. Het interne netwerk mag nooit rechtstreeks via het internet worden benaderd, maar het verkeer dat afkomstig is van het interne netwerk moet de internetsites kunnen bereiken.

De randrouters moeten zo worden geconfigureerd dat ze een eerste beveiligingsniveau bieden door het gebruik van inkomende ACL’s. De ACL’s staan alleen specifiek toegestaan verkeer toe naar de DMZ en staan retourverkeer toe voor interne gebruikers die toegang hebben tot internet. Al het niet-geautoriseerde verkeer moet op de toegangsinterfaces worden gedropt.

ACL-secties voor doorvoer

In het algemeen bestaat een transitACL uit vier secties.

• Adressen voor speciale doeleinden en ingangen tegen spoofing die onwettige bronnen en pakketten met bronadressen die binnen uw netwerk thuishoren, ontzeggen van het invoeren van het netwerk vanuit een externe bron

  

  Opmerking: RFC 1918 definieert gereserveerde adresruimte die geen geldig bronadres op internet is. RFC 3330 definieert adressen voor speciale toepassingen waarvoor mogelijk filtering vereist is. RFC 2827 biedt richtlijnen tegen spoofing.

• Expliciet toegestaan retourverkeer voor interne verbindingen met internet

• Expliciet toegestaan extern bronverkeer bestemd voor beschermde interne adressen

• expliciet deny afschrift

  

  Opmerking: hoewel alle ACL’s een impliciete deny Cisco raadt het gebruik van een expliciete deny verklaring, bijvoorbeeld: deny ip any any. Op de meeste platforms houden dergelijke verklaringen een aantal van de geweigerde pakketten bij die kunnen worden weergegeven met behulp van de show access-list uit.

Hoe ontwikkelt u een transitACL?

De eerste stap in de ontwikkeling van een doorvoer ACL is om de protocollen te bepalen die binnen uw netwerken worden vereist. Hoewel elke site specifieke vereisten heeft, worden bepaalde protocollen en toepassingen op grote schaal gebruikt en meestal toegestaan. Als het DMZ-segment bijvoorbeeld connectiviteit biedt voor een openbaar toegankelijke webserver, is TCP vanaf het internet naar het DMZ-serveradres(sen) op poort 80 vereist. Op dezelfde manier vereisen interne verbindingen met internet dat de ACL-rechten een vastgesteld TCP-verkeer terugsturen - verkeer dat de ACC-bitset heeft.

Vereiste protocollen identificeren

De ontwikkeling van deze lijst van vereiste protocollen kan een ontmoedigende taak zijn, maar er zijn verscheidene technieken die kunnen worden gebruikt, zoals nodig, helpen vereist verkeer identificeren.

• Herzie uw lokaal veiligheidsbeleid/de dienstbeleid.

  Uw lokale sitebeleid moet u helpen bij het bieden van een basislijn van toegestane en geweigerde services.

• Bekijk/controleer de configuratie van uw firewall.

  De huidige firewallconfiguratie moet expliciet bevatten permit verklaringen voor toegestane diensten. In veel gevallen kunt u deze configuratie naar ACL-indeling vertalen en deze gebruiken om het merendeel van de ACL-vermeldingen te maken.

  

  Opmerking: stateful firewalls hebben doorgaans geen expliciete regels voor retourverkeer naar geautoriseerde verbindingen. Aangezien router ACL’s niet stateful zijn, moet het retourverkeer expliciet worden toegestaan.

• Bekijk/controleer uw toepassingen.

  De toepassingen die op de DMZ worden gehost en de toepassingen die intern worden gebruikt, kunnen helpen bij het bepalen van de filtervereisten. Herzie de toepassingsvereisten om essentiële details over het het filtreren ontwerp te verstrekken.

• Gebruik een classificatie ACL.

  Een classificatie ACL bestaat uit permit verklaringen voor de diverse protocollen die aan het interne netwerk zouden kunnen worden bestemd. (Zie Bijlage A voor een lijst van veelgebruikte protocollen en toepassingen.) Gebruik de show access-list opdracht om een telling van access control entry (ACE) hits weer te geven om de vereiste protocollen te identificeren. Onderzoeken en begrijpen van verdachte of verrassende resultaten voordat u expliciete permit verklaringen voor onverwachte protocollen.

• Gebruik de NetFlow-switchfunctie.

  NetFlow is een switching-functie die, indien ingeschakeld, gedetailleerde stroominformatie biedt. Als NetFlow is ingeschakeld op uw randrouters, doet u het volgende show ip cache flow Deze opdracht geeft een lijst met protocollen die zijn vastgelegd door Netflow. NetFlow kan niet alle protocollen identificeren, dus deze techniek moet gebruikt worden in combinatie met andere protocollen.

Ongeldig verkeer identificeren

Naast directe bescherming moet de transitACL ook een eerste verdedigingslinie bieden tegen bepaalde soorten ongeldig verkeer op het internet.

• Ontken RFC 1918-ruimte.

• Ontken pakketten met een bronadres dat valt onder een adresruimte voor speciale doeleinden, zoals gedefinieerd in RFC 3330.

• Pas anti-spoof filters toe, in overeenstemming met RFC 2827; uw adresruimte zou nooit de bron van pakketten van buiten uw autonoom systeem (AS) moeten zijn.

Andere typen verkeer die u in overweging moet nemen, zijn:

• Externe protocollen en IP-adressen die moeten communiceren met de Edge-router

  • ICMP van IP-adressen van serviceproviders

  • Routing-protocollen

  • IPsec VPN, als een Edge-router wordt gebruikt als de beëindiging

• Expliciet toegestaan retourverkeer voor interne verbindingen met internet

  • Specifieke ICMP-typen (Internet Control Message Protocol)

  • Uitgaande vragen over Domain Name System (DNS)

  • TCP ingesteld

  • User Datagram Protocol (UDP)-retourverkeer

  • FTP-gegevensverbindingen

  • TFTP-gegevensverbindingen

  • Multimedia-verbindingen

• Expliciet toegestaan extern bronverkeer bestemd voor beschermde interne adressen

  • VPN-verkeer

    • Internet Security Association en Key Management Protocol (ISAKMP)

    • Netwerkadresomzetting (NAT) voor transversale toepassingen

    • Gepatenteerde insluiting

    • Encapsulating Security payload (ESP)

    • Verificatieheader (AH)

  • HTTP naar webservers

  • Secure Socket Layer (SSL) voor webservers

  • FTP naar FTP-servers

  • Inkomende FTP-gegevensverbindingen

  • Passieve FTP-gegevensverbindingen (passief)

  • Simple Mail Transfer Protocol (SMTP)

  • Andere toepassingen en servers

  • Inkomende DNS-vragen

  • Inkomende DNS-zoneoverdrachten

De ACL toepassen

De nieuw samengestelde ACL moet worden toegepast op naar internet gerichte interfaces van de Edge-routers. In het voorbeeld dat in de sectie Typische Opstelling wordt geïllustreerd, wordt ACL binnen op de Internet-Onder ogen ziende interfaces op IR1 en IR2 toegepast.

Zie de secties over implementatierichtlijnen en implementatievoorbeeld voor meer informatie.

ACL-voorbeeld

Deze toegangslijst biedt een eenvoudig maar realistisch voorbeeld van typische vermeldingen die vereist zijn in een doorvoerACL. Deze fundamentele ACL moet worden aangepast met lokale site-specifieke configuratiedetails.

!--- Add anti-spoofing entries.
!--- Deny special-use address sources.
!--- Refer to RFC 3330 for additional special use addresses.

access-list 110 deny ip 127.0.0.0 0.255.255.255 any
access-list 110 deny ip 192.0.2.0 0.0.0.255 any
access-list 110 deny ip 224.0.0.0 31.255.255.255 any
access-list 110 deny ip host 255.255.255.255 any

!--- The deny statement should not be configured
!--- on Dynamic Host Configuration Protocol (DHCP) relays.

access-list 110 deny ip host 0.0.0.0 any

!--- Filter RFC 1918 space.

access-list 110 deny ip 10.0.0.0 0.255.255.255 any
access-list 110 deny ip 172.16.0.0 0.15.255.255 any
access-list 110 deny ip 192.168.0.0 0.0.255.255 any

!--- Permit Border Gateway Protocol (BGP) to the edge router.

access-list 110 permit tcp host bgp_peer gt 1023 host router_ip eq bgp
access-list 110 permit tcp host bgp_peer eq bgp host router_ip gt 1023

!--- Deny your space as source (as noted in RFC 2827).

access-list 110 deny ip your Internet-routable subnet any

!--- Explicitly permit return traffic.
!--- Allow specific ICMP types.

access-list 110 permit icmp any any echo-reply
access-list 110 permit icmp any any unreachable
access-list 110 permit icmp any any time-exceeded
access-list 110 deny   icmp any any

!--- These are outgoing DNS queries.

access-list 110 permit udp any eq 53  host primary DNS server gt 1023

!--- Permit older DNS queries and replies to primary DNS server.

access-list 110 permit udp any eq 53  host primary DNS server eq 53

!--- Permit legitimate business traffic.

access-list 110 permit tcp any Internet-routable subnet established
access-list 110 permit udp any range 1 1023 Internet-routable subnet gt 1023

!--- Allow ftp data connections.

access-list 110 permit tcp any eq 20 Internet-routable subnet gt 1023

!--- Allow tftp data and multimedia connections.

access-list 110 permit udp any gt 1023 Internet-routable subnet gt 1023

!--- Explicitly permit externally sourced traffic.
!--- These are incoming DNS queries.


access-list 110 permit udp any gt 1023 host <primary DNS server> eq 53

!-- These are zone transfer DNS queries to primary DNS server.

access-list 110 permit tcp host secondary DNS server gt 1023 host primary DNS server eq 53

!--- Permit older DNS zone transfers.

access-list 110 permit tcp host secondary DNS server eq 53  host primary DNS server eq 53

!--- Deny all other DNS traffic.

access-list 110 deny udp any any eq 53
access-list 110 deny tcp any any eq 53

!--- Allow IPSec VPN traffic.

access-list 110 permit udp any host IPSec headend device eq 500
access-list 110 permit udp any host IPSec headend device eq 4500
access-list 110 permit 50 any host IPSec headend device
access-list 110 permit 51 any host IPSec headend device
access-list 110 deny   ip any host IPSec headend device

!--- These are Internet-sourced connections to
!--- publicly accessible servers.

access-list 110 permit tcp any host public web server eq 80
access-list 110 permit tcp any host public web server eq 443
access-list 110 permit tcp any host public FTP server eq 21

!--- Data connections to the FTP server are allowed
!--- by the permit established ACE.
!--- Allow PASV data connections to the FTP server.

access-list 110 permit tcp any gt 1023 host public FTP server gt 1023
access-list 110 permit tcp any host public SMTP server eq 25

!--- Explicitly deny all other traffic.

access-list 101 deny ip any any 

• Het log Het sleutelwoord kan worden gebruikt om extra detail over bron en bestemmingen voor een bepaald protocol te verstrekken. Hoewel dit trefwoord waardevolle inzichten biedt in de details van ACL-hits, hebben buitensporige hits een ACL-ingang die de log Trefwoord verhoogt CPU-gebruik. De invloed op de prestaties van het vastleggen varieert per platform.

• ICMP-onbereikbare berichten worden gegenereerd voor pakketten die door een ACL administratief worden geweigerd. Dit zou router en verbindingsprestaties kunnen beïnvloeden. Het gebruik van de no ip unreachables opdracht om IP-onbereikbare bestanden uit te schakelen op de interface waar de transitACL (edge) wordt geïmplementeerd.

• Deze ACL kan in eerste instantie met alle permit verklaringen om ervoor te zorgen dat legitiem zakelijk verkeer niet wordt ontkend. Zodra het zakelijke legitieme verkeer is geïdentificeerd en verantwoord, wordt de specifieke deny elementen kunnen worden geconfigureerd.

ACL’s en gefragmenteerde pakketten

ACL’s hebben een fragments sleutelwoord dat gespecialiseerd gefragmenteerd pakketbehandelingsgedrag mogelijk maakt. In het algemeen worden niet-initiële fragmenten die overeenkomen met Layer 3-verklaringen (protocol, bronadres en bestemmingsadres)—ongeacht Layer 4-informatie in een ACL—beïnvloed door de permit of deny verklaring van de gematchte vermelding. Het gebruik van de fragments Met het sleutelwoord kunnen ACL’s worden geforceerd om niet-initiële fragmenten met meer granulariteit te ontkennen of toe te staan.

Het filteren van fragmenten voegt een extra laag van bescherming tegen een de ontkenning-van-dienst (Dos) aanval toe die slechts niet aanvankelijke fragmenten (zoals FO > 0) gebruikt. Het gebruik deny de verklaring voor niet-aanvankelijke fragmenten aan het begin van ACL ontkent alle niet-aanvankelijke fragmenten van de toegang tot van de router. In zeldzame omstandigheden kan een geldige sessie fragmentatie vereisen en daarom worden gefilterd als een deny fragment verklaring bestaat in ACL. De voorwaarden die tot fragmentatie zouden kunnen leiden omvatten het gebruik van digitale certificaten voor authentificatie ISAKMP en het gebruik van IPSec NAT Transversale.

Neem bijvoorbeeld de hier getoonde gedeeltelijke ACL.

access-list 110 deny tcp any Internet routable subnet fragments
access-list 110 deny udp any Internet routable subnet fragments
access-list 110 deny icmp any Internet routable subnet fragments
<rest of ACL>

Door deze vermeldingen toe te voegen aan het begin van een ACL wordt de toegang tot het netwerk voor niet-initiële fragmenten geweigerd, terwijl niet-gefragmenteerde pakketten of initiële fragmenten worden doorgegeven aan de volgende regels van de ACL, die niet worden beïnvloed door de deny fragment verklaringen. Het vorige ACL-fragment vergemakkelijkt ook de classificatie van de aanval sinds elk protocol (UDP, TCP en ICMP) in de ACL afzonderlijke tellers bevat.

Aangezien veel aanvallen afhankelijk zijn van overstroming met gefragmenteerde pakketten, biedt het filteren van inkomende fragmenten op het interne netwerk een extra mate van bescherming en helpt u ervoor te zorgen dat een aanval geen fragmenten kan injecteren door eenvoudigweg Layer 3-regels in de transittoegangslijst aan te passen.

Raadpleeg Toegangscontrolelijsten en IP-fragmenten voor een gedetailleerde bespreking van de opties.

Risicobeoordeling

Wanneer u ACL’s voor transitverkeersbeveiliging implementeert, moet u rekening houden met twee belangrijke risicogebieden.

• Ervoor zorgen dat de juiste permit/deny verklaringen zijn afgelegd. Om ACL effectief te maken, moet u alle vereiste protocollen toestaan.

• ACL-prestaties variëren van platform tot platform. Voordat u ACL’s implementeert, moet u de prestatiekenmerken van uw hardware bekijken.

Cisco raadt u aan dit ontwerp in het lab te testen voordat u het implementeert.

Aanhangsels

Algemeen gebruikte protocollen en toepassingen

TCP-poortnamen

Deze lijst met TCP-poortnamen kan worden gebruikt in plaats van poortnummers wanneer u de ACL in Cisco IOS^®-software configureert. Raadpleeg de RFC van het huidige toegewezen nummer om een verwijzing naar deze protocollen te vinden. Poortnummers die overeenkomen met deze protocollen kunnen ook worden gevonden tegen terwijl u de ACL configureert door een ? in plaats van een poortnummer.

bgp	kshell
chargen	login
cmd	lpd
daytime	nntp
discard	pim
domain	pop2
echo	pop3
exec	smtp
finger	sunrpc
ftp	syslog
ftp-data	tacacstalk
gopher	telnet
hostname	time
ident	uucp
irc	whois
klogin	www

UDP-poortnamen

Deze lijst met UDP-poortnamen kan worden gebruikt in plaats van poortnummers wanneer u de ACL in Cisco IOS-software configureert. Raadpleeg de RFC van het huidige toegewezen nummer om een verwijzing naar deze protocollen te vinden. Poortnummers die overeenkomen met deze protocollen kunnen ook worden gevonden tegen terwijl u de ACL configureert door een ? in plaats van een poortnummer.

biff	ntp
bootpc	pim-auto-rp
bootps	rip
discard	snmp
dnsix	snmptrap
domain	sunrpc
echo	syslog
isakmp	tacacs
mobile-ip	talk
nameserver	tftp
netbios-dgm	time
netbios-ns	who
netbios-ss	xdmcp

Implementatierichtlijnen

Cisco raadt conservatieve implementatiepraktijken aan. U moet een duidelijk begrip van vereiste protocollen hebben om met succes doorvoer ACL’s te kunnen implementeren. Deze richtlijnen beschrijven een zeer conservatieve methode voor de plaatsing van bescherming ACLs die een iteratieve benadering gebruiken.

1. Identificeer protocollen die in het netwerk worden gebruikt met een classificatie ACL.

   Stel een ACL op die alle bekende protocollen toelaat die in het netwerk worden gebruikt. Deze ontdekking, of classificatie, ACL moet een bronadres van any en een bestemming van een IP-adres of het gehele IP-subnet met internetrouteerbare verbindingen. Configureer een laatste item dat dit toestaat ip any any log om extra protocollen te helpen identificeren die u moet toestaan.

   Het doel is om alle vereiste protocollen te bepalen die op het netwerk in gebruik zijn. Gebruik logboekregistratie voor analyse om te bepalen wat anders met de router zou kunnen communiceren.

   

   Opmerking: hoewel de log het sleutelwoord verstrekt waardevol inzicht in de details van ACL hits, zouden de bovenmatige hits aan een ACL ingang die dit sleutelwoord gebruikt in een overweldigend aantal logboekingangen en misschien het hoge gebruik van routerCPU kunnen resulteren. Gebruik de log sleutelwoord voor korte periodes en slechts wanneer nodig om te helpen classificeren verkeer.

   Houd er rekening mee dat het netwerk het risico loopt te worden aangevallen terwijl een ACL bestaat uit alle permit verklaringen is opgesteld. Het classificatieproces zo snel mogelijk uit te voeren, zodat de juiste toegangscontroles kunnen worden ingevoerd.

2. Herzie geïdentificeerde pakketten en begin toegang tot het interne netwerk te filteren.

   Nadat u de pakketten die door de ACL in stap 1 zijn gefilterd, hebt geïdentificeerd en beoordeeld, werkt u de classificatie ACL bij om rekening te houden met nieuw geïdentificeerde protocollen en IP-adressen. Voeg ACL-vermeldingen toe voor antispoofing. Indien nodig moeten specifieke deny inzendingen voor permit verklaringen in de classificatie ACL. U kunt de show access-list opdracht om specifieke deny de gegevens kunnen worden gecontroleerd op het aantal treffers. Dit geeft informatie over verboden pogingen tot netwerktoegang zonder dat u de logboekregistratie van ACL-vermeldingen hoeft in te schakelen. De laatste regel van de ACL moet een deny ip any any. Opnieuw kan de hit tellen op deze laatste inzending informatie geven over verboden toegangspogingen.

3. Controleer en update de ACL.

   Controleer de voltooide ACL om ervoor te zorgen dat de nieuw geïntroduceerde vereiste protocollen op een gecontroleerde manier worden toegevoegd. Als u ACL controleert, verstrekt het ook informatie over verboden pogingen van de netwerktoegang die informatie over dreigende aanvallen konden verstrekken.

Implementatievoorbeeld

Dit voorbeeld toont een transitACL die een netwerk beschermt dat op deze adressering is gebaseerd.

• Het ISP router IP-adres is 10.1.1.1.

  Het adres van de Edge-router voor het internet is 10.1.1.2.

  Het internet-routable subnet is 192.168.201.0 255.255.255.0.

  De VPN-head-end is 192.168.201.100.

  De webserver is 192.168.201.101.

  De FTP-server is 192.168.201.102.

  De SMTP-server is 192.168.201.103.

  De primaire DNS-server is 192.168.201.104.

  De secundaire DNS-server is 172.16.201.50.

Op basis van deze informatie is de transitbeschermingsACL ontwikkeld. De ACL maakt eBGP-doorgifte naar de ISP-router mogelijk, biedt anti-parafefilters, staat specifiek terugkeerverkeer toe, staat specifiek inkomend verkeer toe en ontkent expliciet al het andere verkeer.

no access-list 110

!--- Phase 1 – Add anti-spoofing entries.
!--- Deny special-use address sources.
!--- See RFC 3330 for additional special-use addresses.

access-list 110 deny   ip 127.0.0.0 0.255.255.255 any
access-list 110 deny   ip 192.0.2.0 0.0.0.255 any
access-list 110 deny   ip 224.0.0.0 31.255.255.255 any
access-list 110 deny   ip host 255.255.255.255 any

!--- This deny statement should not be configured 
!--- on Dynamic Host Configuration Protocol (DHCP) relays.

access-list 110 deny   ip host 0.0.0.0 any

!--- Filter RFC 1918 space.

access-list 110 deny   ip 10.0.0.0 0.255.255.255 any
access-list 110 deny   ip 172.16.0.0 0.15.255.255 any
access-list 110 deny   ip 192.168.0.0 0.0.255.255 any

!--- Permit BGP to the edge router.

access-list 110 permit tcp host 10.1.1.1 gt 1023 host 10.1.1.2 eq bgp
access-list 110 permit tcp host 10.1.1.1 eq bgp host 10.1.1.2 gt 1023

!--- Deny your space as source (as noted in RFC 2827).

access-list 110 deny   ip 192.168.201.0 0.0.0.255 any

!--- Phase 2 – Explicitly permit return traffic.
!--- Allow specific ICMP types.

access-list 110 permit icmp any any echo-reply
access-list 110 permit icmp any any unreachable
access-list 110 permit icmp any any time-exceeded
access-list 110 deny   icmp any any

!--- These are outgoing DNS queries.

access-list 110 permit udp any eq domain host 192.168.201.104 gt 1023

!--- Permit older DNS queries and replies to primary DNS server.

access-list 110 permit udp any eq domain host 192.168.201.104 eq domain

!--- Permit legitimate business traffic.

access-list 110 permit tcp any 192.168.201.0 0.0.0.255 established
access-list 110 permit udp any range 1 1023 192.168.201.0 0.0.0.255 gt 1023

!--- Allow FTP data connections.

access-list 110 permit tcp any eq ftp-data 192.168.201.0 0.0.0.255 gt 1023

!--- Allow TFTP data and multimedia connections.

access-list 110 permit udp any gt 1023 192.168.201.0 0.0.0.255 gt 1023

!--- Phase 3 – Explicitly permit externally sourced traffic.
!--- These are incoming DNS queries.

access-list 110 permit udp any gt 1023 host 192.168.201.104 eq domain

!--- Zone transfer DNS queries to primary DNS server.

access-list 110 permit tcp host 172.16.201.50 gt 1023 host 192.168.201.104 eq domain

!--- Permit older DNS zone transfers.

access-list 110 permit tcp host 172.16.201.50 eq domain host 192.168.201.104 eq domain

!--- Deny all other DNS traffic.

access-list 110 deny   udp any any eq domain
access-list 110 deny   tcp any any eq domain

!--- Allow IPSec VPN traffic.

access-list 110 permit udp any host 192.168.201.100 eq isakmp
access-list 110 permit udp any host 192.168.201.100 eq non500-isakmp
access-list 110 permit esp any host 192.168.201.100
access-list 110 permit ahp any host 192.168.201.100
access-list 110 deny   ip any host 192.168.201.100


!--- These are Internet-sourced connections to
!--- publicly accessible servers.

access-list 110 permit tcp any host 192.168.201.101 eq www
access-list 110 permit tcp any host 192.168.201.101 eq 443
access-list 110 permit tcp any host 192.168.201.102 eq ftp



!--- Data connections to the FTP server are allowed 
!--- by the permit established ACE in Phase 3.
!--- Allow PASV data connections to the FTP server.

access-list 110 permit tcp any gt 1023 host 192.168.201.102 gt 1023
access-list 110 permit tcp any host 192.168.201.103 eq smtp

!--- Phase 4 – Add explicit deny statement.

access-list 110 deny   ip any any

Edge-router(config)#interface serial 2/0
Edge-router(config-if)#ip access-group 110 in

Gerelateerde informatie

• Requests for Comments (RFC’s)
• Technische ondersteuning en documentatie – Cisco Systems