Nftables und layer2 Firewall: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(7 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 52: Zeile 52:
 
;postrouting:  
 
;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.
−
=Zustandslose Filterung=
+
=Arp=
−
Wenn Sie den TCP-Zielport in IPv4-Paketen filtern möchten:
+
*arp ist im Gegensatz zur Layer 3 Firewall nicht automatisch freigeschaltet
−
*nft add rule bridge filter forward ether type ip tcp dport 22 accept
+
 
 
=Ein weiteres Beispiel zum Akzeptieren von ARP-Paketen=
 
=Ein weiteres Beispiel zum Akzeptieren von ARP-Paketen=
 
*nft add rule bridge filter forward ether type arp accept
 
*nft add rule bridge filter forward ether type arp accept
 
=Zustandsabhängige Filterung=
 
=Zustandsabhängige Filterung=
−
*Die Bridge-Familie unterstützt die Verbindungsverfolgung seit Linux-Kernel 5.3.
+
*Die Bridge-Familie unterstützt die Verbindungsverfolgung.  
 
*Sie müssen nur auf den Verbindungsstatusinformationen aus Ihrer Regelmenge übereinstimmen, um dies zu aktivieren.
 
*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=
 
=Beispiel: Zustandsabhängige Bridge-Firewall=
−
*Das folgende Beispiel zeigt, wie eine zustandsabhängige Bridge-Firewall bereitgestellt wird.
+
*Wir erstellen einen bridgefilter
−
*Dies setzt voraus, dass die Bridge-Schnittstelle keine IP-Adresse hat.
+
*Wir erstellen die Policy drop
−
=Angenommen, eine Bridge mit zwei Ports, eth0 und eth1=
+
*Connection Tracking wie üblich
−
*Ein Desktop-Computer ist mit dem Bridge-Port eth0 verbunden.
+
*arp ist generell erlaubt
−
*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:
 
  
 
=nftables schnellstart=
 
=nftables schnellstart=
 
*[[nftables schnellstart]]
 
*[[nftables schnellstart]]
−
 
+
=Bridge Firewall=
 +
{{#drawio:bridge-fw}}
  
 
=Regeln=
 
=Regeln=
 +
*cat  /etc/nftables.conf
 
<pre>
 
<pre>
 
#!/usr/sbin/nft -f
 
#!/usr/sbin/nft -f
−
 
+
define open    = enp0s8
 +
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;
 
                 ct state established,related accept
 
                 ct state established,related accept
−
                 iif enp0s8 ether type arp accept
+
                 # Arp freischalten
−
                 iif enp0s9 ether type arp accept
+
        iif $open ether type arp accept
−
                 oifname "enp0s9" udp dport 53 ct state new accept
+
                 iif $filter ether type arp accept
−
                 oifname "enp0s9" tcp dport 80 ct state new accept
+
                 ####icmp von filter nach open freischalten
−
                 oifname "enp0s9" tcp dport 443 ct state new accept
+
                #iif $filter oif $open ip protocol icmp ct state new accept
−
                 oifname "enp0s9" ip protocol icmp ct state new accept
+
                ####dns von filter nach open freischalten
−
                 # Loggen von abgelehnten Paketen
+
                #iif $filter oif $open udp dport 53 ct state new accept
−
                 log prefix " nftables drop: "
+
                 ####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
 +
                 #### Loggen von abgelehnten Paketen
 +
                 log prefix " nft-drop"
 
         }
 
         }
−
 
 
}
 
}
  
 +
</pre>
  
−
</pre>
+
=Regel Handling=
 +
;Laden der Regeln
 +
*nft -f /etc/nftables.conf
 +
;Kontrolle der Regeln
 +
*nft list ruleset
 +
;Löschender Regeln
 +
*nft flush ruleset
 +
=Live Log der Regel Verstösse=
 +
*journalctl -f -t kernel -g "nft-drop"

Aktuelle Version vom 13. Juni 2024, 17:57 Uhr

Vorab

Bei Virtualisierungen Bridge Ports auf Promisc setzen

Vm-promisc-1.png


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


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 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.

Arp

  • arp ist im Gegensatz zur Layer 3 Firewall nicht automatisch freigeschaltet

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.
  • Sie müssen nur auf den Verbindungsstatusinformationen aus Ihrer Regelmenge übereinstimmen, um dies zu aktivieren.

Beispiel: Zustandsabhängige Bridge-Firewall

  • Wir erstellen einen bridgefilter
  • Wir erstellen die Policy drop
  • Connection Tracking wie üblich
  • arp ist generell erlaubt


nftables schnellstart

Bridge Firewall

Regeln

  • 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;
                ct state established,related accept
                # Arp freischalten
	        iif $open ether type arp accept
                iif $filter ether type arp accept
                ####icmp von filter nach open freischalten 
                #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
                #### Loggen von abgelehnten Paketen
                log prefix " nft-drop"
        }
}

Regel Handling

Laden der Regeln
  • nft -f /etc/nftables.conf
Kontrolle der Regeln
  • nft list ruleset
Löschender Regeln
  • nft flush ruleset

Live Log der Regel Verstösse

  • journalctl -f -t kernel -g "nft-drop"
Abgerufen von „http://wiki.ixheim.de/index.php?title=Nftables_und_layer2_Firewall&oldid=54426“