Skip to content

ssh_scan – Sicherheits- und Konfigurationsscanner für SSH Einstellungen

Mit SSH Audit hatte ich bereits vor einiger Zeit ein Tool im Programm, welches SSH auf Einstellungen und Konfiguration testet (Artikel).

Mozilla hat mit ssh_scan ein ähnliches Tool im Portfolio. Das Tool bezieht sich auf die eigenen SSH Guidelines und prüft hinterlegte Ciphers, MACs, und Kex Algorithmen.

Laut eigener Aussage zählt zu den Vorteilen des Tools die einfache Installation ohne allzu viele Abhängigkeiten. Das Programm ist portabel, lässt sich mit eigenen Regeln konfigurieren und wirft am Ende einen Report im JSON Format aus.

Zunächst muss ssh_scan aber erst einmal den Weg auf die Festplatte finden.

Installation unter Ubuntu 16.04 LTS

Für die Installation steht neben einem ssh_scan gem Paket auch ein Docker Container zur Verfügung.

sudo apt-get install ruby gem
sudo gem install ssh_scan

oder via Docker

docker pull mozilla/ssh_scan
docker run -it mozilla/ssh_scan /app/bin/ssh_scan -t example.com

oder froM Source

git clone https://github.com/mozilla/ssh_scan.git
cd ssh_scan

gem install bundler
bundle install

./bin/ssh_scan

SSH Scan im Einsatz

Die SSH-Prüf-Anwendung ist denkbar einfach zu bedienen, es lassen sich einzelne Host scannen, ganze Ranges oder weitere Parameter angeben.

Eine IP scannen

ssh_scan -t ip-addresse

Mehrere IPs scannen

ssh_scan -t ip-addresse1,ip-addresse2,ip-addresse3

ssh_scan

Adressen aus einer Datei scannen

ssh_scan -f ip-addressen.txt

IP Adressen mit bestimmten Port scannen

ssh_scan -t ip-addresse -p 666

Eigene Policy verwenden

ssh_scan -P intermediate -t ip-addresse

In den Standardeinstellungen wird die Mozilla Modern Policy als Prüfvorlage verwendet. Es lässt sich aber mit der oben erwähnten Option P auch auf Intermediate oder andere Richtlinien prüfen.

Hier als Beispiel die Intermediate Richtlinie:


cat intermediate

# Host keys the client accepts - order here is honored by OpenSSH
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256

Alle SSH_scan Befehle lassen sich über die Hilfe einsehen

ssh_scan -h

 

Fazit

Mozilla bietet mit ssh_scan eine praktische Methode um SSH Einstellungen zu prüfen und zu härten. Dank eigener Policies und vieler weiterer Optionen, wie Reports würde ich das Tool vorziehen, alleine weil das eingangs erwähnte SSH-Audit seit 2016 nicht mehr aktualisiert wurde.

Allerdings empfinde ich die Masse an Paketen, welche mit ruby gem auf dem System landen nicht unerheblich, da ist ein einfaches Python Script schon handlicher. 
Zusätzlich setzt ssh_scan wohl weiterhin auf NIST Kurven wie ecdh-sha2-nistp521,ecdh-sha2-nistp384 und ecdh-sha2-nistp256 welchen ich eher kritisch gegenüber stehe.

Schlussendlich sollte bei solchen Tests immer das Ergebnis genau hinterfragt werden. Das Prüfen von SSH Konfigurationen vereinfachen beide Programme dennoch merklich.

 

ssh_scan

Lynis 2.3.4 – Sicherheits Auditing für Linux Systeme mit vielen neuen Features

Das Open Source Security Auditing Tool Lynis  hat ein weiteres Major Update erhalten, welches allerdings schon beim 4. Bugfix Release angekommen ist.
Ich hatte das letzte Mal im März darüber berichtet (Artikel).

Zu den Kern-Neuerungen der Version 2.3.4 zählt unter anderen

  • Neue Ansible Scripte sind verfügbar
  • Ein Entwickler Modus für detaillierte Informationen wurde integriert "--profile developer.prf lynis audit system --developer"
  • Neuer Hilfe Befehl "show" (siehe Screenshot)
  • Es werden nun verschiedene Sprachen unterstützt, Deutsch ist seit Version 2.3.2 dabei.
  • Nginx wird auf veraltete SSL Implementierungen überprüft (SSLv2/SSLv3)
  • Lynis beherrscht verschiedene Profile
  • Remote Scans via SSH sind möglich
  • Systemd wird erkannt und unterstützt
  • Die Auswertung samt Darstellung wurde verbessert
  • Die Auswertung kann debugged werden "--debug flag"
  • Support für Redis, OpenStack und PHP 5.6 wurde integriert
  • Die Logdatei lässt sich mit "lynis show details TestID" öffnen
  • Bösartige Arch Linux Pakete werden nun erkannt

lynis-show

Installation Ubuntu 14.04 oder 16.04

Ubuntu 14.04

sudo sh -c 'echo "deb https://packages.cisofy.com/community/lynis/deb/ trusty main" > /etc/apt/sources.list.d/cisofy-lynis.list'
sudo apt-get update
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C80E383C3DE9F082E01391A0366C67DE91CA5D5F
sudo apt-get install lynis

Ubuntu 16.04

sudo sh -c 'echo "deb https://packages.cisofy.com/community/lynis/deb/ xenial main" > /etc/apt/sources.list.d/cisofy-lynis.list'
sudo apt-get update
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C80E383C3DE9F082E01391A0366C67DE91CA5D5F
sudo apt-get install lynis

Weitere Systeme wie Fedora oder SuSE werden ebenfalls unterstützt, alternativ kann das Paket auch ohne Repository installiert werden.

lynis

Fazit

Für Administratoren oder Sicherheitsexperten ist Lynis ein praktisches Tool, um Systeme zu auditieren oder zu härten. Die deutsche Übersetzung ist etwas dürftig und zum jetzigen Stand eher überflüssig. Dafür wurden zahlreiche Verbesserungen integriert, welche das kleine Programm immer noch zu einem nützlichen Puzzlestück bei einem ausgefeilten Sicherheitskonzept macht.

Download

Hardening Apache Server - In 5min einen Webserver sicherer machen

Letzte Woche hatte ich euch kurz erklärt wie sich ein Apache in Verbindung mit einem Tomcat installieren lässt. Um auf der sicheren Seite zu sein, wurde der Apache gleich mit SSL "SSLEngine on" und einem selbstsignierten Zertifikat konfiguriert. 

In den folgenden Schritten möchte ich zeigen, wie ein Webserver (Apache) weiter abgesichert werden kann. Dazu müssen lediglich weitere Parameter in der Apache Konfiguration "/etc/apache2/sites-available/default-ssl.conf" gesetzt werden.

apache

Theoretisch könnt ihr die folgenden Zeilen direkt in eure Konfigdatei kopieren:

Apache Server härten

Wie bereits oben beschrieben werden alle Einstellungen in der default-ssl.conf gesetzt, innerhalb des ""VirtualHost" Bereichs:

Unsichere SSL Versionen blockieren

SSLProtocol All -SSLv2 -SSLv3

SSL Kompression deaktivieren um beispielsweise der "Crime" Attacke vorzubeugen 

SSLCompression off

Der Server soll vorgeben welche Verschlüsselung verwendet werden darf, normalerweise sucht sich der Client selbst etwas aus. 

SSLHonorCipherOrder On

Sichere Cipher Suites direkt vorgeben und ungewollte blockieren 

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4

Damit ist der Grundstock für einen sicheren Apache gelegt.

HTTP Strict Transport Security aktivieren

Ein weiterer Sicherheitsaspekt wäre beispielsweise HTTP Strict Transport Security.

Nach Aktivierung dieser Option ist es nicht mehr möglich Session Cookies abzugreifen, indem man den Anwender auf eine unsichere HTTP Webseite leitet. Dem Apache wird sozusagen mitgeteilt, über einen bestimmten Zeitraum (max-age - Angaben in Sekunden) nur noch HTTPS Verbindungen zuzulassen.

Um diese Funktion nutzen zu können, muss zunächst ein Apache Modul installiert werden

a2enmod headers

Danach kann wiederum in die default-ssl.conf folgendes eingetragen werden. Im Beispiel wir dem Server mitgeteilt, dass er die nächste 10 Jahre nur HTTPS Verbindungen zulassen soll. Mögliche Subdomains werden mit einbezogen.

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

OCSP (Online Certificate Status Protocol) aktivieren

Eine weitere Möglichkeit den eigenen Webserver gegen Angriffe zu schützen ist OCSP. Hierbei wird während des Aufbaus einer SSL/TLS Verbindung das Zertifikat auf Echtheit überprüft.

Hierzu ist natürlich ein offizielles Zertifikat eines CA notwendig. Diese Sicherheits-Funktion bietet ihre Vor- und Nachteile, warum ich sie nur bedingt empfehle.

Bei einem selbstsignierten Zertifikat, macht diese Sicherheitsfunktion sowieso wenig Sinn. Dennoch hier der Befehl, wie diese eingebunden wird (benötigt Apache 2.4):

SSLUseStapling on

SSLStaplingCache "shmcb:logs/stapling-cache(150000)"

Abschlusstest

Egal welche Funktion ihr in eine Konfiguration einbaut. Sie sollte vor Inbetriebnahme immer getestet werden

apache2ctl -t

sudo service apache2 restart