SSH “in depth”
Im aktuellen IPJ (Internet Protocol Journal) gibt es einen guten und auch detailierten Artikel zu SSH, geschrieben von William Stallings:
Sehr lesenswert!
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 ...
IPv6 TechWiseTV
Bei Cisco gibt es eine TechWiseTV-Episode zu IPv6:
Join Cisco expert Harold Ritter as he provides a technology update, shows best practices, and addresses how to deploy IPv6 in a service provider environment to cope with growing demand (59:18 min.).
Agenda
Is IPv4 Broken? Why Change a System That Works?
IPv6 for Dummies: Layer 2 Deep Exploration
Understanding IPv6 Routing and Security Challenges
Quality of Service and Transition Mechanisms
Planning and Deployment Considerations
Update: Eben sehe ich gerade, dass diese Folge schon über zwei Jahre alt ist. Bis Ende Januar ist sie noch anzuschauen.
Der Weg zur Weisheit
Nur wenige Wege führen zur Weisheit, und den Wenigsten ist dies wohl beschieden …
Für EDVler gibt es aber schon einen Weg, weise zu werden. Im Zuge des IPv6-Zertifizierungs-Prozesses von Hurricane Electric (die Firma hinter tunnelbroker.net, die kostenlose IPv6-Tunnel zur Verfügung stellen) durchläuft man verschiedene Stufen, bis man beim “Sage” angekommen ist und zumindest für dieses Thema eine Form der Weisheit erreicht hat.
Bei dieser Zertifizierung geht es darum, verschiedene Level der IPv6-Erreichbarkeit zu demonstrieren und eine Reihe von Fragen zu IPv6 zu beantworten. Die Sache ist nicht nur sehr informativ, sondern macht auch viel Spaß. Bei dieser IPv6-Erreichbarkeit ist es nicht notwendig, einen Tunnel von HE zu verwenden. Wer einen anderen Tunnel-Provider benutzt oder sogar nativ IPv6 hat (der Glückliche), der kann natürlich ebenfalls mitmachen.
Im folgenden beschreibe ich mein Setup, mit dem ich die verschiedenen Stufen dieser Zertifizierung durchgeführt habe und letztendlich bei der Weisheit angekommen bin:
- Newbie
- Explorer
- Enthusiast
- Administrator
- Professional
- Guru
- Sage
Für diesen ersten Level muss man nur ein paar einfache Fragen zu IPv6 beantworten. Wer sich bisher nicht mit IPv6 auseinandergesetzt hat, der könnte hiermit den Einstieg wagen.
Die Explorer-Stufe erreicht man, wenn man eine IPv6-Verbindung zum Internet hat. Für eine getunnelte Verbindung mit einem Cisco-Router habe ich die Vorgehensweise in einem eigenen Beitrag beschrieben.
Für den Enthusiast muss man einerseits einen IPv6-fähigen Client haben, mit dem man auf das Internet zugreifen kann, andererseits muss man einen Webserver betreiben, der Webseiten per IPv6 ausliefern kann. Die generelle Konfiguration eines Linux-Servers hat Jens Link schon in einer Reihe von Beiträgen beschrieben. Bei mir kamen noch ein paar Punkte hinzu. Zum einen sind meine Dienste (Mail, Web, DNS, etc.) mit OpenVZ virtualisiert. OpenVZ muss also auch für IPv6 konfiguriert sein (alle Systeme sind Debian Lenny):
klio:~# grep ipv6 /etc/sysctl.conf
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1
klio:~# grep IPV6 /etc/vz/vz.conf
IPV6="yes"
Weiterhin muss dem OpenVZ-Gast eine weitere IP-Adresse zugewiesen werden, in diesem Fall eine IPv6-Adresse:
klio:~# vzctl set 123 --ipadd 2001:DB8:1:2:3::1 --save
Diese IPv6-Adresse stammt nicht aus dem Tunnel-Netz, sondern aus dem zusätzlich zugewiesenen “routed /64″-Netz, das man beispielsweise bei tunnelbroker.net bekommt.
Hier könnte man natürlich auch mehrere IP-Adressen zuweisen, um jedem vhost eine eigene IP-Adresse zu geben. Damit könnte man problemlos alle Webpräsenzen mit HTTPS sichern. In meinem Beispiel bekommt die gesamte VM eine IPv6-Adresse, die für alle vhosts verwendet werden kann.
Vor einiger Zeit bin ich vom Apachen auf Lighttpd umgestiegen und bin bisher sehr zufrieden damit. IPv6 ist beim Lighty eine einzige zusätzliche Zeile in der Konfiguration:
root@www2:/# grep ipv6 /etc/lighttpd/lighttpd.conf
server.use-ipv6 = "enable"
Natürlich soll auf die Webpräsenz per FQDN zugegriffen werden, weshalb auch im DNS ein neuer Eintrag vorgenommen werden muss. Während die IPv4-Adresse mit einem A-Eintrag konfiguriert wird, muss die IPv6-Adresse mit einem AAAA-Eintrag konfiguriert werden:
In der Zonen-Datei wird also folgende Zeile aufgenommen:
www IN AAAA 2001:DB8:1:2:3::1
Durch diesen Eintrag in der Zonen-Datei von example.com kann der FQDN nun zu der IPv6-Adresse 2001:470:1f0b:c2c::211 aufgelöst werden und der Webserver kann per IPv6 die Seite für www.example.com ausliefern.
Für diesen Level muss der Mail-Server per IPv6 Mails annehmen können.
In einem einfachen Postfix-Setup wird auch dafür nur eine neue Zeile in der Konfiguration benötigt:
inet_protocols = all
Ebenso muß für den FQDN des Mailservers natürlich ein AAAA-Eintrag hinzugefügt werden.
Um die Professional-Stufe zu erlangen, muss man eine funktionierende Reverse-DNS-Auflösung für den Mailserver haben.
Bei Tunnelbroker.net kann man für sein IPv6-Netz eine Reverse-Delegation anlegen. Damit ist der eigene Nameserver dann für die Reverse-Auflösung zuständig. Hierbei gibt es die Herausforderung, daß in der Zonendatei die Adressen in einer umgekehrten Schreibweise angegeben werden. Aus der Adresse 2001:DB8:1:2:3::1 wird z.B. die Zeichenkette 1.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2. Diese Umrechnung kann man mit dem Befehl “host -n” durchführen:
karstens-macbook-pro:~ karsten$ host -n 2001:DB8:1:2:3::1
Host 1.0.0.0.0.0.0.0.0.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN)
Alternativ kann man sich die Zonendatei bei fpsn.net mit dem Zone-Builder erstellen lassen.
Hier muss der Nameserver selbst AAAA-Einträge haben und per IPv6 erreichbar sein. Das ist im Prinzig die gleiche Arbeit wie beim Webserver weiter oben. Zusäzlich muss beim Bind9 die Option “listen-on-v6″ gesetzt sein.
Die letzte Stufe. Hierfür benötigt man für seinen Nameserver einen IPv6-Glue-Record. Dieser wäre notwendig, wenn Systeme, die kein Dual-Stack haben und nur noch IPv6 benutzen, eine Namensauflösung durchführen wollen. Das ist zwar heutzutage nun wirklich noch nicht relevant, gehört aber halt zu einer kompletten DNS-Konfiguration dazu. Meine Domain habe ich bei Hosteurope registriert, die dies nicht automatisiert eintragen können. Dort musste ich ein Ticket öffnen und um eine manuelle Eintragung bitten. Diese war dann auch schon nach kurzer Zeit erledigt und der letzte Test der Zertifizierung war bestanden.
Natürlich ist mit IPv6 nicht alles automatisch besser. Einige Baustellen bleiben schon. Da ist zum Beispiel die Zugriffs-Geschwindigkeit per Tunnel ein gutes Stück langsamer als per IPv4. Weiterhin gibt es wohl in der einen oder anderen Software doch noch einige Bugs. Unter PHP funktioniert beispielsweise die fopen()-Funktion nicht mehr, die in Wordpress an einigen Stellen benötigt wird. Aber das kann mit der Zeit natürlich nur besser werden.
Viel Spaß an alle, die ihre Server auch per IPv6 erreichbar machen wollen.
Remote Triggered Black Hole Filtering
“Remote Triggered Black Hole Filtering” ist ein Mechanismus, der in Service-Provider-Netzen eingesetzt wird, um (D)DoS-Angriffe besser handeln zu können. Das erste Mal habe ich davon 2004 auf einer Service-Provider-Security-Session auf der Cisco Networkers gehört und fand die ganze Thematik extrem spannend (BGP als Werkzeug für die Security). Jetzt ist ein neuer RFC zu diesem Thema erschienen:
RFC 5635: Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF)
Dieser ergänzt die Informationen aus einem 2004er RFC:
RFC 3882: Configuring BGP to Block Denial-of-Service Attacks
Weiterhin befindet sich bei PacketLife eine sehr gute Einführung zu dem Thema:
PacketLife: Remotely-Triggered Black Hole (RTBH) Routing
The Internet is broken. Let’s fix it.
Das schreibt Larry Roberts in einem Bericht der aktuellen IEEE Spectrum. Und der muss es wissen. Immerhin hat er mit seiner Firma Anagran einen Router gebaut, der das Problem lösen soll 1967 den Vorläufer des Internets — das ARPANET — mit entworfen.
Seine These ist, dass heutige Router für das aktuelle Datenaufkommen nicht gerüstet sind, da sie immer noch jedes Paket einzeln betrachten und nicht in der Lage sind, Flows zu erkennen. Seine Beschreibung, wie ein heutiger Router funktionieren müsste, erinnert dann auch sehr an das Fast-Switching, wie es z.B. Cisco früher implementiert hat. Abgelöst wurde das durch CEF, unter anderem deshalb, weil das Fast-Switching nicht skalierte. Beim Fast-Switching wird über Teile des Paket-Headers ein Hash-Wert berechnet und daraus bestimmt, wie alle weiteren Pakete des Flows geswitcht werden können (“route first, switch many”). Im Campus-LAN war das eine gute Sache, im Internet mit seiner Vielzahl an unterschiedlichen Flows ging das nicht mehr. CEF hat das Problem bei Cisco gelöst.
Larry Roberts hat diese Art des Routings und Switchings wieder aufgenommen, da heute der dafür benötigte Speicher um ein Vielfaches günstiger ist, als damals. Dabei ist das Gerät FR-1000 herausgekommen, das für den Service-Provider Aggregation-Bereich bestimmt ist und 80 GBit/s (vermutlich Marketing-Math) verarbeiten kann. Das Ganze soll dann nur 300 Watt verbrauchen, was schon eindrucksvoll wäre.
Dabei soll diese Maschine die Flows auch sehr umfangreich manipulieren können. Es kann z.B. kontrolliert werden, dass P2P-Anwendungen mit vielen Flows nicht zu viel Bandbreite verbrauchen.
Insgesamt ist das eine sehr interessante Entwicklung und ich bin gespannt, was da noch so alles kommt.
Per Tunnel ins IPv6-Internet
Da bei vielen DSL-Anbietern IPv6 ein Fremdwort ist, muss man sich oft mit einem Tunnel behelfen. Die Erweiterung einer IOS-Umgebung (Router und Switch) um IPv6 ist zwar nicht sehr aufwendig, umfasst aber doch etliche Schritte, die ich hier beispielhaft zusammenfasse.
Dabei gehe ich von der folgenden Umgebung aus:

Beispiel-Netzwerk
Die notwendigen Schritte:
- Registrieren eines IPv6-Tunnels bei einem Tunnel-Broker:
- Tunnelkonfiguration auf dem IOS-Router
- Anpassungen bei der Verwendung dynamischer IP-Adressen
- Konfigurieren der Firewall
- Konfigurieren der weiteren Router-Interfaces
- Einbinden des internen Switches
Sehr leicht hat man die Einrichtung bei dem (kostenlosen) Anbieter Hurricane Electric: http://tunnelbroker.net/
Dort muss man sich registrieren und bekommt seine Zugangsdaten per Mail zugesendet. Nachdem man sich angemeldet hat, kann man einen neuen Tunnel konfigurieren:

In dem dann folgenden Dialog wird die eigene IPv4-Adresse eingetragen. Weiterhin wird angegeben, wo der Tunnel im Internet terminiert werden soll. In Deutschland bietet sich evtl. Frankfurt an.

Um den Tunnel einrichten zu können, muss der Router, über den man sich ins Internet verbindet, anpingbar sein! Wenn das gewährleistet ist, kann der Dialog mit “Submit” abgeschlossen werden.
In der dann folgenden Bestätigung wählt man die “Tunnel Details” aus, wo man sich noch Beispielkonfigurationen für verschiedene Systeme ausgeben lassen kann. Standardmäßig bekommt man ein /64er Netz. Wenn man hinter dem Router noch mehr Infrastruktur hat (wie in diesem Beispiel), muss man noch das “Routed /48″ aktivieren:

Die grundsätzliche Router-Konfiguration ist recht simpel und kann als Vorlage von der obigen Webseite generiert werden:
interface Tunnel0
description Hurricane Electric IPv6 Tunnel Broker
no ip address
ipv6 address [die zugewiesene /64-Adresse ]
ipv6 enable
tunnel source Dialer0 !!! <<-----
tunnel destination [Der ausgewählte Tunnelserver]
tunnel mode ipv6ip
end
!
ipv6 route ::/0 Tunnel0
Abweichend von der vorgeschlagenen Konfiguration habe ich die "tunnel source" auf das verwendete Dialer-Interface geändert. Damit ist die Konfig unabhängig von der konfigurierten oder dynamisch empfangenen IP-Adresse.
IPv6 muss auch noch global eingeschaltet werden:
ipv6 unicast-routing
ipv6 cef
Die Access-Liste auf dem Public-Interface (Dialer0 bei mir) muss wie oben beschrieben anpingbar sein. Das lässt sich auch auf die richtige Source-IP (66.220.2.74) eingrenzen. Weiterhin muss das IP-Protokoll 41 für den Tunnel erlaubt sein:
gw#sh ip access-lists interface Dialer 0 | i 41|icmp
40 permit icmp any any echo (12 matches)
50 permit 41 any any (3252 matches)
Wenn man eine dynamsiche IP-Adresse hat, dann muss der Tunnel für jede neue IP neu registriert werden. Sehr einfach geht das mit einem EEM-Script von der Cisco EEM Scripting Community (danke an meinen Blogger-Kollegen Jens Link für den Tip):
Dieses Script wird heruntergeladen und muss um die eigenen Tunnel-Parameter ergänzt werden:
set user "USER_ID"
set md5pass "MD5-PASSWORD"
set tid "TUNNEL-ID"
Die User-ID ist nicht der Login sondern die Zeichenkette, die nach dem Login auf der Tunnelbroker.net-Seite zu sehen ist (32 Stellen).
Die Tunnel-ID ist die "Global Tunnel ID" aus den Tunnel-Details der Tunnelbroker.net-Seite.
Das MD5-Password ist das eigene Password, das mit MD5 gehashed wird. Auf dem Mac kann dafür das Programm "md5" verwendet werden, jedes andere anständige Betriebssystem bringt sicher ein entsprechendes Tool mit:
karstens-macbook-pro:~ karsten$ md5 -s "Mein Password"
MD5 ("Mein Password") = 4d3b73493102972e8b989fa5b563b150
karstens-macbook-pro:~ karsten$
Dieses Script wird ins Flash des Routers geladen und muss für den Embedded Event-Manager (EEM) aktiviert werden:
event manager directory user policy "flash:/"
event manager policy ipv6-tunnel-update.tcl type user
Der erste Befehl gibt an, wo die Scripte liegen, der zweite meldet das gerade hochgeladene Script im System an.
Als Nächstes steuert man, wann man die Aktualisierung der IP vornehmen möchte. Dafür habe ich das Script so modifiziert, dass es die Syslog-Ausgaben überwacht und immer dann aktiv wird, wenn der Dialer an das Ausgangs-Interface gebunden wird (ich habe nur einen Dialer im System, daher kann ich das recht einfach halten):
::cisco::eem::event_register_syslog pattern "%DIALER-6-BIND" priority all
namespace import ::cisco::eem::*
namespace import ::cisco::lib::*
set url "http://ipv4.tunnelbroker.net"
set php "ipv4_end.php"
set ip "ipv4b=AUTO"
set user "USER"
set md5pass "PASS"
set tid "TUNNEL-ID"
append url "\/$php\?$ip\&pass=$md5pass\&user_id=$user\&tunnel_id=$tid"
after 5000
if {[catch {http::geturl $url -queryblocksize 50 -type "text/plain" } token]} {
action_syslog priority info msg "http request failed"
} else {
action_syslog priority info msg "Response: [http::data $token]"
}
exit 0
Damit wird die neue IP-Adresse auch bei einem Router-Neustart registriert, was das Original-Script nicht macht.
Natürlich wird man auch für IPv6 eine Firewall aktivieren. Hier offenbart sich dann leider das Grauen bei Cisco. Zum einen unterstützt die Zone-Based-Firewall kein IPv6, und auch die traditionelle IOS-Firewall (CBAC) unterstützt nur TCP, UDP, ICMP und FTP. Keine weiteren Protokolle und auch keine Erweiterungen, wie das Inspizieren von Router-eigenem Traffic.
Als erstes wird die FW-Policy angelegt und im Tunnel aktiviert:
ipv6 inspect name FW tcp
ipv6 inspect name FW udp
ipv6 inspect name FW icmp
ipv6 inspect name FW ftp
!
interface Tunnel0
ipv6 inspect FW out
Als Nächstes muss der eingehende Traffic gefiltert werden. Dabei muss man aufpassen, kein einfaches "deny ipv6 any any" zu konfigurieren, da dann das Neighbor-Discovery nicht mehr funktioniert. So könnte es aber aussehen:
ipv6 access-list OUTSIDE-IN-v6
permit icmp any any nd-na
permit icmp any any nd-ns
deny ipv6 any any
!
interface Tunnel0
ipv6 traffic-filter OUTSIDE-IN-v6 in
Aus dem zugewiesenen /48er Netz wird jedem Netz ein Subnet zugewiesen. Welche Subnet-Adressen man nehmen könnte, habe ich hier schon mal angedeutet. Da alle diese Netze die ersten 48 Bit gemeinsam haben, kann man sich die Konfiguration mit Hilfe der "General-Prefixes" erleichtern. Diese haben einen Namen (hier HE1) und beinhalten die ersten 48 Bit der IP-Adresse.
ipv6 general-prefix HE1 2001:aaaa:bbbb::/48
Auf den Interfaces kann bei der Konfiguration der IP-Adressen dieser Prefix referenziert werden:
interface Vlan250
ipv6 address HE1 ::250:0:0:0:1/64
ipv6 enable
Mit dieser Konfig kündigt sich der Router automatisch an, und der PC sollte sich mit einer IPv6-Adresse selbst konfigurieren. Die Funktion kann per Ping ("ping6 ipv6.google.com") oder per Webbrowser ("http://ip6.me") überprüft werden.
Um auf dem verwendeten Cisco Catalyst 3560 IPv6 konfigurieren zu können, muss der Switch erst vorbereitet werden. Das Default-"Switch Database Management-Template" unterstützt kein IPv6:
c3560(config)#sdm prefer dual-ipv4-and-ipv6 default
Je nachdem, was man mit seinem Catalyst alles machen möchte, ist evtl. auch ein anderes Template nötig. Diese sind im Configuration-Guide beschrieben. Dieser Befehl taucht später nicht in der Konfiguration auf, kann aber mit "sh sdm prefer" kontrolliert werden.
Der Rest der Konfiguration ist dann dem Router sehr ähnlich. IPv6 aktivieren, General-Prefix konfigurieren und Interfaces mit einer IPv6-Adresse versehen:
ipv6 general-prefix HE1 2001:aaaa:bbbb::/48
ipv6 unicast-routing
!
interface Vlan250
ipv6 address HE1 ::250:0:0:0:2/64
!
interface Vlan255
ipv6 address HE1 ::255:0:0:0:1/64
Der Router muss jetzt natürlich noch die internen Netze lernen und der Switch eine Default-Route bekommen. In einem kleinen Netz reichen dafür ohne weiteres statische Routen, die mit "ipv6 route" anstelle "ip route" konfiguriert werden. Bei Bedarf kann man natürlich auch RIP, OSPF, EIGRP oder IS-IS benutzen.


