Cloud-Firewall für Cloud-VPS und vServer

Mit der Cloud-Firewall legst Du in der lima-city-Verwaltung fest, welcher Netzwerkverkehr Deine Cloud-VPS und vServer erreichen darf. Sie arbeitet im Netzwerk vor Deiner Maschine: Verbindungen, die keine Regel erlaubt, kommen gar nicht erst beim Betriebssystem an. Du konfigurierst sie einmal und kannst sie auf beliebig viele Maschinen anwenden, ohne auf jeder Maschine einzeln Regeln zu pflegen.

Die Cloud-Firewall ersetzt keine Firewall im Betriebssystem (zum Beispiel ufw oder nftables), sondern ergänzt sie. Beide gelten unabhängig voneinander: Eine Verbindung muss an beiden vorbei.

Das Prinzip in drei Begriffen

• Firewall: eine benannte Sammlung von Erlaubnis-Regeln, zum Beispiel „Webserver öffentlich“ mit HTTP und HTTPS.
• Labels: Schlüssel-Wert-Paare an Deinen Maschinen, zum Beispiel role=web und env=prod.
• Selektor: Jede Firewall beschreibt mit einem Selektor, welche Labels eine Maschine tragen muss, damit die Firewall auf sie greift.

Du weist eine Firewall also nicht direkt einer Maschine zu, sondern über Labels. Das hat einen großen Vorteil: Eine neue Maschine mit den passenden Labels ist sofort geschützt, ohne dass Du eine Firewall anfassen musst.

Maschine web-1     Labels: role=web, env=prod

Firewall           Selektor             auf web-1
-----------------  -------------------  -----------------
Webserver          role=web             greift
SSH aus dem Büro   env=prod             greift
Datenbank intern   role=db              greift nicht

Auf web-1 gelten damit die Regeln von „Webserver“ und „SSH aus dem Büro“ zusammen.

Was erlaubt ist und was gesperrt wird

1. Greift keine aktive Firewall auf eine Maschine, bleibt ihr Verkehr unverändert.
2. Greift mindestens eine, ist eingehend alles gesperrt, was keine Regel ausdrücklich erlaubt. Ausgehender Verkehr bleibt offen.
3. Sobald mindestens eine ausgehende Regel greift, ist auch ausgehend alles gesperrt, was keine ausgehende Regel erlaubt.
4. Greifen mehrere Firewalls, addieren sich ihre Regeln. Es gibt keine Reihenfolge und keine Priorität, weil es nur Erlaubnisse gibt und sich Erlaubnisse nicht widersprechen können.

Außerdem gilt immer:

• Antworten kommen durch. Die Firewall erkennt zusammengehörige Verbindungen. Antworten auf eine erlaubte Verbindung brauchen keine eigene Regel, egal in welche Richtung.
• Grundfunktionen bleiben erlaubt. Die Vergabe der IP-Adresse per DHCP und die IPv6-Nachbarerkennung funktionieren auch bei einer gesperrten Maschine.
• Sperren von lima-city haben Vorrang. Eine eigene Regel kann weder eine Netzwerksperre noch die Sperre für ausgehende E-Mails über SMTP (Port 25 und 465) aufheben.

Wegen Punkt 4 lohnt es sich, Firewalls klein und thematisch zu schneiden: eine breite Firewall „SSH aus dem Büro“ für alle Produktionsmaschinen und eine enge „Datenbank für die App-Server“ ergänzen sich, statt sich in die Quere zu kommen.

Schnellstart: einen Webserver absichern

In diesem Beispiel erlaubst Du auf einem Webserver HTTP und HTTPS für alle und SSH nur von Deiner eigenen IP-Adresse. Alles andere wird eingehend gesperrt.

1. Labels an der Maschine setzen

1. Öffne in der Verwaltung Virtuelle Maschinen und wähle Deinen Webserver aus.
2. Wechsle in den Tab Firewall.
3. Trage unter Labels im Feld Eigene Labels role=web ein und bestätige mit Enter.
4. Klicke auf Labels speichern.

2. Firewall anlegen

1. Öffne im Menü unter Virtuelle Maschinen den Punkt Firewalls und klicke auf Firewall erstellen.
2. Gib einen Namen ein, zum Beispiel „Webserver öffentlich“.
3. Trage als Selektor role=web ein und bestätige mit Enter. Unter Passende Maschinen erscheint jetzt Dein Webserver. Fehlt er, stimmen Label und Selektor nicht überein.

3. Regeln hinzufügen

1. Klicke auf Regel hinzufügen. Wähle eingehend, Protokoll TCP, Ports 80,443 und als Quelle beliebige Adresse. Klicke auf Hinzufügen.
2. Klicke erneut auf Regel hinzufügen. Wähle eingehend, Protokoll TCP, Port 22 und als Quelle IP-Adressen. Trage Deine öffentliche IP-Adresse ein, zum Beispiel 203.0.113.7, und eine Bemerkung wie „SSH Büro“.
3. Klicke auf Firewall erstellen.

4. Prüfen

1. Öffne wieder den Tab Firewall Deines Webservers. Der Status wechselt nach wenigen Momenten von Änderung wird angewendet auf Regeln angewendet.
2. Unter Wirksame Regeln siehst Du alle Regeln, die jetzt auf der Maschine gelten, mit den tatsächlich verwendeten Adressen.
3. Teste von Deinem Rechner aus, ob die erlaubten Dienste erreichbar sind, zum Beispiel:

curl -I http://203.0.113.10
ssh root@203.0.113.10

Von einem anderen Internetanschluss aus sollte SSH jetzt nicht mehr erreichbar sein.

Labels

Ein Label ist ein Schlüssel mit optionalem Wert:

env=prod
role=web
backup

• Schlüssel und Werte bestehen aus Kleinbuchstaben, Ziffern, Punkt, Unterstrich und Bindestrich und beginnen mit einem Buchstaben oder einer Ziffer. Großbuchstaben werden automatisch kleingeschrieben: Env=Prod und env=prod sind dasselbe.
• Ein Label ohne Wert, zum Beispiel backup, ist eine reine Markierung.
• Jeder Schlüssel kommt an einer Maschine nur einmal vor. Trägst Du env=staging ein, ersetzt das ein vorhandenes env=prod.
• Eine Maschine kann bis zu 64 eigene Labels tragen.

Labels bearbeitest Du im Tab Firewall der Maschine. Das Eingabefeld schlägt Dir Schlüssel und Werte vor, die Du in Deinem Account schon verwendest. So bleibt die Schreibweise über alle Maschinen hinweg einheitlich.

Labels, die wir automatisch vergeben

Jede Maschine trägt zusätzlich Labels, die wir aus ihr selbst ableiten. Du musst dafür nichts einrichten und kannst sie nicht ändern:

Du findest sie im Tab Firewall der Maschine im Hinweis unter den Labels. Mit lima.uid bindest Du eine Firewall an genau eine Maschine, ohne an dieser Maschine etwas einzutragen.

Der Präfix lima. ist für diese Labels reserviert. Eigene Labels, die damit beginnen, werden abgewiesen.

Selektoren

Der Selektor beschreibt, auf welche Maschinen eine Firewall greift. Er besteht aus einer oder mehreren Bedingungen:

Mehrere Bedingungen müssen alle zutreffen. Im Formular trägst Du jede Bedingung einzeln ein und bestätigst sie mit Enter; Du kannst sie aber auch mit Komma getrennt auf einmal eingeben:

env=prod,role in (app,worker),!wartung

Weitere Labels an der Maschine stören nie. Der Selektor beschreibt, was mindestens vorhanden sein muss, keine exakte Übereinstimmung.

Zwei Feinheiten

Verneinungen treffen auch Maschinen ohne das Label. env!=prod passt nicht nur auf Maschinen mit einem anderen env, sondern auch auf Maschinen, die gar kein env tragen. Dasselbe gilt für notin und !.

Ein Selektor braucht mindestens eine einschließende Bedingung (env=prod, backup oder role in (…)). Ein Selektor, der nur ausschließt, wird abgewiesen:

env!=prod            abgelehnt
role=web,env!=prod   in Ordnung
backup,!wartung      in Ordnung

Der Grund: env!=prod würde jede Maschine ohne env treffen, auch jede, die Du erst später anlegst. Weil eine greifende Firewall alles sperrt, was sie nicht erlaubt, wäre eine solche neue Maschine sofort von außen unerreichbar. Die Vorschau im Formular kann davor nicht warnen, weil die Maschine von morgen dort noch nicht auftaucht.

Ein leerer Selektor ist erlaubt. Die Firewall greift dann auf keine Maschine. Das ist praktisch, wenn Du erst die Regeln aufbauen und die Firewall später binden möchtest.

Regeln

Jede Regel erlaubt Verkehr. Sie besteht aus:

Bei einer eingehenden Regel ist die Gegenstelle die Quelle, bei einer ausgehenden das Ziel. Die andere Seite ist immer Deine Maschine selbst.

Eine Regel darf höchstens 15 Ports enthalten, ein Bereich wie 8000-8999 zählt dabei doppelt. Brauchst Du mehr, verteile die Ports auf mehrere Regeln.

ICMP erlaubt Ping und die Fehlermeldungen des Netzwerks, für IPv4 und IPv6 gleichermaßen.

Feste IP-Adressen und Netze

Trage einzelne Adressen oder Netze in CIDR-Schreibweise ein, getrennt durch Kommas. IPv4 und IPv6 dürfen gemischt werden:

203.0.113.7, 198.51.100.0/24, 2001:db8::/32

Ein Netz muss mit seiner Netzadresse angegeben werden. 10.0.5.17/24 wird abgewiesen, weil unklar ist, ob Du die einzelne Adresse 10.0.5.17 oder das ganze Netz 10.0.5.0/24 meinst. Die Fehlermeldung schlägt Dir beide Schreibweisen vor.

Maschinen nach Selektor als Gegenstelle

Statt fester Adressen kannst Du als Quelle oder Ziel einen Selektor angeben, zum Beispiel role=app. Er wird in die IP-Adressen aller passenden Maschinen aufgelöst, immer nur innerhalb Deines eigenen Accounts. Eine Maschine eines anderen Kunden wird nie erlaubt, auch wenn sie dieselben Labels trägt.

Kommt später eine Maschine mit passenden Labels hinzu, ist sie automatisch erlaubt. Fällt eine weg, ist sie automatisch nicht mehr erlaubt. Du musst dafür keine Regel anfassen.

Trifft der Selektor gerade keine Maschine mit IP-Adresse, wird die Regel übersprungen. Das siehst Du im Tab Firewall der Maschine bei den wirksamen Regeln.

$self: eine Firewall für alle Umgebungen

In einem Gegenstellen-Selektor steht $self für den Wert, den die Maschine, auf die die Regel gerade angewendet wird, unter diesem Schlüssel trägt:

Quelle: role=app,env=$self

Auf einer Datenbank mit env=prod erlaubt diese Regel die App-Server mit env=prod. Auf der Staging-Datenbank mit env=staging erlaubt dieselbe Regel die Staging-App-Server. Ohne $self bräuchtest Du eine Firewall pro Umgebung.

$self funktioniert auch in einer Werteliste, zum Beispiel env in ($self,shared). Trägt die Maschine den Schlüssel nicht, wird die Regel auf ihr übersprungen. Sie erlaubt dann bewusst nicht alle Maschinen mit diesem Schlüssel.

$self ist nur in Gegenstellen möglich, nicht im Selektor der Firewall selbst.

Ausgehenden Verkehr einschränken

Solange keine ausgehende Regel greift, darf Deine Maschine jede ausgehende Verbindung aufbauen. Mit der ersten ausgehenden Regel wechselst Du bewusst in den Allow-List-Betrieb: Ab dann sind nur noch die ausdrücklich erlaubten ausgehenden Verbindungen möglich.

Das ist sinnvoll, wenn eine Maschine nur mit wenigen bekannten Zielen sprechen soll, zum Beispiel ein Datenbankserver. Eine typische Grundausstattung, damit Namensauflösung, Zeitabgleich und Paketaktualisierungen weiter funktionieren:

Prüfe danach, ob alles Nötige funktioniert, zum Beispiel mit apt update oder dnf check-update, und ergänze gezielt weitere Ziele, etwa die Adressen eines externen Backup-Dienstes.

Eine Regel mit Protokoll „alle Protokolle“, ohne Ports und mit beliebigem Ziel erlaubt wieder jeden ausgehenden Verkehr. Allein ändert sie nichts. Sie ist nur nötig, wenn eine andere Firewall auf derselben Maschine ausgehend einschränkt und Du das für diese Maschine wieder aufheben möchtest.

Praxisbeispiele

Öffentlicher Webserver

HTTP und HTTPS aus dem Internet, sonst nichts hinein.

Selektor:  role=web
Regel:     eingehend  TCP  80,443  Quelle: beliebige Adresse

Da keine ausgehende Regel greift, kann die Maschine weiterhin Updates laden und externe Dienste erreichen.

SSH nur aus dem Büro für alle Produktionsmaschinen

Selektor:  env=prod
Regel:     eingehend  TCP  22  Quelle: 203.0.113.7

Diese Firewall ergänzt die vom Webserver. Auf einer Maschine mit env=prod,role=web greifen beide, erlaubt sind dann HTTP, HTTPS und SSH aus dem Büro.

Datenbank nur für die App-Server derselben Umgebung

Selektor:  role=db
Regel:     eingehend  TCP  3306  Quelle: role=app,env=$self

Auf der Prod-Datenbank sind genau die Prod-App-Server erlaubt, auf der Staging-Datenbank die Staging-App-Server. Ein neuer App-Server ist erlaubt, sobald er role=app und das passende env trägt.

Cache für mehrere Rollen

App- und Worker-Server dürfen beide auf Redis zugreifen, mit einer Regel:

Selektor:  role=cache
Regel:     eingehend  TCP  6379  Quelle: role in (app,worker)

Monitoring von einem zentralen Server

Ein Monitoring-Server mit role=monitoring fragt auf allen Produktionsmaschinen Kennzahlen ab, zum Beispiel vom Prometheus Node Exporter:

Selektor:  env=prod
Regel:     eingehend  TCP  9100  Quelle: role=monitoring

Genau eine bestimmte Maschine

Eine einzelne Maschine absichern, ohne an ihr Labels zu pflegen:

Selektor:  lima.uid=ezvfccc3
Regel:     eingehend  TCP  443  Quelle: beliebige Adresse

Grundschutz für alle Maschinen eines Standorts

Weil lima.location automatisch vergeben wird, greift eine solche Firewall auch auf Maschinen ohne eigene Labels:

Selektor:  lima.location=fra1
Regeln:    eingehend  TCP   22  Quelle: 203.0.113.7
           eingehend  ICMP      Quelle: beliebige Adresse

Grundschutz mit Ausnahme für Wartungsarbeiten

Selektor:  env=prod,!wartung
Regel:     eingehend  TCP  22  Quelle: 203.0.113.7

Setzt Du an einer Maschine das Label wartung, fällt sie aus dieser Firewall heraus. Achtung: Fällt damit die letzte zutreffende Firewall weg, ist die Maschine anschließend eingehend vollständig offen, nicht gesperrt.

Wo Du was siehst

• Firewalls im Menü unter Virtuelle Maschinen: alle Firewalls mit Selektor, Status, Anzahl der Regeln und der getroffenen Maschinen.
• Firewall erstellen und bearbeiten: Unter Passende Maschinen siehst Du sofort, auf welche Maschinen der Selektor gerade passt.
• Detailseite einer Firewall: Selektor, Regeln und die Maschinen, auf die sie angewendet wird.
• Tab „Firewall“ einer Maschine: welche Firewalls auf diese Maschine greifen, ihre Labels und welche Regeln in Summe wirksam sind, mit den bereits aufgelösten Adressen.

Änderungen werden im Hintergrund auf die Maschine übertragen, meist innerhalb weniger Sekunden. Der Status im Tab Firewall zeigt den Stand:

Lassen sich die Regeln einer Maschine nicht anwenden, bleibt sie zu ihrem Schutz gesperrt: Es gilt keine Deiner Freigaben, bis Du die zutreffenden Firewalls anpasst. Ein Speichern derselben Einstellungen ändert daran nichts.

Limits

Bei den wirksamen Regeln pro Maschine zählt jede Regel einfach, egal wie viele IPv4- und IPv6-Adressen ihre Gegenstelle umfasst. Nur eine ICMP-Regel zählt doppelt, wenn sie IPv4 und IPv6 betrifft. Würde eine Änderung an einer Firewall oder an Labels dieses Limit überschreiten, wird sie beim Speichern abgelehnt, und die Meldung nennt Dir die betroffene Maschine.

Fehlerbehebung

Häufige Fragen

Brauche ich zusätzlich eine Firewall im Betriebssystem?

Nicht zwingend. Die Cloud-Firewall hält unerwünschten Verkehr von Deiner Maschine fern, bevor er sie erreicht, und lässt sich zentral für viele Maschinen pflegen. Eine Firewall im Betriebssystem kann zusätzlich sinnvoll sein, etwa um einzelne Dienste nur lokal erreichbar zu machen. Beide gelten unabhängig voneinander.

Gilt die Firewall auch für Verbindungen zwischen meinen eigenen Maschinen?

Ja. Auch Verbindungen von einer Deiner Maschinen zur anderen müssen von einer Regel erlaubt sein, sobald auf der Zielmaschine eine Firewall greift. Am einfachsten geht das mit einem Selektor als Quelle, zum Beispiel role=app.

Gilt die Firewall für IPv4 und IPv6?

Ja, für beide. Regeln mit beliebiger Gegenstelle gelten für beide Adressfamilien, Regeln mit festen Adressen oder Selektoren für die Adressfamilien der jeweiligen Adressen.

Was passiert mit bestehenden Verbindungen, wenn ich eine Regel entferne?

Bereits aufgebaute Verbindungen können bestehen bleiben, bis sie beendet werden. Neue Verbindungen werden sofort nach der Anwendung gesperrt. Möchtest Du eine laufende Verbindung sicher trennen, starte den betroffenen Dienst neu.

Wie schnell wirkt eine Änderung?

Meist innerhalb weniger Sekunden. Nach einer Änderung an einer Firewall oder an Labels berechnen wir alle Maschinen Deines Accounts neu, weil ein Selektor auf andere Maschinen verweisen kann. Der Tab Firewall der Maschine zeigt Dir, wann die Änderung angewendet ist.

Kann ich eine Firewall vorübergehend abschalten?

Ja. Entferne beim Bearbeiten das Häkchen bei aktiv. Die Firewall bleibt mit allen Regeln gespeichert, greift aber auf keine Maschine mehr. Beachte, dass eine Maschine ohne zutreffende Firewall eingehend wieder vollständig offen ist.