staging.inyokaproject.org

Hallo zusammen,

habe ich beim setzen von "drop" als Standard für einen normalen Arbeitsplatzrechner etwas vergessen zu berücksichtigen?

table inet filter {
        chain input {
                type filter hook input priority filter; policy drop;
                iif "lo" accept
                ip saddr 127.0.0.0/8 counter packets 0 bytes 0 drop
                ip6 saddr ::1 counter packets 0 bytes 0 drop
                ct state established,related accept
                icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
        }

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

        chain output {
                type filter hook output priority filter; policy drop;
                oif "lo" accept
                tcp dport { 22, 80, 443 } accept
                udp dport 53 accept
                tcp dport 53 accept
                tcp dport { 25, 143, 110, 465, 993 } accept
        }
}

Ich verstehe noch genau was dein Ziel sein soll? Bitte mehr Infos, manchmal ist ein reject eine gute Alternative

Gesamten nicht frei gegebenen ausgehenden Verkehr blockieren und eingehenden nur zulassen wenn Verbindung angefordert wurde.

Port 123 (ntp) und icmp bzw. arp für IPv4 zulassen. Related und established für den Input-Traffic.

Dann würden die Regeln, nach meinem Verständnis, aktuell so aussehen:

table inet filter {
	chain input {
		type filter hook input priority filter; policy drop;
		iif "lo" accept
		ip saddr 127.0.0.0/8 counter packets 0 bytes 0 drop
		ip6 saddr ::1 counter packets 0 bytes 0 drop
		ct state established,related accept
	}

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

	chain output {
		type filter hook output priority filter; policy drop;
		oif "lo" accept
		tcp dport { 22, 80, 443 } accept
		udp dport 53 accept
		tcp dport 53 accept
		tcp dport { 25, 110, 143, 465, 993, 8443, 8843 } accept
		udp dport 123 accept
		udp dport 67 accept
		icmp type { echo-reply, destination-unreachable, echo-request, time-exceeded } accept
		icmpv6 type { nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept
		ether type arp accept
	}
}

Mylin schrieb:

[…] habe ich beim setzen von "drop" als Standard für einen normalen Arbeitsplatzrechner etwas vergessen zu berücksichtigen?

Dazu musste man wissen, was Du erreichen willst.

Generell fällt auf:

• Üblicherweise akzeptiert man alle Pakete über die lokale Schnittstelle lo. Filtern lokaler Adressen wie 127/8 und ::1 macht keinen Sinn bzw. kann schädlich sein.

• Funktional wichtige Protokolle wie DHCP, DNS und NTP sollte man immer zulassen, aber bzgl. der Ziele einschränken.

• Multicast hast Du vergessen.

kB schrieb:

Dazu musste man wissen, was Du erreichen willst.

Einrichtung eines Systems nach CIS Level 1 mit Standardfunktionen wie Internet und E-Mail.

Filtern lokaler Adressen wie 127/8 und ::1 macht keinen Sinn bzw. kann schädlich sein.

Dann ist nftables von Grund auf falsch konfiguriert.

Multicast hast Du vergessen

IGMP-Pakete werden durch die established,related Regel in der input-Chain zugelassen.

Mylin schrieb:

Dann ist nftables von grund auf falsch konfiguriert.

Warum? Ist die default policy für Input und Output, beim loopback-Interface nicht auf accept?

default .conf aus 24.04

table inet filter {
        chain input {
                type filter hook input priority filter; policy accept;
                iif "lo" accept
                ip saddr 127.0.0.0/8 counter packets 0 bytes 0 drop
                ip6 saddr ::1 counter packets 0 bytes 0 drop
                iif "lo" accept
                ip saddr 127.0.0.0/8 counter packets 0 bytes 0 drop
                ip6 saddr ::1 counter packets 0 bytes 0 drop
        }

        chain forward {
                type filter hook forward priority filter; policy accept;
        }

        chain output {
                type filter hook output priority filter; policy accept;
        }
}

D. h. für die 3 chains, per default auf accept.

Genau. Eine mögliche Erklärung wäre, die bevorzugte Verwendung von iptables in Ubuntu.

Mylin schrieb:

Eine mögliche Erklärung wäre, die bevorzugte Verwendung von iptables in Ubuntu.

Es macht keinen Unterschied ob Du iptables oder nftables benutzt, … denn es ist ja nicht iptables-legacy.

Ob iptables bevorzugt wird im aktuellen Ubuntu, kann man mit z. B. systemd testen (… wenn dieses basierend auf der Konfiguration, eine oder mehrere Filterregeln generieren muss. Macht systemd in Ubuntu, das mit nftables oder mit iptables(-legacy)?)

Mylin schrieb:

[…] Einrichtung eines Systems nach CIS Level 1 mit Standardfunktionen wie Internet und E-Mail.

Dafür benötigst Du bei einem Ubuntu-Desktop gar keine Netfilter-Konfiguration. Lese: Personal Firewalls

[…] Dann ist nftables von Grund auf falsch konfiguriert.

Deine überraschende Schlussfolgerung verstehe ich nicht.

Multicast hast Du vergessen

IGMP-Pakete werden durch die established,related Regel in der input-Chain zugelassen.

Nur in Empfangsrichtung. Mit Deinen bisherigen Regeln verbietest Du das Senden von IP-Multicast, damit sind z.B. Multicast-DNS-Abfragen nicht möglich. Vielleicht willst Du das, es wird aber z.B. den Komfort bei SMB-Verbindungen beeinträchtigen.

kB schrieb:

Dafür benötigst Du bei einem Ubuntu-Desktop gar keine Netfilter-Konfiguration.

@kB: Ich vermute, das ist ein Misscerständnis, Mylin möchte generell ausgehenden Netzwerkverkehr blockieren, und nur noch den ausgehenden Netzwerkverkehr zulassen, der ausdrücklich erlaubt wird.

Mylin schrub:

Gesamten nicht frei gegebenen ausgehenden Verkehr blockieren und eingehenden nur zulassen wenn Verbindung angefordert wurde.

Ich habe das so gemacht, dass ich eine Group "no-internet" erstellt habe, die von iptables blockiert wird. Vertrauensunwürdige Programme, wie etwa proprietäre Windows Spiele unter Wine starte ich generell mit dieser "no-internet" Group.

Die Eingangsfrage läßt sich, abgesehen von den notwendigen Standarddiensten für die Netzwerkkommunikation, nicht pauschal beantworten. Und, auch bei den Standarddiensten (z.B. ICMP) gibt es potenzielle Sicherheitsrisiken die bei der Erstellung der Regeln berücksichtigt werden sollten. Insgesamt eine sehr interessante Thematik mit der man sich allerdings auseinander setzen muss.

Die Regeln für ein Gerät mit Browsing, E-Mail, CalDAV, CarDAV, SSH, CUPS, Syncthing und einer individuellen Anwendung:

table inet filter {
        chain input {
                type filter hook input priority filter; policy drop;
                iif "lo" accept
                ip saddr 127.0.0.0/8 counter packets 0 bytes 0 drop
                ip6 saddr ::1 counter packets 0 bytes 0 drop
                ct state established,related accept
                tcp sport { 22000, 22067 } accept
                udp dport { 21027, 22000 } accept
                tcp dport 22 ether saddr [MAC des Gerätes] accept
                tcp dport 3333 ether saddr [MAC des Gerätes] accept
                tcp dport { 631, 9100 } accept
                udp dport 5353 accept
                icmp type { echo-reply, destination-unreachable, echo-request, time-exceeded } accept
                icmpv6 type { nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept
                ether type arp accept
                log prefix "nftables-in: "
                #journalctl -f -t kernel -g "nftables-in: " 
        }

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

        chain output {
                type filter hook output priority filter; policy drop;
                oif "lo" accept
                tcp dport { 22, 80, 443 } accept
                udp dport 53 accept
                tcp dport 53 accept
                tcp dport { 2525, 143, 465, 587, 993, 8443, 8843 } accept
                udp dport 123 accept
                udp dport 67 accept
                tcp dport { 22000, 22067 } accept
                udp dport { 21027, 22000 } accept
                tcp sport 22 accept
                tcp sport 3333 accept
                tcp dport { 161, 443, 631, 9100 } accept
                udp dport 5353 accept
                ip protocol icmp accept
                meta l4proto ipv6-icmp accept
                ether type arp accept
                log prefix "nftables-out: "
        }
}

Soweit erfüllen diese ihren Zweck, Hinweise zur Optimierung sind willkommen. Ich bedanke mich für die Hilfestellungen.