SSH-Client-Konfiguration unter MacOS

Beim letzten Beitrag zur SSH-Konfiguration unter Cisco IOS und Cisco ASA fiel mir noch ein, dass man über sinnvolle Anpassungen der Client-Konfiguration auch mal schreiben sollte. Zumindest unter MacOS (und mindestens auch unter Debian und älterem Ubuntu Linux) wird standardmäßig nicht immer die optimale Kryptographie verwendet.
Die SSH-Parameter können an zwei Stellen konfiguriert werden:

  • systemweit unter /etc/ssh_config
  • per User unter ~/.ssh/config

In der systemweiten SSH-Config befinden sich z.B. die folgenden drei Zeilen, die weite Teile der verwendeten Kryptographie bestimmen (genauer gesagt zeigen sie die Defaults):

#Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
#KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
#MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-sha1-96,hmac-md5-96,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96

Was kann/sollte man ändern:

Ciphers

Wer keine legacy Systeme zu pflegen hat, der könnte alle nicht-AES ciphers entfernen. Aber Geräte wie 2950 Switche sind halt auch noch ab und an anzutreffen. Daher muss man in so einem Fall 3des-cbc auch konfiguriert haben. Die Cipher-Zeile könnte dann folgendermaßen aussehen:

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc

Laut Manpage (und basierend auf der unter Mavericks verwendeten OpenSSH-Version 6.2) sollten zwar auch die moderneren GCM-Typen unterstützt sein. Wenn die konfiguriert sind, meldet der SSH-Client aber „Bad SSH2 cipher spec“.
Beim Zugriff auf Cisco Router und Switche kommen typischerweise die CBC-Versionen zum Einsatz, da CTR erst ab IOS 15.4 unterstützt ist.

KexAlgorithms
Hier wird der Key-Exchange gesteuert. Meine Konfig-Zeile auf dem Mac ist die folgende:

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

Die ElipticCurve Algorithmen habe ich entfernt, da diese im Verdacht stehen Backdoors zu beinhalten. Die vermutlich vertrauenswürdige curve25519 von D.J. Bernstein ist erst in OpenSSH 6.6p1 enthalten. Diese werde ich bei Verfügbarkeit mit aufnehmen. Als letztes in der Zeile ist weiterhin ein Group1-Exchange (768 Bit), der für Legacy-Geräte benötigt wird.

MACs
Am meisten stört mich, dass eine MD5-Methode die höchste Priorität hat, gefolgt von einer SHA1-Methode. Da sollte die Reihenfolge angepasst werden:

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

Interessant sind die etm-MACs. Dazu ein kleiner Ausflug in Message Authentication Codes. Die Protokolle SSL, IPsec und SSH verwenden standardmäßig verschiedene Methoden um die Daten zu verschlüsseln und die Integrität zu sichern:

  • SSL: mac-then encrypt. Dabei wird erst der MAC gebildet, dann werden Daten und MAC verschlüsselt.
  • IPsec: encrypt-then-mac. Dabei werden die Daten erst verschlüsselt und dann darüber der MAC gebildet.
  • SSH: encyrpt-and-mac. Die Daten werden verschlüsselt, die MAC wird aber über die Klartextdaten gebildet.

Es hat sich herausgestellt, dass von diesen drei Optionen die von IPsec verwendete Methode die sicherste ist. Diese encrypt-then-mac (etm) Verfahren können auch bei SSH verwendet werden.

Was hat sich jetzt beim Zugriff auf ein IOS-Gerät geändert? Ohne diese Anpassungen sieht die SSH-Session so aus (auf einem Cisco 3560 mit IOS 15.0(2)SE5):

c3560#sh ssh
Connection Version Mode Encryption  Hmac	 State	            Username
1          2.0     IN   aes128-cbc  hmac-md5     Session started   ki
1          2.0     OUT  aes128-cbc  hmac-md5     Session started   ki

Es wird aes-128-cbc mit einem MD5-HMAC verwendet. Nach den Änderungen ist die Krypto etwas besser (im Rahmen der Möglichkeiten des IOS):

c3560#sh ssh
Connection Version Mode Encryption  Hmac	 State	           Username
0          2.0     IN   aes256-cbc  hmac-sha1    Session started   ki
0          2.0     OUT  aes256-cbc  hmac-sha1    Session started   ki

Hier noch einmal die resultierende ~/.ssh/config:

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc,3des-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

Update:
Nach einigem Nachdenken kam ich zu dem Ergebnis, dass mir die Aufnahme der Legacy-Verfahren in die Config-Datei irgendwie nicht gefällt. Daher habe ich diese wieder rausgeschmissen und gebe bei der Verbindung zu älteren Geräten die benötigte Crypto direkt an. Hier ein Beispiel für den Zugriff auf einen 2950:

ssh -l ki 10.10.10.200 -o Ciphers="3des-cbc" -o KexAlgorithms="diffie-hellman-group1-sha1"

Und hier die angepasste ~/.ssh/config:

Ciphers aes256-ctr,aes128-ctr,aes256-cbc,aes128-cbc
KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,hmac-sha1

Weitergehende Verbesserungsvorschläge werden gerne angenommen.

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

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
Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Das Erste und die IP-Adressen

Ja, Telefonica gibt mir kein IPv6, aber dann will ich wenigstens diese „IPv4,5″ haben, wie es gestern bei der ARD in PlusMinus zu sehen war:

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Was ist Kiva?

Für alle, die Kiva noch nicht kennen gibt es ein neues Werbevideo, das  in gut 1:30 erzählt was Kiva ist. Sehr schön gemacht:

Die Anmeldung ist sehr einfach, und das Team Netzwerft freut sich auch über jedes neue Mitglied.

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

O2 Business-DSL und IPv6

Meine letzte Anfrage beim Geschäftskunden-Support ist schon wieder etwas her, daher war es mal wieder Zeit nachzufragen. Die Antwort war jetzt nicht viel besser:

einen genauen Zeitplan für die Einführung von IPv6 gibt es leider noch nicht. Telefónica Germany wird zu einem späteren Zeitpunkten die IPv6-Unterstützung einführen.

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Windows Server 2012R2-Support im Cisco CDA

Es hat recht lange gedauert, aber im Patch 3 unterstützt der Cisco Context Directory Agent (CDA) endlich auch Windows Server 2012R2.
Der neue Patch ist im Download-Bereich der ASA zu finden.

Artikel weiterverbreiten

Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

Cisco Live 2014 – Nachlese

CL2014Die diesjährige Cisco Live in San Francisco ist zwar schon einige Wochen her (18.-22. Mai; was diesmal sehr früh im Jahr war) und da ich etwas knapp in der Zeit war wollte ich auf eine Nachlese schon verzichten. Aber auf Aufforderung kommt diese jetzt mit deutlicher Verspätung trotzdem.
In diesem Jahr war ich mir nicht sicher, ob ich überhaupt zur Cisco Live wollte, da mir der Termin eigentlich überhaupt nicht passte. Aber da ich über den diesjährigen Cisco Designated VIP-Status die Eintrittsgebühr wieder umsonst bekommen habe, bin ich dann doch hin.
Das späte Buchen hat sich aber zumindest in Hinsicht auf die Hotelpreise als deutlicher Nachteil herausgestellt. Über die Cisco-Webseite waren keine Hotels mehr zu bekommen und auch über die typischen Buchungsseiten war nichts “preiswertes” mehr zu bekommen.
Da ich erst am Samstag angereist bin, habe ich am Sonntag diesmal auch kein Techtorial besucht. Mit JetLag und Müdigkeit bekommt man dann doch zu wenig mit. Das ist auch einer der Gründe warum ich normalerweise versuche lieber zwei/drei Tage vorher anzureisen.

Outback Prime Rib

Outback Prime Rib

So stand diesmal am Sonntag die kostenlose Prüfung und etwas Shoppen mit den auch anwesenden Trainer-Kollegen auf dem Programm. Und da einer der Kollegen zum Glück ein Auto gemietet hatte kamen wir da auch zu unserem obligatorischen Outback-Besuch mit einem hervorragenden Prime-Rib.

Montag bis Donnerstag waren dann wieder viele sehr interessante Sessions:

  • BRKSEC-1030 – Introduction to the Cisco Sourcefire NGIPS
  • Naja, hätte ich mal vorher darauf geachtet, dass dies eine 1000er Session ist. Das war deutlich zuviel Marketing!

  • BRKSEC-2053 – Practical PKI for Remote Access VPN
  • Eine extrem wichtige Session wenn man vor hat AnyConnect-VPNs mit Zertifikaten zu implementieren. Ich habe gehofft, dass schon auf Windows 2012 eingegangen wird, was aber nicht der Fall war. Trotzdem gab es auch hier den einen oder anderen Trick und Kniff der mir sicher mal helfen wird.

  • BRKCRT-2000 – HardCore IPv6 Routing – No Fear
  • Die Session war eine riesige Enttäuschung. Es ging nur und ausschließlich um IPv6 in den Cisco Zertifizierungen vom CCNA bis CCIE. HardCore? Keine Spur! Basierend auf meiner bisherigen Erfahrung werde ich in Zukunft wohl Sessions meiden wenn Scott Morris einer der Presenter ist. Da ist irgendwie nie “Real Life” drin sondern immer nur Zertifizierung.

  • BRKCRT-2206 – Cisco Cyber Security Analyst Specialist Certification
  • Das ist eine sehr interessante neue Zertifizierung, die ich mir als mittelfristiges Ziel mal auf die Liste schreibe.

  • BRKSEC-2042 – Web Filtering and Content Control in the Enterprise
  • Hier wurden die Vor- und Nachteile der verschiedenen Methoden (CWS/WSA/WSE/SF) anhand vieler Merkmale miteinander verglichen. Das war eine sehr gute Übersicht wenn man sich fragt welche Lösung jetzt die richtige wäre. CWS war dabei fast immer führend. Tja, wenn es nicht eine Cloud-Proxy-Lösung wäre …

  • BRKSEC-3001 – Advanced IKEv2 Protocol
  • Eine super Session. IKEv2 habe ich mir bisher komplett im Selbststudium beigebracht. In dieser Session gab es dann die für mich sehr wichtige Bestätigung, dass ich die Änderungen zu IKEv1 richtig gelernt und verstanden habe. Denn es passiert sehr schnell, dass man im Selbststudium etwas falsch versteht und das Falsche verinnerlicht.

  • BRKSEC-2025 – Snort Packet Processing Architecture
  • Interessant, aber hätte deutlich tiefer gehen können.

  • BRKSEC-3032 – Advanced – ASA Clustering Deep Dive
  • Auch wieder ein Highlight. Den Presenter habe ich in der Vergangenheit schon bei “ASA Performance Optimizations” erlebt. Der Mann lebt einfach die ASA und es gab jede Menge Infos zum neuen Clustering.

  • BRKRST-3336 – WAN Virtualization Using Over-the-Top (OTP)
  • OTP ist eine EIGRP-Erweiterung, die ich schon auf der letzten Cisco Live kennengelernt habe. Super interessant. Wird Zeit, dass bei einem Kunden mal wieder eine neue Routing-Implementierung ansteht, bei der das zum Einsatz kommen könnte. Die letzten Implementierungen liefen immer auf OSPF hinaus, obwohl EIGRP lange Zeit mein Lieblings-Protokoll war.

  • BRKRST-2304 – Hitchhiker’s Guide to Troubleshooting IPv6
  • Vor zwei Jahren habe ich diese Session schon einmal gehört und sie war sehr gut. Und da sich beim Thema IPv6 ja doch eine Menge tut werde ich diese Session auch in Zukunft sicher erneut anhören.

  • BRKSEC-3697 – Advanced ISE Services, Tips and Tricks
  • Auch ein Highlight der Networkers. Aaron Woland ist einer der Top-ISE-Leute bei Cisco. Im letzten Jahr war ich auch schon in dieser Session und es gab viel neues zur damals anstehenden Version 1.2. Dieses Jahr gab es zwar auch Wiederholung zum letzten Jahr, aber auch viel Neues und Infos zu der kommenden Version 1.3.

  • BRKSEC-3061 – Detect and Protect Against Security Threats, Before It’s Too Late!
  • Und wie in jedem Jahr sind natürlich auch schlechte Sessions dabei. Diese klang vom Titel her zwar recht gut und eine 3000er Session verspricht eigentlich auch Tiefgang, aber nach der Session habe ich mich gefragt was die Presenter einem eigentlich erzählen wollten. Das war irgendwie nix.

    Was gab es so bei der CiscoLive drum herum?

    • Montag
    • Die Keynote mit John Chambers. Ja, ich wiederhole mich, aber ich höre ihm gerne zu. Und wie jedes Jahr fragt man sich was er einem überhaupt gesagt hat … ;-) Auf jeden Fall ging es wie im letzten Jahr auch schon um das “Internet of Everything”, was auch zentrales Thema dieses Jahr war. Weiteres Thema war “Fast IT” Hat er wirklich gesagt, das die Kunden wollen, dass sich die IT-Welt schneller drehen, und die Innovationszyklen schneller werden müssen? Ok, machen wir uns darauf gefasst, dass das Hamsterrad der IT noch einen Gang zulegt.
      In der Certification-Lounge der World of Solutions wurde wieder der Cisco-Badge aufgepeppt und es gab ein paar CCIE-Geschenke. U.a. eine Ersatz-Akku zum Aufladen von Handys. Sehr praktisch, denn so etwas habe ich auch immer beim Rennrad-Fahren dabei. Ein iPhone-Akku hält halt doch keine vier Stunden wenn dabei der Weg getrackt wird.
      Abends war dann das Cisco Designated VIP-Dinner. Es wurden mal wieder sehr leckere Speisen und Getränke aufgefahren, und das erneute Treffen der VIP-Kollegen war sehr schön. Auch gab es wieder ein paar Goodies wie das 2014er VIP-Polo-Shirt oder eine Wanduhr.

    • Dienstag
    • Mittags war die CCIE/NetVet-Reception mit John Chambers. Sehr gefreut hat mich, dass die dieses Jahr nicht parallel zu anderen Sessions stattfand. Und ein alternatives Mittagessen nimmt man ja gerne mit. Das “normale” Mittagessen waren immer die abgepackten Sandwich-Boxen die zwar ok waren, aber halt auch kein überragender Gaumenschmaus. Die Reception fand in einem Restaurant gleich neben dem Convention-Center statt. Als ich aus dem Center kam war mein erster Gedanke “oh, was ist das denn für eine riesige Schlange; die armen müssen in der Sonne schwitzen”. Ok, eine Minute später habe ich gemerkt, dass das die Warteschlange der CCIE/NetVets war. Ein paar hundert Leute und beim Einlass nur eine Person die kontrolliert und einer der die Sammle-Pins verteilt. Aber ans Schlange stehen sollte man sich sowieso noch gewöhnen …
      Drinnen war es dann mehr als voll, was beim Essen nicht so sehr gestört hat. Als es in die Diskussion mit John Chambers ging war aber deutlich zu erkennen, dass dieser Laden viel zu klein war. Wer sich nicht direkt in der Mitte oder aber neben einem der Lautsprecher postieren konnte hat halt nicht viel mitbekommen. Ein Teil der Diskussion hat etwas widergespiegelt was als Gerüchte in letzter Zeit ab und an zu hören ist. Er werde im ersten Jahr nach seiner CEO-Zeit erst einmal überhaupt nichts machen. Ich bin schon gespannt wie irgendwann eine Cisco ohne John Chambers aussehen wird und was sich z.B. mit Sachen wie dieser immer sehr interessanten CCIE/NetVet Reception ändern wird.
      Abends war die CCIE-Party in der California Academy of Sciences. Mit Bussen wurden wir dort hingebracht und die Schlange zum Eingang war riesig. Zumindest für uns, die wir nicht-CCIEs als Gäste mitgebracht haben. Dann konnte man nämlich nicht direkt hinein. Trotzdem wie immer sehr leckeres Essen und viel Interessantes anzuschauen.

    • Mittwoch
    • Der Customer Appreciation Event fand im AT&T-Park statt, das Stadion in dem die San Francisco Giants normalerweise ihre Siege einspielen. Der Eintritt war mal wieder abenteuerlich. Die ca. 15000 Leute durch eine viel zu kleine Anzahl von Metall-Detecktoren zu bekommen dauerte so lange, dass sich um das Stadion herum eine wirklich gewaltige Schlange gebildet hat. Der Stimmung drinnen hat das nicht geschadet, Lenny Kravitz und Imagine Dragons haben für super Stimmung gesorgt. Und Essen und Getränke? Ja, auch gut und reichlich!

    • Donnerstag
    • Nachmittags gab es die Guest-Keynote. Salman Khan hat von seinem Leben erzählt und wie er die Khan Academy aufgebaut hat. Das war super erzählt und mit diversen Lachern gespickt. Eine tolle Leistung so ein Lern-Portal für jeden auf die Beine zu stellen.

      Am Donnerstag gab es dann aber auch den größten mitleidigen Lacher bzw. eine kleine Enttäuschung. Für das Ausfüllen der Konferenz-Evaluation bekommt man normalerweise ein kleines Geschenk. So hieß die Ankündigung dann auch sinngemäß “Fill out the conference-evaluation and get a Giants-Baseball-Cap”.

      Das Cisco BaseCap

      Das Cisco BaseCap

      Ok, habe ich gemacht und mein Basecap bekommen. Aber kurz nach mir hieß es nur noch “keine Caps mehr verfügbar”. Und der Lacher schlechthin? Für die 25000 angemeldeten Teilnehmer hat Cisco nur 3000 (oder 2000? Ich weiß es nicht mehr) Caps gehabt. Und davon gingen dann auch ein paar hundert ab, denn fast alle vom Staff hatten ja welche auf oder kurz vor Ende noch unter dem Tisch verschwinden lassen. Das gab dann auch einen kleinen Shitstorm, wobei einige öffentliche Kommentare dann ganz schnell wieder verschwunden sind … Das war wirklich traurig.

    Schön war, dass es das Mittagessen an verschiedenen Orten gab. U.a. im Yerba Buena Gardens, was sehr schön war:

    Die Zusammenfassung:
    Es hat wieder enorm Spaß gemacht die Networkers zu besuchen und es war fast durchgehend sehr interessant. Die gesamte Organisation hat aber an vielen Stellen gewirkt, als würde diese Veranstaltung zum ersten Mal ausgerichtet. Und San Francisco hat sich dieses Jahr als Veranstaltungsort einfach als viel zu klein herausgestellt.

    Die nächste Cisco Live findet dann (wie vor zwei Jahren) wieder in San Diego statt, der 7. bis 11. Juni ist schon im Kalender markiert. Ich freue mich jetzt schon wieder.

    Artikel weiterverbreiten

    Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

    Der (fast) perfekte Home-Office-Router

    Gerade habe ich testweise meinen ersten Cisco 866VAE-k9 installiert. Hier beschreibe ich ein paar Eindrücke von diesem Gerät.

    Warum der 866VAE-k9
    Ich wollte einen IOS-Router mit eingebautem VDSL-Modem. Eine Zeitlang hatte ich eine Fritzbox als DSL-Router und Telefonanlage laufen, aber das ist einfach zu unflexibel. Die Fritzbox bleibt zwar die Telefonanlage bis ich da etwas besseres finde, aber als Router wollte ich ein vollwertiges IOS-Gerät haben, das zumindest anständig VPNs beherrscht und auch Policy-Based Routing kann. Zusätzlich benötigte ich DNS-Views um selektiv DNS-Abfragen an den DNS-Server im Büro zu senden. Weiterhin sollte der Router keinen oder zumindest einen sehr leisen Lüfter haben.
    Meine Wahl fiel dann auf den Cisco 866VAE-k9, der ein eingebautes DSL-Modem hat, ohne Lüfter daherkommt und zudem noch recht günstig ist. Meine erste Befürchtung war zwar, dass er am 50 MBit-VDSL überfordert wäre, aber dort wurde ich angenehm überrascht.

    Die VDSL-Konfig
    Die Konfiguration des VDSLs bei diesem Router weicht deutlich von der ADSL-Konfig ab, wie sie auf älteren Geräten durchgeführt wurde. Hier ein kleiner Auszug aus der Konfig:

    controller VDSL 0
     operating mode vdsl2
    !
    interface Ethernet0
     description VDSL Internet Verbindung - VLAN 7 tagged
     no ip address
     no ip route-cache cef
    !
    interface Ethernet0.7
     encapsulation dot1Q 7
     pppoe-client dial-pool-number 1
    !
    interface Dialer0
     description log. WAN-Interface
     dialer pool 1

    Für VDSL erwartet die Telekom die Daten getagged mit VLAN 7. Dafür wird das logische Interface Ethernet0 verwendet, das als physikalischer Port nicht vorhanden ist.

    Die VPN-Konfig
    Die ist nicht weiter erwähnenswert da der Router wie jeder andere IOS-Router konfiguriert wird. Allerdings werden nicht alle VPN-Arten unterstützt. IKEv1 und IKEv2 sind beide supported, Crypto-Maps und VTIs gehen natürlich auch und FlexVPN soll ebenfalls gehen. DMVPN ist anscheinend nicht supported. Mit FlexVPN ist aber ein leistungsfähiger Nachfolger verfügbar. Auch WebVPN ist nicht enthalten, aber das ist bei der angepeilten Zielgruppe wohl auch nicht notwendig.
    Ich habe mein VPN wegen der dynamischen IP-Adresse mit einem Virtual Tunnel Interface (VTI) auf der Spoke-Seite und einem dynamic Virtual Tunnel Interface (dVTI) auf der Hub-Seite konfiguriert.

    Routing-Möglichkeiten:
    Bei dVTIs muss die Aussenstelle mit dynamischem Routing angebunden werden. Da kann es von Nachteil sein, dass der Router kein OSPF und EIGRP unterstützt (der Router benutzt ein Advanced Security Image; diese haben auch bei anderen 800er Routern sehr eingeschränkte Routing-Möglichkeiten). Diese Routing-Protokolle sind unterstützt:

    inet-home(config)#router ?
      bgp  Border Gateway Protocol (BGP)
      odr  On Demand stub Routes
      rip  Routing Information Protocol (RIP)
    
    inet-home(config)#router

    Eine echte Einschränkung sind die angebotenen Protokolle natürlich auch nicht, vor allem da BGP/ODR und RIP noch besser skalieren als EIGRP oder OSPF wenn eine sehr große Anzahl von Aussenstellen vorhanden sind. Ich habe jetzt unidirectional RIP für die Verbindung ins Büro laufen was auch sehr gut funktioniert.

    Geschwindigkeit am Telekom-VDSL:
    Da war ich wie schon erwähnt sehr überrascht. Bei ein paar massiven Downloads steigt die CPU-Last des Routers zwar auf gute 50%, aber dabei erreiche ich Download-Raten von guten 5.2 bis 5.3 MB/s. Mit der FritzBox 7390 habe ich nie über 4.9 bis 5.0 MB/s erreicht.

    Aber natürlich gibt es ein paar Nachteile:

    1. Das Flash: Wir haben 2014 und das Flash ist so klein, dass man nicht einmal ein zweites Image ablegen kann. Das ist einfach nur peinlich!
    2. inet-home#sh flash:
      57344K bytes system flash allocated
      
      Directory of flash:/
      
          2  -rwx    28385048  Jan 31 2014 13:02:11 +01:00  c860vae-advsecurityk9-mz.152-4.M5.bin
          4  -rwx         780  Apr 19 2014 23:10:08 +02:00  vlan.dat
      
      55351296 bytes total (26959872 bytes free)
    3. CPU-Power
    4. Das muss ich noch etwas weiter untersuchen. Aber das Upgrade des Routers auf das neuere IOS 15.2(4)M6a lief über das LAN mit ca, 20 KB/s. Das war die CPU-Auslastung dabei:

      CPU utilization for five seconds: 99%/1%; one minute: 99%; five minutes: 97%
       PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
       234     1367564       10866     125857 97.20% 97.27% 94.18%   4 SSH Process

      Jetzt muss aber vor dem Update wegen des knappen Flashs das alte IOS gelöscht werden. Wenn dann das Update sehr lange dauert und der Router dabei eine sehr hohe Last hat, dann wäre mir etwas mulmig wenn ich das remote durchführen müsste.

    5. Keine VRFs
    6. Ok, für so ein kleines Gerät sollte man das auch nicht erwarten, aber die Trennung von internem und public Routing wäre schon schön!

    Fazit?
    Der Router ist recht günstig und kommt daher natürlich mit einigen Nachteilen. Wenn diese bekannt und nicht zu störend sind, dann ist der 866VAE sicher ein guter Kauf. Wenn etwas mehr Budget zur Verfügung steht würde ich aber doch lieber zu einem 886VAer greifen.

    Artikel weiterverbreiten

    Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

    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.

    Artikel weiterverbreiten

    Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

    Am I running XP?

    Eine Webseite von Microsoft gibt Auskunft:

    Windows XP End of Service

    Puh, Glück gehabt … ;-)

    Artikel weiterverbreiten

    Um Artikel über soziale Netzwerke weiterzuverbreiten, müssen Sie diese aktivieren - für mehr Datenschutz.

    Nächste Seite »