Server sichern mit ufw

[Pius Noel]

Um es gleich vorweg zu nehmen, ich bin ein grosser Fan der ufw und finde jeden Beitrag gut, der dazu motiviert dieses Tool zu verwenden.

Bei der Verwendung dieses Scripts sehe ich allerdings auch Probleme, denn Tools wie ss (oder netstat) zeigen nicht die tatsächlich offenen Ports, sondern Ports die von einem gerade laufenen Programm abgehört werden. Dabei werden auch Ports gelistet die an die interne lokale Adresse gebunden sind und eigentlich gar nicht nach aussen geöffnet werden müssen.

Ich persönlich bin der Meinung, dass man wissen sollte, welche Ports von welcher Anwendung benötigt werden. Vorausgesetzt, dass alle Systeme laufen, kann das mit dem Befehl 'ss -tulp' oder 'ss -tulpn' (Port Nummern statt Namen) abgerufen werden. Ein leicht abgeändertes Besipiel von einem Raspberry Pi der hinter einem Home-Router mit DHCP-Server steht:

Code:

Netid  State  Local Addr:Port         Process                          
udp    UNCONN    0.0.0.0:bootpc        users:(("dhcpcd",pid=971,fd=10))
udp    UNCONN    0.0.0.0:9000          users:(("dotnet",pid=4578,fd=257
udp    UNCONN          *:https         users:(("caddy",pid=972,fd=9))  
udp    UNCONN          *:dhcpv6-client users:(("dhcpcd",pid=971,fd=16))
tcp    LISTEN  127.0.0.1:mysql         users:(("mariadbd",pid=804,fd=19
tcp    LISTEN    0.0.0.0:9000          users:(("dotnet",pid=4578,fd=166
tcp    LISTEN    0.0.0.0:ssh           users:(("sshd",pid=760,fd=3))  
tcp    LISTEN  127.0.0.1:2019          users:(("caddy",pid=972,fd=3))  
tcp    LISTEN  127.0.0.1:45271         users:(("containerd",pid=731,fd=
tcp    LISTEN          *:http          users:(("caddy",pid=972,fd=10))
tcp    LISTEN          *:https         users:(("caddy",pid=972,fd=8))  
tcp    LISTEN       [::]:ssh           users:(("sshd",pid=760,fd=4))

Damit wird ersichtlich, von welcher Anwendung welche Ports benutzt werden (wegen der Übersichtlichkeit habe ich Im Beispiel die Spalten Recv-Q, Send-Q und Peer-Address : Port entfernt).

Die Anbindung des Ports an die Adresse 0.0.0.0 steht unabhängig von der tatsächlichen IP-Adresse für alles was von aussen über IPv4 an den Rechner adressiert wird. [::] gilt entsprechend für IPv6.

127.0.0.1 gilt für Ports die an die interne Adresse (localhost) gebunden sind und somit von aussen nicht zugänglich sein müssen (und somit auch nicht dürfen). Ein * gilt für alle Adressen, egal ob intern oder extern, IPv4 oder IPv6.

Im Beispiel ist der Port 9000 für udp und tcp interessant. Er gehört zum Prozess dotnet. Es sollte allen Betreiber*innen eines OpenSim Servers klar sein, dass es sich damit um OpenSimulator handeln könnte, das mit 'dotnet OpenSim.dll' gestartet wurde.

Damit in Verbinung steht mariadb das an die interne Adresse gebunden ist und im konkreten Fall von der OpenSim benutzt wird. Wenn falsch konfiguriert, kann der Port auch an die externe Adresse gebunden werden und das möchten wir natürlich nicht. Deshalb wollen wir diesen Port auch niemals nach aussen hin öffnen.

Ähnliches gilt für den Prozess containerd, der zu Docker gehört, sowie den Port 2019 von caddy.

Caddy ist ein Web Server, der hier auf allen Schnittstellen an den TCP Ports http (80) und https (443) hört. Da Caddy auch DNS über https unterstützt muss hier der https Port nach aussen hin geöffnet werden. Das kann man der Dokumentation von Caddy entnehmen. Der Port 2019 hingegegen, darf niemals nach aussen hin zugänglich sein, weil darüber über ein API die gesamte Konfiguration zugänglich und somit veränderbar ist.

Da ich mich auf desem Pi von aussen nur über SSH einlogge muss auch dieser Port geöffnet sein. Da ssh-Login-Versuche von aussen aber extrem häufig stattfinden verwende ich auf all meinen Systemen eine andere Port Nummer. Das bedeutet nicht, dass mein System deswegen sicherer ist, aber es hält mir die Logs wesentlich sauberer.

Da bleiben noch die offenen Ports vom Prozess dhcpcd, der auf jedem Raspberry Pi vorinstelliert ist und den es in der Regel auch braucht. Er dient dazu beim Starten von einem DHCP Server (in der Regel vom Router) eine IP Adresse im LAN oder WLAN zu erhalten. Hmmm... muss dieser Port jetzt offen sein oder nicht? Da noch andere Komponenten mithineinspielen ist die Frage gar nicht so einfach zu beantworten. Bevor ich den Port aus den allow-Rules entfernte musste ich mir zuerst eine Notfallstratgeie überlegen, was zu tun ist, falls es nicht funktioniert. Es hat sich dann herausgestellt, dass sich in meinem Fall der Pi beim Starten die IP vom Router holt und in der Tat keine Verbindung von aussen her nötig ist. Ohne den dhcpcd Prozess, hätte mein Pi aber keine im LAN/WAN gültige IP Adresse und er wäre nicht erreichbar.

Der langen Rede kurzer Sinn: ich benötige zur Konfiguration meiner Firewall nur folgende vier Befehle:

Code:

sudo ufw allow ssh
sudo ufw allow http/tcp
sudo ufw allow https
sudo ufw allow 9000

Dem gegenüber steht das Resultat des Scripts von Manni:

Code:

#!/bin/bash
sudo ufw allow 68/tcp
sudo ufw allow 68/udp
sudo ufw allow 80/tcp
sudo ufw allow 80/udp
sudo ufw allow 443/tcp
sudo ufw allow 443/udp
sudo ufw allow 546/tcp
sudo ufw allow 546/udp
sudo ufw allow 922/tcp
sudo ufw allow 922/udp
sudo ufw allow 2019/tcp
sudo ufw allow 2019/udp
sudo ufw allow 3306/tcp
sudo ufw allow 3306/udp
sudo ufw allow 9000/tcp
sudo ufw allow 9000/udp
sudo ufw allow 45271/tcp
sudo ufw allow 45271/udp

Auch wenn damit soweit nichts passieren kann, würde mir das nicht gefallen.

Meine Devise: alles dicht machen und nur öffnen, was es unbedingt braucht! Damit behalte ich auch den Überblick.

P.S. Ja, es kann schon mal passieren, dass man sich selber aussperrt. Nach dem 2. Mal passiert es seltener.