Firewalld- und nftables-Regeln für NFS, Samba, NTP, DNS und DHCP: welche Ports genau zu öffnen sind

Worum es geht

Jeder Infrastrukturdienst dieser Serie braucht von der Host-Firewall genau eines: den Port bzw. die Ports, auf denen er tatsächlich lauscht, offen für die Clients, die ihn erreichen sollen, und für niemanden sonst. Firewalld bringt vordefinierte Service-Definitionen mit diesen Werten mit: Das NFS4-Protokoll ist dokumentiert als TCP 2049. Die Samba-Definition öffnet TCP 139 und 445 für die Datei- und Druckerfreigabe von Windows und über den enthaltenen Service samba-client zusätzlich UDP 137/138 für NetBIOS (SMB2 und neuer brauchen nur TCP 445). DNS öffnet TCP und UDP 53. Die DHCP-Definition erlaubt einem DHCP-Server, Nachrichten von DHCP-Clients und Relay-Agents auf UDP 67 anzunehmen (Clients verwenden UDP 68, das betrifft die Client-Seite). NTP öffnet UDP 123 (ein NTS-Server braucht zusätzlich TCP 4460). Für NFSv3 sind ausserdem die Services nfs3, mountd (20048) und rpc-bind (111) nötig, dazu die statd/lockd-Ports, die dynamisch vergeben werden, sofern sie nicht in /etc/nfs.conf fest eingestellt sind.

Warum es wichtig ist

Eine zu enge Regel legt den Dienst so lahm, dass es wie ein Fehler auf dem Server aussieht (Clients laufen in Timeouts, ohne Fehlermeldung). Genau das verursachen die zusätzlichen Ports von NFSv3 am häufigsten, wenn nur 2049 geöffnet wird. Eine zu weite Regel, etwa eine komplett als vertrauenswürdig eingestufte Zone oder ein Portbereich, der «sicherheitshalber» geöffnet wird, bedeutet zusätzliche Angriffsfläche ohne jeden Gegenwert.

So wird es angewendet

• Mit firewalld, wo vorhanden, die vordefinierten Services den selbst gebauten Portregeln vorziehen: firewall-cmd --permanent --zone=internal --add-service=nfs, danach dasselbe mit samba, dns, dhcp und ntp, anschliessend firewall-cmd --reload als root. Regeln in dieser Zone gelten nur für Datenverkehr von den Quellen oder Schnittstellen, die ihr zugeordnet sind. Wo kein vordefinierter Service passt, fügt --add-port den Port hinzu. Die Option lässt sich mehrfach angeben, einmal pro benötigtem Port oder Bereich.
• Mit nftables direkt dieselben Werte explizit in der Input-Chain abbilden, zum Beispiel udp dport 123 accept und tcp dport 2049 accept, eingegrenzt auf die jeweilige Schnittstelle oder ein Set von Quelladressen. Die Manpage von nft dokumentiert diese dport-Syntax für tcp und udp. Mit nft add rule hinzugefügte Regeln gehen beim Neustart verloren, wenn sie nicht zusätzlich in die Ruleset-Datei geschrieben werden (/etc/nftables.conf oder /etc/sysconfig/nftables.conf). Rohe nft-Regeln nicht mit einem aktiven firewalld mischen.
• Jede Regel auf eine Quelladresse oder eine firewalld-Zone eingrenzen, nicht nur auf einen Port. Ein Port, der für einen rein internen Dienst für alle Adressen offen ist, macht den Sinn exakt aufgelisteter Ports zunichte.
• Einen TCP-Dienst von einem Client aus mit nc -zv <host> <port> testen, das liefert ein schnelles Signal, ob die Verbindung zustande kommt oder abgewiesen wird. Bei UDP-Diensten (NTP, DNS, DHCP) ist ein blosser nc -u- oder nmap -sU-Test deutlich weniger aussagekräftig: Die Nmap-Dokumentation zum UDP-Scan hält fest, dass eine ausbleibende Antwort, auch nach erneuten Sendeversuchen, als mehrdeutiger Zustand open|filtered gemeldet wird und nicht als klare Antwort. UDP-Dienste daher besser mit dem echten Client-Werkzeug prüfen (chronyc, dig, eine DHCP-Lease-Erneuerung) als mit einem Portscanner.

Stolpersteine

• Die alten NFSv3-Ports «für alle Fälle» öffnen, obwohl bereits auf reines NFSv4 umgestellt wurde, und damit den Portmapper wieder exponieren.
• Ein UDP-Ergebnis open|filtered von nmap -sU als Beleg für die eine oder andere Seite lesen. Nur closed (eine ICMP-Antwort «port unreachable») ist eine klare Aussage, und der Test mit dem echten Client bleibt die bessere Prüfung.