Rocky fw

Die Firewall

Ziel

Die Firewall trennt drei Netzbereiche voneinander: das Schulungsnetz (WAN), die DMZ und das interne LAN. Sie übernimmt gleichzeitig die Aufgaben eines Routers, eines DHCP-Servers für das LAN und kontrolliert den gesamten Netzverkehr zwischen den Zonen.

Netzplan

Interface	Zone	Netz	IP Firewall
enp0s3	external	192.168.HS.0/24 (Schulungsnetz)	192.168.HS.2XX
enp0s8	dmz	10.88.2XX.0/24	10.88.2XX.1
enp0s9	internal	172.26.2XX.0/24	172.26.2XX.1

Feste IP-Adressen

System	Netz	IP	Dienste
fw.itXX.int	WAN/DMZ/LAN	siehe oben	firewalld, Kea DHCP
ns.itXX.int	DMZ	10.88.2XX.21	BIND9 (DNS)
http.itXX.int	DMZ	10.88.2XX.11	Apache
ldap.itXX.int	LAN	172.26.2XX.3	OpenLDAP
client.itXX.int	LAN	per DHCP	Ansible Control Node

Dienste auf der Firewall

firewalld

Zonenverwaltung, Paketfilterung, Masquerading

Kea DHCP4

IP-Vergabe für das LAN (172.26.2XX.0/24)

Regelwerk

Von	Nach	Erlaubt	Gesperrt
LAN	WAN	alles (Masquerading)	—
LAN	DMZ	alles (SSH, DNS, HTTP, HTTPS ...)	—
DMZ	WAN	alles (Masquerading)	—
WAN	DMZ	UDP+TCP/53 nur auf ns, TCP/80+443 nur auf http	alles andere
WAN	LAN	—	alles
DMZ	LAN	TCP/636 (LDAPS)	alles andere

LAN ist vertrauenswürdig

Aus dem internen Netz darf alles raus – sowohl ins WAN als auch in die DMZ. So kann Ansible von client.itXX.int per SSH alle Maschinen erreichen.

WAN → DMZ gezielt

Aus dem Internet kommen nur die Dienste rein, die wirklich öffentlich sein sollen – und nur auf die jeweilige Ziel-IP. Dafür werden Rich Rules verwendet.

DMZ → LAN nur LDAPS

Die DMZ-Server (ns, http) authentifizieren sich über SSSD gegen den LDAP-Server im LAN. Alle anderen Verbindungen von der DMZ ins LAN sind gesperrt – ein kompromittierter DMZ-Server soll keinen freien Zugriff auf das interne Netz bekommen.

Umsetzung

Netzwerkkonfiguration

enp0s3 (WAN)

Die WAN-Verbindung bekommt eine feste IP im Schulungsnetz sowie Gateway und DNS des KIT-Routers

• nmcli con mod enp0s3 ipv4.addresses 192.168.HS.2XX/24
• nmcli con mod enp0s3 ipv4.gateway 192.168.HS.1
• nmcli con mod enp0s3 ipv4.dns 192.168.HS.1
• nmcli con mod enp0s3 ipv4.method manual
• nmcli con up enp0s3

enp0s8 (DMZ)

Das DMZ-Interface bekommt die Gateway-IP für das DMZ-Netz – kein Gateway, kein DNS nötig

• nmcli con mod enp0s8 ipv4.addresses 10.88.2XX.1/24
• nmcli con mod enp0s8 ipv4.method manual
• nmcli con up enp0s8

enp0s9 (LAN)

Das LAN-Interface wird Gateway für alle internen Clients

• nmcli con mod enp0s9 ipv4.addresses 172.26.2XX.1/24
• nmcli con mod enp0s9 ipv4.method manual
• nmcli con up enp0s9

IP-Forwarding aktivieren

Ohne IP-Forwarding leitet der Kernel keine Pakete zwischen den Interfaces weiter – die Firewall wäre kein Router

• echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/99-forwarding.conf
• sysctl -p /etc/sysctl.d/99-forwarding.conf

firewalld

Installation und Start

firewalld ist auf Rocky meist vorinstalliert, zur Sicherheit

• dnf install -y firewalld
• systemctl enable --now firewalld

Interfaces den Zonen zuweisen

Jedes Interface wird einer Zone zugeordnet – darüber entscheidet firewalld welche Regeln gelten

• firewall-cmd --permanent --zone=external --change-interface=enp0s3
• firewall-cmd --permanent --zone=dmz --change-interface=enp0s8
• firewall-cmd --permanent --zone=internal --change-interface=enp0s9

Masquerading

Masquerading ersetzt die Quell-IP ausgehender Pakete durch die externe IP der Firewall – so kommen LAN und DMZ hinter einer einzigen öffentlichen Adresse ins Internet

• firewall-cmd --permanent --zone=external --add-masquerade

LAN → alles: uneingeschränkt raus

Das interne Netz ist vertrauenswürdig – von hier darf alles raus, auch SSH für Ansible

• firewall-cmd --permanent --zone=internal --add-masquerade

WAN → DMZ: nur gezielt per Rich Rule

Statt ganze Dienste freizugeben, erlauben Rich Rules den Zugriff auf eine bestimmte Ziel-IP.

So landet DNS-Traffic nur auf dem Nameserver und HTTP nur auf dem Webserver.

DNS auf ns.itXX.int (10.88.2XX.21)

• firewall-cmd --permanent --zone=dmz --add-rich-rule='rule family="ipv4" destination address="10.88.2XX.21" service name="dns" accept'

HTTP und HTTPS auf http.itXX.int (10.88.2XX.11)

• firewall-cmd --permanent --zone=dmz --add-rich-rule='rule family="ipv4" destination address="10.88.2XX.11" service name="http" accept'
• firewall-cmd --permanent --zone=dmz --add-rich-rule='rule family="ipv4" destination address="10.88.2XX.11" service name="https" accept'

DMZ → LAN: nur LDAPS

Die DMZ-Server müssen sich gegen LDAP im LAN authentifizieren – nur Port 636 (LDAPS) wird durchgelassen

• firewall-cmd --permanent --zone=internal --add-rich-rule='rule family="ipv4" source address="10.88.2XX.0/24" service name="ldaps" accept'

Konfiguration laden

Alle permanent gesetzten Regeln werden erst nach reload aktiv

• firewall-cmd --reload

Kontrolle

Jede Zone einzeln prüfen – Interfaces, Services und Rich Rules müssen stimmen

• firewall-cmd --list-all --zone=external
• firewall-cmd --list-all --zone=dmz
• firewall-cmd --list-all --zone=internal

Kea DHCP4 für das LAN

Installation

• dnf install -y kea

Konfiguration

Kea lauscht nur auf enp0s9 (LAN) und verteilt IPs im Bereich .100–.200. Als Gateway und DNS-Server werden fw und ns eingetragen.

• vim /etc/kea/kea-dhcp4.conf

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": [ "enp0s9" ]
    },
    "lease-database": {
      "type": "memfile",
      "persist": true,
      "name": "/var/lib/kea/kea-leases4.csv"
    },
    "valid-lifetime": 3600,
    "subnet4": [
      {
        "subnet": "172.26.2XX.0/24",
        "pools": [ { "pool": "172.26.2XX.100 - 172.26.2XX.200" } ],
        "option-data": [
          { "name": "routers", "data": "172.26.2XX.1" },
          { "name": "domain-name-servers", "data": "10.88.2XX.21" },
          { "name": "domain-name", "data": "it2XX.int" }
        ]
      }
    ]
  }
}

Start

• systemctl enable --now kea-dhcp4

Kontrolle

• systemctl status kea-dhcp4
• cat /var/lib/kea/kea-leases4.csv