* How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 @ 2019-10-01 23:22 Jags 2019-10-03 19:00 ` zrm 0 siblings, 1 reply; 16+ messages in thread From: Jags @ 2019-10-01 23:22 UTC (permalink / raw) To: netfilter hello everyone, I would like to block all traffic from an IP range (e.g.: 123.0.0.0/8), irrespective of its origin, going to, or coming from, using nftables firewall in Debian 10. If I understand correctly, the following will block traffic originating from that IP range. nft insert rule ip filter INPUT ip saddr 123.0.0.0/8 counter drop But it will still allow traffic if it's in response to (or associated with) an application on my Debian machine. The problem: When I run a torrent client and add any torrent, be it Debian/Ubuntu ISO or any other torrent, I can see a bunch of IPs from my ISP connects to the torrent. Even if I add a torrent that have only 1 seed and no peer at all, I can see a lot of IPs from my ISP (with zero percent of torrent availability) in qBittorrent client. In fact, I have blocked like 100+ in qBittorrent but the new IPs still keep popping up under "peers". So I'd like to block an IP range, irrespective of traffic origin, going to, or coming from, using nftables. Thanks a lot in advance. Here's my nftables.conf file: ::::: #!/usr/sbin/nft -f flush ruleset table inet filter { chain input { type filter hook input priority 0; policy drop; iifname lo accept # ssh for internal network ip saddr 192.168.0.0/16 tcp dport 22 counter accept ct state established,related accept # Avoid brute force on ssh tcp dport 22 ct state new limit rate 10/minute accept # Early drop of invalid connections ct state invalid drop # VsFTPD ip saddr 192.168.0.0/16 tcp dport 20 counter accept ip saddr 192.168.0.0/16 tcp dport 21 counter accept ip saddr 192.168.0.0/16 tcp dport 990 counter accept ip saddr 192.168.0.0/16 tcp dport 40000-50000 counter accept # ICMP & IGMP ip saddr 192.168.0.0/16 icmp type echo-request counter accept icmp type echo-request counter drop ip protocol igmp drop # Everything else reject with icmpx type port-unreachable log flags all counter drop log prefix "[nftables] Input Denied: " flags all counter drop } } ::::: ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-01 23:22 How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 Jags @ 2019-10-03 19:00 ` zrm 2019-10-04 9:45 ` Jags 0 siblings, 1 reply; 16+ messages in thread From: zrm @ 2019-10-03 19:00 UTC (permalink / raw) To: Jags, netfilter On 10/1/19 19:22, Jags wrote: > hello everyone, > > I would like to block all traffic from an IP range (e.g.: 123.0.0.0/8), irrespective of its origin, going to, or coming from, using nftables firewall in Debian 10. > > If I understand correctly, the following will block traffic originating from that IP range. > > nft insert rule ip filter INPUT ip saddr 123.0.0.0/8 counter drop > > > But it will still allow traffic if it's in response to (or associated with) an application on my Debian machine. > > The problem: When I run a torrent client and add any torrent, be it Debian/Ubuntu ISO or any other torrent, I can see a bunch of IPs from my ISP connects to the torrent. > > Even if I add a torrent that have only 1 seed and no peer at all, I can see a lot of IPs from my ISP (with zero percent of torrent availability) in qBittorrent client. In fact, I have blocked like 100+ in qBittorrent but the new IPs still keep popping up under "peers". > > So I'd like to block an IP range, irrespective of traffic origin, going to, or coming from, using nftables. > > > Thanks a lot in advance. A torrent client could try to connect to a peer in either direction, so if you don't want communication with that IP range at all then you would also want a rule to drop packets in the OUTPUT chain with that address range as the daddr. You may also want to use reject rather than drop in that case because the then the client will figure out that the peer is not available faster. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-03 19:00 ` zrm @ 2019-10-04 9:45 ` Jags 2019-10-04 10:18 ` Reindl Harald 0 siblings, 1 reply; 16+ messages in thread From: Jags @ 2019-10-04 9:45 UTC (permalink / raw) To: zrm; +Cc: netfilter @zrm thank you so much for the reply. (1) Would it be something like this: ::::: chain output { type filter hook output priority 0; policy accept; ip daddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter reject } ::::: Because just last night I tried that, but I could still see IPs from the blocked range. Or am I missing something here. Note: In this OUTPUT chain, if I change: "policy accept" to "policy drop", I lose the internet completely. (2) In addition to the OUTPUT chain, I've added this into INPUT chain too: ::::: chain input { type filter hook input priority 0; policy drop; ip saddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter drop } ::::: So how should I modify the either or both of the above please... many thanks. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, October 3, 2019 7:00 PM, zrm <zrm@trustiosity.com> wrote: > On 10/1/19 19:22, Jags wrote: > > > hello everyone, > > I would like to block all traffic from an IP range (e.g.: 123.0.0.0/8), irrespective of its origin, going to, or coming from, using nftables firewall in Debian 10. > > If I understand correctly, the following will block traffic originating from that IP range. > > nft insert rule ip filter INPUT ip saddr 123.0.0.0/8 counter drop > > But it will still allow traffic if it's in response to (or associated with) an application on my Debian machine. > > The problem: When I run a torrent client and add any torrent, be it Debian/Ubuntu ISO or any other torrent, I can see a bunch of IPs from my ISP connects to the torrent. > > Even if I add a torrent that have only 1 seed and no peer at all, I can see a lot of IPs from my ISP (with zero percent of torrent availability) in qBittorrent client. In fact, I have blocked like 100+ in qBittorrent but the new IPs still keep popping up under "peers". > > So I'd like to block an IP range, irrespective of traffic origin, going to, or coming from, using nftables. > > Thanks a lot in advance. > > A torrent client could try to connect to a peer in either direction, so > if you don't want communication with that IP range at all then you would > also want a rule to drop packets in the OUTPUT chain with that address > range as the daddr. You may also want to use reject rather than drop in > that case because the then the client will figure out that the peer is > not available faster. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 9:45 ` Jags @ 2019-10-04 10:18 ` Reindl Harald 2019-10-04 10:44 ` Jags 0 siblings, 1 reply; 16+ messages in thread From: Reindl Harald @ 2019-10-04 10:18 UTC (permalink / raw) To: Jags, zrm; +Cc: netfilter Am 04.10.19 um 11:45 schrieb Jags: > @zrm thank you so much for the reply. > > > (1) Would it be something like this: > > ::::: > chain output { > type filter hook output priority 0; policy accept; > > ip daddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter reject > } > ::::: > > Because just last night I tried that, but I could still see IPs from the blocked range. Or am I missing something here. > > Note: In this OUTPUT chain, if I change: "policy accept" to "policy drop", I lose the internet completely. > > > (2) In addition to the OUTPUT chain, I've added this into INPUT chain too: > > ::::: > chain input { > type filter hook input priority 0; policy drop; > > ip saddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter drop > } > ::::: > > > So how should I modify the either or both of the above please... many thanks it's the same as with iptables "established,related" allows responses and so when your client made a connection to a peer data from this peer is allowed back order matters and there is no point to change the outbound policy to DROP the policy is applied after all rules and the first mathcing action wins, everywhere ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 10:18 ` Reindl Harald @ 2019-10-04 10:44 ` Jags 2019-10-04 11:05 ` Reindl Harald 0 siblings, 1 reply; 16+ messages in thread From: Jags @ 2019-10-04 10:44 UTC (permalink / raw) To: Reindl Harald; +Cc: zrm, netfilter Should I modify it to the following: ::: chain output { type filter hook output priority 0; policy accept; ip daddr 123.0.0.0/8 counter reject } ::: and ::: chain input { type filter hook input priority 0; policy drop; ip saddr 123.0.0.0/8 counter drop } ::: Many thanks. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 4, 2019 10:18 AM, Reindl Harald <h.reindl@thelounge.net> wrote: > Am 04.10.19 um 11:45 schrieb Jags: > > > @zrm thank you so much for the reply. > > (1) Would it be something like this: > > ::::: > > chain output { > > type filter hook output priority 0; policy accept; > > > > ip daddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter reject > > } > > > > > > ::::: > > Because just last night I tried that, but I could still see IPs from the blocked range. Or am I missing something here. > > Note: In this OUTPUT chain, if I change: "policy accept" to "policy drop", I lose the internet completely. > > (2) In addition to the OUTPUT chain, I've added this into INPUT chain too: > > ::::: > > chain input { > > type filter hook input priority 0; policy drop; > > > > ip saddr 123.0.0.0/8 ct state established,related,new,invalid,untracked counter drop > > } > > > > > > ::::: > > So how should I modify the either or both of the above please... many thanks > > it's the same as with iptables > > "established,related" allows responses and so when your client made a > connection to a peer data from this peer is allowed back > > order matters and there is no point to change the outbound policy to DROP > > the policy is applied after all rules and the first mathcing action > wins, everywhere ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 10:44 ` Jags @ 2019-10-04 11:05 ` Reindl Harald 2019-10-04 12:21 ` Jags 0 siblings, 1 reply; 16+ messages in thread From: Reindl Harald @ 2019-10-04 11:05 UTC (permalink / raw) To: Jags; +Cc: zrm, netfilter Am 04.10.19 um 12:44 schrieb Jags: > Should I modify it to the following: > > ::: > chain output { > type filter hook output priority 0; policy accept; > > ip daddr 123.0.0.0/8 counter reject } > ::: > > and > > ::: > chain input { > type filter hook input priority 0; policy drop; > > ip saddr 123.0.0.0/8 counter drop } > ::: surely, and that on top of the ruleset before any accept-rule, there is no point to mention "ct state" when you just want to block communication from and to a ip unconditionally ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 11:05 ` Reindl Harald @ 2019-10-04 12:21 ` Jags 2019-10-04 13:06 ` Reindl Harald 0 siblings, 1 reply; 16+ messages in thread From: Jags @ 2019-10-04 12:21 UTC (permalink / raw) To: Reindl Harald; +Cc: zrm, netfilter Thank you so much. Now do I need to have OUTPUT chain before INPUT chain? 'Coz all the examples I've seen so far had INPUT as the first chain. Side question: Does order of the chains or tables matter... like on other PC, I have "table inet nat" with chains "prerouting/postrouting". Here's my complete nftables.conf: xxxxx #!/usr/sbin/nft -f flush ruleset table inet filter { chain input { type filter hook input priority 0; policy drop; iifname lo accept ---> ip saddr 123.0.0.0/8 counter drop # Early drop of invalid connections ct state invalid drop ct state established,related accept # ICMP & IGMP ip saddr 192.168.0.0/16 icmp type echo-request counter accept icmp type echo-request counter drop ip protocol igmp drop # ssh for internal network ip saddr 192.168.0.0/16 tcp dport 22 counter accept # Avoid brute force on ssh tcp dport 22 ct state new limit rate 10/minute accept # VsFTPD ip saddr 192.168.0.0/16 tcp dport 20 counter accept ip saddr 192.168.0.0/16 tcp dport 21 counter accept ip saddr 192.168.0.0/16 tcp dport 990 counter accept ip saddr 192.168.0.0/16 tcp dport 40000-50000 counter accept ct state new drop # Everything else drop log flags all counter drop log prefix "[nftables] Input Denied: " flags all counter drop } chain output { type filter hook output priority 0; policy accept; ---> ip daddr 123.0.0.0/8 counter reject } } xxxxx ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 4, 2019 11:05 AM, Reindl Harald <h.reindl@thelounge.net> wrote: > Am 04.10.19 um 12:44 schrieb Jags: > > > Should I modify it to the following: > > ::: > > chain output { > > type filter hook output priority 0; policy accept; > > > > ip daddr 123.0.0.0/8 counter reject } > > > > > > ::: > > and > > ::: > > chain input { > > type filter hook input priority 0; policy drop; > > > > ip saddr 123.0.0.0/8 counter drop } > > > > > > ::: > > surely, and that on top of the ruleset before any accept-rule, there is > no point to mention "ct state" when you just want to block communication > from and to a ip unconditionally ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 12:21 ` Jags @ 2019-10-04 13:06 ` Reindl Harald 2019-10-04 14:28 ` Jags 0 siblings, 1 reply; 16+ messages in thread From: Reindl Harald @ 2019-10-04 13:06 UTC (permalink / raw) To: Jags; +Cc: zrm, netfilter Am 04.10.19 um 14:21 schrieb : > Thank you so much. > > Now do I need to have OUTPUT chain before INPUT chain? 'Coz all the examples I've seen so far had INPUT as the first chain. shouldn't matter at all because a packet can only be output or input and not both > # Early drop of invalid connections > ct state invalid drop > ct state established,related accept switch both of them! you have far more packets from legit traffic than invalid ones and hence "established,related" should always be the first rule in any stateful filter with exceptions like the topic not sure about nftables but with iptables i would just place the drop stuff for 123.0.0.0/8 in -t raw PREROUTING because it's before conntrack and consider place it in a ipset for the case the list becomes longer becasue then you have only one rule and a lightning fast hash-lookup no matter how much entries > Side question: Does order of the chains or tables matter... like on other PC, I have "table inet nat" with chains "prerouting/postrouting". > > > Here's my complete nftables.conf: > > > xxxxx > #!/usr/sbin/nft -f > > flush ruleset > > table inet filter { > chain input { > type filter hook input priority 0; policy drop; > > iifname lo accept > > ---> ip saddr 123.0.0.0/8 counter drop > > # Early drop of invalid connections > ct state invalid drop > ct state established,related accept > > # ICMP & IGMP > ip saddr 192.168.0.0/16 icmp type echo-request counter accept > icmp type echo-request counter drop > ip protocol igmp drop > > # ssh for internal network > ip saddr 192.168.0.0/16 tcp dport 22 counter accept > > # Avoid brute force on ssh > tcp dport 22 ct state new limit rate 10/minute accept > > # VsFTPD > ip saddr 192.168.0.0/16 tcp dport 20 counter accept > ip saddr 192.168.0.0/16 tcp dport 21 counter accept > ip saddr 192.168.0.0/16 tcp dport 990 counter accept > ip saddr 192.168.0.0/16 tcp dport 40000-50000 counter accept > > ct state new drop > # Everything else > drop > > log flags all counter drop > log prefix "[nftables] Input Denied: " flags all counter drop > } > chain output { > type filter hook output priority 0; policy accept; > > ---> ip daddr 123.0.0.0/8 counter reject > } > } ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 13:06 ` Reindl Harald @ 2019-10-04 14:28 ` Jags 2019-10-04 15:10 ` Reindl Harald 0 siblings, 1 reply; 16+ messages in thread From: Jags @ 2019-10-04 14:28 UTC (permalink / raw) To: Reindl Harald; +Cc: zrm, netfilter > not sure about nftables but with iptables i would just place the drop > stuff for 123.0.0.0/8 in -t raw PREROUTING because it's before conntrack > and consider place it in a ipset for the case the list becomes longer > because then you have only one rule and a lightning fast hash-lookup no > matter how much entries Yes, I noticed CPU spikes, and removed drop/reject rules immediately. Thought I would re-enable these rules only when I run a torrent client. So should I just add a new table "raw" (and place this table at the top): xxxxxxxxx table inet raw { chain prerouting { type filter hook prerouting priority 0; policy accept; ip saddr 123.0.0.0/8 counter drop } chain output { type filter hook output priority 0; policy accept; ip daddr 123.0.0.0/8 counter reject } xxxxxxxxx Now do I need POSTROUTING chain in there too? From Gentoo wiki for Nftables: https://wiki.gentoo.org/wiki/Nftables#Tables "postrouting: This hook comes after the routing decision has been made, all packets leaving the machine hit this hook." Thank you so much. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 4, 2019 1:06 PM, Reindl Harald <h.reindl@thelounge.net> wrote: > Am 04.10.19 um 14:21 schrieb : > > > Thank you so much. > > Now do I need to have OUTPUT chain before INPUT chain? 'Coz all the examples I've seen so far had INPUT as the first chain. > > shouldn't matter at all because a packet can only be output or input and > not both > > > # Early drop of invalid connections > > ct state invalid drop > > ct state established,related accept > > > > switch both of them! you have far more packets from legit traffic than > invalid ones and hence "established,related" should always be the first > rule in any stateful filter with exceptions like the topic > > > > Side question: Does order of the chains or tables matter... like on other PC, I have "table inet nat" with chains "prerouting/postrouting". > > Here's my complete nftables.conf: > > xxxxx > > #!/usr/sbin/nft -f > > flush ruleset > > table inet filter { > > chain input { > > type filter hook input priority 0; policy drop; > > > > iifname lo accept > > > > > > ---> ip saddr 123.0.0.0/8 counter drop > > > > # Early drop of invalid connections > > ct state invalid drop > > ct state established,related accept > > > > # ICMP & IGMP > > ip saddr 192.168.0.0/16 icmp type echo-request counter accept > > icmp type echo-request counter drop > > ip protocol igmp drop > > > > # ssh for internal network > > ip saddr 192.168.0.0/16 tcp dport 22 counter accept > > > > # Avoid brute force on ssh > > tcp dport 22 ct state new limit rate 10/minute accept > > > > # VsFTPD > > ip saddr 192.168.0.0/16 tcp dport 20 counter accept > > ip saddr 192.168.0.0/16 tcp dport 21 counter accept > > ip saddr 192.168.0.0/16 tcp dport 990 counter accept > > ip saddr 192.168.0.0/16 tcp dport 40000-50000 counter accept > > > > ct state new drop > > # Everything else > > drop > > > > log flags all counter drop > > log prefix "[nftables] Input Denied: " flags all counter drop > > } > > chain output { > > type filter hook output priority 0; policy accept; > > > > > > ---> ip daddr 123.0.0.0/8 counter reject > > } > > } ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 14:28 ` Jags @ 2019-10-04 15:10 ` Reindl Harald 2019-10-04 15:47 ` Neal P. Murphy 2019-10-04 16:25 ` Jags 0 siblings, 2 replies; 16+ messages in thread From: Reindl Harald @ 2019-10-04 15:10 UTC (permalink / raw) To: Jags; +Cc: zrm, netfilter Am 04.10.19 um 16:28 schrieb Jags: >> not sure about nftables but with iptables i would just place the drop >> stuff for 123.0.0.0/8 in -t raw PREROUTING because it's before conntrack >> and consider place it in a ipset for the case the list becomes longer >> because then you have only one rule and a lightning fast hash-lookup no >> matter how much entries > > > Yes, I noticed CPU spikes, and removed drop/reject rules immediately. Thought I would re-enable these rules only when I run a torrent client. > > So should I just add a new table "raw" (and place this table at the top): > > xxxxxxxxx > table inet raw { > chain prerouting { > type filter hook prerouting priority 0; policy accept; > ip saddr 123.0.0.0/8 counter drop > } > chain output { > type filter hook output priority 0; policy accept; > ip daddr 123.0.0.0/8 counter reject > } > xxxxxxxxx > > > Now do I need POSTROUTING chain in there too? > > From Gentoo wiki for Nftables: https://wiki.gentoo.org/wiki/Nftables#Tables > > "postrouting: This hook comes after the routing decision has been made, all packets leaving the machine hit this hook" you don't need chains where you don't place rules disclaimer: i use iptables and plan to switch to iptables-nft over the long, so nftables may have sbtle different behavior however, it turned out to have way better performance for a big firewall setup place as much as possible in "-t mangle PREROUTING" (ct state invalid) and "-t raw PREROUTING" because less processing of packets not sure if "table inet raw" hast the same semantic (before conntrack, before routing)" but if it can have a postrouting hook i doubt because that's not possible for "-t raw" in iptables given that in this table there is no routing decision possible look at the image to get a picture, i can't help with nfstables itself https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 15:10 ` Reindl Harald @ 2019-10-04 15:47 ` Neal P. Murphy 2019-10-04 16:25 ` Jags 1 sibling, 0 replies; 16+ messages in thread From: Neal P. Murphy @ 2019-10-04 15:47 UTC (permalink / raw) Cc: netfilter On Fri, 4 Oct 2019 17:10:05 +0200 Reindl Harald <h.reindl@thelounge.net> wrote: > Am 04.10.19 um 16:28 schrieb Jags: > >> not sure about nftables but with iptables i would just place the drop > >> stuff for 123.0.0.0/8 in -t raw PREROUTING because it's before conntrack > >> and consider place it in a ipset for the case the list becomes longer > >> because then you have only one rule and a lightning fast hash-lookup no > >> matter how much entries > > > > > > Yes, I noticed CPU spikes, and removed drop/reject rules immediately. Thought I would re-enable these rules only when I run a torrent client. > > > > So should I just add a new table "raw" (and place this table at the top): > > > > xxxxxxxxx > > table inet raw { > > chain prerouting { > > type filter hook prerouting priority 0; policy accept; > > ip saddr 123.0.0.0/8 counter drop > > } > > chain output { > > type filter hook output priority 0; policy accept; > > ip daddr 123.0.0.0/8 counter reject > > } > > xxxxxxxxx > > > > > > Now do I need POSTROUTING chain in there too? > > > > From Gentoo wiki for Nftables: https://wiki.gentoo.org/wiki/Nftables#Tables > > > > "postrouting: This hook comes after the routing decision has been made, all packets leaving the machine hit this hook" > you don't need chains where you don't place rules > > disclaimer: i use iptables and plan to switch to iptables-nft over the > long, so nftables may have sbtle different behavior > > however, it turned out to have way better performance for a big firewall > setup place as much as possible in "-t mangle PREROUTING" (ct state > invalid) and "-t raw PREROUTING" because less processing of packets The top of mangle:PREROUTING is the best place to DROP packets you already know you never want to process, route or forward, such as INVALID packets, TEST net addresses, and blacklisted public IPs and IP ranges. But remember that you might not know all addresses until table filter when NAT is involved. > > not sure if "table inet raw" hast the same semantic (before conntrack, > before routing)" but if it can have a postrouting hook i doubt because > that's not possible for "-t raw" in iptables given that in this table > there is no routing decision possible > > look at the image to get a picture, i can't help with nfstables itself > https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 15:10 ` Reindl Harald 2019-10-04 15:47 ` Neal P. Murphy @ 2019-10-04 16:25 ` Jags 2019-10-04 20:30 ` Anton Rieger 1 sibling, 1 reply; 16+ messages in thread From: Jags @ 2019-10-04 16:25 UTC (permalink / raw) To: Reindl Harald; +Cc: zrm, netfilter, neal.p.murphy Could someone please clarify RAW/MANGLE tables in regards to Nftables. I could not find any details in Nftables wiki specifically for RAW/MANGLE tables. While I find Gentoo wiki for Nftables much more friendlier: https://wiki.gentoo.org/wiki/Nftables#Tables xxx Tables: A table is nothing more than a container for your chains. With nftables there are no predefined tables (filter, raw, mangle...) anymore. You are free to recreate an iptables-like structure, but anything might do. Currently there are 5 different families of tables: ip, ip6, arp, bridge, inet xxx My question is, since Nftables doesn't have predefined tables, just by naming a table: "table inet raw", does it becomes a RAW table or not? If not, what do I have to do? I thank you all so much. For now I have added this to my nftables.conf xxxxx table inet raw { chain prerouting { type filter hook prerouting priority 0; policy accept; ip saddr 123.0.0.0/8 counter drop } chain output { type filter hook output priority 0; policy accept; ip daddr 123.0.0.0/8 counter reject } } xxxxx ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 4, 2019 3:10 PM, Reindl Harald <h.reindl@thelounge.net> wrote: > Am 04.10.19 um 16:28 schrieb Jags: > > > > not sure about nftables but with iptables i would just place the drop > > > stuff for 123.0.0.0/8 in -t raw PREROUTING because it's before conntrack > > > and consider place it in a ipset for the case the list becomes longer > > > because then you have only one rule and a lightning fast hash-lookup no > > > matter how much entries > > > > Yes, I noticed CPU spikes, and removed drop/reject rules immediately. Thought I would re-enable these rules only when I run a torrent client. > > So should I just add a new table "raw" (and place this table at the top): > > xxxxxxxxx > > table inet raw { > > chain prerouting { > > type filter hook prerouting priority 0; policy accept; > > ip saddr 123.0.0.0/8 counter drop > > } > > chain output { > > type filter hook output priority 0; policy accept; > > ip daddr 123.0.0.0/8 counter reject > > } > > xxxxxxxxx > > Now do I need POSTROUTING chain in there too? > > From Gentoo wiki for Nftables: https://wiki.gentoo.org/wiki/Nftables#Tables > > "postrouting: This hook comes after the routing decision has been made, all packets leaving the machine hit this hook" > > you don't need chains where you don't place rules > > disclaimer: i use iptables and plan to switch to iptables-nft over the > long, so nftables may have sbtle different behavior > > however, it turned out to have way better performance for a big firewall > setup place as much as possible in "-t mangle PREROUTING" (ct state > invalid) and "-t raw PREROUTING" because less processing of packets > > not sure if "table inet raw" hast the same semantic (before conntrack, > before routing)" but if it can have a postrouting hook i doubt because > that's not possible for "-t raw" in iptables given that in this table > there is no routing decision possible > > look at the image to get a picture, i can't help with nfstables itself > https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 16:25 ` Jags @ 2019-10-04 20:30 ` Anton Rieger 2019-10-04 21:27 ` Jags 0 siblings, 1 reply; 16+ messages in thread From: Anton Rieger @ 2019-10-04 20:30 UTC (permalink / raw) To: netfilter >Could someone please clarify RAW/MANGLE tables in regards to Nftables. Short story short: They doesn't exist anymore, but you can change priorities to simulate them. Long answer: A table in nftables is identified by: 1) Their name 2) Their addressees family is one of ip, ip6, inet, arp, bridge, netdev (inet is ip+ip6) Currently only the ``dormant'' flag is supported meaning the table is not evaluated any more A table is a container for chains. A chain is a container for rules. There are two types of chains: 1) base chain 2) regular chain A base chain must specify a ``type'', ``hook'' and ``priority''. They need them, as these chains are entry points of packets from the network stack. You can use these to reconstruct the predefined iptables chains by naming them the same. Each type is bound to certain families hooks: filter) Standard type can be used everywhere. nat) Must be ip, ip6 or inet and provide prerouting, input, output, postrouting hooks Performs NAT based on conntrack entries. Only first packet of a connection traverses this chain. Specify conntrack details here. route) Must be ip or ip6 and only provides the output hook. If accepted and IP header changes a new route lookup is performed. Use this to e.g. implement policy routing selectors. Quirks: netdev needs filter and ingress hook and device parameter is mandatory. arp only supports input/output hooks. So you can see, that the most used type is filter. To order with chain gets triggered in which order is determined by the priority parameter. This can either be a signed integer (lower values have precedence) or standard priority names. These standard priority names are labeled to match xtables default values: raw := -300 (ip,ip6,inet) all hooks mangle := -150 (ip,ip6,inet) all hooks dstnat := -100 (ip,ip6,inet) prerouting filter := 0 (ip,ip6,inet,arp,netdev) all hooks security := 50 (ip,ip6,inet) all hooks srcnat := 100 (ip,ip6,inet) postrouting Please note, the ``bridge'' family has different values for dstnat,filter,out,scrnat You can also use addition/subtraction in your definitions. So their order is basically the same. All this information is well documented in nft(8) >Currently there are 5 different families of tables: ip, ip6, arp, bridge, inet Should be updated to include the ``netdev'' family (for ingress handling) >My question is, since Nftables doesn't have predefined tables, just by naming a table: >"table inet raw", does it becomes a RAW table or not? It is NOT implicitly a raw table in the iptables sense. It's just a table matching ip or ip6 family packets. > If not, what do I have to do? You have to add at least one chain with the priority ``raw''. So to match iptables: ``` table inet raw { chain PREROUTING { type filter hook prerouting priority raw; policy accepted; } chain OUTPUT { type filter hook output priority raw; policy accepted; } } ``` Please note that ``policy accept'' is the default choice thus defining it here is just for better understanding. >For now I have added this to my nftables.conf > >xxxxx >table inet raw { > chain prerouting { > type filter hook prerouting priority 0; policy accept; > ip saddr 123.0.0.0/8 counter drop > } > chain output { > type filter hook output priority 0; policy accept; > ip daddr 123.0.0.0/8 counter reject > } >} >xxxxx Please note a priority of 0 is equal to ``filter''. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 20:30 ` Anton Rieger @ 2019-10-04 21:27 ` Jags 2019-10-06 17:26 ` sean darcy 0 siblings, 1 reply; 16+ messages in thread From: Jags @ 2019-10-04 21:27 UTC (permalink / raw) To: Anton Rieger; +Cc: netfilter @Anton Rieger, thank you so much. (1) > You have to add at least one chain with the priority ``raw''. > So to match iptables: This is the answer I was looking for. Note-1: If anyone reading this who could edit Nftables wiki, needs to highlight this. http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields I came across this page earlier and saw "-300" but the page didn't mention THE importance of "priority -300" Note-2: In regards to command syntaxes on Nftables wiki: Following is just one example, but it almost applies everywhere on Nftables wiki pages. The following example will display an error: From this page: http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields nft add chain raw prerouting {type filter hook prerouting priority -300\;} While I think, what it should be (at least when run in Bash on Debian/Ubuntu): nft add chain raw prerouting '{ type filter hook prerouting priority -300; }' I figured this difference out a while ago from Arch wiki page: https://wiki.archlinux.org/index.php/Nftables#Base_chain (2) AFTER reading your mail, I have modified the PRIORITY to -300, for "raw" table: table inet raw { chain prerouting { type filter hook prerouting priority -300; policy accept; ip saddr 123.0.0.0/8 counter drop } chain output { type filter hook output priority -300; policy accept; ip daddr 123.0.0.0/8 counter reject } } (3) Just before I read your mail, I found these pages: (a) https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families#netdev I found this very interesting: "This family provides the ingress hook, that allows you to classify packets that the driver has just passed up to the networking stack." (b) In regards to INGRESS hook: https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks (c) "Mandatory to specify the device where the chain will be attached": https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Adding_base_chains So I have added this "devfilter" table: table netdev devfilter { chain ingress { type filter hook ingress device wlx98ded00b03a5 priority -400; policy accept; ip saddr 123.0.0.0/8 counter drop } } Now I think with "netdev/ingress", there's no need for prerouting within "raw" table, as the new ingress hook comes before prerouting (as per Nftables wiki). But I've kept it there for now. I truly thank you all... ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 4, 2019 8:30 PM, Anton Rieger <rieger@jikken.de> wrote: > > Could someone please clarify RAW/MANGLE tables in regards to Nftables. > > Short story short: > They doesn't exist anymore, but you can change priorities to simulate them. > > Long answer: > A table in nftables is identified by: > 1) Their name > 2) Their addressees family is one of ip, ip6, inet, arp, bridge, netdev (inet is ip+ip6) > Currently only the `dormant'' flag is supported meaning the table is not evaluated any more A table is a container for chains. A chain is a container for rules. There are two types of chains: 1) base chain 2) regular chain A base chain must specify a`type'', `hook'' and`priority''. > They need them, as these chains are entry points of packets from the network stack. > You can use these to reconstruct the predefined iptables chains by naming them the same. > > Each type is bound to certain families hooks: > filter) Standard type can be used everywhere. > nat) Must be ip, ip6 or inet and provide prerouting, input, output, postrouting hooks > Performs NAT based on conntrack entries. > Only first packet of a connection traverses this chain. > Specify conntrack details here. > route) Must be ip or ip6 and only provides the output hook. > If accepted and IP header changes a new route lookup is performed. > Use this to e.g. implement policy routing selectors. > > Quirks: > netdev needs filter and ingress hook and device parameter is mandatory. > arp only supports input/output hooks. > > So you can see, that the most used type is filter. > To order with chain gets triggered in which order is determined by the priority parameter. > This can either be a signed integer (lower values have precedence) or standard priority names. > These standard priority names are labeled to match xtables default values: > > raw := -300 (ip,ip6,inet) all hooks > mangle := -150 (ip,ip6,inet) all hooks > dstnat := -100 (ip,ip6,inet) prerouting > filter := 0 (ip,ip6,inet,arp,netdev) all hooks > security := 50 (ip,ip6,inet) all hooks > srcnat := 100 (ip,ip6,inet) postrouting > > Please note, the ``bridge'' family has different values for dstnat,filter,out,scrnat > You can also use addition/subtraction in your definitions. > So their order is basically the same. > All this information is well documented in nft(8) > > > Currently there are 5 different families of tables: ip, ip6, arp, bridge, inet > > Should be updated to include the ``netdev'' family (for ingress handling) > > > My question is, since Nftables doesn't have predefined tables, just by naming a table: > > "table inet raw", does it becomes a RAW table or not? > > It is NOT implicitly a raw table in the iptables sense. It's just a table matching ip or > ip6 family packets. > > > If not, what do I have to do? > > You have to add at least one chain with the priority ``raw''. > So to match iptables: > > table inet raw { > chain PREROUTING { > type filter hook prerouting priority raw; policy accepted; > } > > chain OUTPUT { > type filter hook output priority raw; policy accepted; > } > } > > > Please note that ``policy accept'' is the default choice thus defining it here > is just for better understanding. > > > For now I have added this to my nftables.conf > > xxxxx > > table inet raw { > > chain prerouting { > > type filter hook prerouting priority 0; policy accept; > > ip saddr 123.0.0.0/8 counter drop > > } > > chain output { > > type filter hook output priority 0; policy accept; > > ip daddr 123.0.0.0/8 counter reject > > } > > } > > xxxxx > > Please note a priority of 0 is equal to ``filter''. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-04 21:27 ` Jags @ 2019-10-06 17:26 ` sean darcy 2019-10-06 23:00 ` Jags 0 siblings, 1 reply; 16+ messages in thread From: sean darcy @ 2019-10-06 17:26 UTC (permalink / raw) To: netfilter On 10/4/19 5:27 PM, Jags wrote: > @Anton Rieger, thank you so much. > > > > (1) >> You have to add at least one chain with the priority ``raw''. >> So to match iptables: > > This is the answer I was looking for. > > > Note-1: If anyone reading this who could edit Nftables wiki, needs to highlight this. > > http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields > > I came across this page earlier and saw "-300" but the page didn't mention THE importance of "priority -300" > > > Note-2: In regards to command syntaxes on Nftables wiki: Following is just one example, but it almost applies everywhere on Nftables wiki pages. The following example will display an error: > > From this page: http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields > > nft add chain raw prerouting {type filter hook prerouting priority -300\;} > > While I think, what it should be (at least when run in Bash on Debian/Ubuntu): > > nft add chain raw prerouting '{ type filter hook prerouting priority -300; }' > > I figured this difference out a while ago from Arch wiki page: > > https://wiki.archlinux.org/index.php/Nftables#Base_chain > > > > (2) > AFTER reading your mail, I have modified the PRIORITY to -300, for "raw" table: > > table inet raw { > chain prerouting { > type filter hook prerouting priority -300; policy accept; > ip saddr 123.0.0.0/8 counter drop > } > chain output { > type filter hook output priority -300; policy accept; > ip daddr 123.0.0.0/8 counter reject > } > } > > > (3) > Just before I read your mail, I found these pages: > > (a) https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families#netdev > > I found this very interesting: "This family provides the ingress hook, > that allows you to classify packets that the driver has just passed up to the networking stack." > > (b) In regards to INGRESS hook: https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks > > (c) "Mandatory to specify the device where the chain will be attached": > https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Adding_base_chains > > So I have added this "devfilter" table: > > > table netdev devfilter { > chain ingress { > type filter hook ingress device wlx98ded00b03a5 priority -400; policy accept; > ip saddr 123.0.0.0/8 counter drop > } > } > > > Now I think with "netdev/ingress", there's no need for prerouting within "raw" table, > as the new ingress hook comes before prerouting (as per Nftables wiki). But I've kept it there for now. > > > I truly thank you all... > > > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, October 4, 2019 8:30 PM, Anton Rieger <rieger@jikken.de> wrote: > >>> Could someone please clarify RAW/MANGLE tables in regards to Nftables. >> >> Short story short: >> They doesn't exist anymore, but you can change priorities to simulate them. >> >> Long answer: >> A table in nftables is identified by: >> 1) Their name >> 2) Their addressees family is one of ip, ip6, inet, arp, bridge, netdev (inet is ip+ip6) >> Currently only the `dormant'' flag is supported meaning the table is not evaluated any more A table is a container for chains. A chain is a container for rules. There are two types of chains: 1) base chain 2) regular chain A base chain must specify a`type'', `hook'' and`priority''. >> They need them, as these chains are entry points of packets from the network stack. >> You can use these to reconstruct the predefined iptables chains by naming them the same. >> >> Each type is bound to certain families hooks: >> filter) Standard type can be used everywhere. >> nat) Must be ip, ip6 or inet and provide prerouting, input, output, postrouting hooks >> Performs NAT based on conntrack entries. >> Only first packet of a connection traverses this chain. >> Specify conntrack details here. >> route) Must be ip or ip6 and only provides the output hook. >> If accepted and IP header changes a new route lookup is performed. >> Use this to e.g. implement policy routing selectors. >> >> Quirks: >> netdev needs filter and ingress hook and device parameter is mandatory. >> arp only supports input/output hooks. >> >> So you can see, that the most used type is filter. >> To order with chain gets triggered in which order is determined by the priority parameter. >> This can either be a signed integer (lower values have precedence) or standard priority names. >> These standard priority names are labeled to match xtables default values: >> >> raw := -300 (ip,ip6,inet) all hooks >> mangle := -150 (ip,ip6,inet) all hooks >> dstnat := -100 (ip,ip6,inet) prerouting >> filter := 0 (ip,ip6,inet,arp,netdev) all hooks >> security := 50 (ip,ip6,inet) all hooks >> srcnat := 100 (ip,ip6,inet) postrouting >> >> Please note, the ``bridge'' family has different values for dstnat,filter,out,scrnat >> You can also use addition/subtraction in your definitions. >> So their order is basically the same. >> All this information is well documented in nft(8) >> >>> Currently there are 5 different families of tables: ip, ip6, arp, bridge, inet >> >> Should be updated to include the ``netdev'' family (for ingress handling) >> >>> My question is, since Nftables doesn't have predefined tables, just by naming a table: >>> "table inet raw", does it becomes a RAW table or not? >> >> It is NOT implicitly a raw table in the iptables sense. It's just a table matching ip or >> ip6 family packets. >> >>> If not, what do I have to do? >> >> You have to add at least one chain with the priority ``raw''. >> So to match iptables: >> >> table inet raw { >> chain PREROUTING { >> type filter hook prerouting priority raw; policy accepted; >> } >> >> chain OUTPUT { >> type filter hook output priority raw; policy accepted; >> } >> } >> >> >> Please note that ``policy accept'' is the default choice thus defining it here >> is just for better understanding. >> >>> For now I have added this to my nftables.conf >>> xxxxx >>> table inet raw { >>> chain prerouting { >>> type filter hook prerouting priority 0; policy accept; >>> ip saddr 123.0.0.0/8 counter drop >>> } >>> chain output { >>> type filter hook output priority 0; policy accept; >>> ip daddr 123.0.0.0/8 counter reject >>> } >>> } >>> xxxxx >> >> Please note a priority of 0 is equal to ``filter''. > > > Or use netdev to drop the packets when they first show up at the interface: table netdev netdev1 { chain ingress1 { type filter hook ingress device etho priority 0 ; ip saddr 123.0.0.0/8 counter drop } } ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 2019-10-06 17:26 ` sean darcy @ 2019-10-06 23:00 ` Jags 0 siblings, 0 replies; 16+ messages in thread From: Jags @ 2019-10-06 23:00 UTC (permalink / raw) To: sean darcy; +Cc: netfilter @Sean thank you. > Or use netdev to drop the packets when they first show up at the interface: > > table netdev netdev1 { > chain ingress1 { > type filter hook ingress device etho priority 0 ; > ip saddr 123.0.0.0/8 counter drop > } > } As I've mentioned in the previous mail, now I have this in place: xxxxx table netdev devfilter { chain ingress { type filter hook ingress device wlx98ded00b03a5 priority -400; policy accept; ip saddr 123.0.0.0/8 counter drop } } table inet raw { chain output { type filter hook output priority -300; policy accept; ip daddr 123.0.0.0/8 counter reject } } xxxxx ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, October 6, 2019 5:26 PM, sean darcy <seandarcy2@gmail.com> wrote: > On 10/4/19 5:27 PM, Jags wrote: > > > @Anton Rieger, thank you so much. > > (1) > > > > > You have to add at least one chain with the priority ``raw''. > > > So to match iptables: > > > > This is the answer I was looking for. > > Note-1: If anyone reading this who could edit Nftables wiki, needs to highlight this. > > http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields > > I came across this page earlier and saw "-300" but the page didn't mention THE importance of "priority -300" > > Note-2: In regards to command syntaxes on Nftables wiki: Following is just one example, but it almost applies everywhere on Nftables wiki pages. The following example will display an error: > > From this page: http://wiki.nftables.org/wiki-nftables/index.php/Mangle_packet_header_fields > > nft add chain raw prerouting {type filter hook prerouting priority -300\;} > > While I think, what it should be (at least when run in Bash on Debian/Ubuntu): > > nft add chain raw prerouting '{ type filter hook prerouting priority -300; }' > > I figured this difference out a while ago from Arch wiki page: > > https://wiki.archlinux.org/index.php/Nftables#Base_chain > > (2) > > AFTER reading your mail, I have modified the PRIORITY to -300, for "raw" table: > > table inet raw { > > chain prerouting { > > type filter hook prerouting priority -300; policy accept; > > ip saddr 123.0.0.0/8 counter drop > > } > > chain output { > > type filter hook output priority -300; policy accept; > > ip daddr 123.0.0.0/8 counter reject > > } > > } > > (3) > > Just before I read your mail, I found these pages: > > (a) https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families#netdev > > I found this very interesting: "This family provides the ingress hook, > > that allows you to classify packets that the driver has just passed up to the networking stack." > > (b) In regards to INGRESS hook: https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks > > (c) "Mandatory to specify the device where the chain will be attached": > > https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Adding_base_chains > > So I have added this "devfilter" table: > > table netdev devfilter { > > chain ingress { > > type filter hook ingress device wlx98ded00b03a5 priority -400; policy accept; > > ip saddr 123.0.0.0/8 counter drop > > } > > } > > Now I think with "netdev/ingress", there's no need for prerouting within "raw" table, > > as the new ingress hook comes before prerouting (as per Nftables wiki). But I've kept it there for now. > > I truly thank you all... > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Friday, October 4, 2019 8:30 PM, Anton Rieger rieger@jikken.de wrote: > > > > > > Could someone please clarify RAW/MANGLE tables in regards to Nftables. > > > > > > Short story short: > > > They doesn't exist anymore, but you can change priorities to simulate them. > > > Long answer: > > > A table in nftables is identified by: > > > > > > 1. Their name > > > 2. Their addressees family is one of ip, ip6, inet, arp, bridge, netdev (inet is ip+ip6) > > > Currently only the `dormant'' flag is supported meaning the table is not evaluated any more A table is a container for chains. A chain is a container for rules. There are two types of chains: 1) base chain 2) regular chain A base chain must specify a`type'', `hook'' and`priority''. > > > They need them, as these chains are entry points of packets from the network stack. > > > You can use these to reconstruct the predefined iptables chains by naming them the same. > > > > > > > > > Each type is bound to certain families hooks: > > > filter) Standard type can be used everywhere. > > > nat) Must be ip, ip6 or inet and provide prerouting, input, output, postrouting hooks > > > Performs NAT based on conntrack entries. > > > Only first packet of a connection traverses this chain. > > > Specify conntrack details here. > > > route) Must be ip or ip6 and only provides the output hook. > > > If accepted and IP header changes a new route lookup is performed. > > > Use this to e.g. implement policy routing selectors. > > > Quirks: > > > netdev needs filter and ingress hook and device parameter is mandatory. > > > arp only supports input/output hooks. > > > So you can see, that the most used type is filter. > > > To order with chain gets triggered in which order is determined by the priority parameter. > > > This can either be a signed integer (lower values have precedence) or standard priority names. > > > These standard priority names are labeled to match xtables default values: > > > raw := -300 (ip,ip6,inet) all hooks > > > mangle := -150 (ip,ip6,inet) all hooks > > > dstnat := -100 (ip,ip6,inet) prerouting > > > filter := 0 (ip,ip6,inet,arp,netdev) all hooks > > > security := 50 (ip,ip6,inet) all hooks > > > srcnat := 100 (ip,ip6,inet) postrouting > > > Please note, the ``bridge'' family has different values for dstnat,filter,out,scrnat > > > You can also use addition/subtraction in your definitions. > > > So their order is basically the same. > > > All this information is well documented in nft(8) > > > > > > > Currently there are 5 different families of tables: ip, ip6, arp, bridge, inet > > > > > > Should be updated to include the ``netdev'' family (for ingress handling) > > > > > > > My question is, since Nftables doesn't have predefined tables, just by naming a table: > > > > "table inet raw", does it becomes a RAW table or not? > > > > > > It is NOT implicitly a raw table in the iptables sense. It's just a table matching ip or > > > ip6 family packets. > > > > > > > If not, what do I have to do? > > > > > > You have to add at least one chain with the priority ``raw''. > > > So to match iptables: > > > > > > table inet raw { > > > chain PREROUTING { > > > type filter hook prerouting priority raw; policy accepted; > > > } > > > > > > chain OUTPUT { > > > type filter hook output priority raw; policy accepted; > > > } > > > } > > > > > > > > > Please note that ``policy accept'' is the default choice thus defining it here > > > is just for better understanding. > > > > > > > For now I have added this to my nftables.conf > > > > xxxxx > > > > table inet raw { > > > > chain prerouting { > > > > type filter hook prerouting priority 0; policy accept; > > > > ip saddr 123.0.0.0/8 counter drop > > > > } > > > > chain output { > > > > type filter hook output priority 0; policy accept; > > > > ip daddr 123.0.0.0/8 counter reject > > > > } > > > > } > > > > xxxxx > > > > > > Please note a priority of 0 is equal to ``filter''. > > Or use netdev to drop the packets when they first show up at the interface: > > table netdev netdev1 { > chain ingress1 { > type filter hook ingress device etho priority 0 ; > ip saddr 123.0.0.0/8 counter drop > } > } ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2019-10-06 23:00 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-01 23:22 How can I block all traffic from an IP range, irrespective of origin, going to, or coming from, using nftables in Debian 10 Jags 2019-10-03 19:00 ` zrm 2019-10-04 9:45 ` Jags 2019-10-04 10:18 ` Reindl Harald 2019-10-04 10:44 ` Jags 2019-10-04 11:05 ` Reindl Harald 2019-10-04 12:21 ` Jags 2019-10-04 13:06 ` Reindl Harald 2019-10-04 14:28 ` Jags 2019-10-04 15:10 ` Reindl Harald 2019-10-04 15:47 ` Neal P. Murphy 2019-10-04 16:25 ` Jags 2019-10-04 20:30 ` Anton Rieger 2019-10-04 21:27 ` Jags 2019-10-06 17:26 ` sean darcy 2019-10-06 23:00 ` Jags
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.