Cisco ASA und Policy-based Routing (PBR)

Dieses Feature ist vermutlich eines, auf das sehr viele Admins gewartet haben. Endlich ist es (in Version 9.4(1)) implementiert:

Policy Based Routing

Policy Based Routing (PBR) is a mechanism by which traffic is routed through specific paths with a specified QoS using ACLs. ACLs let traffic be classified based on the content of the packet’s Layer 3 and Layer 4 headers. This solution lets administrators provide QoS to differentiated traffic, distribute interactive and batch traffic among low-bandwidth, low-cost permanent paths and high-bandwidth, high-cost switched paths, and allows Internet service providers and other organizations to route traffic originating from various sets of users through well-defined Internet connections.
We introduced the following commands: set ip next-hop verify-availability, set ip next-hop, set ip next-hop recursive, set interface, set ip default next-hop, set default interface, set ip df, set ip dscp, policy-route route-map, show policy-route, debug policy-route

Cisco ASA und Policy-based Routing (PBR)

ASA Software 9.3.2

Sehr lange hat es gedauert, aber mit der gerade veröffentlichten Version hält ein Feature in die ASA Einzug, dass ich schon lange vermisst habe:

Transport Layer Security (TLS) version 1.2 support

We now support TLS version 1.2 for secure message transmission for ASDM, Clientless SSVPN, and AnyConnect VPN.

Das wurde auch Zeit, vor allem wegen der in letzten Zeit vermehrt gefundenen Angriffe gegen ältere TLS-Versionen.

Auch sehr interessant:

ASA 5506-X

We introduced the ASA 5506-X.

Das Ende der ASA 5505 war schon lange erwartet. Aber jetzt ist es wohl endlich soweit und ein Nachfolger ist vorhanden.

ASA Software 9.3.2

Konfiguration von SSH auf Cisco ASA und IOS

Ab und zu erschrecke ich doch was Cisco-Mitarbeiter so verzapfen. Jetzt hat gerade einer in der Cisco Support-Community ein Dokument zur Konfiguration von SSH auf der ASA veröffentlicht. Und da liest man z.B., dass die Keysize von 1024 Bit benutzen werden soll. Und nichts weiter zu heutigen “Best Practices” der SSH-Konfig. Grund genug eine in meinen Augen “anständige” SSH-Konfig für IOS-Geräte und die ASA zu zeigen:

Cisco IOS
Es geht damit los, ein RSA-Keypair zu generieren, das nur für den SSH-Prozess verwendet wird. Dafür wird dem Keypair ein Label mitgegeben:

crypto key generate rsa label SSH-KEY modulus 4096

Etwas Gedanken sollte man sich über die Keylänge machen. Länger bedeutet zum einen sicherer, aber auch langsamer. Allerdings nicht so langsam, dass es nicht benutzbar wäre. Damit ist die Entscheidung recht einfach. Allgemeine Hinweise zu minimalen Keylängen findet man u.a. auf http://www.keylength.com

Das RSA-Keypair wird der SSH-Konfig zugewiesen:

ip ssh rsa keypair-name SSH-KEY

Nur SSHv2 erlauben:

ip ssh version 2

Beim Verbindungsaufbau werden die Session-Keys per Diffie-Hellman erzeugt. Das ist standardmäßig mit der Gruppe 1 (768 Bit) erlaubt, was nicht mehr state-of-the-art ist. Daher wird eine höhere DH-Gruppe konfiguriert. Jetzt ist es aber so, dass die aktuelle Version (0.63) von Putty mit einem 4096 Bit Key-Exchange nicht klar kommt. Sowohl mit SecureCRT, als auch mit dem eingebauten SSH von Mac OS und Linux klappt es aber. Wer per Putty administrieren will, sollte hier also nur 2048 verwenden, was natürlich auch sehr sicher ist.

ip ssh dh min size 4096

Login-Vorgänge sollten protokolliert werden:

ip ssh logging events

Als letztes wird auf der VTY-Line nur SSH erlaubt. Telnet ist damit abgeschaltet.

line vty 0 4
  transport input ssh

Was könnte man sonst noch für SSH konfigurieren: Ab und an kommt der Wunsch auf, für SSH nicht den Port TCP/22 zu verwenden. Das erhöht zwar nicht unbedingt die Sicherheit, sorgt aber dafür, dass die Logs etwas kleiner bleiben wenn SSH vom Internet aus erreichbar ist:

ip ssh port 7890 rotary 1
line vty 0 4
  rotary 1

Wenn der Zugriff über ein Interface erfolgt, auf dem eine eingehende ACL konfiguriert ist, dann muss in dieser die Kommunikation natürlich auch erlaubt werden.

Weitere Schutzmechanismen über die nachgedacht werden können sind Control-Plane-Protection und Management-Plane-Protection wenn out-of-band Management verwendet wird. Wenn der SSH-Zugriff nicht von “any” benötigt wird, dann sollte für die Lines natürlich auch eine Access-Class konfiguriert werden. Aber auch das ist nicht SSH-spezifisch.

Cisco ASA
Für die ASA gilt so ziemlich das oben genannte, nur das die SSH-Konfiguration nicht so umfangreich angepasst werden kann. Weiterhin ist die Syntax teilweise anders:

crypto key generate rsa modulus 4096
ssh version 2
ssh key-exchange group dh-group14-sha1

Die Key-Länge ist hier auch von der Plattform abhängig. Die Legacy-ASAs unterstützen keine Keys mit mehr als 2048 Bit. Auf den aktuellen -X-Geräten kann aber auch 4096 Bit genutzt werden.

Auch muss der SSH-Zugriff auf der ASA explizit für die Management-IPs erlaubt werden:

ssh 10.10.0.0 255.255.0.0 inside
ssh 192.0.2.100 255.255.255.255 outside
Konfiguration von SSH auf Cisco ASA und IOS

Die neue ASA Software 9.2

Bei dieser Version gibt es mal wieder eine Reihe sehr interessanter Neuerungen. Produktiv würde ich so eine frische Software zwar meist nicht einsetzen, aber wenn die ersten Bugs erstmal raus sind, dann wird es sehr interessant.

Für welche ASAs gibt es die neue Software:
Alle Nutzer der “Legacy”-ASAs (das sind die 5510/20/40/50/80) kommen nicht mehr in den Genuss dieser Software. Für diese Geräte ist bei 9.1x Schluss. Für die 5505 ist diese Software allerdings verfügbar; diese ASA ist aber auch noch nicht EOS.

Die neuen Features:
Diese sind in den Release-Notes zur 9.2(x) aufgeführt. Sehr interessant finde ich die folgenden neuen Funktionen:

  • Unterstützung der ASAv
  • Die ASAv läuft unter VMware vSphere und kommt in der kleinsten Version mit einer vCPU und 2GB RAM aus. Das könnte gerade für den Lab-Einsatz sehr interessant werden. Ein paar Features der regulären ASA sind aber nicht unterstützt.

  • BGP Support
  • Danach wurde ich schon häufiger gefragt. Damit kann man sich jetzt in einigen Situationen den extra WAN-Router vor der ASA sparen.

  • Null0-Interface
  • Auf dem Router kann man ganze Netze in das Null0-Interface routen. Das kann jetzt auch die ASA.

  • ISE Change of Authorization
  • Um für VPN-User eine geänderte Autorisierung erzwingen zu können wurde in einer ISE-Umgebung bisher ein ISE-Inline-Node verwendet. Der wird jetzt nicht mehr benötigt.

  • Embedded Event Manager (EEM)
  • Ein aussergewöhnlich leistungsfähiges Tool um Aktionen zu automatisieren.

  • Auto-Enable
  • Jetzt kann man nach der Anmeldung direkt im Enable-Mode landen, ohne sich erneut authentifizieren zu müssen.

Insgesamt eine sehr interessante Erweiterung der ASA-Funktionalität. Ein paar Features auf die ich schon länger hoffe (z.B. RA-VPNs in Security-Kontexten oder FlexVPN) sind zwar immer noch nicht enthalten, aber ein paar Features muss sich Cisco ja auch für die nächsten Versionen lassen.

Die neue ASA Software 9.2

Cisco ASA VPNs: Spoke-to-Spoke Traffic via Hub

In dem Cisco Support-Forum kommt regelmäßig die Frage, wie man per VPN Spoke-zu-Spoke Kommunikation über den Hub leiten kann.
Diese Konfiguration wird hier gezeigt. Vorweg aber der Hinweis, dass bei Vorhaben wie diesen, IOS-Router oftmals die bessere Wahl sind, da sie dabei um ein vielfaches flexibler sind als die ASA.

Die Konfiguration wird anhand des folgenden Aufbaus für die ASA-Version 8.4+ gezeigt. Es beginnt mit der Hub-to-Spoke-Konfiguration, die dann später mit einer Spoke-to-Spoke-Kommunikation erweitert wird:

ASA-Hub-and-Spoke

Auf allen ASAs werden Phase1- und Phase2-Policies für IPSec benötigt. Diese sind natürlich nach dem eigenen Bedürfnis zu wählen:

crypto ikev1 policy 1
 authentication pre-share
 encryption aes 256
 hash sha
 group 5
 lifetime 86400
!
crypto ikev1 enable outside
!
crypto ipsec ikev1 transform-set ESP-AES256-SHA esp-aes-256 esp-sha-hmac

Auf allen ASAs werden die benötigten Object-Groups, ACLs, Crypto-Maps und Tunnel-Groups angelegt. Zusätzlich wird der Traffic vom NAT ausgenommen:

Spoke1:

object-group network SPOKE1-NETWORKS
 network-object 10.0.1.0 255.255.255.0
object-group network HQ-NETWORKS
 network-object 10.0.0.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object HQ-NETWORKS
!
access-list VPN-SPOKE1-TO-HQ extended permit ip object-group SPOKE1-NETWORKS object-group HQ-NETWORKS
!
crypto map VPN 1 match address VPN-SPOKE1-TO-HQ
crypto map VPN 1 set peer 192.0.2.1
crypto map VPN 1 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN interface outside
!
tunnel-group 192.0.2.1 type ipsec-l2l
tunnel-group 192.0.2.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke1isN0Tc0mpl3xEnough
!
nat (any,outside) source static SPOKE1-NETWORKS SPOKE1-NETWORKS destination static NAT-EXEMPTION-DESTINATIONS NAT-EXEMPTION-DESTINATIONS no-proxy-arp route-lookup description NAT-Excempt for VPN

Spoke2:

object-group network SPOKE2-NETWORKS
 network-object 10.0.2.0 255.255.255.0
object-group network HQ-NETWORKS
 network-object 10.0.0.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object HQ-NETWORKS
!
access-list VPN-SPOKE2-TO-HQ extended permit ip object-group SPOKE2-NETWORKS object-group HQ-NETWORKS
!
crypto map VPN 1 match address VPN-SPOKE2-TO-HQ
crypto map VPN 1 set peer 192.0.2.1
crypto map VPN 1 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN interface outside
!
tunnel-group 192.0.2.1 type ipsec-l2l
tunnel-group 192.0.2.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke2isN0Tc0mpl3xEnough
!
nat (any,outside) source static SPOKE2-NETWORKS SPOKE2-NETWORKS destination static NAT-EXEMPTION-DESTINATIONS NAT-EXEMPTION-DESTINATIONS no-proxy-arp route-lookup description NAT-Excempt for VPN

Hub:

object-group network SPOKE1-NETWORKS
 network-object 10.0.1.0 255.255.255.0
object-group network SPOKE2-NETWORKS
 network-object 10.0.2.0 255.255.255.0
object-group network HQ-NETWORKS
 network-object 10.0.0.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object SPOKE1-NETWORKS
 group-object SPOKE2-NETWORKS
!
access-list VPN-HQ-TO-SPOKE1 extended permit ip object-group HQ-NETWORKS object-group SPOKE1-NETWORKS
!
access-list VPN-HQ-TO-SPOKE2 extended permit ip object-group HQ-NETWORKS object-group SPOKE2-NETWORKS
!
crypto map VPN 1 match address VPN-HQ-TO-SPOKE1
crypto map VPN 1 set peer 203.0.113.1
crypto map VPN 1 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN 2 match address VPN-HQ-TO-SPOKE2
crypto map VPN 2 set peer 198.51.100.1
crypto map VPN 2 set ikev1 transform-set ESP-AES256-SHA
crypto map VPN interface outside
!
tunnel-group 203.0.113.1 type ipsec-l2l
tunnel-group 203.0.113.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke1isN0Tc0mpl3xEnough
!
tunnel-group 198.51.100.1 type ipsec-l2l
tunnel-group 198.51.100.1 ipsec-attributes
 ikev1 pre-shared-key Th!sP$KHQ-Spoke2isN0Tc0mpl3xEnough

nat (any,outside) source static HQ-NETWORKS HQ-NETWORKS destination static NAT-EXEMPTION-DESTINATIONS NAT-EXEMPTION-DESTINATIONS no-proxy-arp route-lookup description NAT-Excempt for VPN

Mit der gegebenen Konfiguration kann zwischen Spoke1 und dem Hub, als auch zwischen Spoke2 und dem Hub per VPN kommuniziert werden.

Jetzt wird die VPN-Konfig um Spoke-to-Spoke-Kommunikation erweitert. Dabei soll jeder Spoke den Traffic für die anderen Spokes durch den schon bestehenden Tunnel zum Hub senden. Der Hub sendet den Traffic dann zum jeweiligen Spoke weiter.

Spoke1:

object-group network SPOKE2-NETWORKS
 network-object 10.0.2.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object SPOKE2-NETWORKS
!
access-list VPN-SPOKE1-TO-HQ extended permit ip object-group SPOKE1-NETWORKS object-group SPOKE2-NETWORKS

Spoke2:

object-group network SPOKE1-NETWORKS
 network-object 10.0.1.0 255.255.255.0
object-group network NAT-EXEMPTION-DESTINATIONS
 group-object SPOKE1-NETWORKS
!
access-list VPN-SPOKE2-TO-HQ extended permit ip object-group SPOKE2-NETWORKS object-group SPOKE1-NETWORKS

Die Crypto-ACLs haben jetzt permit-statements für die Kommunikation zum Hub, als auch zum anderen Spoke. Weiterhin wird auch der Spoke-to-Spoke-Traffic nicht genatted da die Spoke-Ziele der NAT-Exemption-Object-Group hinzugefügt wurden. Die Crypto-ACLs könnte man durch eine weitere Object-Group für die VPN-Ziele natürlich noch eleganter konfigurieren.

Hub:
Auf der Hub-ASA müssen zwei Änderungen vorgenommen werden.
Als erstes werden die Crypto-ACL so erweitert, dass die Crypto-ACL zum Spoke 1 auch den Traffic von Spoke2 beinhaltet und die Crypto-ACL zum Spoke2 auch den Traffic vom Spoke1 beinhaltet.

access-list VPN-HQ-TO-SPOKE1 extended permit ip object-group SPOKE2-NETWORKS object-group SPOKE1-NETWORKS
!
access-list VPN-HQ-TO-SPOKE2 extended permit ip object-group SPOKE1-NETWORKS object-group SPOKE2-NETWORKS

Als letzten Schritt wird die ASA so konfiguriert, dass Hairpinning erlaubt wird, also Traffic auf dem selben Interface die ASA verlassen kann, über das der Traffic empfangen wurde.

same-security-traffic permit intra-interface
Cisco ASA VPNs: Spoke-to-Spoke Traffic via Hub

Cisco ASA 5580

asa5580_60x48.jpg1,2 GBit/s (ASA 5550) ist zwar schön und gut für eine Firewall-Appliance, aber 6,5 GBit/s bzw. 14 GBit/s ist besser. 🙂 Diese Leistung sollen die neuen ASA 5580-20 bzw. ASA 5580-40 bringen, die Cisco gestern vorgestellt hat.
Neu sind auch die Interface-Karten, die es in der 5580 bis 10 Gig geben wird. Was die ASA 5580 aber nicht hat, sind mehrere SSM-Slots (von diesen gibt es nämlich keinen in dem Gerät). Der Wunsch mancher Kunden sowohl IPS, als auch Anti-X-Techniken betreiben zu können, wird also auch weiterhin erstmal nicht möglich sein.

Weitere Informationen gibt es unter http://www.cisco.com/go/asa.

Cisco ASA 5580