Wissen, was jede Firewall erlaubt — und sich nie aussperren.

Derzeit Hetzner, DigitalOcean und TransIP. Was möglich ist, unterscheidet sich je Anbieter und wird deklariert statt angenommen: bei Hetzner und DigitalOcean legst du eine Firewall an und hängst sie an mehrere Server, TransIP gibt jedem VPS eine eigene, die sich weder umbenennen noch lösen lässt, und OVHcloud hat überhaupt keine Firewall-API — dort gehört das Filtern zur IP-Adresse und nicht zur Maschine, deshalb lassen wir das Thema unangetastet, statt es als abgeschaltet zu melden. Die Integrationsseite listet, was wo funktioniert.

Nein. Es verwaltet die eigene Firewall, die dein Anbieter dir ohnehin gibt. Regeln werden in die Cloud zurückgeschrieben, es läuft also die Firewall des Anbieters — nur von einer Stelle aus bearbeitet, in einem Satz zusammengefasst und vor dem Speichern geprüft. Benennst du eine Firewall um, heißt sie auch beim Anbieter so, statt einen lokalen Spitznamen zu tragen.

Sie werden übernommen, wie sie sind, sobald du einen Anbieter verbindest — nichts fällt weg, nichts wird umgeschrieben. Regeln, die der Anbieter selbst verwaltet und in Tags, Servern, Load Balancern oder Kubernetes-Clustern statt in Adressen ausdrückt, lassen sich hier nicht bearbeiten, weil unsere Regelform Adressen enthält. Sie werden gezeigt, gezählt und beim Speichern unverändert mitgeführt, statt versteckt oder still gelöscht zu werden.

Es hält die Adresse, von der deine Sitzung kommt, gegen die Regeln, die du gleich anwenden willst, und sieht nur auf die Ports, die ein Weg zurück sind — SSH und RDP — wobei jede Adressfamilie getrennt geprüft wird, damit eine IPv4-Regel mit 0.0.0.0/0 nicht als Zugang für jemanden auf IPv6 gilt. Portbereiche zählen mit, eine Regel, die 20-30 öffnet, wird also als SSH erkannt. Nimmt die Änderung dir den Zugang, ist Bestätigen gesperrt, bis du es bestätigst. Läuft die Prüfung noch, ist Bestätigen tot und sagt warum.

Nur wenn du Ersetzen wählst, und du siehst den entstehenden Regelsatz, bevor du bestätigst — die Alternative ist Ergänzen, das die Regeln der Vorlage zu den vorhandenen legt. Integrierte Vorlagen sind schreibgeschützt; eigene lassen sich bearbeiten und löschen, und eine gelöschte holst du vierzehn Tage lang aus dem Papierkorb zurück.

Nur eingehende Regeln, die für jede Adresse offen sind, kommen überhaupt in Frage. Eine Regel, die alle Ports öffnet, ist für sich schon kritisch; darüber hinaus wird auf SSH (22), Remotedesktop (3389) und neun Datenbank- und Cache-Dienste geschaut — MySQL, PostgreSQL, SQL Server, MongoDB, Redis, Elasticsearch, Memcached, Docker und Kubernetes — die jeweils einen kritischen Befund ergeben. FTP und Telnet sind eine Warnung statt eines Fehlers: unverschlüsselt, aber keine Datenbank. Portbereiche und Kommalisten werden geprüft, nicht nur exakte Ports. Jeder Befund lässt sich für diese eine Prüfung ausblenden.

Ja — binde die Regel an eine dynamische IP, und der Eintrag folgt deiner Adresse. Nur der Eintrag, den wir geschrieben haben, ändert sich; jede andere Adresse in der Regel bleibt unangetastet. Es ist immer ein einzelner Host und nie ein Bereich, und immer die Adresse, von der du wirklich gekommen bist, nicht eine, die du angegeben hast. Vor jedem Schreiben werden die aktuellen Regeln beim Anbieter zurückgelesen, und ist die Regel, der wir gefolgt sind, verschwunden, wird das Ziel markiert und gemeldet, statt still auf eine veraltete Adresse zu zeigen.