FirewallD Zonen-Konzept erstellen

HigH_HawK

Cadet 4th Year
Registriert
Jan. 2008
Beiträge
105
Hallo Community,

ich arbeite gerade an einem FirewallD Zonen-Konzept, hänge dabei aber gerade etwas fest und bräuchte einen kleinen Denkanstoß, den ich leider bei Google nicht finden konnte.

Was möchte ich machen?
Ich habe einen Server mit zwei NICs und einem VNIC für ein VLAN. NIC1 soll ganz normal die externen Verbindungen verarbeiten. Über dieses NIC soll ich per SSH und nur von einer bestimmten Source-IP rein und der Server auf seine Update-Server rauskommen. NIC2 und VNIC sind interne Controller und sollen auch nur im VRack über einen bestimmten Port erreichbar sein.

Meine Idee war also, dass ich NIC1 der Standard-Zone "public" zuweise und dort dann alle externen Regeln eintrage, sowie NIC2 und VNIC der Zone "internal" zuweise und darin die internen Regeln eintrage.

Würde diese Idee funktionieren, oder denke ich hier komplett in die falsche Richtung?

Ich danke jedem für seine Hilfe im Voraus

Grüße
Hawk
 
Erste Regel einer DMZ:
Die Maschine, welche die Sicherheit des LAN bestimmt, darf nie direkten Kontakt zum Internet haben.

Ich würde das nicht so machen.
 
@supastar: Leider ist nicht immer alles eine golden-grüne Wiese wo man nur Best Practices folgt ;)

@HigH_HawK: Neben dem reinen Firewalling musst dich auch um das Routing kümmern sofern gewünscht (oder eben nicht). NIC1 bekommt daher ein Gateway als auch die Default-Route und im Regelwerk erlaubst dann tcp/22 für $eine-feste-Source-IP, zweite Regel dann Drop. Ausgehende Regeln werden schon etwas komplizierter: Du kannst zwar nur ausgehend mit Destination-Port 80 & 443 arbeiten aber so könnte jeder von dem System aus "im Internet surfen". Den Zugriff auf die Update-Server über Destination-IP hat auch Stolperstellen, da sich die IPs ändern können oder sowieso aus mehreren Systemen besteht. Müsstest du googlen ob du Firewall-Regeln erstellen kannst und nur bestimmte Binaries zulassen kannst.

NIC2 & vNIC bekommen dann nur ihre IP & Netz konfiguriert und ein Gateway sofern vorhanden und genutzt sowie weitere einzelne Routen falls notwendig und im Regelwerk dann entsprechend die gewünschten Dienste.
Die Unterschiede zwischen den Zonen sind aber mMn nach marginal und dienen eher der Lesbarkeit eines menschlichen Admins, die vorgefertigten Settings sind naja... in vielen Fällen brauchbar, sollten aber immer(!) kontrolliert/geprüft und an die eigenen Bedürfnisse angepasst werden.
 
@supastar Grundsätzlich gebe ich Dir recht, aber es ist manchmal nicht einfach, der best practice zu folgen. Dieses Konstrukt wird im Oktober auch ausgetauscht, musste jetzt aber bis dahin abgesichert werden.

@snaxilian Danke dafür! Es ging nur um das Firewalling, da das Routing schon vorhanden ist. Ich habe jetzt die "public" Zone mit zwei Sources und dem ssh service versehen, so dass sich nur diese per SSH von außen mit dem Server verbinden können. Andere Services sind darüber nicht möglich.

Die Drop Regel muss ich noch hinzufügen, die habe ich scheinbar vergessen oder den Reload danach nicht gemacht.

Das VLAN habe ich in die "internal" gepackt und nur einen Port freigegeben, der von anderen Server im VRack angesprochen wird.
 
Eventuell ist die DROP-Rule auch schon automatisch bei dieser Zone gesetzt. Solltest du ja sehen wenn du dir die XML-Dateien ansiehst, die direkt die Zonen beschreiben (https://firewalld.org/documentation/) oder dir direkt das Regelwerk mit nftables/iptables anzeigen lässt. firewalld ist ja nichts anderes als ein Frontend für die Konfiguration von Zonen & Regeln. Entweder hast du sowieso ein Standard-Verhalten DROP o.ä. für diese Zone/Chain oder als entsprechende DROP-Regel innerhalb der Zone/Chain.
 
Die DROP-Rule ist im Standard nicht gesetzt, sondern gibt es nur als Zone. Geändert hatte ich es bis heute noch nicht. Ich habe jetzt einfach eine DROP Regel hinzugefügt und damit hatte sich das auch. Diese Lösung verschwindet sowieso im Oktober, wenn dann die neue Hardware da ist, denn da ist dann anhand einer pfSense eine Firewall davor geschaltet. Damit erziele ich dann die "Best Practice".

Danke für Deine Hilfe!
 
Zurück
Oben