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
