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\u00f6ffentlicht. 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\u00e4ndige” SSH-Konfig f\u00fcr IOS-Ger\u00e4te und die ASA zu zeigen:<\/p>\n
Cisco IOS<\/strong> Etwas Gedanken sollte man sich \u00fcber die Keyl\u00e4nge machen. L\u00e4nger bedeutet zum einen sicherer, aber auch langsamer. Allerdings nicht so langsam, dass es nicht benutzbar w\u00e4re. Damit ist die Entscheidung recht einfach. Allgemeine Hinweise zu minimalen Keyl\u00e4ngen findet man u.a. auf http:\/\/www.keylength.com<\/a><\/p>\n Das RSA-Keypair wird der SSH-Konfig zugewiesen:<\/p>\n Nur SSHv2 erlauben:<\/p>\n Beim Verbindungsaufbau werden die Session-Keys per Diffie-Hellman erzeugt. Das ist standardm\u00e4\u00dfig mit der Gruppe 1 (768 Bit) erlaubt, was nicht mehr state-of-the-art ist. Daher wird eine h\u00f6here 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\u00fcrlich auch sehr sicher ist.<\/p>\n Login-Vorg\u00e4nge sollten protokolliert werden:<\/p>\n Als letztes wird auf der VTY-Line nur SSH erlaubt. Telnet ist damit abgeschaltet.<\/p>\n Was k\u00f6nnte man sonst noch f\u00fcr SSH konfigurieren: Ab und an kommt der Wunsch auf, f\u00fcr SSH nicht den Port TCP\/22 zu verwenden. Das erh\u00f6ht zwar nicht unbedingt die Sicherheit, sorgt aber daf\u00fcr, dass die Logs etwas kleiner bleiben wenn SSH vom Internet aus erreichbar ist:<\/p>\n Wenn der Zugriff \u00fcber ein Interface erfolgt, auf dem eine eingehende ACL konfiguriert ist, dann muss in dieser die Kommunikation nat\u00fcrlich auch erlaubt werden.<\/p>\n Weitere Schutzmechanismen \u00fcber die nachgedacht werden k\u00f6nnen sind Control-Plane-Protection<\/a> und Management-Plane-Protection<\/a> wenn out-of-band Management verwendet wird. Wenn der SSH-Zugriff nicht von “any” ben\u00f6tigt wird, dann sollte f\u00fcr die Lines nat\u00fcrlich auch eine Access-Class konfiguriert werden. Aber auch das ist nicht SSH-spezifisch.<\/p>\n Cisco ASA<\/strong> Die Key-L\u00e4nge ist hier auch von der Plattform abh\u00e4ngig. Die Legacy-ASAs unterst\u00fctzen keine Keys mit mehr als 2048 Bit. Auf den aktuellen -X-Ger\u00e4ten kann aber auch 4096 Bit genutzt werden.<\/p>\n Auch muss der SSH-Zugriff auf der ASA explizit f\u00fcr die Management-IPs erlaubt werden:<\/p>\n 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\u00f6ffentlicht. 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 <\/p>\n
\nEs geht damit los, ein RSA-Keypair zu generieren, das nur f\u00fcr den SSH-Prozess verwendet wird. Daf\u00fcr wird dem Keypair ein Label mitgegeben:<\/p>\ncrypto key generate rsa label SSH-KEY modulus 4096<\/code><\/pre>\nip ssh rsa keypair-name SSH-KEY<\/code><\/pre>\nip ssh version 2<\/code><\/pre>\nip ssh dh min size 4096<\/code><\/pre>\nip ssh logging events<\/code><\/pre>\nline vty 0 4\n transport input ssh<\/code><\/pre>\nip ssh port 7890 rotary 1\nline vty 0 4\n rotary 1<\/code><\/pre>\n
\nF\u00fcr 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:<\/p>\ncrypto key generate rsa modulus 4096\nssh version 2\nssh key-exchange group dh-group14-sha1<\/code><\/pre>\nssh 10.10.0.0 255.255.0.0 inside\nssh 192.0.2.100 255.255.255.255 outside<\/code><\/pre>\n","protected":false},"excerpt":{"rendered":"