linux-rhel-centos-fedora security firewall design architecture rhel

Firewalld Design: Conceptual Zone Model (Artikel 093)

Architektur-Guide für komplexe Firewall-Szenarien. Erfahren Sie, wie Sie ein Zonen-Modell für DMZs, interne Netze und Management-Schnittstellen auf RHEL-Basis entwerfen.

# Firewall Design: Das konzeptionelle Zonen-Modell

TL;DR / Management Summary Ein Server ist nur so sicher wie seine schwächste Schnittstelle. In diesem Modul verlassen wir die reine Befehlsebene und widmen uns dem Design. Ein professionelles Zonen-Modell trennt den Traffic konsequent nach Vertrauensstufen. Wir schauen uns an, wie wir eine RHEL-Maschine als Security-Gateway oder gehärteten Applikationsserver mit getrennten Zonen für Management, Datenbank und Public Traffic aufbauen.


# 1. Einführung & Architektur

Die Philosophie der Segmentierung.

Anstatt alle Regeln in einen “Haufen” (Chain) zu werfen, nutzen wir Zonen als logische Container.

# Das 3-Zonen-Modell (Mermaid)

graph TD
    subgraph "External Network (Untrusted)"
        A[Internet]
    end
    subgraph "RHEL Gateway / Host"
        B{firewalld}
        B -->|Zone: public| C[Interface eth0: Web Traffic]
        B -->|Zone: dmz| D[Interface eth1: App Proxy]
        B -->|Zone: trusted| E[Interface eth2: Backend DB]
        B -->|Zone: mgmt| F[Source IP: VPN-Net: Admin Access]
    end
    C --- A
    D --- G[App Server Cluster]
    E --- H[Internal DB Cluster]

# 2. Die Standard-Zonen im Enterprise-Einsatz

Wann nutze ich welche Zone?

  1. drop: Pakete werden ohne Antwort verworfen. Ideal für bekannte Angreifer-IPs.
  2. block: Pakete werden mit ICMP-Reject abgelehnt.
  3. public: Nur absolute Basis-Dienste (HTTP/S, SSH).
  4. dmz: Für Dienste, die von außen erreichbar sind, aber das interne Netz nicht sehen dürfen.
  5. internal: Vertrauenswürdiges Netz. Alle Dienste für Kollegen offen.
  6. trusted: Voller Zugriff. Nur für Loopback oder dedizierte Backup-Netze.

# 3. Design-Pattern: IP-basierte Zonen (Sources)

Sicherheit ohne zusätzliche Netzwerkkarten.

Man kann Zonen auch basierend auf der Quell-IP statt auf dem Interface zuweisen. Das ist das mächtigste Feature für Admins.

# Szenario: Admin-Zugriff nur aus dem Management-Netz

Wir wollen, dass der SSH-Port nur für das Management-Team (10.50.0.0/24) offen ist, egal auf welchem Interface sie reinkommen.

# 1. SSH in der 'public' Zone verbieten
sudo firewall-cmd --permanent --zone=public --remove-service=ssh

# 2. Das Management-Netz der 'internal' Zone zuweisen
sudo firewall-cmd --permanent --zone=internal --add-source=10.50.0.0/24

# 3. SSH in der 'internal' Zone erlauben
sudo firewall-cmd --permanent --zone=internal --add-service=ssh

sudo firewall-cmd --reload

# 4. Day-2 Operations: Custom Services

Lesbarkeit erhöhen.

Erstellen Sie eigene Service-Definitionen (/etc/firewalld/services/), anstatt kryptische Port-Nummern in die Konfiguration zu schreiben.

# Beispiel: myapp.xml

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>My Enterprise App</short>
  <description>Custom Go-Application for Data-Processing</description>
  <port protocol="tcp" port="8080"/>
  <port protocol="udp" port="8081"/>
</service>

Danach können Sie einfach nutzen: firewall-cmd --add-service=myapp.


# 5. Troubleshooting & “War Stories”

Design-Fehler finden.

# Story 1: “Der Default-Zone Fallstrick”

Symptom: Ein neuer Server wird ans Netz gehängt, aber niemand kommt per SSH drauf. Ursache: Die Default-Zone wurde aus “Sicherheitsgründen” auf drop gesetzt, und das Interface wurde keiner anderen Zone zugewiesen. Lösung: Immer erst das Interface explizit einer Zone zuordnen (--add-interface), bevor man die Default-Zone ändert.

# Story 2: “Überlappende Quellen”

Symptom: Ein Server aus dem Netz 10.0.0.0/24 wird der Zone internal zugeordnet, bekommt aber trotzdem nur Zugriff auf public Regeln. Ursache: firewalld verarbeitet Zonen in einer festen Reihenfolge. Wenn eine IP in zwei Zonen passt, gewinnt die spezifischere Regel oder die Interface-Regel (je nach Konfiguration). Lösung: Prüfen Sie mit firewall-cmd --get-active-zones, welche IPs aktuell wo gemappt sind.


# 6. Fazit & Empfehlung

  • Minimierung: Deaktivieren Sie alle Zonen, die Sie nicht brauchen.
  • Whitelisting: Nutzen Sie die internal Zone für alle administrativen Aufgaben und beschränken Sie sie auf Quell-IPs.
  • Dokumentation: Zeichnen Sie Ihr Zonen-Modell auf (wie im Mermaid-Diagramm oben), bevor Sie die erste Regel tippen.

# Anhang: Cheatsheet

Aufgabe Befehl
Default Zone ändern firewall-cmd --set-default-zone=<zone>
Interface verschieben firewall-cmd --zone=<zone> --change-interface=<if>
Source IP hinzufügen firewall-cmd --zone=<zone> --add-source=<ip>
Aktive Quellen sehen firewall-cmd --get-active-zones
Service Info sehen firewall-cmd --info-service=<name>