RIP Cisco IPS

Schon lange hat man auf diesen Tag gewartet, jetzt ist er gekommen. Cisco schickt das „legacy IPS“ aufs Altenteil. Und das komplett:

Product Migration Options
This end-of-life announcement covers the entire Cisco IPS Family, including all hardware, software, and licenses, with no exceptions. The IPS software also includes management applications: IPS Device Manager (IDM) and IPS Manager Express (IME).
Cisco IPS Appliance 4xxx customers are encouraged to migrate to the Cisco FirePOWER Appliance.
Cisco ASA IPS Module 5xxx customers are encouraged to migrate to Cisco ASA with FirePOWER Services.

In dem EOS/EOL-Anouncement wird das IOS-IPS nicht erwähnt. Da das im IOS integriert ist, wäre es vermutlich ein zu großer Aufwand, das gegen eine FirePOWER-Implementierung zu ersetzen.
Update: Es ist aktuell geplant, das EOS/EOL des IOS-IPS in ca. einem Jahr bekanntzugeben.

Das komplette Anouncement ist hier zu finden:
http://www.cisco.com/c/en/us/products/collateral/security/ips-4200-series-sensors/eos-eol-notice-c51-733186.html

Artikel weiterverbreiten

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

OS X Yosemite

Die neue OS X Version läuft jetzt seit über einer Woche auf einem meiner Macs und ich bin nicht nur positiv angetan, sondern auch wirklich überrascht. Es funktioniert einfach (fast) alles … Während man bei älteren Major Upgrades doch besser auf die .2 oder .3 Version gewartet hat, kann man diese Version meiner Meinung nach gleich installieren.
Was gibt es zu dieser Version zu erwähnen:

  • Java muss nach dem Update neu installiert werden, für OS X 10.10 steht nur Java 8 zur Verfügung. Meine wichtigste Java-Anwendung, der ASDM (zumindest in recht neuen Versionen) funktioniert anstandslos. Probleme macht leider aus irgend einem Grund die JRE, wenn man aber das JDK installiert läuft alles wie es soll.
  • Der Cisco AnyConnect Client funktioniert (Version 3.1.05187 unterstützt OS X 10.10 offiziell). Das hat mich wirklich gewundert. Bei den letzten OS X Updates kam es mir vor, als wenn Cisco regelmäßig von den neuen Versionen überrascht wurde …
  • Shimo (mein VPN Session-Manager, den ich für EasyVPN und openVPN verwende) funktioniert ohne Probleme. Genau so läuft der Fortinet VPN-Client.
  • Die Mail-Plugins von Chungasoft (ich habe Face2face und ForgetMeNot) laufen problemlos, genau so Letter Opener Pro von Creative in Austria.
  • VMware Fusion läuft auch in der 6er Version gut. Das Update auf die 7er ist also nicht zwingend notwendig.
  • Zwei wichtige Productivity-Tools sind für mich der TotalFinder und Default Folder X  Auch diese beiden System-Tools laufen ohne Probleme.
  • Bisher kommt es mir nicht so vor, dass Yosemite langsamer als Mavericks in der Bedienung wäre. (Fast) alles läuft recht flüssig.
  • Gefühlt schlechter wurde der Zugriff auf Volumes mit sehr vielen Ordnern und Dateien. Unter Mountain Lion war z.B. der Zugriff auf externe Platten mit tausenden von Ordnern und Dateien noch recht flüssig, mit dem Wechsel auf Mavericks wurde das deutlich langsamer. Jetzt mit Yosemite gibt es noch einmal längere Wartezeiten. Das ist aber auch der bisher einzige Negativ-Punkt, der mir auffällt.
  • Weitere kleine Enttäuschung: Die unter Yosemite verwendete OpenSSH-Version ist wie unter Mavericks auch schon die 6.2p2. Interessante Crypto-Erweiterungen der neueren OpenSSH-Version sind daher nicht verfügbar.
  • Das GPGMail-Plugin ist leider auch noch nicht für Yosemite verfügbar. Für Maverics war dieses Plugin sehr schnell angepasst, für Yosmite wird die neue Version in ein paar Wochen erwartet. Diese wird dann nicht mehr frei verfügbar sein, sondern kostenpflichtig sein. Schade, dass Apple das nicht direkt in die Mail-Anwendung integriert. Auch, wenn PGP nicht mehr ganz state-of-the-art ist.
  • Endlich hat Apple einen Security-Bug geschlossen, den ich (und anscheinend einige andere) vor längerer Zeit schon gemeldet habe. Dafür wurde ich sogar im Security-Advisory erwähnt. Damit könnte ich mir doch jetzt auch „Security-Researcher“ auf die Visitenkarte drucken … ;-)

Die offizielle Aufzählung der Yosemite-Neuerungen ist bei Apple verfügabr:

http://help.apple.com/osx-yosemite/whats-new/from-mavericks

Artikel weiterverbreiten

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

Die neue Cisco AnyConnect Lizenzierung

Ein großer Vorteil der Cisco Remote-Access VPN-Lösung war bisher, dass die Lizenzierung recht einfach war und nicht pro  PC bezahhlt werden musste, auf dem der AnyConnect Client installiert war. Natürlich gab es auch Ärgernisse, z.B. dass AnyConnect Essentials und AnyConnect Premium nicht gemischt werden konnte.

Mit den aktuellen Änderungen für den neuen AnyConnect 4 wird zwar letzteres möglich sein, allerdings wird das gesamte Lizenzmodell deutlich aufwendiger. Was sich alles ändert:
Es gibt drei neue Lizenzstufen:

  • Plus Subscription
  • Plus Perpetual
  • Apex Subscription

Subscription heißt, dass man die Lizenz mit Laufzeiten von einem, drei und fünf Jahren erwerben kann. Die Lizenzierung des Headend Termination Devices (z.B. die ASA) ist unabhängig davon.
Im AnyConnect Plus sind die folgenden Features enthalten:

  • VPN
  • per App VPN (das ist neu in v4)
  • Web Security für CWS und WSA
  • Network Access Manager

Mit Ausnahme des neuen “per App VPNs” sieht das also ziemlich nach den bisherigen Features aus.
In der neuen AnyConnect Apex Lizenz kommen die folgenden Features dazu:

  • Posture
    Das gab es zwar vorher schon, neu ist aber, dass der AnyConnect Client jetzt auch für die ISE ab der kommenden Version 1.3 benutzt werden kann. Der alte NAC Posture Agent ist nicht mehr notwendig. Das ist eine Änderung, die schon lange überfällig ist. Erstaunlich, dass mir auf der diesjährigen Cisco Networkers von einem Cisco-Mitarbeiter noch gesagt wurde, dass dies auf absehbare Zeit nicht zu erwarten sei. 
  • Next Generation Crypto / Suite B
    Für Firmen, die für anständige Crypto extra Geld verlangen fallen mir viele Worte ein. Die könnte aber alle Einfluss auf potentielle Altersbeschränkungen dieser Seite haben …
  • Clientless VPN
    Was früher per AnyConnect Premium auf dem Headend Device lizenziert wurde, ist jetzt also von der Client-Lizenz abhängig.

Mit dem neuen AnyConnect benötigt jeder Client eine Lizens:

The number of Cisco AnyConnect licenses needed is based on all the possible unique users that may use any Cisco AnyConnect service. The exact number of Plus or Apex licenses should be based on the total number of unique users that require the specific services associated with each license type.

Die kleinste Lizenz-Stufe ist jetzt für 25 Clients. Für mein Setup mit zwei Macs und auf jedem Mac drei VMs mit XP/Win7/Win8 brauche ich also schon acht Lizenzen.

Was lange überfällig war, ist dass verschiede Versionen gemischt werden können:

Cisco AnyConnect Apex and Plus licenses can be mixed in the same environment.
The number of Plus licenses can be smaller or greater than the number of Apex licenses.

Das Lizens-Management bringt uns eventuell noch ein paar „Herausforderungen“ …

When a Cisco ASA is used Cisco AnyConnect, your production activation key (PAK) for Plus or Apex must be registered to the serial number of each individual Cisco ASA via the Cisco License Management portal.

Wie das genaue Handling sein wird, vor allem wenn man Szenarien hat, bei denen ein Client auf viele verschiedene ASAs zugreift, dass muss sich noch zeigen. Ich hoffe, dass es da keine Probleme geben wird.

Die genaue Beschreibung des neuen Lizenzmodells gibt es im Cisco AnyConnect Ordering Guide.

Artikel weiterverbreiten

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

Rückkehr des IPJ

Das Internet Protocol Journal war eines der besten Publikationen im Netzwerk-Sektor. Deshalb war ich recht enttäuscht als dieses im letzten Jahr eingestellt wurde. Um so erfreulicher, dass das IPJ mit neuen Sponsoren neu aufgelegt wurde. So habe ich meine Ausgabe am Wochenende im Briefkasten gehabt.
Noch ist auf der neuen Webseite noch nicht zu finden, wie die Print-Ausgabe aboniert werden kann. Die Online-Version kann aber — wie früher auch — online herunter geladen werden.
Die Haupt-Themen der aktuellen Ausgabe sind

  • Gigabit Wi-Fi
  • A Question of DNS Protocols
Artikel weiterverbreiten

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

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 sowohl unter Mavericks und Yosemite verwendeten OpenSSH-Version 6.2p2) sollten 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.

Nächste Seite »