Linux-Security Teil 2: OpenSSH optimieren, brute force Attacken erkennen & Rootkits aufspüren

Im zweiten Teil des Linux-Security-Artikels schauen wir uns folgende Themen an:

• wie wir die OpenSSH optimieren können
• wie wir brute force Attacken mit fail2ban erkennen und abwehren
• wie wir rootkits mit rkhunter im System aufspüren

Da wir mit unserem Server via SSH (secure shell) verschlüsselt kommmunizieren, kommt diesem Service besondere Aufmerksamkeit zu. Bieten wir diesen Service an, werden wir sofort Opfer von «brute force» Attacken. Diese sind in erster Linie äusserst lästig. Durch unsere Vorkehrungen aus dem 1. Teil des Blogs haben wir dank starken Passworten und einer Limite für Fehlversuche gute Chancen. Trotzdem bleiben diese Angriffe lästig. Sie erzeugen einen Verbindungsaufbau sowie Meldungen in Logfiles. Mittels fail2ban werden wir dafür sorgen, dass IP-Adressen nach wenigen Versuchen geblockt werden.

Eine Bedrohung unter Linux können RootKits darstellen. Ein RootKit ist eine Art Trojaner. Der Rootkit will auf Stufe System-Calls/Kernel eingreifen und das System kompromitieren. Ein Worst-Case-Szenario wäre, wenn ein Eindringling das login-Programm austauschen könnte und somit alle Accounts und Passworte abhören. rkhunter prüft bekannte Angriffspunkte auf ihre Integrität.

OpenSSH absichern

Die Konfigurationsdateien der OpenSSH liegen unter /etc/ssh. Sehen wir uns ein paar Optionen der Datei sshd_config an:

Port 22522

las die SSH auf einem anderen Port laufen. Viele Angreifer prüfen nur genau Port 22.

PermitRootLogin no

kein root-Login.

StrictModes yes

Stimmen die Dateirechte nicht, wird eine Verbindung verweigert.

MaxAuthTries

Maximale Anzahl Fehlversuche. Ab 3 Versuchen wird der Versuch geloggt.

PermitEmptyPasswords no

Verweigert leere Passworte.

AllowGroups ssh-users

Nur Mitgliedern der Gruppe ssh-users ist es erlaubt, SSH zu benutzen. Hinweis: Einmal mehr steuern Gruppn, bzw. deren Miglieder, ob ein Dienst benutzt werden kann oder nicht.

ClientAliveInterval 120
ClientAliveCountMax 3

Der Client wird nach 3 x 2 Minuten (3 x 120s) ausgeloggt.

X11Forwarding no

Ein Server, ohne GUI, braucht das X11-Protokoll nicht weiterzuleiten.

Natürlich verwenden wir nur noch die SSH-Protokoll-Version:

Protocol 2

OpenSSH-Schlüssel

Anstatt mit Passworten, authentifizieren wir uns mittels eines Keys. Dazu generieren wir uns ein Schlüsselpaar:

$ ssh-keygen -t rsa -b 4096

Kreiert ein 4096 Byte langes RSA-Schlüsselpaar (id-rsa und id_rsa.pub) im Verzeichnis $HOME/.ssh. Auch SSH-Clients wie puTTY unterstützen dies.

Um deinen öffentlichen Schlüssel auf dem Zielsystem/Konto einzutragen verwendest du:

$ ssh-copy-id user@host.beispiel.ch

Auf host.beispiel.ch wurde der öffentliche Schlüssel in eine Datei $HOME/.ssh/authorized_keys eingetragen. Weisst die Datei nicht die Rechte 0400 oder 0600 auf, wird diese Authentifizierung verworfen.

Kein “root”-Login!

Absolut. Du kannst als eingeloggter Benutzer root-Rechte erlangen (su) oder Kommandos als root starten (sudo) falls du dazu berechtigt bist.

$ ssh -t user@host.beispiel.ch 'sudo script'

SSH mit ‘-t’ starten um ‘sudo’ ein Terminal vorzugauckeln. Und wieder die chaiben Gruppen. Ist Benutzer user ein Mitglied der entsprechenden Gruppe, darf er script mit root-Rechten auf “host.beispiel.ch” ausführen.

brute force – Attacken erkennen und Abwehren

Wie bereits angekündigt werden Ports welche eine Authentifizierung anbieten (HTTPS, SSH, FTP, SMTP, …) angegriffen. Im wesentlichen probiert ein Angreifer standard Benutzer und Passworte zu erraten um Zugang zum System zu erlangen. Ein Kommando wie:

$ sed -e 's/^.*nvalid user //:' -e 's/ .*//' /var/log/auth.log | sort -u | less<

zeigt an welche Kontonamen (Benutzernamen) ausprobiert wurden. Auf einem beliebigen Wirt-Server wurden in einem Zeitraum von rund 12 Stunden:

736 verschiedene Konto-/Benutzernamen ausprobiert

2336 Login-Versuche, also rund 3 pro Name, weil …

Fail2ban in dieser Zeit 1010 IP-Adressen gesperrt (banned) hat welche 3 Fehlversuche gestartet hatten

Fail2ban zählt die Fehlversuche einer IP-Adresse auf ein Konto zuzugreifen. Wird ein konfigurierter Wert erreicht, wir die IP-Adresse des Angreifers per IP-Tables gesperrt. Nach einer wiederum konfigurierten Frist, wird die Adresse wieder frei gegeben. Ein etwas schussliger Benutzer wird also nicht ewig gesperrt.

Die Installation ist einfach, mittels apt install fail2ban oder etwas ähnlichem (yum install) . Die Konfiguration liegt in /etc/fail2ban/.

# cd /etc/fail2ban
# cp jail.conf jail.local

Passe anschliessend die Datei jail.local nach deinem Gusto an:

# cat jail.local
ssh
enabled = true
mode = aggressive
port = 22522
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 600
ignoreip = 127.0.0.1

Die Zeile ‘ filter = sshd’ weist auf eine Datei ‘sshd.conf’ hin, welche im Unterverzeichnis ‘filter.d’ liegt.

Restarte fail2ban anschliessend service fail2ban restart und bestaune die Einträge in ‘/var/log/fail2ban.log’.

Fail2ban betreibt nun ein Jail Namens ‘f2b-ssh’. Mittels:

# iptables -L
...
Chain f2b-ssh (1 references)
target prot opt source destination 
REJECT all -- 208.58.129.131 anywhere reject-with icmp-port-unreachable
REJECT all -- 210-10-205-158.bri.static-ipl.aapt.com.au anywhere reject-with icmp-port-unreachable
REJECT all -- 197.156.67.251 anywhere reject-with icmp-port-unreachable
REJECT all -- 115.159.88.192 anywhere reject-with icmp-port-unreachable
REJECT all -- ns2.altegrosky.ru anywhere reject-with icmp-port-unreachable
...

siehst du die aktuell Verbannten. Du wirst die Angriffe, zumindest wenn du Ports mit Authentication hast, nicht verhindern können. Mit fail2ban kannst du sie zumindest im Zaun halten ..

RootKits erkennen

Programme wie z.B. rkhunter helfen uns RootKits auf unserem System zu erkennen. Alle gängigen Distributionen haben rkhunter in ihren Repos. Die Konfiguration ist in /etc/rkhunter.conf zu finden.

Setze die Option:

PKGMGR=DPKG

und starte anschliessend:

# rkhunter --propupdate

um rkhunter beizubringen, wie deine OS-Landschaft aussieht.

Anschliessend kannst du mittels:

# rkhunter --check

einen ersten Check ausführen. Schau dir die Resultate in der Datei /var /log/rkhunter.log. Jenach System – Host, Gast, VM, Container –

Ausblick

Sichere SSH-Zugänge garantieren die Integrität des Servers

Systeme welche im Internet sichtbar sind werden angegriffen

Mit Fail2ban haben eine Methode, die Angreifer in Schach zu halten

Rkhunter gibt uns die Möglichkeit “rootkits” zu erkennen

Vorausblick

Services isolieren mit Container (lxc, docker & Co)