Eine Firewall pro Server gehört zu den einfachsten Möglichkeiten, die Angriffsfläche einer Geschäftsumgebung zu reduzieren. Sie begrenzt, welche Systeme sich verbinden dürfen, von wo aus und zu welchem Zweck. Das ist auch dann wichtig, wenn ein Server hinter einer Cloud-Sicherheitsgruppe, einem virtuellen Netzwerk oder einer physischen Perimeter-Firewall liegt.
Der zuverlässigste Ausgangspunkt ist eine Default-Deny-Richtlinie: Nicht angeforderten eingehenden Datenverkehr blockieren, nur dokumentierte Dienste erlauben und ausgehenden Datenverkehr kontrollieren, wenn das Risiko dies rechtfertigt. Die Regeln sollten die Rolle des Servers widerspiegeln, statt aus einer allgemeinen Portliste kopiert zu werden. Ein öffentlicher Webserver, Datenbankserver, Mail-Relay und Backup-Quellsystem haben unterschiedliche Anforderungen.
Dieser Ansatz macht außerdem Verantwortlichkeiten klarer. Jeder Server verfügt über eine ausdrückliche Netzwerkrichtlinie, sodass ein vergessener Dienst nicht automatisch erreichbar ist, nur weil er auf Verbindungen wartet.
Mit einer Default-Deny-Richtlinie beginnen
Eine praktische Server-Firewall arbeitet normalerweise mit drei Entscheidungsebenen:
- Eingehender Datenverkehr: standardmäßig verweigern und anschließend nur die für legitime Dienste erforderlichen Ports erlauben.
- Ausgehender Datenverkehr: erforderliche Verbindungen zulassen, aber sensible oder unnötige Ziele nach Möglichkeit einschränken.
- Interner Datenverkehr: nur die Kommunikation zwischen festgelegten Serverrollen, Netzwerken oder Managementsystemen erlauben, die tatsächlich benötigt wird.
Bevor Regeln geändert werden, sollten Sie die Funktion des Servers, die darauf lauschenden Dienste, deren erwartete Clients sowie die Frage dokumentieren, ob diese öffentlich, privat oder administrativ sind. Nützliche Quellen sind die Dienstkonfiguration, Cloud-Sicherheitsgruppen, Load-Balancer-Einstellungen, DNS-Einträge, Anwendungsdokumentation und Verbindungsprotokolle.
Behandeln Sie einen Port nicht isoliert als sicher oder gefährlich. Eine Portnummer bezeichnet einen üblichen Dienst, nicht die Qualität seiner Konfiguration. Port 443 kann weiterhin eine verwundbare Anwendung offenlegen, während SSH auf Port 22 gut geschützt sein kann, wenn der Zugriff eingeschränkt und die Authentifizierung gehärtet ist. Das Ändern eines Standardports kann Hintergrund-Scans reduzieren, ersetzt aber keine Zugriffskontrolle.
Übliche Dienst-Ports und ihr Risiko
Teams suchen häufig nach gängigen Server-Firewall-Ports zum Öffnen und Sperren. Auf eine solche Liste muss jedoch immer eine Zugriffsentscheidung folgen. Die entscheidende Frage ist nicht nur, ob ein Dienst einen Port verwendet, sondern wer ihn aus welchem Netzwerk erreichen muss.
Ports 80 und 443: öffentliche Webdienste
Die Ports 80 und 443 sind normalerweise für eine öffentliche Website oder Webanwendung geeignet. Port 443 überträgt HTTPS und sollte der wichtigste öffentliche Einstiegspunkt sein. Port 80 kann für HTTP-zu-HTTPS-Weiterleitungen, die Zertifikatsvalidierung, die Kompatibilität mit älteren Systemen oder einen bewusst öffentlichen HTTP-Dienst erforderlich sein.
Wenn der Server hinter einem Reverse-Proxy, CDN oder Load Balancer liegt, muss der Ursprung nicht zwangsläufig Webdatenverkehr aus dem gesamten Internet akzeptieren. Die Einschränkung eingehender Verbindungen auf die veröffentlichten Adressbereiche des Proxys kann direkte Angriffe auf den Ursprung reduzieren. Stellen Sie sicher, dass die Anwendung weiterhin vertrauenswürdige Clientinformationen erhält und dass Health Checks, Zertifikatserneuerungen und Deployment-Prozesse im Design berücksichtigt sind.
Bei einer internen Anwendung muss keiner dieser Ports öffentlich sein. Erlauben Sie stattdessen den Zugriff aus dem Unternehmensnetzwerk, VPN, Application Gateway oder festgelegten privaten Subnetzen.
Port 22: SSH-Sicherheit
SSH ist für die Administration von Linux-Systemen, Automatisierung und bestimmte Dateiübertragungen unverzichtbar. Eine globale Freigabe lädt jedoch zu Passwort- und Zugangsdatenangriffen sowie zur Ausnutzung von Schwachstellen im SSH-Stack oder seiner umgebenden Konfiguration ein.
Für eine hohe SSH-Sicherheit sollten Sie Port 22 nur aus einem VPN-Adressbereich, von einer Unternehmens-Egress-IP, einem gehärteten Bastion-Host oder einem privaten Managementnetzwerk erlauben. Bevorzugen Sie schlüsselbasierte Authentifizierung, deaktivieren Sie die direkte Passwortanmeldung, sofern praktikabel, beschränken Sie privilegierte Zugriffe und verwenden Sie separate benannte Konten mit protokollierter Rechteerhöhung. Eine Multi-Faktor-Authentifizierung kann eine zusätzliche Schutzschicht bieten, insbesondere wenn administrative Zugriffe über ein nicht vertrauenswürdiges Netzwerk erfolgen.
Die Verlagerung von SSH auf einen anderen Port kann das Rauschen in Protokollen reduzieren, macht einen internetseitig erreichbaren Dienst jedoch nicht privat. Wenn die Fernadministration nur gelegentlich erforderlich ist, ist ein VPN oder eine Firewall-Regel mit zeitlich begrenzter Freigabe in der Regel eine bessere Kontrolle, als auf Verschleierung zu setzen.
Port 3389: RDP-Sicherheit
RDP ist ein besonders lohnendes Ziel, da es interaktiven Zugriff auf Windows-Systeme ermöglicht. Port 3389 sollte im normalen Betrieb nicht für das öffentliche Internet geöffnet sein. Verwenden Sie ein VPN, ein privates Netzwerk, ein Remote-Access-Gateway oder einen Bastion-Dienst und beschränken Sie die Quelladressen auf zugelassene Administrationsnetzwerke.
Eine gute RDP-Sicherheit hängt außerdem von der Authentifizierung auf Netzwerkebene, starken Identitätskontrollen, Patchen, Kontosperrungen oder gleichwertigen Erkennungsrichtlinien sowie der Einschränkung ab, welche Administratoren sich anmelden dürfen. Wenn ein externer Supportdienst Zugriff benötigt, geben Sie ihm einen festgelegten Weg und eine zeitlich begrenzte Berechtigung statt einer dauerhaften Regel für beliebige Quellen.
Port 25: SMTP
Port 25 wird für die E-Mail-Zustellung zwischen Servern verwendet. Ein Mailserver, der E-Mails direkt sendet oder empfängt, kann diesen Port benötigen, obwohl Anbieter und vorgelagerte Netzwerke aus Gründen des Missbrauchsschutzes ausgehendes SMTP gelegentlich einschränken. Ein Server, der keine Maildienste betreibt, sollte Port 25 nicht offenlegen.
Gehen Sie nicht davon aus, dass die Freigabe des ausgehenden Ports 25 auf jedem Server harmlos ist. Ein kompromittierter Anwendungsserver kann zu einer Spamquelle werden oder den Ruf der Organisation als Mailversender beschädigen. Leiten Sie Anwendungs-E-Mails nach Möglichkeit über ein zugelassenes Relay und erlauben Sie ausgehendes SMTP nur zu diesem Relay. Der eingehende Port 25 sollte auf eine tatsächliche Mailserver-Rolle beschränkt und durch separate Maßnahmen gegen Missbrauch abgesichert werden.
Port 53: DNS
DNS verwendet sowohl UDP als auch TCP auf Port 53. Ein rekursiver Resolver muss möglicherweise Clientabfragen aus einem internen Netzwerk beantworten, während ein autoritativer DNS-Server öffentliche Abfragen beantworten muss. Dies sind unterschiedliche Rollen und sollten nicht ohne sorgfältige Prüfung kombiniert werden.
Setzen Sie niemals einen offenen rekursiven Resolver dem Internet aus. Beschränken Sie die Rekursion auf zugelassene Netzwerke, erlauben Sie Zonentransfers nur zwischen festgelegten Nameservern und lassen Sie TCP 53 zu, wenn große Antworten, DNSSEC oder Zonentransfers dies erfordern. Ein Server, der DNS lediglich nutzt, sollte ausgehende Abfragen normalerweise an festgelegte Resolver senden, statt eingehenden DNS-Datenverkehr anzunehmen.
Ports 3306 und 5432: MySQL und PostgreSQL
MySQL lauscht üblicherweise auf Port 3306 und PostgreSQL auf Port 5432. Diese Ports sollten fast nie öffentlich sein. Datenbanken enthalten wertvolle Geschäftsdaten und sind häufige Ziele für Angriffe auf Zugangsdaten, die Erkennung von Fehlkonfigurationen und die Ausnutzung ungepatchter Software.
Erlauben Sie Datenbankverkehr nur von den Anwendungsservern, Berichtssystemen, administrativen Bastion-Hosts oder privaten Netzwerken, die ihn tatsächlich benötigen. Verwenden Sie die Authentifizierung der Datenbank, sofern unterstützt Verschlüsselung, Konten mit geringstmöglichen Rechten und Netzwerkregeln, die der Anwendungstopologie entsprechen. Eine Bindung der Datenbank an eine private Schnittstelle ist sinnvoll, sollte die Firewall jedoch ergänzen und nicht ersetzen.
Management-Konsolen, Orchestrierungsoberflächen, Hypervisor-Konsolen und Monitoring-Endpunkte verdienen dieselbe Behandlung. Sie sollten nur über ein Managementnetzwerk, VPN oder eine streng kontrollierte Allowlist erreichbar sein. Eine öffentlich zugängliche Managementoberfläche kann dazu führen, dass ein gestohlenes Passwort oder eine ungepatchte Komponente die Kontrolle über den Server und möglicherweise über seine verbundene Umgebung ermöglicht.
Öffentlichen, Anwendungs- und Managementverkehr trennen
Portregeln sind wirksamer, wenn das Netzwerk segmentiert ist. Eine typische Bereitstellung in einem kleinen Unternehmen könnte folgende Bereiche trennen:
- Öffentliche Dienste: Web- oder Maildienste, die Verbindungen aus dem Internet annehmen müssen.
- Anwendungsdienste: APIs, Warteschlangen und interne Anwendungskomponenten, die nur von zugelassenen Systemen erreichbar sind.
- Datendienste: Datenbanken und Speicher, die nur von Anwendungs- oder Administrationsnetzwerken erreicht werden können.
- Managementdienste: SSH, RDP, Management-Konsolen, Monitoring- und Orchestrierungswerkzeuge, die nur über private Administrationswege erreichbar sind.
- Backup-Verbindungen: Ausgehende Verbindungen geschützter Server zu einem zugelassenen Backup-Ziel, ohne allgemeinen eingehenden Zugriff auf das Backup-Repository.
Dieses Modell begrenzt die seitliche Bewegung. Wird ein öffentlicher Webdienst kompromittiert, sollte der Angreifer nicht automatisch eine Verbindung zur Datenbank, zum Hypervisor oder zum Backupsystem herstellen können. Firewall-Regeln sollten Quell- und Zielrolle benennen und nicht lediglich aus Bequemlichkeit ein gesamtes virtuelles Netzwerk erlauben.
Auch interner Datenverkehr muss geprüft werden. Private IP-Adressen sind nicht automatisch vertrauenswürdig. Ein kompromittierter interner Server kann ein anderes System genauso effektiv scannen und angreifen wie ein Host aus dem Internet. Wenden Sie zwischen Subnetzen und Serverrollen das Prinzip der geringsten Rechte an und vermeiden Sie weitreichende Regeln wie die Erlaubnis jedes Ports von jeder internen Adresse.
Backup-Verbindungen und Wiederherstellungskopien schützen
Backup-Datenverkehr benötigt einen bewusst geplanten Weg, da Backupsysteme wertvolle Ziele sind. Ein häufig sichereres Muster besteht darin, dass der vom Kunden kontrollierte Quellserver eine ausgehende Verbindung zum Backupdienst initiiert, während eingehende Verbindungen aus dem Internet zum Backup-Repository blockiert bleiben. Erlauben Sie nur das Ziel, das Protokoll und die Richtung, die das Backupdesign erfordert.
Veröffentlichen Sie kein Backup-Repository, keinen Speicherendpunkt und keine Backup-Managementoberfläche direkt im Internet. Wenn ein Backup-Produkt eingehende Kommunikation erfordert, führen Sie diese über ein privates Netzwerk, VPN oder eine streng eingeschränkte Allowlist und dokumentieren Sie, warum sie notwendig ist. Trennen Sie Backup-Zugangsdaten von Produktionszugangsdaten und verwenden Sie für Backup-Vorgänge kein Domänenadministratorkonto.
Safenix bietet Offsite-Backups für vom Kunden kontrollierte Geschäftsserver. Die Backups werden mit einem Schlüssel verschlüsselt, den Safenix niemals besitzt, in Deutschland gespeichert und für die Dauer des Aufbewahrungszeitraums unveränderbar aufbewahrt. Der Kunde sollte Backup-Verbindungen dennoch an der Quell-Firewall beschränken und nur den für den Dienst erforderlichen Datenverkehr erlauben. Details zu Safenix-Backups für Geschäftsserver und dem Schutz der Offsite-Wiederherstellung können gemeinsam mit dem Firewall-Design des Kunden geprüft werden.
Offen zugängliche Backup-Verbindungen bergen zwei Risiken. Ein Angreifer kann sie als Weg in die Backup-Plattform nutzen oder Wiederherstellungskopien stören, löschen oder verschlüsseln. Wenn der Backup-Datenverkehr möglichst eng und unidirektional gehalten wird, sinkt die Wahrscheinlichkeit, dass die Kompromittierung eines Produktionsservers auch die Wiederherstellungsumgebung erfasst.
IPv4- und IPv6-Regeln müssen übereinstimmen
Ein häufiger Firewallfehler besteht darin, IPv4 abzusichern, während IPv6 weitgehend erreichbar bleibt. Wenn der Server eine öffentliche IPv6-Adresse besitzt, benötigt er eine IPv6-Firewallrichtlinie mit derselben Default-Deny-Ausrichtung, denselben Dienstbeschränkungen und denselben Erwartungen an die Protokollierung wie IPv4.
Gehen Sie nicht davon aus, dass das Deaktivieren einer IPv4-Regel den Dienst schützt. Prüfen Sie für beide Protokolle die lauschenden Adressen, Cloud-Sicherheitsgruppen, die Firewallkonfiguration des Hosts und Kontrollen auf Anbieterebene. Wenn IPv6 nicht benötigt wird, deaktivieren Sie es erst, nachdem Sie bestätigt haben, dass Anwendungen, Monitoring, DNS und Netzwerkabhängigkeiten weiterhin funktionieren. Andernfalls muss IPv6 ordnungsgemäß gepflegt werden.
Prüfen Sie neben eingehendem auch ausgehenden IPv6-Datenverkehr. Eine Anwendung, die über eine nicht überwachte Adressfamilie externe Systeme erreichen kann, könnte Annahmen umgehen, die in ein ausschließlich auf IPv4 ausgerichtetes Sicherheitsdesign eingeflossen sind.
Ausgehende Regeln, Protokollierung und Alarmierung
Das vollständige Blockieren des ausgehenden Datenverkehrs ist für einen Geschäftsserver selten praktikabel. Updates, DNS, Zeitsynchronisation, E-Mail, APIs, Monitoring und Backups können ausgehenden Zugriff erfordern. Eine sinnvolle Richtlinie beginnt damit, diese Abhängigkeiten zu identifizieren, und begrenzt anschließend Ziele und Ports, sofern das Betriebsrisiko dies rechtfertigt.
Ein Anwendungsserver benötigt beispielsweise HTTPS zu bestimmten Softwarediensten, DNS zu zugelassenen Resolvern, NTP zu zugelassenen Zeitquellen und eine ausgehende Backup-Verbindung. Es gibt möglicherweise keinen Grund, dass er beliebige SMTP-Server, Datenbankports oder Fernadministrationsdienste im Internet kontaktiert.
Protokollieren Sie abgewiesenen Datenverkehr, aber machen Sie die Protokolle nützlich statt überwältigend. Erfassen Sie Quelle, Ziel, Port, Protokoll, Schnittstelle, Aktion und Zeitstempel. Begrenzen Sie die Rate wiederholter Ereignisse und leiten Sie wichtige Protokolle an einen Ort weiter, den ein Angreifer nicht einfach verändern kann. Alarmieren Sie bei Mustern wie wiederholten SSH- oder RDP-Versuchen, Scans über viele Ports, unerwartetem ausgehendem SMTP, neuem Zugriff auf Datenbankports oder einer plötzlichen Änderung des Verhaltens von Backup-Verbindungen.
Protokollierung soll Untersuchungen unterstützen und nicht Prävention ersetzen. Eine Regel, die täglich Tausende von Alarmen erzeugt, wird irgendwann ignoriert. Stimmen Sie Schwellenwerte auf den normalen Datenverkehr ab und legen Sie fest, wer Alarme prüft, wie schnell dies geschieht und welche Beweise aufbewahrt werden sollen.
Wie Agenturen viele Kundenumgebungen verwalten können
Agenturen benötigen Konsistenz, ohne so zu tun, als hätte jeder Kunde dieselbe Architektur. Die Lösung ist eine kontrollierte Basis mit dokumentierten Ausnahmen.
- Erstellen Sie rollenbasierte Vorlagen für Web-, Anwendungs-, Datenbank-, Mail-, Windows-Administrations- und Backup-Quellserver.
- Verwenden Sie Variablen für Kunden-IP-Bereiche, VPN-Adressen, private Subnetze und zugelassene Dienstziele, statt Annahmen fest zu codieren.
- Speichern Sie Firewallregeln, sofern die Plattform dies erlaubt, als versionskontrollierte Konfiguration mit Vier-Augen-Prüfung und dokumentierter Änderungshistorie.
- Wenden Sie eine einheitliche Namenskonvention für Regeln an, einschließlich Zweck, Quelle, Ziel, Verantwortlichem und Prüfdatum.
- Nutzen Sie Automatisierung, um Syntax zu testen, erforderliche lauschende Ports zu bestätigen und die Übereinstimmung der IPv4- und IPv6-Richtlinien zu prüfen.
- Halten Sie Notfallzugriffsverfahren getrennt und zeitlich begrenzt; wenn möglich mit automatischem Ablauf.
Erstellen Sie vor der Bereitstellung einer Vorlage ein Dienstinventar. Prüfen Sie Anwendungsdokumentation, aktive Verbindungen und geplante Aufgaben und fragen Sie den Kunden, welche externen Anbieter Zugriff benötigen. Eine kurze Analysephase ist günstiger, als eine Abrechnungsintegration, einen Monitoring-Agenten oder eine Deployment-Pipeline zu unterbrechen.
Führen Sie Änderungen schrittweise ein. Wenden Sie eine geplante Richtlinie, sofern verfügbar, zunächst im Audit- oder Protokollierungsmodus an, vergleichen Sie den beobachteten Datenverkehr mit dem vorgesehenen Design und setzen Sie sie anschließend während eines Wartungsfensters durch. Halten Sie eine Out-of-Band-Konsole oder einen Wiederherstellungsweg verfügbar, damit ein Administrator nicht durch eine fehlerhafte Regel ausgesperrt wird.
VPS-Firewalls im Vergleich zu Shared Hosting
Ein VPS gibt dem Kunden Kontrolle über das Betriebssystem, die installierten Dienste und normalerweise die Firewall auf Hostebene. Das bedeutet, dass der Kunde oder seine Agentur dafür verantwortlich ist, zu entscheiden, welche Ports lauschen und welche Quellen sie erreichen dürfen – zusätzlich zu den vom Hostinganbieter bereitgestellten Kontrollen.
Shared Hosting ist anders. Mehrere Kunden nutzen eine vom Anbieter verwaltete Umgebung, wobei der Anbieter den Perimeter, die Netzwerkisolierung und die Dienstfreigaben kontrolliert. Der Kunde kann normalerweise keine vollständige Firewallrichtlinie pro Server auf dem zugrunde liegenden Host anwenden oder die eingehenden Regeln des Anbieters ändern. Eine hilfreiche Abgrenzung zwischen kundenverwalteter VPS-Infrastruktur und Shared-Hosting-Diensten finden Sie in dieser Referenz zu VPS- und Hosting-Infrastruktur.
Dieser Unterschied ist für die Sicherheitsplanung entscheidend. Eine Website im Shared Hosting ist nicht dasselbe wie ein vom Kunden kontrollierter Geschäftsserver mit Firewall auf Betriebssystemebene. Safenix schützt vom Kunden kontrollierte Server; es bietet keinen Backupplan für eine Website, nur weil diese im Shared Hosting betrieben wird. Die Möglichkeiten des Hostinganbieters und die Verantwortung des Kunden müssen vor der Planung von Backup- und Wiederherstellungsverfahren bestätigt werden.
Firewallregeln als Teil des Betriebs überprüfen
Eine Firewallrichtlinie wird ungenau, sobald sich Dienste, Anbieter, Netzwerke oder Administratoren ändern. Überprüfen Sie Regeln regelmäßig sowie nach bedeutenden Architekturänderungen, Migrationen, Sicherheitsvorfällen oder personellen Veränderungen.
Entfernen Sie bei einer Prüfung Regeln ohne Verantwortlichen, Quelle oder dokumentierten geschäftlichen Zweck. Suchen Sie nach temporären Allowlists, die nie zurückgenommen wurden, zu weit gefassten Netzwerkbereichen, doppelten Einträgen, ungenutzten lauschenden Diensten und über IPv6 erreichbaren Managementports. Bestätigen Sie, dass Datenbank- und Backup-Schnittstellen privat bleiben und öffentliche Dienste weiterhin aktuelle Zertifikate und sichere Konfigurationen verwenden.
Führen Sie für jede Ausnahme eine einfache Aufzeichnung: Was erlaubt sie, warum existiert sie, wer hat sie genehmigt, wann soll sie überprüft werden und wodurch könnte sie ersetzt werden? So wird die Firewallverwaltung von einer Sammlung spontaner Korrekturen zu einer wiederholbaren Kontrolle.
Eine Firewall pro Server mit Default-Deny verhindert nicht jede Kompromittierung. Sie kann jedoch viele unnötige Wege zu einem System blockieren und die Bewegung nach einem Vorfall begrenzen. Kombinieren Sie sie mit gehärteter Authentifizierung, Patch-Management, Segmentierung, Monitoring und geschützten Offsite-Backups. Das Ergebnis ist eine kleinere Angriffsfläche und ein zuverlässigerer Weg zur Wiederherstellung, wenn ein Server oder Netzwerk nicht mehr vertrauenswürdig ist.