Cisco IOS: Interface-ACLs für VPNs

Jeder Router, der mit dem Internet verbunden ist, sollte mit einer eingehenden Access-Liste (ACL) auf dem externen Interface konfiguriert sein, der den Zugriff auf den Router einschränkt. In diesem Beitrag zeige ich, wie so eine ACL aussehen kann.

Anmerkung1: Die gezeigte Konfig gilt nur für IOS-Versionen 12.4+. Bei älteren IOS-Releases ist etwas mehr Konfiguration notwendig.
Anmerkung2: Dies gilt nicht für die ASA da dort so eine ACL nicht benötigt wird. Auf der ASA filtert die Interface-ACL standardmäßig nur den durch die ASA durchgehenden Traffic, aber nicht den Traffic, der zur ASA selbst gesendet wird.

Die folgenden Beispiele basieren auf der folgenden Topologie:
VPN-Interface-ACLs

Voraussetzungen:
Der Router sollte mit einer Stateful-Firewall-Konfig versehen sein, die Antwort-Pakete auf selbst generierten Traffic ohne ACEs erlaubt. Das ist Bestandteil der Baseline-Security und vereinfacht die Konfiguration. In diesen Beispiel wird das ältere CBAC verwendet, da es deutlich einfacher zu verstehen und implementieren ist, als die leistungsfähigere Zone-Based-Firewall:

ip inspect name FW ftp
ip inspect name FW tcp router-traffic
ip inspect name FW udp router-traffic
ip inspect name FW icmp router-traffic
!
interface GigabitEthernet0/0
  ip access-group SITE-A-INTERNET-IN in
  ip inspect FW out
!
ip access-list extended SITE-A-INTERNET-IN
  deny ip any any

Basierend auf dieser Konfiguration wird die ACL mit den benötigten ACEs ergänzt.

Scenario 1: Site-to-Site VPNs mit statischen VPN-Peers
Bei diesem einfachen Beispiel wird angenommen, dass alle Peers eine statische public IP haben, die zwischen den beiden Gateways nicht genatted werden. Der in der ACL benötigte Traffic ist IP-Protocol 50 (ESP) und UDP/500 (ISAKMP). Viele Beispiele im Internet haben auch ACEs für IP/51 (AH), dies wird aber normalerweise nicht für VPNs verwendet.

Als erstes wird eine Object-Group für alle VPN-Peers erstellt (Object-Groups benötigen mindestens IOS 12.4(20)T+):

object-group network IPSEC-PEERS
  host 198.51.100.1
  host 203.0.113.1

Dann wird in der ACL der ESP- und ISAKMP-Traffic von den VPN-Peers zum Router-Interface erlaubt:

ip access-list extended SITE-A-INTERNET-IN
  permit esp  object-group IPSEC-PEERS host 192.0.2.1
  permit udp  object-group IPSEC-PEERS host 192.0.2.1 eq isakmp
  permit icmp object-group IPSEC-PEERS host 192.0.2.1 echo

Die letzte Zeile ist für die VPN-Funktionalität natürlich nicht nötig, erleichtert aber das Troubleshooting.

Scenario 2: VPN-Peers hinter einem NAT-device mit statischen IPs
Wenn ein oder beide IPsec-Peers sich hinter einem NAT-Device befinden, dann verwendet IPsec NAT-Traversal, das auch mit UDP/500 anfängt, aber dann auf UDP/4500 wechselt.

Dafür werden die folgenden Einträge benötigt:

ip access-list extended SITE-A-INTERNET-IN
  permit esp  object-group IPSEC-PEERS host 192.0.2.1
  permit udp  object-group IPSEC-PEERS host 192.0.2.1 eq isakmp non500-isakmp
  permit icmp object-group IPSEC-PEERS host 192.0.2.1 echo

Die Einträge in der Object-Group sind weiterhin die public IPs der Router, nicht die realen IP-Adressen der Router.
Wenn alle Router hinter einem NAT-Device sind, dann wird der ACL-Eintrag für ESP (IP/50) nicht benötigt, da dann der gesamte User-Traffic über UDP/4500 gesendet wird.

Scenario 3: IPsec-Peers mit dynamischer IP-Adresse
Dies ist das typische Remote-Access-Scenario, oder aber auch verwendet, wenn z.B. Branchoffices mit günstigen Kabel- oder DSL-Anschlüssen betrieben werden, für die keine festen IPs verfügbar sind. Daraus resultiert die folgende ACL:

ip access-list extended SITE-A-INTERNET-IN
  permit esp any host 192.0.2.1
  permit udp any host 192.0.2.1 eq isakmp non500-isakmp
  ! generally allow ping from the internet if your security-policy allows that:
  permit icmp any host 192.0.2.1 echo

In diesem Scenario wird die Object-Group mit den IPsec-Peers nicht benötigt, da deren IP im Vorwege sowieso nicht bekannt sind.

Viel Spaß beim Absichern der VPNs!

Advertisements
Cisco IOS: Interface-ACLs für VPNs

RFC 3330 ist obsolet

In RFC 3330 waren die “Special Use IPv4 Addresses” definiert. Dieser RFC wurde jetzt durch den RFC 5735 ersetzt (leider kann man sich diese Nummer nicht so gut merken).
Sehr interessant ist die Erweiterung der TEST-NET-Einträge:

192.0.2.0/24 
198.51.100.0/24
203.0.113.0/24 

Während der erste Eintrag schon länger vorhanden ist, stehen jetzt zwei weitere Netze zu Dokumentationszwecken zur Verfügung. Diese Verwendung ist explizit im RFC 5737 – IPv4 Address Blocks Reserved for Documentation beschrieben.

Damit sollte man auch die typische Anti-Spoofing-ACL für Perimeter-Router anpassen:

ip access-list extended PERIMETER-IN
 deny   ip 0.0.0.0 0.255.255.255 any
 deny   ip 10.0.0.0 0.255.255.255 any
 deny   ip 127.0.0.0 0.255.255.255 any
 deny   ip 169.254.0.0 0.0.255.255 any
 deny   ip 172.16.0.0 0.15.255.255 any
 deny   ip 192.0.2.0 0.0.0.255 any
 deny   ip 192.168.0.0 0.0.255.255 any
 deny   ip 198.18.0.0 0.1.255.255 any
 deny   ip 198.51.100.0 0.0.0.255 any
 deny   ip 203.0.113.0 0.0.0.255 any
 deny   ip 224.0.0.0 31.255.255.255 any
 deny   ip EIGENES-NETZ any
 permit ...
RFC 3330 ist obsolet

Cisco Access-Control-Listen

routerImmer wieder stelle ich fest, dass manche Admins eine der wichtigsten Erweiterungen der Cisco Access-Listen verpasst haben:

Access-Listen lassen sich komfortabel editieren
Seit einiger Zeit (nein, an das genaue Release erinnere ich mich nicht mehr) haben die ACEs (Access-List-Entries) Sequenznummern, die man beim show access-lists sehen kann:

c1841#sh access-lists    
Extended IP access list 100
    10 permit icmp any any (5 matches)
Extended IP access list TEST
    10 permit icmp any any (5 matches)
    20 permit udp any any
    30 permit esp any any

Diese Sequenznummern können verwendet werden, um neue ACEs einzufügen. Dazu muss eine bisher nicht verwendete Nummer genommen werden:

c1841(config)#ip access-list ext TEST
c1841(config-ext-nacl)#15 permit tcp any any 
c1841(config-ext-nacl)#
c1841(config-ext-nacl)#do sh ip access-list TEST
Extended IP access list TEST
    10 permit icmp any any (5 matches)
    15 permit tcp any any
    20 permit udp any any
    30 permit esp any any
c1841(config-ext-nacl)#

ACEs können natürlich auch gelöscht werden:

c1841(config-ext-nacl)#no 10
c1841(config-ext-nacl)#do sh ip access-list TEST
Extended IP access list TEST
    15 permit tcp any any
    20 permit udp any any
    30 permit esp any any
c1841(config-ext-nacl)#

Wenn in einer ACL keine freien Sequenznummern mehr zur Verfügung stehen, können diese neu gebildet werden. Bei einem Reload werden diese mit einem Startwert von 10 und einer Schrittweite von 10 gebildet.

c1841(config)#ip access-list resequence TEST 50 20 
c1841(config)#
c1841(config)#do sh ip access-list TEST           
Extended IP access list TEST
    50 permit tcp any any
    70 permit udp any any
    90 permit esp any any
c1841(config)#

Wer noch an seinen nummerierten ACLs hängt, kann die Editier-Funktionen natürlich auch benutzen. Dafür muss die Nummer einfach wie ein Name in den named ACLs verwendet werden:

c1841(config)#ip access-list extended 100
c1841(config-ext-nacl)#20 deny ip any any log
c1841(config-ext-nacl)#
c1841(config-ext-nacl)#do sh ip access-list 100
Extended IP access list 100
    10 permit icmp any any (5 matches)
    20 deny ip any any log
c1841(config-ext-nacl)#

Weitere Funktionen, die bei den ACLs in der Vergangenheit hinzugekommen sind:

Direktes Anzeigen der ACL zu einem Interface

c1841#sh ip access-list interface loo11
Extended IP access list TEST in
    10 permit icmp any any (5 matches)
c1841#
c1841#sh ip access-list interface loo12
Extended IP access list TEST in
    10 permit icmp any any (10 matches)
c1841#
c1841#sh ip access-list interface loo13
Extended IP access list TEST in
    10 permit icmp any any (15 matches)
Extended IP access list TEST2 out
    10 permit tcp any any

Obwohl dieselbe ACL auf drei verschiedenen Interfaces gebunden wurde, werden getrennte Statistiken geführt.

Mehrere Ports pro ACE

c1841(config)#ip access-list ext IPSEC
c1841(config-ext-nacl)#permit esp any any
c1841(config-ext-nacl)#permit udp any any eq isakmp non500-isakmp 
c1841(config-ext-nacl)#
c1841(config-ext-nacl)#do sh access-list IPSEC
Extended IP access list IPSEC
    10 permit esp any any
    20 permit udp any any eq isakmp non500-isakmp
c1841(config-ext-nacl)#

Natürlich verliert man bei dieser Konfiguration die getrennten Counter für die unterschiedlichen Ports (hier 500 und 4500).

ACLs können auf weitere Felder wie z.B. den TTL-, den DSCP-Wert oder TCP-Flags filtern

c1841(config)#ip access-list extended TEST3
c1841(config-ext-nacl)#permit icmp any any ttl gt 128
c1841(config-ext-nacl)#permit udp any any dscp ef 
c1841(config)#ip access-list extended TEST4
c1841(config-ext-nacl)#permit tcp any any match-all +syn +ack +fin -urg 

Im zweiten Beispiel wird TCP-Traffic erlaubt, der sowohl das SYN, ACK und FIN-Bit trägt, aber nicht das URG-Bit.

Gruppieren von Network- oder Service-Objekten
Wer sich traut, das IOS 12.4(20)T einzusetzen, hat sogar die Möglichkeit, Object-Groups zu verwenden, wie es die PIX bzw. ASA schon lange vorgemacht hat:

c1841(config)#object-group network RFC1918
c1841(config-network-group)#10.0.0.0 0.255.255.255
c1841(config-network-group)#172.16.0.0 0.15.255.255
c1841(config-network-group)#range 192.168.0.0 192.168.255.255
c1841(config-network-group)#exit
c1841(config)#
c1841(config)#ip access-list extended TEST5
c1841(config-ext-nacl)#permit icmp any object-group RFC1918 

Setzen von Cookies für das Logging
Ab 12.4(22)T kann an das Keyword log oder log-input ein “Cookie” angehängt werden, das als Tag zum Syslog-Server mitgesendet wird:

c1841(config)#ip access-list ext TEST6
c1841(config-ext-nacl)#deny icmp host 10.1.1.1 host 10.2.2.2 log BewareOfTheseHosts
c1841(config-ext-nacl)#
c1841(config-ext-nacl)#do sh ip access-lists TEST6
Extended IP access list TEST6
    10 deny icmp host 10.1.1.1 host 10.2.2.2 log (10 matches) (tag = BewareOfTheseHosts)
c1841(config-ext-nacl)#

Auf dem Syslog-Server kommt dieses Tag mit der Log-Meldung an und kann z.B. gefiltert werden:

%SEC-6-IPACCESSLOGDP: list TEST6 denied icmp 10.1.1.1 -> 10.2.2.2 (0/0), 10 packets  [BewareOfTheseHosts]
Cisco Access-Control-Listen

Standard-ACLs

Wie oft wird dieser Mist eigentlich noch verbreitet?

Question: Where should you place standard ACLs in the Network?
Answer: Standard ACLs should be placed as close as possible to the destination to prevent unintended traffic from filtering to your other networks.

Standard-ACLs werden nicht zum Filtern von Traffic verwendet! Dazu sind die extended Access-Listen da. Standard-ACLs haben ihre Daseinsberechtigung z.B. im Filtern von Routing-Updates, für Access-Classes, etc. Aber leider ist die Original-Aussage in diversen Cisco-Trainings zu finden und wird auch genauso oft nachgeplappert (leider auch von Leuten, die es besser wissen sollten).

Standard-ACLs

Cisco ACL Editor und Simulator

Mit der Konfiguration von Access-Listen (ACLs) muss jeder Cisco-Admin erst einmal “warm werden”. Eine neue Software von Gareth O. Evans kann den Umgang mit ACLs erleichtern. Diese erlaubt nicht nur die Konfiguration von Access-Listen sondern auch deren Simulation. Man merkt allerdings, daß dieses Programm erst in Version 1.0.0.2 vorliegt. Benannte Access-Listen sind nicht möglich, die Eingabe der ACL-Nummern ist über ein Drop-Down-Menue eher umständlich und alles was vom “Standard” abweicht, ist nicht möglich. So gehen z.B. keine Time-Ranges, mehrere Ports pro ACE, ICMP-Typen oder aber das Filtern auf TCP-Flags. Das Programm ist zwar zur Zeit nur als 30-Tage-Test-Version zu bekommen, aber wenn es kostenlos bleibt, dann könnte es für den Einen oder Anderen interessant sein.

Cisco ACL Editor und Simulator