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.

    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!

    Artikel weiterverbreiten

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

    High-Tech-Unternehmen DHL

    Eigentlich hätte heute eine wichtige Sendung mit DHL kommen sollen. Ein Blick in die Sendungsverfolgung zeigte dann aber “Rücksendung eingeleitet – Der Empfänger ist unbekannt verzogen”.

    Erstaunlich aber, was mir beim DHL-Kundendienst gesagt wurde:

    • Wenn die Rücksendung einmal eingeleitet wurde, dann kann sie nicht gestoppt werden.
    • Selbst wenn ich zum Paket-Verteilzentrum fahren würde um den Paketwagen dort abzufangen, bekomme ich meine Sendung nicht.
    • Und sie habe auch keine Adressen von den Verteilzentren.

    Der Grund für die Rücksendung war wohl ein fehlendes “b” hinter der Hausnummer. Und das obwohl meine Büronachbarn genau gegenüber heute von DHL beliefert wurden.

    Und ich dachte bisher, nur mit Hermes ist eine Paketzustellung reine Glücksache …

    Artikel weiterverbreiten

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

    Geld für GnuPG

    logo-draft-1Zur Zeit bin ich dabei einen weiteren Teil meiner “alles verschlüsseln”-Strategie umzusetzen. Das wird demnächst auch noch ein eigener Beitrag werden.
    Dazu passend berichtet heute heise.de, dass GnuPG per Crowdfunding Geld einsammeln möchte. Als jemand, der unter anderem auch OpenPGP einsetzt, ist das natürlich eine Sache die ich auch unterstützte. Das Ziel ist zwar schon fast erreicht, aber noch kann man natürlich mitmachen!

    Artikel weiterverbreiten

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

    Wir backen uns ein Netzwerk

    Netzwerkbaeckerei

    Passend zur Adventszeit backen wir uns ein Netzwerk anstelle es wie sonst immer aus realen Komponenten zusammenzubauen. Zusätzlich gibt es ein Gewinnspiel für Netzwerker:

    Die Netzwerftbäckerei zur Weihnachtszeit

    Viel Spaß dabei und schöne Advents- und Weihnachtszeit!

    Artikel weiterverbreiten

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

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

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

    Apple und die Security

    Apple LogoFrüher war die Security von Apple Computern so einfach. Vor der Auslieferung hat Steve Jobs einfach eine Hand voll Feenstaub auf die Macs gestreut und sie wurden quasi unverwundbar. Leider geht das heute nicht mehr. Apple muss für die Sicherheit seiner Systeme mit “normalen” Sicherheitsmechanismen sorgen. Um so ärgerlicher, wenn Security Bugs auch nach mehreren Updates immer noch in der Software enthalten sind:

    Im Juni/Juli (ok, es war schon 2013) hatte ich einen regen E-Mail-Verkehr mit dem Apple Product Security Team über ein Problem mit verschlüsselten Volumes das sich folgendermaßen zeigt:

    1. Auf einer externen Festplatte (in meinem Fall war es eine USB-Platte) wird eine verschlüsselte Partition angelegt (das macht man im Festplattendienstprogramm).
    2. Wenn man diese externe Platte anschließt, wird man nach dem Password gefragt und der vormals verschlüsselte Inhalt ist zugänglich.
    3. Wenn man nicht mehr mit dem Inhalt der Platte arbeiten muss, kann man diese über das Kontextmenü der Partition auswerfen.
    4. Jetzt sollte man annehmen, dass der Inhalt nicht mehr erreichbar ist und das Betriebssystem auch den Schlüssel nicht mehr im Speicher behält. Aber:
    5. Man loggt sich aus und wieder ein (gerne auch mit einem anderen Benutzerkonto).
    6. Die verschlüsselte Partition ist sofort wieder gemountet, ohne dass man erneut ein Password eingeben muss (und das Kennwort war natürlich nicht im Schlüsselbund gesichert).

    Leider ist dieser Fehler immer noch enthalten. Sowohl im danach erschienenen Update 10.8.5, als auch in der neuen Version 10.9 “Mavericks”.

    Artikel weiterverbreiten

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

    Nächste Seite »