Puncte:1

Filtrarea traficului după adresa MAC cu nftables

drapel in

TL;DR: la falsificarea adreselor MAC, cum mă pot asigura că adresele reale nu vor fi scurse în restul rețelei folosind nftables?

Context

În scopul formării în domeniul securității rețelei, în prezent construiesc un atingeți rețeaua format dintr-un punte transparentă cu două interfețe (robinetul).

Robinetul este un computer care rulează Debian Bullseye, care are 4 interfețe ethernet, după cum urmează:

Interfață MAC
enp3s0 00:90:27:b4:40:58
enp4s0 00:90:27:b4:40:59
enp6s0 00:90:27:b4:40:5a
enp7s0 00:90:27:b4:40:5b
  • enp3s0 este conectat la switch și primește o adresă IP prin DHCP.
  • În plus, am creat un bridge br0 cu nmcli, cu două interfețe slave: enp6s0 și enp7s0
  • enp7s0 este conectat la comutator

Podul este creat după cum urmează:

conexiune nmcli adăugați connection.type bridge ifname br0 con-name br0 ipv4.method dezactivat ipv6.method ignora bridge.stp nu bridge.vlan-filtering da connection.autoconnect-slaves 1 autoconnect nu
conexiune nmcli adăugați tip ethernet ifname enp6s0 con-name br0-slave-enp6s0 slave-type bridge master br0 autoconnect nu
conexiune nmcli adăugați tip ethernet ifname enp7s0 con-name br0-slave-enp7s0 slave-type bridge master br0 autoconnect nu

Poartă

Vreau ca mașina să rămână ascuns în orice moment în rețea, deoarece este o atingere pasivă, așa că vreau renunțați la traficul de ieșire care ar putea accidental scurgere adresele MAC ale aparatului meu. Așa că am făcut o încercare cu nftables după cum urmează, cu a set numit pentru adresele MAC:

table netdev bridge {
    setați macs {
        tastați ether_addr
        elemente = { 00:90:27:b4:40:59,
                 00:90:27:b4:40:5a, 00:90:27:b4:40:5b }
    }

    lanț br0 {
        tip filter hook ingress devices = { enp4s0, enp6s0, enp7s0 } priority filter; acceptarea politicii;
        ether saddr @macs drop
        jurnalul semnalează toate prefixele "filtrul meu".
    }
}

De asemenea, vreau să am contoare și detalii de jurnal ale pachetelor abandonate.

Problemă

Traficul este eliminat și înregistrarea se face în /var/log/syslog așa cum era de așteptat. Contoarele sunt actualizate. Dar regula netfilter nu pare să funcționeze așa cum a fost prevăzut. În schimb, se pare că renunță la tot traficul trimis către enp7s0.

Probă:

20 decembrie 01:23:47 nucleu testbox: [32441.125971] myfilter IN=enp7s0 OUT= MACSRC=10:c2:5a:58:72:8f MACDST=01:00:5e:7f:ff:fa MACPROTO=0800 SRC= 192.168.0.1 DST=239.255.255.250 LEN=367 TOS=0x00 PREC=0x00 TTL=4 ID=37026 PROTO=UDP SPT=1900 DPT=1900 LEN=347 
20 decembrie 01:23:47 kernel testbox: [32441.126842] myfilter IN=enp7s0 OUT= MACSRC=10:c2:5a:58:72:8f MACDST=01:00:5e:7f:ff:fa MACPROTO=0800 SRC= 192.168.0.1 DST=239.255.255.250 LEN=312 TOS=0x00 PREC=0x00 TTL=4 ID=37027 PROTO=UDP SPT=1900 DPT=1900 LEN=292 
20 decembrie 01:23:47 nucleu testbox: [32441.127554] myfilter IN=enp7s0 OUT= MACSRC=10:c2:5a:58:72:8f MACDST=01:00:5e:7f:ff:fa MACPROTO=0800 SRC= 192.168.0.1 DST=239.255.255.250 LEN=303 TOS=0x00 PREC=0x00 TTL=4 ID=37028 PROTO=UDP SPT=1900 DPT=1900 LEN=283 
20 decembrie 01:23:47 nucleu testbox: [32441.128342] myfilter IN=enp7s0 OUT= MACSRC=10:c2:5a:58:72:8f MACDST=01:00:5e:7f:ff:fa MACPROTO=0800 SRC= 192.168.0.1 DST=239.255.255.250 LEN=377 TOS=0x00 PREC=0x00 TTL=4 ID=37029 PROTO=UDP SPT=1900 DPT=1900 LEN=357 
20 decembrie 01:23:53 kernel testbox: [32447.003559] myfilter IN=enp7s0 OUT= MACSRC=10:c2:5a:58:72:8f MACDST=33:33:00:00:00:01 MACPROTO=86dd SRC=86dd SRC fe80:0000:0000:0000:12c2:5aff:fe75:899d DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=176 TC=0 HOPLIMIT=255 FLOWTYPE=BL=06 COD=0 
20 decembrie 01:23:53 kernel testbox: [32447.015382] myfilter IN=enp7s0 OUT= MACSRC=00:90:27:e6:10:58 MACDST=33:33:00:00:00:16 MACPROTO=86dd SRC= fe80:0000:0000:0000:6d06:284e:2844:db03 DST=ff02:0000:0000:0000:0000:0000:0000:0016 LEN=136 TC=0 HOPLIMIT=0 HOPLIBL=0 OPTICv (FLUX) TIP=143 COD=0 
20 decembrie 01:23:53 kernel testbox: [32447.619279] myfilter IN=enp7s0 OUT= MACSRC=00:90:27:e6:10:58 MACDST=33:33:00:00:00:16 MACPROTO=86dd SRC= fe80:0000:0000:0000:6d06:284e:2844:db03 DST=ff02:0000:0000:0000:0000:0000:0000:0016 LEN=136 TC=0 HOPLIMIT=0 HOPLIBL=0 OPTICv (FLUX) TIP=143 COD=0 

Cred că ar putea fi nevoie să folosesc un ieşire cârlig în loc de intrare. Am înțeles că cârligul de ieșire este disponibil în nft din versiunea 1.01. Versiunea actuală stabilă a nft în Debian este 0.98, așa că am făcut upgrade manual la v1.01 descarcând manual pachetele. Dar înlocuirea intrării cu ieșirea nu funcționează: nft nu recunoaște regula mea.

Întrebări

  • Are sens abordarea mea? Pot folosi cârligul de intrare în scopul meu? Sau este necesară ieșirea?
  • Alternativ, se poate face acest lucru cu tc?
  • Sau poate fi izolat și mai mult podul față de traficul care provine de la alte interfețe?
A.B avatar
drapel cl
A.B
Ca o remarcă, suportul din partea nucleului Linux pentru ieșirea nftables netdev începe de la Linux 5.16 (inclusiv „actualul” 5.16-rc6)
Kate avatar
drapel in
@A.B Punct bun: kernel-ul meu care rulează, evident, nu este suficient de recent: Linux testbox 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.