Nftables und layer2 Firewall: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
(→Regeln) |
|||
| Zeile 1: | Zeile 1: | ||
=Vorab= | =Vorab= | ||
;Bei Virtualisierungen Bridge Ports auf Promisc setzen | ;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. | ||
| + | *CLI-Äquivalent: <code>ip link set enp0s8 promisc on</code> | ||
[[Datei:Vm-promisc-1.png]] | [[Datei:Vm-promisc-1.png]] | ||
| + | =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= | =Installation der Bridgeutils= | ||
| Zeile 29: | Zeile 35: | ||
bridge_stp no | bridge_stp no | ||
</pre> | </pre> | ||
| − | + | ;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 | *ifup vmbr0 | ||
| − | |||
=Bridge-Filterung= | =Bridge-Filterung= | ||
| − | + | ==Arten von Bridge-Ketten== | |
| − | =Arten von Bridge-Ketten= | ||
*Die Bridge-Familie bietet vier Kettenarten: | *Die Bridge-Familie bietet vier Kettenarten: | ||
| − | |||
;prerouting: | ;prerouting: | ||
| − | *Hier können Pakete vor der Forward-Datenbank (FDB) Entscheidung gefiltert werden. | + | *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. | + | *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. | + | *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. | *Nach der FDB-Entscheidung können Pakete entweder dem Eingangs- oder dem Weiterleitweg folgen. | ||
;input: | ;input: | ||
| − | *Hier können Pakete gefiltert werden, die an den IP-Stack übergeben werden. | + | *Hier können Pakete gefiltert werden, die an den IP-Stack übergeben werden. |
| − | *Wenn | + | *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: | + | ;forward: |
| − | *Diese Hook | + | *Diese Hook filtert Pakete, die von einem Bridge-Port eingehen und an einen anderen Bridge-Port geliefert werden (der Bridge-Weiterleitungspfad). |
| − | ;output: | + | *'''Im vorliegenden Szenario wird ausschließlich diese Chain genutzt''' – die Bridge hat keine IP-Adresse im Datenpfad, es wird rein gebridged. |
| − | *Hier können Pakete gefiltert werden, die vom IP-Stack kommen und deren Ziel | + | ;output: |
| − | ;postrouting: | + | *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. | *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: <code>nft add rule bridge filter forward ether type arp accept</code> | ||
| + | |||
=Zustandsabhängige Filterung= | =Zustandsabhängige Filterung= | ||
| − | *Die Bridge-Familie unterstützt | + | *Die Bridge-Familie unterstützt Connection Tracking (Verbindungsverfolgung). |
| − | * | + | *Durch Matching auf den Verbindungsstatus (<code>ct state</code>) können bestehende Verbindungen automatisch durchgelassen werden, ohne jede Richtung explizit freizuschalten. |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=Bridge Firewall= | =Bridge Firewall= | ||
{{#drawio:bridge-fw}} | {{#drawio:bridge-fw}} | ||
=Regeln= | =Regeln= | ||
| − | *cat | + | ;Konzept |
| + | *<code>enp0s8</code> ist die '''offene''' Seite (z.B. Richtung Internet/unsicheres Netz) | ||
| + | *<code>enp0s9</code> ist die '''gefilterte''' Seite (z.B. internes Netz) | ||
| + | *Policy ist <code>drop</code> – alles was nicht explizit erlaubt ist, wird verworfen | ||
| + | *cat /etc/nftables.conf | ||
<pre> | <pre> | ||
#!/usr/sbin/nft -f | #!/usr/sbin/nft -f | ||
| + | |||
define open = enp0s8 | define open = enp0s8 | ||
define filter = enp0s9 | define filter = enp0s9 | ||
| + | |||
flush ruleset | flush ruleset | ||
| + | |||
table bridge filter { | table bridge filter { | ||
chain forward { | chain forward { | ||
type filter hook forward priority 0; policy drop; | type filter hook forward priority 0; policy drop; | ||
| + | |||
| + | # Bestehende Verbindungen durchlassen (Connection Tracking) | ||
ct state established,related accept | ct state established,related accept | ||
| − | # | + | |
| − | + | # ARP freischalten (beide Richtungen notwendig) | |
| + | iif $open ether type arp accept | ||
iif $filter 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 | #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 | #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 | #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 | #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 | #iif $open oif $filter ct state new accept | ||
| − | # | + | |
| + | # Abgelehnte Pakete loggen (sichtbar mit journalctl) | ||
log prefix " nft-drop" | log prefix " nft-drop" | ||
} | } | ||
} | } | ||
| − | |||
</pre> | </pre> | ||
| + | ;Hinweis zu ICMP | ||
| + | *Die ICMP-Regel matcht nur IPv4. Für IPv6 wäre zusätzlich <code>meta l4proto icmpv6</code> notwendig. | ||
| + | ;Hinweis zum Log-Prefix | ||
| + | *Das führende Leerzeichen in <code>" nft-drop"</code> ist Absicht – es verbessert die Lesbarkeit im Kernel-Log. | ||
=Regel Handling= | =Regel Handling= | ||
| Zeile 108: | Zeile 128: | ||
;Kontrolle der Regeln | ;Kontrolle der Regeln | ||
*nft list ruleset | *nft list ruleset | ||
| − | ; | + | ;Löschen der Regeln |
*nft flush ruleset | *nft flush ruleset | ||
| + | |||
=Live Log der Regel Verstösse= | =Live Log der Regel Verstösse= | ||
*journalctl -f -t kernel -g "nft-drop" | *journalctl -f -t kernel -g "nft-drop" | ||
| + | |||
| + | =Weiterführende Artikel= | ||
| + | *[[nftables schnellstart]] | ||
Version vom 5. Mai 2026, 16:21 Uhr
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.
- CLI-Äquivalent:
ip link set enp0s8 promisc on
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
Regeln
- Konzept
enp0s8ist die offene Seite (z.B. Richtung Internet/unsicheres Netz)enp0s9ist 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 icmpv6notwendig.
- 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"

