SSH und Zugang des Bitcoin-/ Lightning Node sichern [Part 2]

UFW aka uncomplicated Firewall & Fail2ban

Im folgenden werden wir die Softwarefirewall UFW installieren und einrichten.

Die Uncomplicated Firewall - ist ein Frontend für iptables und eignet sich besonders gut für hostbasierte Firewalls. Ufw bietet einen Rahmen für die Verwaltung von Netzfiltern sowie eine Befehlszeilenschnittstelle zur Manipulation der Firewall.

Eine Firewall steuert, welche Art von Datenverkehr von außen auf unserem Rechner akzeptiert wird und welche Anwendungen Daten nach außen senden können. Standardmäßig sind viele Netzwerkports offen und warten auf eingehende Verbindungen. Das Schließen unnötiger Ports kann viele potenzielle Schwachstellen des Systems verringern.

Die Installation bezieht sich auf Debian / Ubuntu basierte Systeme und Server/Nodes.

Wir benötigen einen "Nicht root Account" mit sudo Rechten. Update des Paketmanagers und des Systems mit anschließender Default Einrichtung der Firewall:

sudo apt update && sudo apt upgrade
sudo apt install ufw

Wir setzen die Defaultwerte von ufw zum Schließen aller Ports von außen und erlauben nur ausgehenden Datenverkehr.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh (default Port22, oder euer eigener SSH Port)

Danach schalten wir UFW ein und stellen sicher, dass sie als Service immer automatisch läuft.

sudo ufw enable
sudo systemctl enable ufw
sudo systemctl status ufw

Die Ausgabe zum Servicestatus sollte so aussehen:

Nun checken wir die UFW Statusausgabe und gesetzten Regeln.

sudo ufw status verbose

Ausgabe wie folgt:
Status: active
Logging: on (info)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp ssh                 ALLOW IN    Anywhere

Damit ist die Grundvoraussetzung zum Nutzen von UFW gegeben und nur der SSH Service bzw der Port 22 ist geöffnet. Ist SSH/Port nicht freigegeben und ihr meldet euch vom Node ab, habt ihr euch ausgesperrt und kommt nur mit Tastatur/Maus wieder auf euren Node.

Tip: öffnet ein neues Terminal und versucht euch am Node anzumelden. Klappt das nicht checkt eure ufw settings... hier ein Basic Guide

Fail2Ban: ban hosts that cause multiple authentication errors

Fail2ban durchsucht Protokolldateien wie /var/log/auth.log und sperrt IP-Adressen, die zu viele fehlgeschlagene Anmeldeversuche durchführen. Dazu aktualisiert es die Firewall-Regeln des Systems, um neue Verbindungen von diesen IP-Adressen für eine konfigurierbare Zeitspanne abzulehnen. Fail2Ban wird so ausgeliefert, dass es viele Standard-Protokolldateien lesen kann, wie z.B. die für sshd und Apache, und kann leicht so konfiguriert werden, dass es jede beliebige Protokolldatei für jeden gewünschten Fehler liest.

Fail2Ban ist zwar in der Lage, die Rate der falschen Authentifizierungsversuche zu reduzieren, kann aber das Risiko einer schwachen Authentifizierung nicht ausschalten.

Wir installieren uns Fail2ban und richten uns einen Jail und Banfilter für unseren SSH Zugang ein. Die Software bietet sehr viele weitere Features um einen Server gegen unauthorisierten Zugang zu schützen... es gibt massig Filter und Konfigurationsmöglichkeiten u.A. für Apache, Nginx Webserver oder Mailserver. Wir beschränken uns auf den Usecase unseren BTC / Fulcrum Node zu sichern.

Link zum Github Wiki

Wir installieren Fail2ban & alle Abhängigkeiten aus dem Main Repo:

sudo apt install fail2ban

Fail2ban wird nach der Installation automatisch einen System Service einrichten und starten. Wir checken den Status nach Installation:

sudo systemctl status fail2ban

Die Ausgabe sollte in etwa so aussehen...

Falls der Service mit einem Exitcode nicht gestartet werden konnte müssen wir das Backend für den Service in der Konfig anpassen.

Fail2ban legt seine Konfigurationsdateien unter /etc/fail2ban automatisch an. Wir nutzen einen Texteditor wie Nano oder Vim um diese Konfigs als Sudo User zu bearbeiten...

Falls wir nun einen exit Status des Service angezeigt bekommen ändern wir das backend in systemd wie folgt (falls nicht überspringen wir diesen Punkt):

Erstellen einer Kopie des Konfigfile unter dem Namen jail.local

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Bearbeiten der jail.local Konfig

sudo nano /etc/fail2ban/jail.local

Wir suchen die Zeile backend = auto und ändern diese in

backend = systemd

Strg + x und speichern... danach starten wir den Service neu:

sudo systemctl restart fail2ban
sudo systemctl status fail2ban

Status sollte nun Active / Running sein.

Konfiguration zum Schutz des SSH Service

Wir bearbeiten nie die Standard fail2ban.conf oder jail.conf Dateien da diese bei Updates überschrieben werden würden!

Entweder wir erstellen individuelle Profile für Fail2ban in mehreren Dateien innerhalb des /etc/fail2ban/jail.d/ -Verzeichnisses, oder sammeln alle unsere lokalen Einstellungen in einer jail.local-Datei. Die Datei jail.conf wird regelmäßig aktualisiert, wenn Fail2ban selbst aktualisiert wird, und wird als Quelle für Standardeinstellungen verwendet, falls wir diese nach Fehlkonfiguration zurücksetzen müssen.

Falls noch nicht geschehen erstellen wir uns eine Kopie der Datei jail.conf mit dem Namen jail.local:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Wir scrollen runter zur Rubrik #Jails, [sshd]

Dort setzen wir folgende Setting:

enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

Schauen wir uns diese Konfigurationseinstellungen genauer an:

Enabled: Auf true / false setzen, um eine Regel zu aktivieren / deaktivieren.
Port: Der zu überwachende Port. SSH standard 22 oder euer eigener Port.
Filter: In diesem Fall wollen wir den sshd-Filter verwenden.
Logpath: Pfad zur SSH-Protokolldatei. Unter Debian 12 befindet sich die Standard-Protokolldatei unter /var/log/auth.log.
Maxretry: Die Anzahl der erlaubten Fehlversuche, bevor eine IP-Adresse gesperrt wird. Default = 5

Wir speichern und schließen die Datei mit Strg + x, Enter.

Danach muss Fail2ban neu gestartet werden um die Konfig zu übernehmen...

sudo systemctl restart fail2ban

Wir können den Status der konfigurierten Jails checken:

sudo fail2ban-client status sshd

Die Ausgabe sieht in etwa so aus:

Wenn wir eine gesperrte IP freigeben möchten nutzen wir:

sudo fail2ban-client set sshd unbanip <IP_Address>

Dabei ersetzen wir <IP_Address> mit den zu entsperrenden IP's aus der Banned IP List.

Zum manuellen Sperren einer IP nutzen wir:

sudo fail2ban-client set sshd banip <IP_Address>

Damit haben wir Fail2ban erfolgreich eingerichtet um unseren SSH Service und Server oder Node zu schützen!

Es gibt viele weiter Konfigurationsmöglichkeiten um mit UFW und Fail2ban möglichen Bruteforce oder DDos Attacken effektiv und sicher umzugehen.

Einige andere Einstellungen sind der Filter, der verwendet wird, um zu entscheiden, ob eine Zeile in einem Protokoll auf eine fehlgeschlagene Authentifizierung hinweist, und der Protokollpfad, der fail2ban mitteilt, wo sich die Protokolle für diesen bestimmten Dienst befinden.

Der Filterwert ist ein Verweis auf eine Datei, die sich im Verzeichnis /etc/fail2ban/filter.d befindet. Diese Dateien enthalten reguläre Ausdrücke, die bestimmen, ob eine Zeile im Protokoll ein fehlgeschlagener Authentifizierungsversuch ist. Wir werden diese Dateien in dieser Anleitung nicht ausführlich behandeln, da sie ziemlich komplex sind und die vordefinierten Einstellungen gut zu den entsprechenden Jails passen.

Trotz alledem kann man sich einen Überblick der vorhandenen Filter verschaffen, indem man sich das Verzeichnis auflisten lässt...

ls /etc/fail2ban/filter.d

Man wird einige Services finden die man kennt oder aktiv nutzt. Um sich die Filter anzuschauen nutzen wir wieder Nano oder Vim als Editor. In unserem SSH Jail nutzen wir SSHD-Filter und können ihn uns anschauen oder bearbeiten mit:

sudo nano /etc/fail2ban/filter.d/sshd.conf

Die meisten dieser Filter haben entsprechende, deaktivierte Abschnitte in der Datei jail.conf, die wir bei Bedarf in unserer Datei jail.local aktivieren können.

Beispiel Nginx Webserver:

Dies ist bereits in einem Abschnitt der jail.local namens [nginx-http-auth]. Wir müssten nur noch den Parameter