Nftables und layer2 Firewall

Vorab

Bei Virtualisierungen Bridge Ports auf Promisc setzen

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

• ifup vmbr0

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 Ihre Bridge-Schnittstelle eine IP-Adresse hat und Pakete an diese IP-Adresse gehen (oder diese IP-Adresse als Gateway verwendet wird), folgen die Pakete diesem Pfad (in diesem Fall verlassen die Pakete die Bridge, um in den IP-Stack einzutreten, also werden die Pakete "geroutet").

forward

• Diese Hook kann verwendet werden, um Pakete zu filtern, die von einem Bridge-Port eingehen und an einen anderen Bridge-Port geliefert werden (dies ist der Bridge-Weiterleitungspfad, in diesem Fall werden die Pakete "gebridged").

output

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

postrouting

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

Zustandslose Filterung

Wenn Sie den TCP-Zielport in IPv4-Paketen filtern möchten:

• nft add rule bridge filter forward ether type ip tcp dport 22 accept

Ein weiteres Beispiel zum Akzeptieren von ARP-Paketen

• nft add rule bridge filter forward ether type arp accept

Zustandsabhängige Filterung

• Die Bridge-Familie unterstützt die Verbindungsverfolgung seit Linux-Kernel 5.3.
• Sie müssen nur auf den Verbindungsstatusinformationen aus Ihrer Regelmenge übereinstimmen, um dies zu aktivieren.
• Für diejenigen, die mit iptables vertraut sind: Dies bietet einen Ersatz für br_netfilter und das -m physdev-Match für iptables.

Beispiel: Zustandsabhängige Bridge-Firewall

• Das folgende Beispiel zeigt, wie eine zustandsabhängige Bridge-Firewall bereitgestellt wird.
• Dies setzt voraus, dass die Bridge-Schnittstelle keine IP-Adresse hat.

Angenommen, eine Bridge mit zwei Ports, eth0 und eth1

• Ein Desktop-Computer ist mit dem Bridge-Port eth0 verbunden.
• Ein Webserver (mit SSH für die Remote-Verwaltung) ist mit dem Bridge-Port eth1 verbunden.
• Die Uplink-Verbindung erfolgt über den Bridge-Port eth2.
• Die folgende Richtlinie ermöglicht es dem Desktop-Computer und dem Webserver, eine Verbindung zu initiieren. Von außen:
• Es kann keine Verbindung zum Desktop-Computer initiiert werden.
• Verbindungen zu den HTTP- und SSH-Diensten zum Server sind erlaubt.
• Von innen in die Bridge können der Desktop-Computer und der Webserver überall Verbindungen initiieren:

Regeln

#!/usr/sbin/nft -f

flush ruleset

table bridge filter {

        chain forward {
                type filter hook forward priority 0; policy drop;
                ct state established,related accept
                iif enp0s8 ether type arp accept
                iif enp0s9 ether type arp accept
                oifname "enp0s9" udp dport 53 ct state new accept
                oifname "enp0s9" tcp dport 80 ct state new accept
                oifname "enp0s9" tcp dport 443 ct state new accept
                oifname "enp0s9" ip protocol icmp ct state new accept
                # Loggen von abgelehnten Paketen
                log prefix " nftables drop: "
        }

}