Hallo Allerseits. In diesem Post geht es um Einstellungen, welche wir an unseren Routern/Switches vornehmen können, um die Sicherheit unseres SSH-Server zu erhöhen.

Bemerkung: Man kann nie von 100% Sicherheit sprechen. Dennoch kann man die Arbeit für den Angreifer erschweren.

SSH besser als Telnet

Ich will hier nicht all so tief ins Detail gehen, denn in einem separaten Beitrag werde ich einige Sachen im Vergleich Telnet vs. SSH schreiben.

Hier geht es eigentlich darum, dass mit uns Telnet ein Protokoll zur Verfügung steht, welches komplett in Klartext kommuniziert. SSH bietet uns da eine Reihe an Sicherheitseinstellungen, um die Integrität der Verbindung zu schützen. Aber wie richten wir das ein?

Für unser Beispiel werde ich zwei Router nehmen (R1 und R3). Gehen wir die Konfiguration Schritt-für-Schritt durch.

Router – R1

Hostname definieren

hostname R1

Interface einrichten

int gig 0/1
 ip address 213.32.25.1 255.255.255.252
 no shut

Benutzer einrichten

Wir richten zuerst einen Benutzer ein, welcher wir später benutzen werden, um auf diesem Gerät zu verbinden.

aaa new-model

aaa authentication login AUTHE local
aaa authorization exec AUTHE local

username ssh algorithm-type scrypt secret ssh

Ein Enable-Kennwort für den EXEC-Modus

enable algorithm-type scrypt secret cisco

SSH-Keys generieren

crypto key gen rsa general-keys modulus 4096 label mypair

SSH-Version festlegen

ip ssh version 2

Nun ist der SSH-Server auf unserem Netzwerkgerät eingerichtet. Aber, darauf haben wir noch keine Sicherheitseinstellungen vorgenommen. Schauen wir uns diese einwenig detaillierter an

Zusätzliche allgemeine Einstellungen für den SSH-Server

ip ssh time-out 30
login block-for 180 attempts 10 within 60
ip ssh authentication-retries 10
ip ssh logging events
login on-failure log
login on-success log

ip ssh time-out 30: Standardmässig wartet der SSH-Server 60 Sekunden beim Authentifizieren, um die Verbindung mit einem Timeout zu beenden. Dieser Wert ist definitiv zu hoch und sollte auf ein Minimum reduziert werden. Hier kann man sich wie bei vielen Einstellungen darüber streiten. Ist dieser Wert zu tief, werde viele Verbindungen abgebrochen, weil der Benutzer nicht in der Lage war das Kennwort rechtzeitig einzugeben. Hierfür benutze ich persönlich 30 Sekunden.

login block-for 180 attempts 10 within 60: Das device stellt automatisch ein ACL und blockt die Dienste für 180 Sekunden, wenn innerhalb von 60 Sekunden 10 fehlerhafte Anmeldeversuche gab.

ip ssh authentication-retries 10: Wie oft nach dem Passwort gefragt wird, bevor die Verbindung geschlossen wird.

ip ssh logging events
login on-failure log
login on-success log

Wir möchten jedes mal ein Ereignis im Log generieren, wenn jemand versucht sich über SSH auf dem Gerät anzumelden. Und so sieht es nun im Log aus:

*Dec 27 12:17:20.147: %SSH-5-SSH2_SESSION: SSH2 Session request from 213.32.25.2 (tty = 0) using crypto cipher 'aes256-ctr', hmac 'hmac-sha2-512' Succeeded
*Dec 27 12:17:24.317: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: ssh] [Source: 213.32.25.2] [localport: 22] [Reason: Login Authentication Failed] at 12:17:24 UTC Fri Dec 27 2019
*Dec 27 12:17:26.564: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: ssh] [Source: 213.32.25.2] [localport: 22] at 12:17:26 UTC Fri Dec 27 2019
*Dec 27 12:17:26.564: %SSH-5-SSH2_USERAUTH: User 'ssh' authentication for SSH2 Session from 213.32.25.2 (tty = 0) using crypto cipher 'aes256-ctr', hmac 'hmac-sha2-512' Succeeded

SSH Default Port umgehen

Unter Umständen kann man auch den SSH standard TCP-Port auf einen anderen Port verlegen. Cisco stellt dafür folgende

ip ssh port 2222 rotary 1

Somit wird der Port für SSH auf 2222 verlegt

Um die Konfiguration erfolgreich abzuschliessen, müssen wir unter der VTY-Konfiguration den Statement „rotatory 1“ noch eingeben.

Verschlüsselung für die Datenverbindung

Dabei handelt es sich um ein symmetrisches Verschlüsselungsverfahren für die Datenverbindung. Für uns bedeutet das, dass Client und Server über den selben Schlüssel besitzen, um die Daten ent- und verschlüsseln zu können. Ergo, wird der Schlüssel am Anfang des Kommunikationsaufbau ausgetauscht. Um diesen Austausch so sicher wie möglich zu machen, benutzen wir ein „Key Exchange Protocol“. In diesem Fall handelt es sich um Diffie-Hellman (DH). Darüber erfahren wir gleich anschliessend in diesem Text.

R1(config)#ip ssh server algorithm encryption ?
 3des-cbc Three-key 3DES in CBC mode
 aes128-cbc AES with 128-bit key in CBC mode
 aes128-ctr AES with 128-bit key in CTR mode
 aes192-cbc AES with 192-bit key in CBC mode
 aes192-ctr AES with 192-bit key in CTR mode
 aes256-cbc AES with 256-bit key in CBC mode
 aes256-ctr AES with 256-bit key in CTR mode
R1(config)#ip ssh server algorithm encryption aes256-ctr

CTR-Mode (Counter) wird über CBC-Mode vorgeschlagen, da im CTR-Mode verschiedene Vorteile gegenüber CBC gibt:

• Im CBC haben wir Verbreitung von Fehlern, CTR hat das nicht.
• CTR hat einen Initisialisierungsvektor, CBC nicht.

Diffie-Hellman Schlüsselaustausch

Möchte man einen Verschlüsselungsverfahren benutzen, welcher den selben Schlüssel zum ver- und entschlüsseln braucht, dann spricht man von einer symetrischen Verschlüsselung. Der Austausch der Schlüssel darf also nicht in Klartext geschehen, denn so hätten Lauscher die Möglichkeit ihn zu lesen und für das entschlüsseln der Datenverbindung zu benutzen. Um die Geheimhaltung dieser Schlüssel zu garantieren nutzen wir Diffie-Hellman (DH). Auch hier möchte ich an dieser Stelle nicht ins Detail gehen, denn in diesem Post geht es nur darum, die Dienste so sicher wie möglich zu konfigurieren. Man kann sich Tagelang über Kryptoverfahren auseinander setzen.

R1(config)#ip ssh dh min size ?
   2048  Diffie Group 14 2048-bit key
   4096  Diffie Group 16 4096-bit key
R1(config)#ip ssh dh min size 4096

Rekeying

Bei der Benutzung einer symmetrische Verschlüsselung muss, wie oben erwähnt, den Schlüssel zwischen Client und Server ermittelt werden. Wird dieser aber aus irgendeinem Grund kompromittiert, dann ist unsere Verbindung nicht mehr sicher und kann von einem Angreifer entschlüsselt werden. Rekeying heisst die Prozedur einen Schlüssel erneut zwischen Client und Server auszutauschen. Im IOS lässt sich ein „Rekeying“ nach zwei Prinzipien durchführen:

• Zeit
• Datenvolumen

R1(config)#ip ssh rekey time ?
<R1(config)#ip ssh rekey time ?
   <10-1440>  Minutes
 R1(config)#ip ssh rekey volume ?
   <100-4194303>  kilobytes
 R1(config)#ip ssh rekey volume 

ip ssh rekey time 10

Jede 10 Minuten scheint es eine gute Wahl zu sein. Wir können den Rekeying live auf der Console anschauen:

*Dec 28 22:48:19.056: SSH2 0: Initiating rekey based on time
*Dec 28 22:48:19.059: SSH2 0: SSH2_MSG_KEXINIT sent
*Dec 28 22:48:19.087: SSH2 0: SSH2_MSG_KEXINIT received
*Dec 28 22:48:19.088: SSH2 0: kex: client->server enc:aes256-ctr mac:hmac-sha2-512 
*Dec 28 22:48:19.090: SSH2 0: kex: server->client enc:aes256-ctr mac:hmac-sha2-512 
*Dec 28 22:48:19.091: SSH2 0: Using kex_algo = diffie-hellman-group14-sha1
*Dec 28 22:48:19.127: SSH2 0: expecting SSH2_MSG_KEXDH_INIT
*Dec 28 22:48:19.148: SSH2 0: SSH2_MSG_KEXDH_INIT received
*Dec 28 22:48:19.315: SSH2: kex_derive_keys complete
*Dec 28 22:48:19.315: SSH2 0: newkeys: mode 1
*Dec 28 22:48:19.316: SSH2 0: newkeys: rekeying
*Dec 28 22:48:19.318: SSH2 0: SSH2_MSG_NEWKEYS sent
*Dec 28 22:48:19.319: SSH2 0: waiting for SSH2_MSG_NEWKEYS
*Dec 28 22:48:19.364: SSH2 0: newkeys: mode 0
*Dec 28 22:48:19.364: SSH2 0: newkeys: rekeying
*Dec 28 22:48:19.365: SSH2 0: SSH2_MSG_NEWKEYS received

Message Authentication Code (MAC)

hier stellen wir fest welches Algorithmus dafür gebraucht wird. Beim MAC geht es eigentlich darum, dass die Pakete zusätzlich mit einem zuvor berechneten MAC zum Empfänger verschickt werden. Der Empfänger berechnet dieser Wert selber und vergleicht das mit dem erhaltener Code. Stimmen beide überein, dann kann der Empfänger davon ausgehen, dass die Nachricht authentisch ist und dass diese unterwegs nicht manipuliert worden ist.

R1(config)#ip ssh server algorithm mac ?
   hmac-sha1      HMAC-SHA1 (digest length = key length = 160 bits)
   hmac-sha1-96   HMAC-SHA1-96 (digest length = 96 bits, key length = 160 bits)
   hmac-sha2-256  HMAC-SHA2-256 (digest length = 256 bits, key length = 256
                  bits)
   hmac-sha2-512  HMAC-SHA2-512 (digest length = 512 bits, key length = 512
                  bits)
 R1(config)#ip ssh server algorithm mac hmac-sha2-512

Bei Debuggen sieht es wie folgt aus

*Dec 28 22:38:23.641: SSH2 0: ssh_receive: 64 bytes received 
 *Dec 28 22:38:23.642: SSH2 0: input: total packet length of 32 bytes
 *Dec 28 22:38:23.642: SSH2 0: partial packet length(block size)16 bytes,needed 16 bytes,
                maclen 64
 *Dec 28 22:38:23.643: SSH2 0: ssh_receive: 32 bytes received 
 *Dec 28 22:38:23.644: SSH2 0: partial packet length(block size)16 bytes,needed 16 bytes,
                maclen 64
 *Dec 28 22:38:23.644: SSH2 0: MAC compared for #11 :ok

Publickey Authentisierungsmethod

Wir wollen uns nur mit RSA Publickey authentisieren. Das gilt aber nur für unser Beispiel in diesem Beitrag. Daher werden wir nur ssh-rsa eingeben.

R1(config)#ip ssh server algorithm publickey ?
   ssh-rsa         RSA Publickey based authentication
   x509v3-ssh-rsa  RSA Certificate based authentication
R1(config)#ip ssh server algorithm publickey ssh-rsa 

Nur erlaubte Host zulassen

Für diese Aufgabe haben wir zwei Variante. Beide sind korrekt, dennoch Eine ist korrekter als die Andere :).

ACL vs CoPP

Es gibt ein wesentlicher Unterschied zwischen beide Varianten. CoPP wird gegenüber ACL in einen „silent drop“ enden. Der Client erhält irgendwann einen Timeout. Hingegen mit ACL muss der SSH-Server noch eine Nachricht generieren (Connection refused by remote host…). Diese Nachricht muss mit der Hilfe der CPU generiert werden. Lanciert einen Angreifer viele Verbindungsversuche, dann ist der SSH-Server gezwungen, viele Nachrichten zu generieren. Dies kann in einen ungewollten Denia-of-Service Angriff enden, da unser CPU keine Leistung mehr zur Verfügung hat für andere Aufgaben.

Variante 1 – Standard ACL

ip access-list standard 2
permit host 213.32.25.2

Variante 2 – CoPP (Control Plane Protection)

Standard ACL erstellen.

access-list 99 deny tcp 213.32.25.2 255.255.255.255 any eq 22
access-list 99 permit tcp any any eq 22

Class-Map erstellen.

class-map match-all COPP-SSH
match access-group 99

Policy-Map erstellen und unser Class-MAP COPP-SSH miteinbinden.

policy-map COPP-INPUT-POLICY
class COPP-SSH
drop

Unser Policy-Map im Control-Plane einbinden.

control-plane
service-policy input COPP-INPUT-POLICY

Mit dieser „Service-Policy“ kann man den SSH-Verkehr so regulieren, dass nur eine bestimmte IP-Adresse oder Netzwerk auf das Gerät zugreifen kann, das hindert aber niemand daran, sich an LAN- und oder WAN-Interface zu verbinden. Möchte man das auch noch regulieren, so kann man zusätzlich im „control-plane“ ein Interface für den Management Traffic definieren. Somit wird die Sicherheit erhöht.

Unsere VTY konfigurieren

line vty 0 4
  access-class 2 in
  authorization exec AUTHE
  login authentication AUTHE
  rotary 1
  transport preferred ssh
  transport input ssh
  transport output ssh

Bemerkung: Benutzt man CoPP um den SSH-Verkehr zu regulieren, dann muss man auf „access-class 2 in“ verzichten.

Restliche VTY-Linien sperren

line vty 5 924
  no login
  no exec
  transport preferred none
  transport input none
  transport output none

Also, wie sehen die Einstellungen von SSH auf dem Router R1 aus? (Siehe schwarze Markierung)

R1#sh ip ssh
SSH Enabled - version 2.0
Authentication methods:publickey,keyboard-interactive,password
Authentication Publickey Algorithms:ssh-rsa
Hostkey Algorithms:ssh-rsa
Encryption Algorithms:aes256-ctr
MAC Algorithms:hmac-sha2-512
KEX Algorithms:diffie-hellman-group14-sha1
Authentication timeout: 30 secs; Authentication retries: 3
Minimum expected Diffie Hellman key size : 4096 bits
IOS Keys in SECSH format(ssh-rsa, base64 encoded): mypair
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCowFD+2LS/LK76KqqnB0Y0CFL01b0cWNK4IIXVdXw1
FJqXMdrh6xtZZ7kn5ZwNaRkQji/IfRynlxAqNEH1SpgTziXl7baIsnhpkBHR8hey0mCLNQNwSdt36b+m
WfcPJAjzE+B5F1xkHWtCtMXluIZXCu6YLm4xB9zflloh2rGQpkajhq2lVFUh+tCQx3sUAfrO/2kz8brx
5qd9+4io9R6iwx7jsbm/Cd487jhCiUlD07yfg1JG+GDZ/bebiNIvIBjWbxtkwfaLa+jgfMecPESjm3TB
xW+vj9YfSnMZbed1TznJBzW19kwuVx0158oBhzajXl20fz6mGBYTVMaH/AGRgKw06Vl+1Z8P0P+wyhaC
OIW4UNMjUpzv9GRU749apOYY4cmBT0hhMdfQ99PaVRWdtOhi27q1GDPDAEKRAfIvl70X/nREBlRSaNYq
DPllm1PB9WgI3Aga5csXK2MYJM5HpU+/o5LbuH1J/Yz2WA+SjJKOCpe+Wtb98MWaPU56Hi2XiN5URmDk
C9HWtHXy5zOM1ePhW4UPo+vXx5ZZhbhchjUGFNNO9mpy3s92ZfbArkSrF9SNO7dPo236OzeAxYB0EZJN
cUxw1fcLC0pLlhVawcI7C7je1KfEWYukYJeDjrTLs8GE0XsnMeGW19Z8KaVs2/gOexkscynaJ96iKLru
R1#

Nun, wie sieht es jetzt mit der Verbindung aus? Lass uns mal ausprobieren. Verbindung von Router R3 zu R1

R3#
R3#ssh -l ssh 213.32.25.1
Password:
R1>
R1>
R1>en
Password:
R1#

Debug auf Router R1

R1#
*Dec 22 11:46:00.403: SSH0: starting SSH control process
*Dec 22 11:46:00.403: SSH0: sent protocol version id SSH-2.0-Cisco-1.25
*Dec 22 11:46:00.423: SSH0: protocol version id is - SSH-2.0-Cisco-1.25
*Dec 22 11:46:00.423: SSH2 0: kexinit sent: kex algo = diffie-hellman-group14-sha1
*Dec 22 11:46:00.424: SSH2 0: kexinit sent: hostkey algo = ssh-rsa
*Dec 22 11:46:00.424: SSH2 0: kexinit sent: encryption algo = aes256-ctr
*Dec 22 11:46:00.424: SSH2 0: kexinit sent: mac algo = hmac-sha2-512
*Dec 22 11:46:00.425: SSH2 0: send:packet of length 200 (length also includes padlen of 10)
*Dec 22 11:46:00.427: SSH2 0: SSH2_MSG_KEXINIT sent
*Dec 22 11:46:00.427: SSH2 0: ssh_receive: 64 bytes received
*Dec 22 11:46:00.427: SSH2 0: input: total packet length of 312 bytes
*Dec 22 11:46:00.427: SSH2 0: partial packet length(block size)8 bytes,needed 304 bytes,
maclen 0

Momentane Verbindungen überwachen

R1#show ssh
 Connection Version Mode  Encryption  Hmac          State                Username
 0          2.0     IN   aes256-ctr  hmac-sha2-512 Session started       ssh
 0          2.0     OUT  aes256-ctr  hmac-sha2-512 Session started       ssh
 R1#

Und das ist es gewesen. Ich hoffe das war für euch hilfreich. Hier die komplette Konfiguration

hostname R1

int gig 0/1
description *** MGMT Interface ***
ip address 213.32.25.1 255.255.255.252
no shut
exit

username ssh algorithm-type scrypt secret ssh 

enable algorithm-type scrypt secret cisco 

crypto key gen rsa general-keys modulus 4096 label mypair

aaa new-model
aaa authentication login AUTHE local
aaa authorization exec AUTHE local

ip ssh version 2
login block-for 150 attempts 10 within 60
ip ssh authentication-retries 2
ip ssh time-out 30
ip ssh logging events
login on-failure log
login on-success log

ip ssh port 2222 rotary 1 
ip ssh dh min size 4096

ip ssh rekey time 10 

ip ssh server algorithm mac hmac-sha2-512
ip ssh server algorithm publickey ssh-rsa 
ip ssh server algorithm encryption aes256-ctr
ip ssh server algorithm kex diffie-hellman-group14-sha1

ip ssh client algorithm mac hmac-sha2-512
ip ssh client algorithm encryption aes256-cbc aes256-ctr
ip ssh client algorithm kex diffie-hellman-group14-sha1

ip access-list standard 2
permit host 213.32.25.2
exit

line vty 0 4
access-class 2 in
authorization exec AUTHE
login authentication AUTHE
transport preferred ssh
transport input ssh
transport output ssh

line vty 5 924
no login
no exec
transport preferred none
transport input none
transport output none