Hi Rico,
On Tue, Feb 01, 2022 at 05:56:17PM +0100, Rico Koerner wrote:
ich hab das so geregelt, daß die Chains ineinander verschachtelt sind:
table inet filter { chain inbound_ipv4 { icmp type echo-request limit rate 5/second accept }
chain inbound_ipv6 { icmpv6 type echo-request accept icmpv6 type { nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept ip6 nexthdr ipv6-icmp log prefix "[nftables] ICMPv6 Accept: " counter limit rate 20/second accept }
chain inbound { type filter hook input priority filter; policy drop; ct state vmap { invalid : drop, established : accept, related : accept } iifname "lo" accept meta protocol vmap { ip : jump inbound_ipv4, ip6 : jump inbound_ipv6 } tcp dport { 22, 80, 443 } accept log prefix "[nftables] Inbound Denied: " counter drop } }
Damit kann ich relativ übersichtlich globale Regeln vor, als auch nach der ipv4/6-Weiche anlegen.
Danke! Das gefällt mir sehr gut. Die verdict maps hatte ich gar nicht so auf dem Schirm, aber das macht natürlich viel Sinn. Was mir aus der Doku noch nicht ganz klar wurde... die "nicht Base" chains haben offensichtlich nen implizites return - statt nem impliziten accept.
Fail2ban sortiert sich, wenn man es auf nftables umgestellt hat mit table inet ... priority -1 vor den eigenen Regeln ein. Statische Black/Whitelists könnte man dann mit priority -2 davor stellen. Das ist damit sauberer gelöst, als mit iptables. Die Frage ist also nicht, ob man getrennte Tables für die verschiedenen Familien anlegt, sondern ggf. mehrere inet-Tabellen (oder auch ipv4/6) um unterschiedliche Filtersysteme miteinander zu kombinieren.
Ich setzte das zwar nicht ein (auch wenn ich das Prinzip kenne) aber ja, das macht Sinn die tables so zu verwenden, so ähnlich hab ich auch schon routing tables eingesetzt - je nach Quelle der Einträge, so dass die sich nicht gegenseitig in die Quere kommen.
Andreas