Unterstützer gesucht
Zwei Initiativen, die ich selbst gut finde, suchen Unterstützung:
Cisco IOS: Per-Tunnel QoS für DMVPN
DMVPN ist eine der elegantesten VPN-Arten, wenn man eine größere Anzahl von Außenstellen hat, die über das Internet verbunden sind. Leider ist die Konfiguration von Quality of Service (QoS) hierbei leicht eingeschränkt. Vor einiger Zeit habe ich es bei einem ersten Kunden gewagt, Per-Tunnel QoS zu konfigurieren. Gewagt deshalb, weil ich dafür von meinem Lieblings-IOS, 12.4(15)T, auf ein neueres IOS wechseln musste. Im aktuellen Fall hat sich 12.4(22)T5 als stabil und zuverlässig genug herausgestellt. Die vorher getestete Version 12.4(22)T4 hatte massive Speicherlecks und war noch nicht einsetzbar.
Was ist Per-Tunnel-QoS?
Beim DMVPN registriert sich der Spoke-Router per NHRP, um seine (dynamische) public IP beim Next-Hop-Server (NHS) zu registrieren. Dabei kann der Router gleich einen Gruppennamen mitgeben, der in der Per-Tunnel-QoS-Konfiguration verwendet wird. Auf dem Hub wird für jede Gruppe eine QoS-Konfiguration angewendet. Damit lässt sich z.B. für jeden Spoke-Router die Datenrate auf die in der Außenstelle verwendete Downstream-Geschwindigkeit shapen. Wenn in der Hauptstelle eine Internet-Anbindung mit 34 MBit/s vorhanden ist, würde man damit normalerweise fast jede Außenstelle überlasten. Mit Per-Tunnel-QoS lässt sich das individuell runter regeln und wichtiger Traffic kann auch priorisiert werden.
Die Spoke-Konfiguration
Diese beschränkt sich auf eine Zeile in der Konfiguration:
interface Tunnel1
description DMVPN-Tunnel Internet
...
ip nhrp group SDSL2000-Std
...
Der Gruppenname (hier SDSL2000-Std) wird auf der Hub-Seite für die Auswahl der richtigen Policy verwendet. In diesem Beispiel ist die Außenstelle mit einer 2 MBit/s SDSL-Leitung angebunden, in der kein Voice verwendet wird. Die 2 MBit/s-Außenstelle mit Voice benutzt dann z.B. den Gruppennamen SDSL2000-Voice.
Die Gruppen sind auf dem Hub sichtbar:
HUB-Router#sh ip nhrp
...
10.255.255.8/32 via 10.255.255.8
Tunnel1 created 2w5d, expire 01:43:49
Type: dynamic, Flags: registered used
NBMA address: 79.x.y.z
Group: SDSL2000-Std
10.255.255.9/32 via 10.255.255.9
Tunnel1 created 20:53:37, expire 01:46:01
Type: dynamic, Flags: registered
NBMA address: 88.x.y.z
Group: HSDPA-Std
10.255.255.16/32 via 10.255.255.16
Tunnel1 created 2w5d, expire 01:54:05
Type: dynamic, Flags: registered used
NBMA address: 80.x.y.z
Group: SDSL2000-Std
10.255.255.152/32 via 10.255.255.152
Tunnel1 created 2w5d, expire 01:29:46
Type: dynamic, Flags: registered
NBMA address: 80.x.y.z
Group: ADSL3000-Voice
...Die Hub-Konfiguration
Auf dem Hub wird als Minimum eine Policy für Shaping konfiguriert, die von der NHRP-Gruppe abhängig ist:
policy-map SDSL2000-Std-Parent
class class-default
shape average 2000000
policy-map HSDPA-Std-Parent
class class-default
shape average 3000000
Diese Policy-Map wird im DMVPN-Tunnel an die Ziel-NHRP-Gruppe gebunden:
interface Tunnel1
description DMVPN-Tunnel Internet
ip nhrp map group HSDPA-Std service-policy output HSDPA-Std-Parent
ip nhrp map group SDSL2000-Std service-policy output SDSL2000-Std-Parent
Für alle Standorte, die diese NHRP-Gruppen verwenden, wird die ausgehende Datenrate auf zwei, bzw. auf drei MBit/s begrenzt.
Für die Standorte, die auch Voice benutzen, muss innerhalb dieser begrenzten Datenrate aber der Voice-Traffic bevorzugt werden. Dafür wird eine hierarchische Policy-Map konfiguriert:
class-map match-all EF-TRAFFIC
match dscp ef
!
policy-map ADSL3000-Voice
class EF-TRAFFIC
priority 256
class class-default
fair-queue
policy-map ADSL3000-Voice-Parent
class class-default
shape average 3000000
service-policy ADSL3000-VoiceHier wird in der Parent-Policy der Traffic auf 3 MBit geshaped. In diesen drei MBit/s wird 256 kBit/s für Voice-Traffic priorisiert. Auch das weitere gewünschte QoS-Verhalten würde in der Child-Policy konfiguriert werden. In dem Tunnel-Interface wird dann auch hier die Parent-Policy an die NHRP-Gruppe gebunden:
interface Tunnel1
ip nhrp map group ADSL3000-Voice service-policy output ADSL3000-Voice-ParentDie Wirkung der QoS-Implementierung kann man dann mit “show dmvpn detail” und “show policy-map multipoint” überprüfen:
HUB-Router#sh dmvpn detail
...
1 80.x.y.z 10.255.255.16 UP 20:38:56 D 10.255.255.16/32
NHRP group: SDSL2000-Std
Output QoS service-policy applied: SDSL2000-Std-Parent
1 80.x.y.z 10.255.255.152 UP 2w5d D 10.255.255.152/32
NHRP group: ADSL3000-Voice
Output QoS service-policy applied: ADSL3000-Voice-Parent
HUB-Router#sh policy-map multipoint
Interface Tunnel1 <--> 80.x.y.z
Service-policy output: ADSL3000-Voice-Parent
Class-map: class-default (match-any)
3643772 packets, 1136319199 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
queue limit 750 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 3744389/1409612078
shape (average) cir 3000000, bc 12000, be 12000
target shape rate 3000000
Service-policy : ADSL3000-Voice
queue stats for all priority classes:
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 1046668/312237672
Class-map: EF-TRAFFIC (match-all)
1045840 packets, 242902872 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: dscp ef (46)
Priority: 256 kbps, burst bytes 6400, b/w exceed drops: 0
Class-map: class-default (match-any)
2597932 packets, 893416327 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Queueing
queue limit 686 packets
(queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0
(pkts output/bytes output) 2697721/1097374406
Fair-queue: per-flow queue limit 171
...Verbleibende potentielle Probleme:
Auch Per-Tunnel QoS löst natürlich nicht alle Probleme. Wenn man z.B. mehrere Hubs hat, die Traffic zu den Spokes senden, dann weiß Hub1 nicht, wieviel Traffic Hub2 sendet. Auch haben die Hubs keine Information, ob die Spokes evtl. durch lokalen Internet-Traffic oder aber durch Spoke-to-Spoke-Kommunikation überlastet sind. Trotzdem kann die Kommunikation mit diesem Modell in vielen Fällen optimiert werden.
Zusätzlich werden einzelne Pakete durch das Shaping evtl. länger zurückgehalten, wodurch sich die Reihenfolge der IPSec-Pakete ändern kann. Der Replay-Buffer der Router muss also deutlich vergrößert oder der Replay-Check gar komplett ausgeschaltet werden:
crypto ipsec security-association replay window-size 1024
no crypto ipsec security-association replay window-sizeCisco IPv6 Feature Parity
Was es bei einigen Cisco Catalysten schon länger gibt, ist jetzt endlich auch bei der neuen Generation der Integrated Services Router (ISR-G2: 1900, 2900, 3900) angekommen:
Cisco IOS: Public-Key-basierte SSH-Logins
Ein lang gehegter Wunsch ist mit IOS 15.0 in Erfüllung gegangen. SSH-Logins mit Public-Key-Authentifizierung:
Leider klappt es bei mir noch nicht … 
Update 06.10.09: Nach anfänglichen Schwierigkeiten läuft es jetzt. Es hat nicht funktioniert, solange ich den Befehl
aaa authorization exec default localin der Konfiguration hatte, um beim Login direkt im Enable-Mode zu landen. Ohne Exec-Authorization hat man aber leider nicht die Möglichkeit, verschiedene User in unterschiedliche Level einloggen zu lassen. Der Wechsel in den Level15 klappt aber mit der direkten Konfiguration auf der vty-Line:
line vty 0 4
privilege level 15Cisco IOS 15.0: Die nächste Runde ist eröffnet
Bisher bin ich davon ausgeganggen, dass die nächste IOS-Version die 12.5 sein soll. Aber inzwischen ist die Version 15.0 verfügbar:
Cisco IOS Software, C180X Software (C180X-ADVIPSERVICESK9-M), Version 15.0(1)M, RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Wed 30-Sep-09 03:28 by prod_rel_team
Aus den Release-Notes:
Cisco IOS Release 15.0(1)M integrates a portfolio of over 2,000 key capabilities spanning multiple technology areas, including Security, Voice, Multiprotocol Label Switching (MPLS), IP Services, and Embedded Management. Key highlights of Cisco IOS Release 15.0(1)M include the following:
• Feature inheritance from Cisco IOS Releases 12.4T and 12.4 Mainline.
• An extended maintenance release (44 months of support) that allows customers to qualify/deploy/remain on the release longer with active bug fix support.
• Rebuilds of Cisco IOS Release 15.0(1)M that contain bug fixes only.
• Cisco IOS Release 15.0M (extended maintenance) releases that delivers incremental new features and hardware support (in addition to supporting features and hardware previously delivered) every 20 months.
Beschreibung der neuen HW- und SW-Features:
http://www.cisco.com/en/US/docs/ios/15_0/release/notes/150MNEWF.html#wp1015067
Der IOS SCP-Server
Das Cisco IOS stellt schon seit geraumer Zeit einen SCP-Server zur Verfügung. Trotzdem beobachte ich immer wieder, daß IOS-Images standardmäßig per TFTP übertragen werden. Und das selbst dann, wenn die Client-Plattform “nativ” scp unterstützt.
Auch wenn die SCP-Server-Implementierung in meinen Augen suboptimal ist (was die Berechtigungen angeht), ist die Benutzung des Servers recht einfach:
- SSH konfigurieren
- Den SCP-Server einschalten
- Authentifizierung und Autorisierung konfigurieren
- Useraccounts anlegen
- Kopieren der Daten vom Client
SSH benötigt public/private keys. Für das Generieren der Keys muss man einen Host- und Domain-Namen konfigurieren. (Es gibt Tricks, ohne einen Domain-Namen auszukommen, aber der läuft nicht auf allen Plattformen). Die Key-Länge sollte mindestens 1024, besser 2048 Bit sein. Neuere IOS-Releases unterstützen sogar bis 4096 Bit. Weiterhin sollte man die Verwendung der älteren SSH-Version 1 verbieten:
hostname MyDevice
ip domain-name example.org
crypto key generate rsa general-keys modulus 2048
ip ssh version 2
ip scp server enable
Für SCP muss der Router so konfiguriert werden, dass der User direkt Lese- und Schreibrechte auf das Flash hat. Dies wird durch die Exec-Autorisierung gemacht:
aaa new-model
aaa authentication login default local
aaa authorization exec default local
Der Benutzer bekommt einen Privilege-Level von 15 per Exec-Autorisierung zugewiesen:
username Admin privilege 15 secret 0 My0wnV3ryS3cur3Passw0rd
Hierbei muss die Syntax genau beachtet werden. Der Speicher- bzw. der Quellort im Router muss komplett angegeben werden (hier “flash:/):
scp Quelldatei User@MyDevice.example.org:flash:/Zielname
Auch wenn ich in diesem Beitrag immer Router geschrieben habe, so gilt dasselbe auch für die Switche. Voraussetzung ist natürlich jeweils ein Crypto-fähiges Image.
Und natürlich gibt es auch bei Cisco eine SCP-Anleitung.
Entschlüsselung von Cisco Passwörtern
Vermutlich gibt es tausende von Programmen, um Cisco-Passwörter vom Typ “7″ in ihre Klartextform zurückzurechnen. Vor kurzem habe ich aber kein passendes für den MAC gefunden. Daher habe ich mich entschieden, kurzerhand selbst eines in Python zu schreiben. Die Funktion der Passwörter habe ich im Beitrag Der Schutz hinter “service password-encryption” im Cisco IOS schon beschrieben.
Das ist dabei herausgekommen:
#! /usr/bin/python
##
## Karsten Iwen
## please send bug-reports, comments or improvements to:
## ki@security-planet.de
##
import sys
ctable = (0x64, 0x73, 0x66, 0x64, 0x3b, 0x6b, 0x66, 0x6f, 0x41, 0x2c,
0x2e, 0x69, 0x79, 0x65, 0x77, 0x72, 0x6b, 0x6c, 0x64, 0x4a,
0x4b, 0x44, 0x48, 0x53, 0x55, 0x42, 0x73, 0x67, 0x76, 0x63,
0x61, 0x36, 0x39, 0x38, 0x33, 0x34, 0x6e, 0x63, 0x78, 0x76,
0x39, 0x38, 0x37, 0x33, 0x32, 0x35, 0x34, 0x6b, 0x3b, 0x66,
0x67, 0x38, 0x37)
if len(sys.argv) == 2:
input = sys.argv[1]
length = len(input)
if length%2 != 0:
print ("!!!")
print ("!!! The encrypted password has an odd number of digits. It should be even!")
print ("!!! So the decrypted password is not complete!")
print ("!!!")
length = length -1
if length < 4:
print ("!!!")
print ("!!! The Input is too short")
print ("!!!")
else:
pos = 2
tpos = int(input[0:2])
pw = ""
while pos < length:
pw = pw + chr( int("0x"+input[pos:pos+2],16) ^ int(hex(ctable[tpos]),16))
pos = pos + 2
tpos = tpos +1
if tpos == 53: tpos = 0
print (pw)
else:
print ("")
print ("cipade.py v1.0")
print ("==============")
print ("cipade (CIsco PAssword DEcoder) 'decrypts' type 7 passwords used in Cisco IOS-configurations")
print ("")
print ("Usage")
print ("=====")
print ("cipade [the type 7 encrypted password]")
print ("")
print ("Written by:")
print ("===========")
print ("Karsten Iwen")
print ("ki@security-planet.de")
print ("http://security-planet.de")
print ("")
Ich vermute, daß man mindestens die XOR-Operation noch etwas eleganter programmieren könnte. Verbesserungsvorschläge werden gerne angenommen.
Das Script muss einfach als "cipade.py" im Suchpfad abgespeichert und als ausführbar markiert werden.
VPNs zwischen Standorten mit überlappenden Adressen
Gerade habe ich eine Anfrage bekommen, wie man denn Netze verbinden kann, wenn auf beiden Seiten der gleiche Adress-Bereich verwendet wird. Als Lösung gibt es verschiedene Ansätze:
- Readressierung
- Erweiterung des Netzes um IPv6
- Double-NAT zwischen den Netzen
Je nachdem wie gut das Netz gepflegt ist, muss das nicht ein zu großer Aufwand sein. Spätestens jetzt könnte das ein Grund sein, um DHCP und DNS konsequent umzusetzen. Wenn die überlappenden Adress-Bereiche durch einen Firmen-Zusammenschluss zustande gekommen sind, dann wird es wohl hierauf hinauslaufen.
Wenn man sich noch nicht mit IPv6 beschäftigt hat, wird dies sicher am längsten dauern um implementiert zu werden. Aber dann sollte die Wahrscheinlichkeit für überlappende Netze relativ klein sein. 
Hierbei werden die mehrfach verwendeten Netze per NAT verborgen. Je nachdem wie viele Standorte den gleichen Adress-Bereich verwenden, kann die Konfiguration und auch das Management dieser Lösung etwas “eklig” werden. Aber gerade wenn unterschiedliche Firmen verbunden werden sollen, ist dies oft die verwendete Lösung.
Dieser Artikel beschreibt die Konfiguration dieses Ansatzes in Verbindung mit VPN-Tunneln.
Das Ausgangs-Szenario:
An beiden Standorten wird das selbe IP-Netz verwendet. Die Lösung beinhaltet, dass beide Standorte ihre IP-Netze per NAT hinter einem anderen Netz “verbergen”. Dieses neue Netz wird dann verwendet, um auf die Geräte der anderen Seite zuzugreifen.
Um die Kombination von NAT und IPSec zu verstehen, muss man sich einfach bewusst sein, in welcher Reihenfolge im IOS die verschiedenen Funktionen abgearbeitet werden: NAT Order of Operation
Wie man sieht, werden die Daten genatted, bevor sie verschlüsselt werden und auf der anderen Seite entschlüsselt, bevor NAT angewendet wird.
Für jede Seite wird jetzt ein freies Netz gewählt (hier 10.111.111.0/24 und 10.222.222.0/24):
Die Source-Adressen des linken Netzes werden in 10.111.111.x übersetzt, die Source-Adressen des rechten Netzes in 10.222.222.x.
Die (relevante) Konfiguration der zwei Router sieht folgendermaßen aus:
hostname R1
crypto isakmp policy 1
encr aes 256
authentication pre-share
group 5
crypto isakmp key Yes,ThisKeyIsNotReallySecret,LongAndRandom address 192.168.2.2
!
crypto ipsec transform-set ESP-AES256-SHA esp-aes 256 esp-sha-hmac
!
crypto map VPN 1 ipsec-isakmp
set peer 192.168.2.2
set transform-set ESP-AES256-SHA
match address CRYPTO-TO-SITE-2
!
interface FastEthernet0/0
description LAN
ip address 10.10.10.1 255.255.255.0
ip nat inside
!
interface Serial1/0
description Connection to Internet
ip address 192.168.1.2 255.255.255.0
ip nat outside
crypto map VPN
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
ip nat inside source static network 10.10.10.0 10.111.111.0 /24
!
ip access-list extended CRYPTO-TO-SITE-2
permit ip 10.111.111.0 0.0.0.255 10.222.222.0 0.0.0.255
hostname R2
!
crypto isakmp policy 1
encr aes 256
authentication pre-share
group 5
crypto isakmp key Yes,ThisKeyIsNotReallySecret,LongAndRandom address 192.168.1.2
!
crypto ipsec transform-set ESP-AES256-SHA esp-aes 256 esp-sha-hmac
!
crypto map VPN 1 ipsec-isakmp
set peer 192.168.1.2
set transform-set ESP-AES256-SHA
match address CRYPTO-TO-SITE-1
!
interface FastEthernet0/0
description LAN
ip address 10.10.10.1 255.255.255.0
ip nat inside
!
interface Serial1/0
description Connection to Internet
ip address 192.168.2.2 255.255.255.0
ip nat outside
crypto map VPN
!
ip route 0.0.0.0 0.0.0.0 192.168.2.1
!
ip nat inside source static network 10.10.10.0 10.222.222.0 /24
!
ip access-list extended CRYPTO-TO-SITE-1
permit ip 10.222.222.0 0.0.0.255 10.111.111.0 0.0.0.255
Wenn aus dem linken Netz das rechte erreicht werden soll, muss natürlich die NAT-Adresse genommen werden. Bei einem Ping vom linken LAN-Interface zum rechten LAN-Interface sieht das dann folgendermaßen aus:
R1#ping 10.222.222.1 source fastEthernet 0/0 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.222.222.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 32/32/32 ms
R1#
*Mar 1 00:49:23.527: ICMP: echo reply rcvd, src 10.222.222.1, dst 10.10.10.1
R2#
*Mar 1 00:49:23.319: ICMP: echo reply sent, src 10.10.10.1, dst 10.111.111.1
Ein entscheidender Nachteil dieser Methode ist, dass diese Adress-Übersetzung immer durchgeführt wird und ein Router mit dieser Konfiguration nicht mehr sinnvoll für andere Verbindungen verwendet werden kann. Diese Translation dürfte eigentlich nur verwendet werden, wenn das gegenüberliegende NAT-Netz angesprochen wird.
Diese Bedingung — die auf der PIX/ASA per Policy-NAT einfach umzusetzen ist — würde auf einem IOS-Router mit einer Route-Map beschrieben werden. Diese Route-Maps können aber leider in einer statischen Translation nicht verwendet werden, wenn ganze Netze übersetzt werden.
Router-Upgrade
Auf die Sekunde genau hätte ich die Angabe nicht einmal benötigt:
File reception completed.
Writing flash:/c870-advipservicesk9-mz.124-15.T9.bin
Write operation will take approximately 116 to 348 seconds
