Dotaz: nftables - příklad a základní nastavení

[Petr]

Ahoj,
řeším, jak na základní nastavení firewallu nad nftables.

V podstatě mám toto...
- z internetu je pro všechny veřejně povolen přístup na http, https, OpenVPN a Wireguard, což jsou služby, které poskytuje tento stroj
- ssh přístup je povolen pouze z IP adres 192.168.100.11 a 192.168.100.12 (servisní IP)
- maškaráda - ven se jde přes wan rozhraní ens192
- do DMZ směruju porty 33891 a 33892



Nevím si rady s ...
- jak docílit toho aby mezi sítěma nebylo možné procházet - tj. aby se vlany mezi sebou neviděly a nemohly spolu / navzájem komunikovat
- jak docílit toho aby se z vlan100 bylo možné dostat do všech ostatních vlan bez jakýchkoli omezení
- jak docílit toho aby všichni uživatelé ze všech vlan mohli přistupovat do DMZ (vlan20) na IP 192.168.20.10 na port 53udp a žádný jiný
- jak docílit toho aby z OpenVPN (tun0) mohla IP adresa 192.168.40.100 naprosto všude
- jak docílit toho aby z OpenVPN (tun0) mohla IP adresa 192.168.40.111 neomezeně na stroj v DMS s IP 192.168.20.88
- jak docílit toho aby z WireGuard (wg0) mohla IP adresa 192.168.50.100 naprosto všude
- jak docílit toho aby z WireGuard (wg0) mohla IP adresa 192.168.50.111 neomezeně na stroj v DMS s IP 192.168.20.88

Dokumentace je pro mě (jako začátečníka) dost zmatená a nesrozumitelná.
Dokázal by mi prosím někdo poradit, případně mi to na míru napsat ?


Konfigurace, kterou jsem zatím "vymyslel a zplodil" viz. níže..

Děkuji,
Petr

#!/usr/sbin/nft -f

# vlan10:  192.168.10.0/24   - LAN
# vlan20:  192.168.20.0/24   - DMZ
# vlan30:  192.168.30.0/24   - Guest network
# vlan100: 192.168.100.0/24 - servis / management network

# tun0:  192.168.40.0/24   - OpenVPN
# wg0:   192.168.50.0/24   - Wireguard VPN


flush ruleset

table inet filter {
	chain input {
		type filter hook input priority 0; policy drop;

      # accept any localhost traffic
      iif lo accept

      # accept trafic originated from us
      ct state established,related accept

      # drop invalid packets
      ct state invalid counter drop

      # accept http, https from anywhere
      tcp dport { 80,443 } accept

      # accept OpenVPN clients from anywhere
      udp dport 1194 accept

      # accept WireGuard clients from anywhere
      udp dport 5180 accept

      # accept SSH only from my servis / management IPs
      tcp dport ssh ip saadr 192.168.100.11 accept
      tcp dport ssh ip saadr 192.168.100.12 accept

      # accept icmp from anywhere
      ip protocol icmp accept

      # accept icmpv6 from anywhere
      ip6 nexthdr icmpv6 accept

      #  meta nfproto ipv6 from anywhere
      icmpv6 type { nd-neighbor-advert, nd-neighbor-solicit, nd-router-advert} ip6 hoplimit 1 accept
      icmpv6 type { nd-neighbor-advert, nd-neighbor-solicit, nd-router-advert} ip6 hoplimit 255 counter accept

      # count and reject everithing else
      counter reject with icmpx type admin-prohibited



	}
	chain forward {
		type filter hook forward priority 0;

	}
	chain output {
		type filter hook output priority 0;
	}

}


table ip nat {
        chain prerouting {
                type nat hook prerouting priority 100; policy accept;
                iif "ens192" tcp dport 33891 dnat to 192.168.20.11:3389
                iif "ens192" tcp dport 33892 dnat to 192.168.20.12:3389
        }

        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                ip saddr 192.168.10.0/24 oif "ens192" masquerade
                ip saddr 192.168.20.0/24 oif "ens192" masquerade
                ip saddr 192.168.30.0/24 oif "ens192" masquerade
                ip saddr 192.168.40.0/24 oif "ens192" masquerade
                ip saddr 192.168.50.0/24 oif "ens192" masquerade
                ip saddr 192.168.100.0/24 oif "ens192" masquerade
        }
}

Odpovědi

[X]

Kdysi jsem dlouho nemohl pocohpit tento obrazek. Drtiva vetsina tvych pozadavku se deje v sekci 'forward' kdy paket prechazi z jednoho rozhrani (vstupni -i) na druhe rozhrani(vystupni -o). V tom momente jsi schopny definovat ktere pakety "preskoci" z jedne site do druhe. Mnoho prikladu ma Arch.

[Petr]

Asi bych potřeboval vysvětlit na konkrétním případě... Na wiki Archu jsem se díval, ale nic, co by alespoň trochu se blížilo mým potřebám ...mluvím o tom forwardu

[X]

V serialu na rootu je to videt lepe. Dalsi priklad je primo na wiki dole. POradna neni skolici centrum, nebo poptavna na brigadu. "Udela to nekdo za mne?" Ne.

[Petr]

Takže, dejme tomu, že jsem to pochopil správně ?
To jest, vlan100, vlan101, vlan102 a vlan103 mohou komunikovat "do" i "z" internetu, ale pouze vlan100 může komunikovat do vlan101, vlan102 a vlan103.
Chápu to správně ?

chain forward {
		type filter hook forward priority 0; policy drop;
                iifname "vlan100" oifname "ens192" ct state related,established accept          # vlan100 -> WAN
                iifname "ens192" oifname "vlan100" accept                                       # WAN     -> vlan100

                iifname "vlan101" oifname "ens192" ct state related,established accept          # vlan101 -> WAN
                iifname "ens192" oifname "vlan101" accept                                       # WAN     -> vlan101

                iifname "vlan102" oifname "ens192" ct state related,established accept          # vlan102 -> WAN
                iifname "ens192" oifname "vlan102" accept                                       # WAN     -> vlan102

                iifname "vlan103" oifname "ens192" ct state related,established accept          # vlan103 -> WAN
                iifname "ens192" oifname "vlan103" accept                                       # WAN     -> vlan103

                iifname "vlan100" oifname "vlan101" ct state related,established accept         # vlan100 -> vlan101
                iifname "vlan100" oifname "vlan102" ct state related,established accept         # vlan100 -> vlan102
                iifname "vlan100" oifname "vlan103" ct state related,established accept         # vlan100 -> vlan103
                
	}

[X]

Bohuzel ne. Tohle nebude fungovat spravne. nejdrive si nastuduj zakladni fungovani stavoveho firewallu.

[Bugsa]

Taková blbá rada: Nainstaluj si nejnovější OpenWRT do virtualu. Přes GUI si naklikej požadovaná pravidla a pak se koukni jak se vygenerovala nftables pravidla.

[Petr]

Tak jsem se o kousíček (pro mě významný kus) posunul...
Prosím, mohl bych poprosit o radu, jak nejlépe ošetřit nefungující dva body, viz. níže ?

Funguje
- přístup z wanu na HTTP a HTTPS
- přístup z wanu na OpenVPN
- přístup z wanu na WireGuard
- přístup na SSH je povolen pouze z vyjmenovaných IP
- přístup do internetu z vlan100 a vlan101 pakliže komunikace byla navázána z dané vlan
- funguje maškaráda (záměrně snat)
- funguje prostup z vlan100 do vlany101, ve chvíli, kdy se spojení navazuje v vlan100

Co nefunguje a nedaří se mi od rána zprovoznit...
- přístup z vlan101 do vlan100 pro konkrétní IP - řekněme že pouze IP 10.101.1.11 smí vstupovat do vlan100
- přístup na DNS je povolen na všechny veřejné (např. Google) servery, já bych ale potřeboval povolit/vynutit pro vlanu100 vlastní DNS server na adrese 10.100.1.13 a žádný jiný

Moje aktuální konfigurace nftables vypadá takto...

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
        chain input {
        type filter hook input priority 0; policy drop;

      # accept any localhost traffic
      iif lo accept

      # accept trafic originated from us
      ct state established,related accept

      # drop invalid packets
      ct state invalid counter drop

      # accept http, https from anywhere
      tcp dport { 80,443 } accept

      # accept OpenVPN clients from anywhere
      udp dport 1194 accept comment "OpenVPN in"

      # accept WireGuard clients from anywhere
      udp dport 5180 accept comment "WireGuard in"

      # accept SSH only from this IPs
      tcp dport ssh ip saddr 10.255.255.32 accept comment "SSH in"
      tcp dport ssh ip saddr 10.1.100.11 accept comment "SSH in"
      tcp dport ssh ip saddr 10.1.100.12 accept comment "SSH in"

      # accept icmp from anywhere
      ip protocol icmp accept

      # accept icmpv6 from anywhere
      ip6 nexthdr icmpv6 accept

      #  meta nfproto ipv6 from anywhere
      icmpv6 type { nd-neighbor-advert, nd-neighbor-solicit, nd-router-advert} ip6 hoplimit 1 accept
      icmpv6 type { nd-neighbor-advert, nd-neighbor-solicit, nd-router-advert} ip6 hoplimit 255 counter accept

      # count and reject everithing else
      counter reject with icmpx type admin-prohibited


      }


	chain forward {
		type filter hook forward priority 0; policy drop;
                
                # povolím přístup na internet z vlan100
                iifname "vlan100" oifname "ens192" accept                                       # vlan100  to Internet
                iifname "ens192" oifname "vlan100" ct state related,established accept          # Internet to vlan100

                # povolím přístup na internet z vlan101
                iifname "vlan101" oifname "ens192" accept                                       # vlan101 to Internet
                iifname "ens192" oifname "vlan101" ct state related,established accept          # Internet to vlan101

                # povolím přístup z vlan100 do vlan101
                # pokud se komunikace navazuje z vlan100
                iifname "vlan100" oifname "vlan101" accept                                      # vlan100 to vlan101
                iifname "vlan101" oifname "vlan100" ct state related,established accept         # vlan101 to vlan100

	}


	chain output {
		type filter hook output priority 0;
	}

}


table ip nat {
    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        ip saddr 10.100.1.0/24 oif "ens192" snat 10.255.255.251
        ip saddr 10.101.1.0/24 oif "ens192" snat 10.255.255.251
    }
}

Předem děkuji.
Petr

[Petr]

Tak jsem si myslel, že tyto dva řádky ve forwardu to vyřešili, ale radost mě přešla ve chvíli, kdy jsem v konfiguraci IP 10.101.1.11 zaměnil za 10.101.1.15 a zavolal "systemctl restart nftables" - vesele jsem pingal dál. Pokud ale rebootuju celý server, tak to zafunguje - nechápu proč ?? Co mám špatně ? Jak kdyby si to někde na pozadí udržovalo spojení, který by ale podle nově zavedené konfigurace fungovat již neměla.

                iifname "vlan101" ip saddr 10.101.1.11 oifname "vlan100" accept
                iifname "vlan100" ip daddr 10.101.1.11 oifname "vlan101" accept

Díky,
Petr

[alkoholik]

ICMP normalne konci v conntracku a chyta ho established pravidlo.

[Petr]

Aha, ...takže jak nejlépe (viz. konfigurace výše) vyřešit ?

[alkoholik]

Spustenim sudo conntrack -D -p icmp by ping po restartu nftables prestal fungovat.

[Petr]

Takže, jinými slovy, testování prostupnosti sítě přes ping není šťastným řešením jak prostupy testovat ?

[alkoholik]

Unika mi, co presne nechapes.
Mas nejaka pravidla ve firewallu, ktera ti pripadne umozni otevrit spojeni. Ta spojeni skonci v conntracku, pokud je povoleny - viz sudo cat /proc/net/nf_conntrack nebo s nainstalovanou binarkou sudo conntrack -L.
Nahrani nove sady pravidel do firewallu na uz existujici konexe nema vliv. A kdyz se v nem vyskytuje prvidlo s extablished, tak odpovidajici pakety proste matchne.
Pokud bys ten ping zastavil a spustil novy, uz se odpovedi nedockas.

[Petr]

Dosud jsem firewally nepolíbený, takže začínám od nuly a je toho hodně co načíst a hlavně pochopit. Doslova a do písmene se problematice firewallů věnuji své první 2 dny v životě, tak mě prosím omluvte za absolutní neznalost. Snažím se... Bohužel, pokud nahraju do firewallu nová pravidla a ping zastavím a následně jej znovu spustím, tak bez problému pingám. Pokud ale počkám třeba minutu nebo dvě a teprve poté ping opět spustím, tak pak už to nepingnu.

Takže, chápu to správně, že pro účely ladění a hraní si s firewallem, nestačí jen "restartovat nftables" ale také je potřeba vyčistit existující navázaná spojení z conntracku ? Dá se to nějak ošetřit přímo v /etc/nftables.conf ? Dost by mě to usnadnilo prvotní bolesti při prvostním seznamováním.

Děkuji,
Petr

[alkoholik]

Hadam, ze pro ICMP je conntrack trosku hloupejsi a nekontroluje id, takze muze matchnout tu starou konexi. Zkuste ji rucne a smazat a bude hned jasno.
To automaticke mazani nevidim jako pruchozi. Uz navazana konexe nema jak zjistit, ze v minule verzi sice prosla, ale v soucasne by uz nemela. A pri restartu firewallu rozhodne nechcete ustrelit vsechny.
Pro zjisteni, jak pakety bublaji skrz pravidla se da jednoduse pouzit nftrace.

[Petr]

nftrace....šikovná utilitka, díky

[Petr]

Tak jsem právě zjistil, že přístup z WANu na SSH funguje - tj. z IP adresy 10.255.255.32 se na SSH přihlásím. Dále ale v inputu povoluju přístup na SSH pouze pro IP adresy 10.100.1.11 a 10.101.1.11.
Nerozumím tomu, co mám špatně, že se z vnitřní sítě na SSH serveru (ssh root@10.100.1.1 nebo ssh root@10.101.1.1) připojím z kterýchkoli ostatních vnitřních adres než jsou 10.100.1.11 nebo 10.101.1.11.

Dále jsem si na serveru rozchodil DHCP server, který přiděluji IP adresy ve vlan100 a vlan101.
Jak je možné, že DHCP server přidělí stanicím bez problému IP adresu, když jsem DHCP službu nikde v konfiguraci nftables.conf nepovolil ?

Aktuální nftables.conf viz. níže.

cat /etc/nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
        chain input {
        type filter hook input priority 0; policy drop;

      # accept any localhost traffic
      iif lo accept

      # accept trafic originated from us
      # ct state established,related accept

      # drop invalid packets
      ct state invalid counter drop

      # accept http, https from anywhere
      tcp dport { 80,443 } accept

      # accept OpenVPN clients from anywhere
      udp dport 1194 accept comment "OpenVPN in"

      # accept WireGuard clients from anywhere
      udp dport 5180 accept comment "WireGuard in"

      # accept SSH only from this IPs
      tcp dport ssh ip saddr 10.255.255.32 accept comment "SSH in"
      tcp dport ssh ip saddr 10.100.1.11 accept comment "SSH in"
      tcp dport ssh ip saddr 10.101.1.11 accept comment "SSH in"

      # accept icmp from anywhere
      ip protocol icmp accept

      # accept icmpv6 from anywhere
      ip6 nexthdr icmpv6 accept

      #  meta nfproto ipv6 from anywhere
      icmpv6 type { nd-neighbor-advert, nd-neighbor-solicit, nd-router-advert} ip6 hoplimit 1 accept
      icmpv6 type { nd-neighbor-advert, nd-neighbor-solicit, nd-router-advert} ip6 hoplimit 255 counter accept

      # count and reject everithing else
      counter reject with icmpx type admin-prohibited


      }


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

                # povolím přístup na internet z vlan100
                iifname "vlan100" oifname "ens192" accept                                       # vlan100  to Internet
                iifname "ens192" oifname "vlan100" ct state related,established accept          # Internet to vlan100

                # povolím přístup na internet z vlan101
                iifname "vlan101" oifname "ens192" accept                                       # vlan101 to Internet
                iifname "ens192" oifname "vlan101" ct state related,established accept          # Internet to vlan101

                # povolím přístup z vlan100 do vlan101
                # pokud se komunikace navazuje z vlan100
                iifname "vlan100" oifname "vlan101" accept                                      # vlan100 to vlan101
                iifname "vlan101" oifname "vlan100" ct state related,established accept         # vlan101 to vlan100

                iifname "vlan101" ip saddr 10.101.1.12 oifname "vlan100" accept
                iifname "vlan100" ip daddr 10.101.1.12 oifname "vlan101" accept

 	}


	chain output {
		type filter hook output priority 0;
	}

}


table ip nat {
    chain prerouting {
        type nat hook prerouting priority 0; policy accept;
    }

    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        ip saddr 10.100.1.0/24 oif "ens192" snat 10.255.255.251
        ip saddr 10.101.1.0/24 oif "ens192" snat 10.255.255.251
    }
}

Díky, Petr

[Petr]

Tak vyřešeno.
Ve výše uvedené aktuální konfiguraci chybu nemám. Jen jsem měl na straně testovacího PC nastavenou jinou IP adresu, než jsem si myslel, že mám - tak proto mi to fungovalo a mě uvádělo v omyl.

Ohledně DHCP...
Věta "DHCP servers need to use raw sockets for IPv4 clients because the DHCP DISCOVER queries from the clients don't have source addresses (since they don't have one yet!) and thus those packets could not be processed as normal packets on a UDP socket" mluví za vše - proto požadavky na DHCP vůbec neprojdou filtrem a proto se do nftables nedostanou.

Další vysvětlení si lze vzít např. tady: "When getting an IP address the dhcp daemon creates a raw socket to the network interface and handles the UDP protocol itself. Thus the UDP packets never go through iptables. The reason the dhcp daemon has to implement UDP is that the kernel can only handle UDP (in fact all of the TCP/IP suite) when the interface has an IP address. Previously dhcp daemons would first give an interface the IP address of 0.0.0.0 but that no longer works."

Takže, zatím jsem asi vyřešil vše, co jsem do začátku potřeboval

Petr