Nftables und layer2 Firewall

Vorab

Bei Virtualisierungen Bridge Ports auf Promisc setzen

• Dies erlaubt der virtuellen Netzwerkkarte, auch Pakete zu empfangen, die nicht an ihre MAC-Adresse gerichtet sind – notwendig für den Bridge-Betrieb.

Was ist eine Layer 2 Firewall?

• Eine normale Firewall arbeitet auf Layer 3 (IP-Ebene) und benötigt eine IP-Adresse im Datenpfad.
• Eine Layer 2 Firewall greift dagegen auf Ethernet-Ebene (MAC) – sie kann transparent zwischen zwei Netzwerksegmente gestellt werden, ohne eine eigene IP-Adresse im Datenpfad zu benötigen.
• Der Datenverkehr läuft über eine Bridge, die nftables zur Filterung nutzt.

Installation der Bridgeutils

• apt install bridge-utils

/etc/network/interfaces

auto lo
iface lo inet loopback

auto enp0s3
iface enp0s3 inet static
 address 10.0.10.11/24
 gateway 10.0.10.1

auto enp0s8
iface enp0s8 inet manual

auto enp0s9
iface enp0s9 inet manual

auto vmbr0
iface vmbr0 inet manual
    bridge_ports enp0s8 enp0s9
    bridge_fd 5
    bridge_stp no

Hinweise zur Konfiguration

bridge_fd 5

• Der Forward Delay beträgt 5 Sekunden – das Interface benötigt diese Zeit beim Hochfahren. Beim Testen kann das kurz irritieren.

bridge_stp no

• STP (Spanning Tree Protocol) ist deaktiviert. Da nur zwei Ports vorhanden sind, ist kein Loop möglich und STP nicht notwendig.
• ifup vmbr0

Bridge-Filterung

Arten von Bridge-Ketten

• Die Bridge-Familie bietet vier Kettenarten:

prerouting

• Hier können Pakete vor der Forward-Datenbank (FDB) Entscheidung gefiltert werden.
• Die FDB liefert den Bridge-Port, der für eine bestimmte Ziel-MAC-Adresse verwendet wird.
• Wenn es noch keinen Eintrag in der FDB für eine gegebene Ziel-MAC gibt, werden die Pakete an alle Bridge-Ports geflutet.
• Nach der FDB-Entscheidung können Pakete entweder dem Eingangs- oder dem Weiterleitweg folgen.

input

• Hier können Pakete gefiltert werden, die an den IP-Stack übergeben werden.
• Wenn die Bridge-Schnittstelle eine IP-Adresse hat und Pakete an diese IP-Adresse gehen, folgen die Pakete diesem Pfad (die Pakete verlassen die Bridge und treten in den IP-Stack ein).

forward

• Diese Hook filtert Pakete, die von einem Bridge-Port eingehen und an einen anderen Bridge-Port geliefert werden (der Bridge-Weiterleitungspfad).
• Im vorliegenden Szenario wird ausschließlich diese Chain genutzt – die Bridge hat keine IP-Adresse im Datenpfad, es wird rein gebridged.

output

• Hier können Pakete gefiltert werden, die vom IP-Stack kommen und deren Ziel ein Bridge-Port ist.

postrouting

• Hier können Pakete gefiltert werden, die entweder vom IP-Stack kommen oder von einem anderen Bridge-Port weitergeleitet werden.

ARP

• ARP ist im Gegensatz zur Layer 3 Firewall nicht automatisch freigeschaltet und muss explizit erlaubt werden.
• Ohne ARP-Freischaltung ist keine Kommunikation im Netz möglich, da MAC-Adressen nicht aufgelöst werden können.
• Beispiel zum Akzeptieren von ARP-Paketen: nft add rule bridge filter forward ether type arp accept

Zustandsabhängige Filterung

• Die Bridge-Familie unterstützt Connection Tracking (Verbindungsverfolgung).
• Durch Matching auf den Verbindungsstatus (ct state) können bestehende Verbindungen automatisch durchgelassen werden, ohne jede Richtung explizit freizuschalten.

Bridge Firewall

[Bearbeiten]

Regeln

Konzept

• enp0s8 ist die offene Seite (z.B. Richtung Internet/unsicheres Netz)
• enp0s9 ist die gefilterte Seite (z.B. internes Netz)
• Policy ist drop – alles was nicht explizit erlaubt ist, wird verworfen
• cat /etc/nftables.conf

#!/usr/sbin/nft -f

define open    = enp0s8
define filter  = enp0s9

flush ruleset

table bridge filter {
        chain forward {
                type filter hook forward priority 0; policy drop;

                # Bestehende Verbindungen durchlassen (Connection Tracking)
                ct state established,related accept

                # ARP freischalten (beide Richtungen notwendig)
                iif $open   ether type arp accept
                iif $filter ether type arp accept

                #### ICMP von filter nach open freischalten (IPv4)
                #iif $filter oif $open ip protocol icmp ct state new accept

                #### DNS von filter nach open freischalten
                #iif $filter oif $open udp dport 53 ct state new accept

                #### HTTP von filter nach open freischalten
                #iif $filter oif $open tcp dport 80 ct state new accept

                #### HTTPS von filter nach open freischalten
                #iif $filter oif $open tcp dport 443 ct state new accept

                #### Alles von open nach filter freischalten
                #iif $open oif $filter ct state new accept

                # Abgelehnte Pakete loggen (sichtbar mit journalctl)
                log prefix " nft-drop"
        }
}

Hinweis zu ICMP

• Die ICMP-Regel matcht nur IPv4. Für IPv6 wäre zusätzlich meta l4proto icmpv6 notwendig.

Hinweis zum Log-Prefix

• Das führende Leerzeichen in " nft-drop" ist Absicht – es verbessert die Lesbarkeit im Kernel-Log.

Regel Handling

Laden der Regeln

• nft -f /etc/nftables.conf

Kontrolle der Regeln

• nft list ruleset

Löschen der Regeln

• nft flush ruleset

Live Log der Regel Verstösse

• journalctl -f -t kernel -g "nft-drop"

Weiterführende Artikel

• nftables schnellstart