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!

Cisco IOS: Interface-ACLs für VPNs

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