nftables - grundlegende Fragen

[jb_alvarado]

Hallo Allerseits,
Ist das ok wenn ich hier ein paar Fragen zusammenfasse?

Ich habe lange Zeit firehol eingesetzt. Da dort allerdings schon seit längerem die Manpower fehlt um nach nftables zu wechseln, spiele ich schon seit einiger Zeit mit dem Gedanken zu wechseln. Dazu kommt, dass Debian 11 standardmäßig gar kein iptables mehr installiert haben wird, was auch darauf hinweist, dass man sich so langsam mal an nftables gewöhnen sollte.

Ich brauche die Firewall hauptsächlich zum routen von Traffic zwischen Host und VMs.

Auf dem Debian Wiki steht nun allerdings, dass man Firewalld einsetzten sollte. Das kenne ich zwar von CentOS konnte mich damit aber nie anfreunden. Da Firewalld ja nur ein Frontend ist, könnte ich das ja ignorieren und mich ganz in nftables vertiefen. Allerdings stelle ich mir die Frage, ob das auf Dauer vielleicht Nachteile haben könnte. Z.B. wird an Firewalld gelobt, dass es von Docker, libvirt usw. genutzt werden kann.

Heißt das jetzt, dass ich irgendwann Firewalld auf dem System haben muss, um Docker und ähnliches einsetzten zu können?
Wie verträgt sich Docker überhaupt mit eigenen nftables Scripten? Kann das gemischt werden?

Das nächste was mich interessieren würde, ist eure Meinung zu verschiedenen DDoS Maßnahmen auf Firewall Ebene. Wenn ich jetzt einen Hoster habe, der sowieso sein Netz gegen DDoS absichert, macht es da überhaupt noch Sinn hier eigene Regeln zu definieren?

Zu dem Thema habe ich das gefunden: nftables-hardening-rules-and-good-practices. Schaut soweit nett aus, allerdings verstehe ich nicht alle Regeln bis in die Tiefe, daher habe ich etwas Probleme damit, das einfach zu kopieren.

Was mich noch interessieren würde sind die Sets die man in nftables erstellen kann. Wenn ich das richtig verstehe, kann man damit quasi auch ipset ersetzten. Wie wäre hier denn die richtige Herangehensweise, wenn ich Blacklisten regelmäßig updaten möchte? Muss nach jedem Update die ganze Firewall neu gestartet werden, oder können die Regeln einzeln aktualisiert werden?

Und zu guter Letzt: Man kann ja Ordner includen, deren Inhalt dann automatisch mit initialisiert wird. Wie würden denn diese Konfigurationen in diesem Ordner aussehen? Genau wie die Hauptkonfiguration? Mit eigenen Tabellen? Was passiert, wenn dort auch eine Input Kette definiert ist, wird das einfach gemischt?

 

[Jesterfox]

Wie verträgt sich Docker überhaupt mit eigenen nftables Scripten? Kann das gemischt werden?

Ist ne sehr gute Frage... meine Erfahrung mit Docker ist das der extrem viele Regeln in die Firewall reindumpt die alles mögliche anstellen. Wenn Docker am Host lief konnte die VM mit pfSense die per KVN auch auf dem Host lief nicht mehr durchs VPN Routen... hab jetzt Docker auch in ne eigene VM gepackt, dann ist Ruhe ;-)

 

[jb_alvarado]

Ja so ähnlich kenne ich das auch in Verbindung mit firehol. Da gab es drei Möglichkeiten die Firewall und Docker zu betreiben. Bzw. betrifft das ja nicht nur Docker, auch fail2ban braucht ja seine eigenen Regeln.

1. man konnte in die Konfiguration direkt iptables Regeln für Docker definieren
2. in neueren Versionen gab es eigene Docker Helper für die Konfiguration
3. die Holzhammermethode: man konnte ein Script starten, nach dem die Firewall scharf gestellt wurde.
   In dem Script konnte man dann Dienste wie Docker und fail2ban einfach neu startet, das hat dann bewirkt dass die beiden ihre Regeln neu anlegen konnten.

In nftables wird das wohl nicht viel anders sein, denn dort wird ja in der Konfig auch am Anfang erst mal alles geflusht. Am sichersten ist es sicher, wie du machst - Docker in eine VM packen...

 

[jb_alvarado]

So langsam komme ich vorwärts... Was ich noch nebenbei herausgefunden habe ist, dass das Kürzel iif/oif für das Eingangs-/Ausgangsgerät, sich nicht mit Netzwerkbrücken etc. verträgt, weil die beim Booten etwas später erst verfügbar sind. Stattdessen muss man iifname/oifname nehmen.

Das Prinzip von ipset lässt sich auch ziemlich gut implementieren, wenn man es mal raus hat. Hier ein simples Beispiel für eine dynamische Blackliste (Ports als Honeypots):

define dev_wan = enp1s0

table inet bw_filter {
    set honey_ports {
        type inet_service
        elements = { 25, 80, 110, 443, 3309, 8080 }
    }
    set whitelist {
        type ipv4_addr
        flags interval
        elements = { 127.0.0.1, 10.20.0.0/24 }
    }

    set blackhole {
        type ipv4_addr
        flags timeout
    }

    chain bw_input {
        type filter hook input priority -50; policy accept;

        iifname $dev_wan ip saddr @whitelist accept
        ip saddr @blackhole counter set update ip saddr timeout 1m @blackhole drop

        tcp dport @honey_ports update @blackhole { ip saddr timeout 1m }


    }

    chain bw_output {
        type filter hook output priority -50; policy accept;

        ip daddr @blackhole counter reject
    }
}

Statt einer input Kette kann man vielleicht auch eine ingress nehmen, da bin ich noch etwas unschlüssig was besser ist.

 

[jb_alvarado]

@Jesterfox, ich habe mir noch mal etwas Gedanken zu dem Punkt Docker und Firewall auf gleichem Host gemacht. Da ich Docker allerdings nicht produktiv einsetzte, ist das nur Theorie.

Ich denke es gäbe verschiedene Möglichkeiten die Firewall und Docker zu betreiben:

1. Die wohl aufwändigste Möglichkeit wäre sicher, eine Netzwerkbrücke zu definieren, Docker zu sagen dass er diese Brücke verwenden soll und alle Nat Regeln selber managen. Dabei hätte man volle Kontrolle, aber auch mehr Handarbeit. Für KVM finde ich das den besten Weg, bei Docker müsste man das vielleicht mehr abwägen, weil Docker Setups noch mal dynamischer und komplexer sind.
2. Man benennt seine Firewall Tabellen und Ketten so, dass sie nicht im Konflikt mit Docker stehe. In der nftables Konfig würde ich dann kein flush ruleset reinschreiben, sondern explizit meine Firewall Tabellen fushen. Dabei würden dann im Idealfall die Docker Regeln mit der Firewall koexistieren, ohne dass sie sich in die Quere kommen.
3. Ähnlich wie Punkt zwei, nur dass Docker keine Portweiterleitung von allen Interfacen zu den Containern machen soll, sondern nur von localhost. Die letzte Strecke von localhost nach Draußen routet man dann selber in der Firewall.

Auch wenn Punkt drei etwas umständlicher scheint, ist mir dieser trotzdem am sympathischsten. Weil man hier noch explizit mit der Firewall Einfluss auf das Docker Setup nimmt und nicht Docker machen lässt was er will.

 

[Tokolosh]

Auf den neuen Distributionen gibt es anstatt iptables nur noch ein kompatibles legacy Packet, das sich iptables-legacy oder so ähnlich nennt. Unter der Haube läuft nftables, docker nutzt aber noch iptables und somit diese Schnittstelle. Dabei wird die iptables Syntax verwendet, aber nftable rules gesetzt.

Einfach mal

iptables --version

aufrufen. Dort sollte dann (legacy) erscheinen.

 

[Raijin]

Hm.. Funktioniert eigentlich ufw oder andere Frontends schon mit nftables? Die haben ja durchaus eine gewisse Verbreitung, weil sowohl iptables als auch nftables ein gewisses Grundverständnis der Technik im Hintergrund voraussetzen. Ich kenne viele, die ihre Linux-Firewall nur mit ufw einrichten können, weil sie von iptables keine Ahnung haben. Selbst habe ich mich offen gestanden äußerst selten mit ufw auseinandergesetzt, weil ich immer direkt mit iptables arbeite (Gewohnheit).

Wirklich belastbare Infos kann ich dazu momentan nicht finden.

 

[jb_alvarado]

Auf Langzeit gesehen denke ich, dass firewallD ufw verdrängen wird, damit hat man dann wieder ein Frontend was für viele einfacher zu bedienen ist. Aktuell tippe ich, dass ufw auch auf das, von @Tokolosh angesprochene, iptables-legacy zurückgreift. Für einfache Regeln funktioniert das ja recht gut. In Verbindung mit firehol gab es bei mir allerdings immer Probleme und ich musste das System auf iptables umstellen.

 

[jb_alvarado]

Habe hier noch einen interessanten Artikel bezüglich nftables und Docker gefunden: docker-nftables.

Hier geht er her und deaktiviert iptables im Docker Service, erstellt seine eigene Netzwerkbrücke für die Container und regelt die Weiterleitungsregeln in der nftables Config. Finde das ein guter Ansatz, man muss dabei nur drauf achten, dass bei zukünftig eingelegten Container immer das Netzwerk und eine IP angegeben wird.