Transit-Zugriffskontrolllisten: Filterung am Netzwerk-Edge

Einleitung

In diesem Dokument werden Richtlinien und empfohlene Bereitstellungstechniken für die Filterung von Transit- und Edge-Datenverkehr an den Netzwerkeingangspunkten vorgestellt. Transit Access Control Lists (ACLs) erhöhen die Netzwerksicherheit, indem nur der erforderliche Datenverkehr in Ihr Netzwerk oder Ihre Netzwerke explizit zugelassen wird.

Transit-Filter

Typische Einrichtung

In den meisten Edge-Netzwerkumgebungen, z. B. einem typischen Internet-Point of Presence eines Unternehmensnetzwerks, sollte die Eingangsfilterung verwendet werden, um nicht autorisierten Datenverkehr am Netzwerk-Edge zu verwerfen. In bestimmten Service Provider-Bereitstellungen kann diese Form der Filterung von Edge- oder Transitverkehr auch effektiv eingesetzt werden, um den Fluss von Transitverkehr zu und von Kunden auf bestimmte zulässige Protokolle zu beschränken. Im Mittelpunkt dieses Dokuments steht ein Bereitstellungsmodell der Enterprise-Klasse.

Dieses Beispiel zeigt ein typisches Design für eine Internetverbindung eines Unternehmens. Die beiden Edge-Router IR1 und IR2 stellen eine direkte Verbindung mit dem Internet her. Hinter diesen beiden Routern stellt ein Paar Firewalls (in diesem Beispiel Cisco PIXes) Stateful-Inspection-Funktionen und Zugriff auf das interne Netzwerk und die DMZ bereit. Die DMZ enthält Services für die Öffentlichkeit wie DNS und Web. Dies ist das einzige Netzwerk, auf das direkt über das öffentliche Internet zugegriffen werden kann. Auf das interne Netzwerk sollte niemals direkt über das Internet zugegriffen werden. Der aus dem internen Netzwerk stammende Datenverkehr muss jedoch in der Lage sein, Internetsites zu erreichen.

Die Edge-Router sollten so konfiguriert werden, dass sie durch die Verwendung von eingehenden ACLs eine erste Sicherheitsstufe bieten. Die ACLs lassen nur speziell zugelassenen Datenverkehr zur DMZ und umgekehrten Datenverkehr für interne Benutzer zu, die auf das Internet zugreifen. Der gesamte nicht autorisierte Datenverkehr sollte an den Eingangsschnittstellen verworfen werden.

Transit-ACL-Abschnitte

Im Allgemeinen besteht eine Transit-ACL aus vier Abschnitten.

• Einträgen für spezielle Verwendungszwecke und Anti-Spoofing-Einträgen, die verhindern, dass unzulässige Quellen und Pakete mit Quelladressen, die zu Ihrem Netzwerk gehören, von einer externen Quelle in das Netzwerk gelangen

  

  Hinweis: RFC 1918 definiert einen reservierten Adressraum, der keine gültige Quelladresse im Internet ist. RFC 3330 definiert Adressen für spezielle Verwendungszwecke, die ggf. gefiltert werden müssen. RFC 2827 bietet Anti-Spoofing-Richtlinien.

• Explizit zulässiger zurückkehrender Datenverkehr für interne Internetverbindungen

• Explizit zulässiger, an geschützte interne Adressen gerichteter Datenverkehr von außen

• Explizit deny Erklärung

  

  Hinweis: Obwohl alle ACLs eine implizite deny -Anweisung empfiehlt Cisco die Verwendung einer expliziten deny -Anweisung, z. B. deny ip any any. Auf den meisten Plattformen verwalten solche Anweisungen die Anzahl der abgelehnten Pakete, die mithilfe des show access-list aus.

So entwickeln Sie eine Transport-ACL

Der erste Schritt bei der Entwicklung einer Transit-ACL besteht in der Bestimmung der in Ihren Netzwerken erforderlichen Protokolle. Obwohl jeder Standort bestimmte Anforderungen hat, werden bestimmte Protokolle und Anwendungen häufig verwendet und sind in der Regel zulässig. Wenn beispielsweise das DMZ-Segment die Konnektivität für einen öffentlich zugänglichen Webserver bereitstellt, ist TCP vom Internet zu den DMZ-Serveradressen an Port 80 erforderlich. Ebenso erfordern interne Verbindungen zum Internet, dass die ACL die Rückgabe von etabliertem TCP-Datenverkehr zulässt - Datenverkehr, für den das Bestätigungsbit (ACK) festgelegt ist.

Identifizieren erforderlicher Protokolle

Die Entwicklung dieser Liste erforderlicher Protokolle kann eine anspruchsvolle Aufgabe sein, es gibt jedoch verschiedene Techniken, die bei Bedarf verwendet werden können, um den erforderlichen Datenverkehr zu identifizieren.

• Überprüfen Sie Ihre lokale Sicherheitsrichtlinie/Servicerichtlinie.

  Ihre lokalen Standortrichtlinien sollten Ihnen dabei helfen, eine Baseline für zulässige und abgelehnte Services bereitzustellen.

• Überprüfen/Überprüfen Ihrer Firewall-Konfiguration

  Die aktuelle Firewall-Konfiguration sollte explizit permit -Anweisungen für zulässige Dienste. In vielen Fällen können Sie diese Konfiguration in das ACL-Format übersetzen und damit den Großteil der ACL-Einträge erstellen.

  

  Hinweis: Stateful-Firewalls verfügen in der Regel nicht über explizite Regeln für die Rückleitung von Datenverkehr an autorisierte Verbindungen. Da Router-ACLs nicht zustandsbehaftet sind, muss der zurückfließende Datenverkehr explizit zugelassen werden.

• Prüfen/prüfen Sie Ihre Anwendungen.

  Die auf der DMZ gehosteten Anwendungen sowie die intern verwendeten Anwendungen können bei der Ermittlung der Filteranforderungen helfen. Überprüfen Sie die Anwendungsanforderungen, um wichtige Details zum Filterdesign anzugeben.

• Verwenden einer Klassifizierungs-ACL

  Eine Klassifizierungs-ACL besteht aus permit Anweisungen für die verschiedenen Protokolle, die für das interne Netzwerk bestimmt sein könnten. (Eine Liste häufig verwendeter Protokolle und Anwendungen finden Sie in Anhang A.) Verwenden Sie show access-list -Befehl, um die Anzahl der ACE-Treffer (Access Control Entry) zur Identifizierung der erforderlichen Protokolle anzuzeigen. Untersuchen und Verstehen verdächtiger oder überraschender Ergebnisse, bevor Sie explizite permit -Anweisungen für unerwartete Protokolle.

• Verwenden Sie die NetFlow-Switching-Funktion.

  NetFlow ist eine Switching-Funktion, die, sofern aktiviert, detaillierte Informationen zum Datenfluss bereitstellt. Wenn NetFlow auf Ihren Edge-Routern aktiviert ist, show ip cache flow enthält eine Liste der von Netflow protokollierten Protokolle. NetFlow kann nicht alle Protokolle identifizieren. Daher muss dieses Verfahren zusammen mit anderen verwendet werden.

Identifizieren von ungültigem Datenverkehr

Neben dem direkten Schutz sollte die Transit-ACL auch eine erste Verteidigungslinie gegen bestimmte Arten von ungültigem Datenverkehr im Internet bieten.

• Verweigern Sie RFC 1918-Speicherplatz.

• Verweigern Sie Pakete mit einer Quelladresse, die unter den in RFC 3330 definierten Adressraum für spezielle Anwendungen fällt.

• Wenden Sie Anti-Spoofing-Filter gemäß RFC 2827 an. Ihr Adressraum sollte niemals die Quelle von Paketen von außerhalb Ihres autonomen Systems (AS) sein.

Weitere zu berücksichtigende Datenverkehrstypen:

• Externe Protokolle und IP-Adressen für die Kommunikation mit dem Edge-Router

  • ICMP von IP-Adressen des Dienstanbieters

  • Routing-Protokolle

  • IPSec-VPN, wenn ein Edge-Router als Terminierung verwendet wird

• Explizit zulässiger zurückkehrender Datenverkehr für interne Internetverbindungen

  • Spezifische Internet Control Message Protocol (ICMP)-Typen

  • DNS-Abfrageantworten (Outbound Domain Name System)

  • TCP erstellt

  • User Datagram Protocol (UDP)-Rückverkehr

  • FTP-Datenverbindungen

  • TFTP-Datenverbindungen

  • Multimedia-Verbindungen

• Explizit zulässiger, an geschützte interne Adressen gerichteter Datenverkehr von außen

  • VPN-Datenverkehr

    • Internet Security Association and Key Management Protocol (ISAKMP)

    • Network Address Translation (NAT) Traversal

    • Proprietäre Kapselung

    • Encapsulating Security Payload (ESP)

    • Authentifizierungs-Header (AH)

  • HTTP an Webserver

  • Secure Socket Layer (SSL) für Webserver

  • FTP zu FTP-Servern

  • Eingehende FTP-Datenverbindungen

  • Eingehende passive FTP-Datenverbindungen (Pasv)

  • Simple Mail Transfer Protocol (SMTP)

  • Weitere Anwendungen und Server

  • Eingehende DNS-Abfragen

  • Eingehende DNS-Zonenübertragungen

ACL anwenden

Die neu erstellte ACL muss eingehend auf die mit dem Internet verbundenen Schnittstellen der Edge-Router angewendet werden. In dem im Abschnitt Typical Setup dargestellten Beispiel wird die ACL in den zum Internet gerichteten Schnittstellen auf IR1 und IR2 angewendet.

Weitere Informationen finden Sie in den Abschnitten zu Bereitstellungsrichtlinien und Bereitstellungsbeispiel.

ACL-Beispiel

Diese Zugriffsliste stellt ein einfaches, aber realistisches Beispiel für typische Einträge dar, die in einer ACL für die Übertragung erforderlich sind. Diese grundlegende ACL muss mit lokalen, standortspezifischen Konfigurationsdetails angepasst werden.

!--- 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 

• Die Fehlermeldung log -Schlüsselwort verwendet werden, um zusätzliche Details über Quelle und Ziele für ein bestimmtes Protokoll bereitzustellen. Obwohl dieses Schlüsselwort wertvolle Einblicke in die Details von ACL-Treffern bietet, führen übermäßige Treffer zu einem ACL-Eintrag, der die log erhöhen die CPU-Auslastung. Die Leistungsauswirkungen der Protokollierung variieren je nach Plattform.

• Für Pakete, die administrativ von einer ACL abgelehnt werden, werden Nachrichten für "ICMP unreachable" (nicht erreichbar) generiert. Dies könnte die Leistung von Routern und Verbindungen beeinträchtigen. Erwägen Sie die Verwendung des no ip unreachables , um IP unreachables auf der Schnittstelle zu deaktivieren, auf der die Transit-ACL (Edge-ACL) bereitgestellt wird.

• Diese ACL kann bei der Erstbereitstellung mit allen permit um sicherzustellen, dass legitimer geschäftlicher Datenverkehr nicht abgelehnt wird. Sobald legitimer geschäftlicher Datenverkehr erkannt und berücksichtigt wurde, deny -Elemente konfiguriert werden.

ACLs und fragmentierte Pakete

ACLs verfügen über eine fragments -Schlüsselwort, das ein spezielles fragmentiertes Paketverarbeitungsverhalten ermöglicht. Im Allgemeinen werden nicht anfängliche Fragmente, die mit den Layer-3-Anweisungen (Protokoll, Quelladresse und Zieladresse) übereinstimmen - unabhängig von den Layer-4-Informationen in einer ACL - durch die permit Oder deny -Anweisung des ausgeglichenen Eintrags. Beachten Sie, dass die Verwendung des fragments kann ACLs dazu zwingen, nicht initiale Fragmente mit größerer Genauigkeit zu verweigern oder zuzulassen.

Durch das Filtern von Fragmenten wird eine zusätzliche Schutzebene gegen einen DoS-Angriff (Denial-of-Service) hinzugefügt, der nur Fragmente verwendet, die keine Initiale sind (z. B. FO > 0). Die Verwendung eines deny -Anweisung für nicht initiale Fragmente am Anfang der ACL verweigert allen nicht initialen Fragmenten den Zugriff auf den Router. In seltenen Fällen kann eine gültige Sitzung eine Fragmentierung erfordern und daher gefiltert werden, wenn eine deny fragment -Anweisung in der ACL vorhanden ist. Zu den Bedingungen, die zu einer Fragmentierung führen können, gehören die Verwendung digitaler Zertifikate für die ISAKMP-Authentifizierung und die Verwendung von IPSec NAT Traversal.

Betrachten Sie beispielsweise die hier abgebildete partielle 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>

Wenn diese Einträge am Anfang einer ACL hinzugefügt werden, wird der Zugriff auf das Netzwerk durch nicht initiale Fragmente verweigert, während nicht fragmentierte Pakete oder initiale Fragmente an die nächsten Zeilen der ACL weitergeleitet werden, die von den deny fragment -Anweisungen. Der vorherige ACL-Ausschnitt erleichtert auch die Klassifizierung des Angriffs, da jedes Protokoll - UDP, TCP und ICMP - separate Zähler in der ACL inkrementiert.

Da viele Angriffe auf Flooding mit fragmentierten Paketen beruhen, bietet das Filtern eingehender Fragmente im internen Netzwerk eine zusätzliche Schutzmaßnahme und trägt dazu bei, dass ein Angriff keine Fragmente einschleusen kann, indem er einfach die entsprechenden Layer-3-Regeln in der Transit-ACL einfügt.

Eine detaillierte Beschreibung der Optionen finden Sie unter Zugriffskontrolllisten und IP-Fragmente.

Risikobewertung

Bei der Bereitstellung von Zugriffskontrolllisten für den Transitverkehr sollten zwei Risikobereiche berücksichtigt werden.

• Stellen Sie sicher, dass die permit/deny -Anweisungen vorhanden sind. Damit die ACL wirksam ist, müssen Sie alle erforderlichen Protokolle zulassen.

• Die ACL-Leistung variiert von Plattform zu Plattform. Bevor Sie ACLs bereitstellen, überprüfen Sie die Leistungsmerkmale Ihrer Hardware.

Cisco empfiehlt, dieses Design vor der Bereitstellung im Labor zu testen.

Anhänge

Häufig verwendete Protokolle und Anwendungen

TCP-Portnamen

Diese Liste der TCP-Portnamen kann anstelle der Portnummern verwendet werden, wenn Sie die ACL in der Cisco IOS®^-Software konfigurieren. Eine Referenz zu diesen Protokollen finden Sie in der RFC der aktuell zugewiesenen Nummer. Portnummern, die diesen Protokollen entsprechen, können auch gefunden werden, wenn Sie die ACL konfigurieren, indem Sie ein ? anstelle einer Portnummer eingeben.

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-Portnamen

Diese Liste der UDP-Portnamen kann anstelle der Portnummern verwendet werden, wenn Sie die ACL in der Cisco IOS Software konfigurieren. Eine Referenz zu diesen Protokollen finden Sie in der RFC der aktuell zugewiesenen Nummer. Portnummern, die diesen Protokollen entsprechen, können auch gefunden werden, wenn Sie die ACL konfigurieren, indem Sie ein ? anstelle einer Portnummer eingeben.

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

Bereitstellungsrichtlinien

Cisco empfiehlt eine konservative Bereitstellungspraxis. Damit Sie Transit-ACLs erfolgreich bereitstellen können, müssen Sie über klare Kenntnisse der erforderlichen Protokolle verfügen. Diese Richtlinien beschreiben eine sehr konservative Methode für die Bereitstellung von Schutz-ACLs, die einen iterativen Ansatz verwenden.

1. Identifizieren der im Netzwerk verwendeten Protokolle mit einer Klassifizierungs-ACL.

   Bereitstellen einer ACL, die alle im Netzwerk verwendeten bekannten Protokolle zulässt Diese Erkennung oder Klassifizierung der ACL muss die Quelladresse any und das Ziel einer IP-Adresse oder des gesamten über das Internet routbaren IP-Subnetzes. Konfigurieren Sie den letzten Eintrag, der Folgendes zulässt: ip any any log um zusätzliche Protokolle zu identifizieren, die Sie zulassen müssen.

   Ziel ist es, alle erforderlichen Protokolle zu ermitteln, die im Netzwerk verwendet werden. Verwenden Sie die Protokollierung für die Analyse, um zu ermitteln, was sonst noch mit dem Router kommunizieren könnte.

   

   Hinweis: Obwohl die log bietet wertvolle Einblicke in die Details von ACL-Treffern, übermäßige Treffer in einem ACL-Eintrag, der dieses Schlüsselwort verwendet, können zu einer überwältigenden Anzahl von Protokolleinträgen und möglicherweise zu einer hohen CPU-Auslastung des Routers führen. Verwenden Sie log nur für kurze Zeiträume und nur dann, wenn dies zur Klassifizierung des Datenverkehrs erforderlich ist.

   Beachten Sie, dass das Netzwerk einem Angriffsrisiko ausgesetzt ist, während eine ACL aus allen permit -Anweisungen vorhanden ist. Führen Sie den Klassifizierungsprozess so schnell wie möglich durch, damit geeignete Zugriffskontrollen eingerichtet werden können.

2. Identifizierte Pakete überprüfen und Zugriff auf das interne Netzwerk filtern

   Nachdem Sie die von der ACL in Schritt 1 gefilterten Pakete identifiziert und geprüft haben, aktualisieren Sie die Klassifizierungs-ACL, um die neu identifizierten Protokolle und IP-Adressen zu berücksichtigen. Hinzufügen von ACL-Einträgen für Anti-Spoofing Bei Bedarf können Sie spezifische deny Einträge für permit -Anweisungen in der Klassifizierungs-ACL. Sie können die show access-list Befehl zur Überwachung bestimmter deny Einträge können auf die Trefferanzahl überwacht werden. Dies liefert Informationen über unzulässige Netzwerkzugriffsversuche, ohne dass die Protokollierung von ACL-Einträgen aktiviert werden muss. Die letzte Zeile der ACL muss eine deny ip any any. Auch hier kann die Trefferanzahl für diesen letzten Eintrag Informationen über unzulässige Zugriffsversuche liefern.

3. Überwachen und Aktualisieren der ACL

   Überwachen Sie die abgeschlossene ACL, um sicherzustellen, dass neu eingeführte erforderliche Protokolle kontrolliert hinzugefügt werden. Wenn Sie die ACL überwachen, werden auch Informationen über unzulässige Netzwerkzugriffsversuche bereitgestellt, die Informationen über bevorstehende Angriffe liefern könnten.

Bereitstellungsbeispiel

Dieses Beispiel zeigt eine Transit-ACL, die ein Netzwerk basierend auf dieser Adressierung schützt.

• Die IP-Adresse des ISP-Routers lautet 10.1.1.1.

  Die IP-Adresse des Edge-Routers mit Internetzugang lautet 10.1.1.2.

  Das Internet-routbare Subnetz ist 192.168.201.0 255.255.255.0.

  Das VPN-Headend ist 192.168.201.100.

  Der Webserver ist 192.168.201.101.

  Der FTP-Server ist 192.168.201.102.

  Der SMTP-Server ist 192.168.201.103.

  Der primäre DNS-Server ist 192.168.201.104.

  Der sekundäre DNS-Server ist 172.16.201.50.

Die Zugriffskontrollliste für den Transitschutz wurde auf der Grundlage dieser Informationen entwickelt. Die ACL lässt eBGP-Peering zum ISP-Router zu, bietet Anti-Spoof-Filter, lässt bestimmten rückläufigen Datenverkehr zu, lässt bestimmten eingehenden Datenverkehr zu und verweigert explizit den gesamten anderen Datenverkehr.

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

Zugehörige Informationen

• Request For Comments (RFCs)
• Technischer Support und Dokumentation für Cisco Systeme