Am 26.01.22 um 21:41 schrieb Andreas Fett:
Hallo liebe Liste,
Hallo Andreas,
ich hab mal ne nftables Frage in Bezug auf IPv4/IPv6 dualstack handling.
Man gibt dort ja in der table Definition inet, ip, ip6 an.
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.
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.
Wobei ich bei f2b bisher nur ipv4-Regeln da drin gesehen hab. Und nicht wundern, wenn f2b nach dem Start noch keine Rules anlegt, das passiert erst, wenn die erste Sperre angelegt wird.
Gruß Rico