Skip to content

ssh-audit - OpenSSH Sicherheit testen, konfigurieren und härten

Secure Shell (SSH) dürfte fast jeder schon einmal gehört haben, nicht nur wegen der vielen Updates in letzter Zeit.

Das Netzwerkprotokoll, welches häufig zur Wartung oder zum Datenaustausch mit entfernten Geräten verwendet wird, ist aus dem Alltag kaum wegzudenken.

SSH ermöglicht eine sichere Verbindung in unsicherer Umgebung, dank Verschlüsselung und Authentifizierung.

Neben Passwortauthentifizierung kann das Protokoll mit Public Key Verfahren genutzt werden, was durchaus zu empfehlen ist.

Die Einstellungen in der Konfiguration "/etc/ssh/sshd_config" dazu sind schnell gesetzt:

PubkeyAuthentication yes

PasswordAuthentication no

 

Neben der Authentifizierungsmethode gibt es allerdings noch weitere Einstellungsmöglichkeiten.

Um Verbindungen zwischen Client und Server möglichst sicher zu gestalten, können in der Konfiguration verschiedene Einstellungen gesetzt werden.

Unter anderen folgende Werte.

 

  • KexAlgorithms (Key Exchange): Die Schlüsselaustausch-Algorithmen für die symmetrische Verschlüsselung.
  • Ciphers Die Ciphers zur symmetrischen Verschlüsselung der Verbindung.
  • MACs (Message authentication codes): Nachrichten Authentifizierungsverfahren, um die Integrität zu sichern.
  • HostKeyAlgorithms Algorithmus welchen der Client verwendet

 

Durch alte bzw. gebrochene oder mangelhafte Verschlüsselung kann es zu Sicherheitslücken kommen, welche sich durch richtige Einstellungen vermeiden lassen.

Mit Hilfe des Kommandozeilen Tools ssh-audit lassen sich fehlerhafte SSH Einstellungen schnell ausfindig machen.

ssh-audit - OpenSSH Sicherheit testen und richtig konfigurieren

Das Programm liest die Version und Einstellungen von OpenSSH aus und zeigt im Ampelformat an, welche Algorithmen und Ciphers abgeschaltet werden sollten.

ssh-auditDazu werden zusätzliche Infos eingeblendet. Warum genau diese Cipher oder jener Algorithmus nicht mehr verwendet werden sollten.

In der aktuellen Programmversion 1.7.x werden folgende Hauptfeatures unterstützt.

  •     SSH1 and SSH2 protocol server support
  •     grab banner, recognize device or software and operating system, detect compression
  •     gather key-exchange, host-key, encryption and message authentication code algorithms
  •     output algorithm information
    • available since 
    • removed/disabled 
    • unsafe/weak/legacy, etc
  •     output algorithm recommendations
    • append or remove based on recognized software version;
  •     output security information
    • related issues
    • assigned CVE list, etc
  •     analyze SSH version compatibility based on algorithm information
  •     historical information from OpenSSH, Dropbear SSH and libssh
  •     no dependencies, compatible with Python 2.6+, Python 3.x and PyPy

Installation unter Ubuntu 16.04 und Python3

Die Installation ist relativ einfach, allerdings kann es sein, dass mit Ubuntu 14.04 und Python 2.7 und Ubuntu 16.04 mit Python 3 noch ein paar Handgriffe notwendig sind.

wget https://github.com/arthepsy/ssh-audit/archive/v1.7.0.zip

unzip v1.7.0.zip

cd ssh-audit-1.7.0/

Zum Starten des Audits muss Python Script und eine Serveradresse aufgerufen werden. Als ersten Test bietet sich localhost an.

Unter Ubuntu 16.04 muss allerdings darauf geachtet werden, dass Python 3 richtig eingerichtet ist. Darum sollte hier noch ein Symlink gesetzt werden, damit das Script richtig ausgeführt werden kann

$ python -V
-bash: /usr/bin/python: No such file or directory

$ sudo ln -s /usr/bin/python3 /usr/bin/python

$ ls -l /usr/bin/ |grep python
lrwxrwxrwx 1 root   root          16 Oct 29 19:29 python -> /usr/bin/python3

Danach kann das Audit Script den Ubuntu 16.04 Server auf schwache Einstellungen kontrollieren. Hier ein Auszug.

sudo ./ssh-audit.py localhost

# general
(gen) banner: SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
(gen) software: OpenSSH 7.2p2
(gen) compatibility: OpenSSH 7.2+, Dropbear SSH 2013.62+
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) curve25519-sha256@libssh.org          -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp256                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                    -- [fail] using weak elliptic curves

# host-key algorithms
(key) ssh-rsa                               -- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
(key) rsa-sha2-512                          -- [info] available since OpenSSH 7.2
 

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com         -- [info] available since OpenSSH 6.5
                                            `- [info] default cipher since OpenSSH 6.9.
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
 

# message authentication code algorithms
(mac) umac-64-etm@openssh.com               -- [warn] using small 64-bit tag size
                                            `- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com              -- [info] available since OpenSSH 6.2
 

OpenSSH Härtung (ab Version OpenSSH 6.7)

Bei der neuesten OpenSSH Version können verschiedene Sicherheitseinstellungen gesetzt werden.

Im Screenshot seht ihr eine laut Audit optimale Einstellung für einen Server zum jetzigen Zeitpunkt.

ssh-gehaertet


Die Einstellungen kommen wie folgt zu Stande: 

Zunächst zum Key Exchange. Elliptische Kurven vom National Institute of Standards and Technology (Nist) haben nicht den besten Ruf und sind durch Timingangriffe verletzbar. SHA1 zählt auch nicht mehr zu den besten Methoden unserer Zeit und kann ebenfalls deaktiviert werden.

Das heißt von den verfügbaren Möglichkeiten (siehe unten) bleiben nur noch curve25519-sha256 und diffie-hellman-group-exchange-sha256 als Auswahl übrig. 

  • curve25519-sha256: ECDH over Curve25519 with SHA2
  • diffie-hellman-group1-sha1: 1024 bit DH with SHA1
  • diffie-hellman-group14-sha1: 2048 bit DH with SHA1
  • diffie-hellman-group-exchange-sha1: Custom DH with SHA1
  • diffie-hellman-group-exchange-sha256: Custom DH with SHA2
  • ecdh-sha2-nistp256: ECDH over NIST P-256 with SHA2
  • ecdh-sha2-nistp384: ECDH over NIST P-384 with SHA2
  • ecdh-sha2-nistp521: ECDH over NIST P-521 with SHA2
Quelle

Für Mac, HostKeys und Ciphers gelten ähnliche Regeln. Auch hier sollten Einstellungen mit MD5/SHA1 oder CBC entfernt werden. Open SSH Audit hebt diese in roter Schrift hervor. Am Ende bleibt eine sichere Einstellung und folgende Angaben unter /etc/ssh/sshd_config.

Diese beispielhaften Einstellungen wurde so gewählt, dass eine Verbindung via Windows und PuTTY möglich ist.

debianbanner no

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

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

HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa

Fazit

open-ssh audit bietet eine einfache und schnelle Möglichkeit SSH Verbindungen zu testen und bei Bedarf auch zu härten. Das Tool erklärt dem Nutzer seine Wahl und ist somit recht verständlich.

Allerdings sollte immer auf die jeweilige Umgebung in Verbindung mit den Einstellungen geachtet werden. Auch sollte nach einer Änderung zwingend eine Testverbindung aufgebaut werden (SSH Dienst neu starten nicht vergessen).

Details zu weiteren Einstellungen und deren Funktion, welche der Audit zurzeit nicht bieten kann, sollten an anderer Stelle nachgelesen werden. Hier empfiehlt sich das Raven Wiki für einen ersten Überblick

ssh audit

Totgeglaubte Leben länger - mRemoteNG vs. dRemote

Im April hatte ich mit dRemote ein alternatives Multi Connection Management Tool vorgestellt, da mein bisheriger Favorit seit Jahren nicht weiter entwickelt wurde.

Dies hat sich inzwischen dank David Sparer geändert. mRemoteNG wurde wieder Leben eingehaucht und mit der aktuellen Version 1.74 steht eine finale Version zur Verfügung.

dRemotemremoteng

Zeit, den aktuellen Stand der Tools zu betrachten.

 

 

dRemote

mRemoteNG

Version

0.4

1.74

Hosting

github (nicht aktuell)

github

Größe MSI

4MB

40MB

PuTTY

0.67

0.67

RDP

8

8

Passwort Verschlüsselung

AES

MD5 ?

Portabel

ja

ja

Weitere Protokolle

Azure, Vnc,Ica,Telnet,rlogin, Https

Azure, Vnc,Ica,Telnet,rlogin, Https

 

Beide Tools haben verschiedene kleine Hacks zu bieten. So beherrscht mRemoteNG einen Bildschirmschnappschuss direkt über das Tab, dRemote erlaubt wiederum den Zugriff auf Putty / Kitty Settings direkt aus dem Verbindungspanel.

Beide unterscheiden sich ebenfalls leicht in der Oberfläche, wobei dRemote bereits an einer neuen GUI arbeitet.

 

Fazit

Beide Tools sind sich sehr ähnlich, kein Wunder bei gleichen Eltern, dennoch gibt es feine Unterschiede, die für den ein oder anderen den Zuschlag ausmachen dürften.

Persönlich finde ich es wichtig, dass die Entwicklung nicht still steht. Dies ist bei beiden Projekten derzeit der Fall. mRemoteNG hat mit 1.75 Alpha bereits die nächste Version in der Warteschlange

Warum der mRemoteNG MSI Installer auf 40MB aufgebläht wurde und dRemote nicht richtig via github verwaltet wird ist mir jedoch ein Rätsel.

Download dRemote

dRemote

Download mRemoteNG

mRemoteNG

dRemote - freier und nutzerfreundlicher Multi Remote Manager

Vor nahezu sechs Jahren hatte ich mit mRemoteNG ein Tool fürs Connection Management im Netzwerk vorgestellt. 
Es galt als freier Nachfolger von mRemote. Beide Tools sind in dieser Form nicht mehr existent, bzw. aktuell.
mRemote kostet Geld und wird nun unter dem Namen royal ts gehandelt und mRemoteNG wird seit einiger Zeit nicht mehr weiterentwickelt.

Da für ein Multi Verbindungsmanagement im Netzwerk nicht nur Protokolle wie RDP, VNC, ICA, SSH, Telnet oder HTTPS, sondern auch eine gewisse Aktualität des Produkts gefragt ist, musste ein Nachfolger für mRemoteNG ausfindig gemacht werden.

dRemote

dRemote

Mit dem Multi Verbindungs Manager dRemote wurde neben einem Entwickler auch ein funktionierender und aktueller Nachfolger gefunden. 
Das frische Projekt hat sofort die Arbeit aufgenommen und dem Programm einen frischen Anstrich verpasst.

dRemote2


Verbindungen werden nun in Tabs angezeigt und lassen sich beliebig verschieben. Putty wurde aktualisiert und vieles mehr, siehe Changelog.
Da es sich um einen Fork handelt bleibt die Handhabung des Tools im Vergleich zu mRemoteNG so gut wie gleich. 

Für Interessierte steht eine eigene Manual Seite zur Verfügung

Fazit

Es wurde bitter Zeit für einen Forks des praktischen Tools. Mit dRemote scheint ein würdiger Nachfolger gefunden zu sein, der regelmäßig mit Updates versorgt wird und alle Funktionen der Vorgänger unterstützt. Bleibt zu hoffen, dass dies so bleibt.

Sollte das Tool nicht gefallen, gibt es mit Terminals oder RDTabs durchaus Alternativen.

Download

Linux - SSH Login ohne Passwort mit SSH Schlüssel einrichten

Für die Wartung von Servern oder anderen sicheren Netzwerkverbindungen wird meistens SSH (Secure SHELL) verwendet.

Normalerweise erfolgt die Authentifizierung so einer Verbindung via Passwort. Viel sicherer ist eine Authentifizierung mit einem SSH Schlüssel. Für die Einrichtung einer sicheren Verbindung mit SSH Schlüssel sind nur wenige Handgriffe nötig.

Hier eine kurze Anleitung für das Umstellen von Passwort auf SSH Schlüssel Authentifizierung.

Vorraussetzung ist, dass das SSH Server Paket bereits installiert ist.

Schlüssel erzeugen

ssh-keygen -t rsa -b 4096

Generating public/private rsa key pair.

Enter file in which to save the key (/home/guenny/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/guenny/.ssh/id_rsa.

Your public key has been saved in /home/guenny/.ssh/id_rsa.pub.

The key fingerprint is:

a5:e2:b2:38:ff:a7:f5:de:03:dd:ss:6e:dd:c8:7d:11

The key's randomart image is:

+--[ RSA 4096]----+

|                 |

|                 |

|          .      |

|         oE      |

|     .  S ..     |

|    + o. ..      |

|. o. =.o.+ .     |

| = ..o+o+ o .    |

|. .o+oo.   .     |

+-----------------+

Schlüssel kopieren

sudo cat home/guenny/.ssh/id_rsa.pub >> /guenny/.ssh/authorized_keys

SSH Konfiguration sichern

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig

SSH Konfiguration für Public Key Auth anpassen

sudo sed -i 's/PermitRootLogin yes/PermitRootLogin no/g' /etc/ssh/sshd_config

sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config

sudo echo "DebianBanner no" >> /etc/ssh/sshd_config

Die Werte RSAAuthentication und PubkeyAuthentication sollten in den Standardeinstellungen bereits auf yes stehen

Konfiguration neu laden

sudo service ssh reload

Sobald die Konfiguration neu geladen wurde, ist es zwingend notwendig mit einer zweiten Verbindung zu testen, ob alles richtig konfiguriert wurde. Die bestehende Verbindung sollte dazu offen bleiben. 

Schlüssel auf andere Server kopieren 

Um Schlüssel auf andere Server zu kopieren kann der Befehl ssh-copy-id verwendet werden.

ssh-copy-id -i ~/.ssh/id_rsa.pub REMOTE_SERVER

Linux Server auf Botnet Windigo testen

Der Sicherheitsspezialist ESET hat in dieser Woche über die Operation Windigo berichtet. Angeblich wurden seit 2011 mehr als 10 000 linuxbasierte Server von diesem Botnet befallen.

Über diverse Rootkits (Linux/Ebury, Linux/Cdorked, Linux/Onimiki oder Perl/Calfbot) verschafft sich das Botnet Zugriff auf SSH Zugangsdaten oder DNS.

Zusätzlich werden OpenSSH Dateien manipuliert (ssh, sshd, ssh-add). Bei neueren Versionen (Stand Februar 2014) des Rootkits wird angeblich die libkeyutils.so abgehändert und dadurch um einige KB größer.

Ein Befall durch das Botnetz lässt sich mit einem Konsolenbefehl überprüfen:

ssh -G 2>&1 | grep -e illegal -e unknown > /dev/null && echo "System sauber" || echo "System infiziert"

Sollte das System befallen sein, empfehle ich den Server komplett neu aufzusetzen, da durch die offenen Zugangsdaten zusätzliche Änderungen am System vorgenommen worden sein könnten.

linux-logo