* Is viewing a "candidate" ruleset in 'nft list ruleset' format possible?
@ 2020-04-19 2:12 Martin Gignac
2020-04-22 4:51 ` Trent W. Buck
0 siblings, 1 reply; 8+ messages in thread
From: Martin Gignac @ 2020-04-19 2:12 UTC (permalink / raw)
To: netfilter
Hi,
I'd like to know if it's possible tell 'nft' to load a ruleset from
file *without* applying it (a la 'nft -c -f <ruleset>) *but* also have
it show the parsed (yet unapplied) ruleset in 'nft list ruleset'
format as well?
I ask because I have a Bash script with a few helper functions for
nftables and one of the things I'd like to be able to do is to perform
a diff between a candidate ruleset and the last applied/current
ruleset. I can already do this by diffing the ruleset from file with
the last previously saved ruleset from file, but I'd like to be able
to (instead) compare the ruleset using the "cleaned up" format from
'nft list ruleset'. I just don't know how to generate a "candidate"
ruleset in that format without applying it to the kernel first (and
then it's not longer a "candidate", obviously).
Hopefully my question makes sense.
Thanks,
-Martin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is viewing a "candidate" ruleset in 'nft list ruleset' format possible?
2020-04-19 2:12 Is viewing a "candidate" ruleset in 'nft list ruleset' format possible? Martin Gignac
@ 2020-04-22 4:51 ` Trent W. Buck
2020-04-22 16:34 ` Martin Gignac
0 siblings, 1 reply; 8+ messages in thread
From: Trent W. Buck @ 2020-04-22 4:51 UTC (permalink / raw)
To: netfilter
Martin Gignac <martin.gignac@gmail.com> writes:
> I'd like to know if it's possible tell 'nft' to load a ruleset from
> file *without* applying it (a la 'nft -c -f <ruleset>) *but* also have
> it show the parsed (yet unapplied) ruleset in 'nft list ruleset'
> format as well?
I am also interested in this.
You can simply put "list ruleset" at the bottom of the foo.nft file.
However in my experience this routinely gives outright wrong rulesets
(as at nftables 0.9.1), so I don't trust it.
A possible short-term workaround would be to spin up a netns, load the
new ruleset in *there*, then dump it and tear the ns down again...
$ sudo nft list ruleset | b2sum
5524[...]3459 -
$ sudo ip netns add delete-me
$ sudo ip netns exec delete-me nft -i
nft> list ruleset
nft> add table inet filter
nft> add chain inet filter frobozz
nft> add rule inet filter frobozz tcp dport ssh accept
nft> list ruleset
table inet filter {
chain frobozz {
tcp dport 22 accept
}
}
nft>
$ sudo nft list ruleset | b2sum
5524[...]3459 -
$ # Good, the production ruleset hasn't changed.
$ sudo ip netns del delete-me # clean up
If you need to do this as unprivileged user,
I guess look into unshare(1) or bwrap...
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is viewing a "candidate" ruleset in 'nft list ruleset' format possible?
2020-04-22 4:51 ` Trent W. Buck
@ 2020-04-22 16:34 ` Martin Gignac
2020-04-23 2:06 ` Duncan Roe
2020-04-30 3:10 ` Trent W. Buck
0 siblings, 2 replies; 8+ messages in thread
From: Martin Gignac @ 2020-04-22 16:34 UTC (permalink / raw)
To: netfilter
> You can simply put "list ruleset" at the bottom of the foo.nft file.
> However in my experience this routinely gives outright wrong rulesets
> (as at nftables 0.9.1), so I don't trust it.
That's a pretty good tip, thanks!... And you're absolutely right, it
gives some weird output. See below the diff of 'nft -c -f foo.nft'
with a 'list ruleset' at the bottom and the actual output of 'nft list
ruleset' once foot.nft is applied to the kernel:
[root@bouboule ~]# diff -u /tmp/toto1.txt /tmp/toto2.txt
--- /tmp/toto1.txt 2020-04-22 11:55:55.718378603 -0400
+++ /tmp/toto2.txt 2020-04-22 11:56:01.888551779 -0400
@@ -1,12 +1,12 @@
table ip filter {
chain input {
type filter hook input priority filter; policy drop;
- ct state 0x6 accept
+ ct state established,related accept
ct state invalid drop
iif "lo" accept
- meta l4proto icmp icmp type echo-request accept
comment "You can restrict this if you want"
- meta l4proto tcp tcp dport 22 accept comment "You can
restrict this if you want"
- meta l4proto tcp tcp dport 179 accept comment "For BGP"
+ icmp type echo-request accept comment "You can
restrict this if you want"
+ tcp dport 22 accept comment "You can restrict this if you want"
+ tcp dport 179 accept comment "For BGP"
}
chain output {
@@ -15,7 +15,7 @@
chain forward {
type filter hook forward priority filter; policy drop;
- ct state 0x6 counter packets 0 bytes 0 accept
+ ct state established,related counter packets 0 bytes 0 accept
ct state invalid drop
}
}
Of note is the fact that the 'ct state' line does not contain both
states. As well, the addition of 'meta l4proto' adds a lot of
unecessary verbiage. But still, good to know that this is somewhat
doable as it never dawned on me to put 'list ruleset' at the end of
foo.nft.
> A possible short-term workaround would be to spin up a netns, load the
> new ruleset in *there*, then dump it and tear the ns down again...
This is actually a very cool idea! I never realized that nftables
rulesets are bound to a specific namespace, but now it makes perfect
sense. The only "drawback" (I guess) is that I cannot use 'iif' for
any other interface than 'lo' in the temp namespace; I'll need to use
'iifname' instead since the referenced interfaces won't exist in the
temp namespace. But it's not a deal breaker.
I think I will go with this workaround until (if) nftables supports
this functionality natively.
Thanks!
-Martin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is viewing a "candidate" ruleset in 'nft list ruleset' format possible?
2020-04-22 16:34 ` Martin Gignac
@ 2020-04-23 2:06 ` Duncan Roe
2020-04-23 12:10 ` Martin Gignac
2020-04-30 3:25 ` Trent W. Buck
2020-04-30 3:10 ` Trent W. Buck
1 sibling, 2 replies; 8+ messages in thread
From: Duncan Roe @ 2020-04-23 2:06 UTC (permalink / raw)
To: netfilter
On Wed, Apr 22, 2020 at 12:34:26PM -0400, Martin Gignac wrote:
> > You can simply put "list ruleset" at the bottom of the foo.nft file.
> > However in my experience this routinely gives outright wrong rulesets
> > (as at nftables 0.9.1), so I don't trust it.
"list ruleset" at the bottom of an nft script is completely accurate. The
command "nft list ruleset" discards portions of rules that are implicit, in the
interests of brevity.
>
> That's a pretty good tip, thanks!... And you're absolutely right, it
> gives some weird output. See below the diff of 'nft -c -f foo.nft'
> with a 'list ruleset' at the bottom and the actual output of 'nft list
> ruleset' once foot.nft is applied to the kernel:
>
> [root@bouboule ~]# diff -u /tmp/toto1.txt /tmp/toto2.txt
> --- /tmp/toto1.txt 2020-04-22 11:55:55.718378603 -0400
> +++ /tmp/toto2.txt 2020-04-22 11:56:01.888551779 -0400
> @@ -1,12 +1,12 @@
> table ip filter {
> chain input {
> type filter hook input priority filter; policy drop;
> - ct state 0x6 accept
> + ct state established,related accept
> ct state invalid drop
> iif "lo" accept
> - meta l4proto icmp icmp type echo-request accept
> comment "You can restrict this if you want"
> - meta l4proto tcp tcp dport 22 accept comment "You can
> restrict this if you want"
> - meta l4proto tcp tcp dport 179 accept comment "For BGP"
> + icmp type echo-request accept comment "You can
> restrict this if you want"
> + tcp dport 22 accept comment "You can restrict this if you want"
> + tcp dport 179 accept comment "For BGP"
> }
>
> chain output {
> @@ -15,7 +15,7 @@
>
> chain forward {
> type filter hook forward priority filter; policy drop;
> - ct state 0x6 counter packets 0 bytes 0 accept
> + ct state established,related counter packets 0 bytes 0 accept
> ct state invalid drop
> }
> }
>
> Of note is the fact that the 'ct state' line does not contain both
> states.
It does show it. There are 2 bits set in 0x6. Perhaps it is an oversight that
the code path does not interpret them.
> As well, the addition of 'meta l4proto' adds a lot of
> unecessary verbiage.
They are necessary *for the kernel*. The nft user interface is smart enough that
you don't have to specify them.
> But still, good to know that this is somewhat
> doable as it never dawned on me to put 'list ruleset' at the end of
> foo.nft.
>
> > A possible short-term workaround would be to spin up a netns, load the
> > new ruleset in *there*, then dump it and tear the ns down again...
>
> This is actually a very cool idea! I never realized that nftables
> rulesets are bound to a specific namespace, but now it makes perfect
> sense. The only "drawback" (I guess) is that I cannot use 'iif' for
> any other interface than 'lo' in the temp namespace; I'll need to use
> 'iifname' instead since the referenced interfaces won't exist in the
> temp namespace. But it's not a deal breaker.
>
> I think I will go with this workaround until (if) nftables supports
> this functionality natively.
>
> Thanks!
> -Martin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is viewing a "candidate" ruleset in 'nft list ruleset' format possible?
2020-04-23 2:06 ` Duncan Roe
@ 2020-04-23 12:10 ` Martin Gignac
2020-04-30 3:25 ` Trent W. Buck
1 sibling, 0 replies; 8+ messages in thread
From: Martin Gignac @ 2020-04-23 12:10 UTC (permalink / raw)
To: netfilter
> "list ruleset" at the bottom of an nft script is completely accurate. The
> command "nft list ruleset" discards portions of rules that are implicit, in the
> interests of brevity.
> > Of note is the fact that the 'ct state' line does not contain both
> > states.
> It does show it. There are 2 bits set in 0x6. Perhaps it is an oversight that
> the code path does not interpret them.
Point taken. I guess it's just because the output of 'nft list
ruleset' seems more "human readable" to me than "list ruleset" at the
bottom, and I'd rather use the former output as a base for diffs.
Thanks,
-Martin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is viewing a "candidate" ruleset in 'nft list ruleset' format possible?
2020-04-22 16:34 ` Martin Gignac
2020-04-23 2:06 ` Duncan Roe
@ 2020-04-30 3:10 ` Trent W. Buck
1 sibling, 0 replies; 8+ messages in thread
From: Trent W. Buck @ 2020-04-30 3:10 UTC (permalink / raw)
To: netfilter
Martin Gignac <martin.gignac@gmail.com> writes:
> This is actually a very cool idea! I never realized that nftables
> rulesets are bound to a specific namespace, but now it makes perfect
> sense. The only "drawback" (I guess) is that I cannot use 'iif' for
> any other interface than 'lo' in the temp namespace; I'll need to use
> 'iifname' instead since the referenced interfaces won't exist in the
> temp namespace. But it's not a deal breaker.
You can create dummy interfaces with appropriate names inside your dummy
namespace. Something like this (untested):
ip -namespace delete-me link add name eth0 type dummy
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is viewing a "candidate" ruleset in 'nft list ruleset' format possible?
2020-04-23 2:06 ` Duncan Roe
2020-04-23 12:10 ` Martin Gignac
@ 2020-04-30 3:25 ` Trent W. Buck
2020-04-30 8:05 ` Trent W. Buck
1 sibling, 1 reply; 8+ messages in thread
From: Trent W. Buck @ 2020-04-30 3:25 UTC (permalink / raw)
To: netfilter
Duncan Roe <duncan_roe@optusnet.com.au> writes:
> On Wed, Apr 22, 2020 at 12:34:26PM -0400, Martin Gignac wrote:
>> > You can simply put "list ruleset" at the bottom of the foo.nft file.
>> > However in my experience this routinely gives outright wrong rulesets
>> > (as at nftables 0.9.1), so I don't trust it.
>
> "list ruleset" at the bottom of an nft script is completely accurate.
> The command "nft list ruleset" discards portions of rules that are implicit, in the
> interests of brevity.
Sorry, I don't have a testable example.
My rulesets were like this:
flush ruleset
<stuff here>
list ruleset
I *think* I saw the output of "nft -f test.nft" had entire rules
missing, where they were present in "nft list ruleset" immediately
afterwards.
I just tried to reproduce this and couldn't, so it's possible I was just
really tired and the real problem was inside my brain!
I would have understood e.g. ct state keywords being XORed to a number, but
it's possible I was seeing ELEMENTS in a list/mapping "disappear"
because they were being merged (e.g. below) and then mis-remembering
that as "rules disappear".
If I run into this again, I'll try to keep proper records so I can file
a proper bug report!
root@not-omega:/home/twb# nft -f tmp.nft >before
root@not-omega:/home/twb# nft list ruleset >after
root@not-omega:/home/twb# GIT_PAGER=cat git diff -U999 before after
diff --git a/before b/after
index dc38326..ad39c3a 100644
--- a/before
+++ b/after
@@ -1,28 +1,27 @@
table inet my_filter {
map ICMPv6_RFC4890_policy {
type icmpv6_type : verdict
flags interval
- elements = { 0,
- destination-unreachable : accept,
- 5 : drop,
- 100 : drop,
- 102 : drop,
+ elements = { 1-4 : accept,
+ 5-99 : drop,
+ 100-101 : drop,
+ 102-126 : drop,
127 : drop,
- echo-request : accept,
- mld-listener-query : accept,
- nd-router-solicit : accept,
+ 128-129 : accept,
+ 130-132 : accept,
+ 133-136 : accept,
nd-redirect : drop,
router-renumbering : drop,
- 139 : drop,
- ind-neighbor-solicit : accept,
+ 139-140 : drop,
+ 141-142 : accept,
mld2-listener-report : accept,
- 144 : accept,
- 148 : accept,
+ 144-147 : accept,
+ 148-149 : accept,
150 : drop,
- 151 : accept,
- 154 : drop,
- 200 : drop,
- 202 : drop,
+ 151-153 : accept,
+ 154-199 : drop,
+ 200-201 : drop,
+ 202-254 : drop,
255 : drop }
}
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Is viewing a "candidate" ruleset in 'nft list ruleset' format possible?
2020-04-30 3:25 ` Trent W. Buck
@ 2020-04-30 8:05 ` Trent W. Buck
0 siblings, 0 replies; 8+ messages in thread
From: Trent W. Buck @ 2020-04-30 8:05 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]
trentbuck@gmail.com (Trent W. Buck) writes:
> Duncan Roe <duncan_roe@optusnet.com.au> writes:
>
>> On Wed, Apr 22, 2020 at 12:34:26PM -0400, Martin Gignac wrote:
>>> > You can simply put "list ruleset" at the bottom of the foo.nft file.
>>> > However in my experience this routinely gives outright wrong rulesets
>>> > (as at nftables 0.9.1), so I don't trust it.
>>
>> "list ruleset" at the bottom of an nft script is completely accurate.
>> The command "nft list ruleset" discards portions of rules that are implicit, in the
>> interests of brevity.
>
> Sorry, I don't have a testable example.
> If I run into this again, I'll try to keep proper records so I can file
> a proper bug report!
Hooray, I got one (attached).
You can see "list ruleset" inside /etc/nftables.conf ends with
table inet my_filter {
}
where running "nft list ruleset" immediately afterwards, it shows all
the chains and rules that are actually there:
table inet my_filter {
chain my_input {
type filter hook input priority filter; policy drop;
jump my_prologue comment "deal with boring conntrack/loopback/ICMP/ICMPv6"
tcp dport 22 accept
jump my_epilogue
}
[...]
}
It happens reliably if I run "nft delete table inet my_filter" before "/etc/nftables.conf",
but NOT if I run "/etc/nftables.conf" before "/etc/nftables.conf".
To me this feels like "list ruleset" is sometimes running before the block
immediately before it.
[-- Attachment #2: transcript showing "list ruleset" inside foo.nft giving weird output --]
[-- Type: text/plain, Size: 11808 bytes --]
root@zippy:~# nft delete table inet my_filter
root@zippy:~# /etc/nftables.conf
table ip filter {
chain INPUT {
type filter hook input priority filter; policy accept;
iifname "virbr1" meta l4proto udp udp dport 53 counter packets 0 bytes 0 accept
iifname "virbr1" meta l4proto tcp tcp dport 53 counter packets 0 bytes 0 accept
iifname "virbr1" meta l4proto udp udp dport 67 counter packets 0 bytes 0 accept
iifname "virbr1" meta l4proto tcp tcp dport 67 counter packets 0 bytes 0 accept
iifname "virbr0" meta l4proto udp udp dport 53 counter packets 0 bytes 0 accept
iifname "virbr0" meta l4proto tcp tcp dport 53 counter packets 0 bytes 0 accept
iifname "virbr0" meta l4proto udp udp dport 67 counter packets 0 bytes 0 accept
iifname "virbr0" meta l4proto tcp tcp dport 67 counter packets 0 bytes 0 accept
}
chain FORWARD {
type filter hook forward priority filter; policy accept;
iifname "virbr1" oifname "virbr1" counter packets 0 bytes 0 accept
oifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
oifname "virbr0" ip daddr 192.168.122.0/24 ct state related,established counter packets 0 bytes 0 accept
iifname "virbr0" ip saddr 192.168.122.0/24 counter packets 0 bytes 0 accept
iifname "virbr0" oifname "virbr0" counter packets 0 bytes 0 accept
oifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
oifname "virbr1" meta l4proto udp udp dport 68 counter packets 0 bytes 0 accept
oifname "virbr0" meta l4proto udp udp dport 68 counter packets 0 bytes 0 accept
}
}
table ip6 filter {
chain INPUT {
type filter hook input priority filter; policy accept;
}
chain FORWARD {
type filter hook forward priority filter; policy accept;
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
}
}
table bridge filter {
chain INPUT {
type filter hook input priority filter; policy accept;
}
chain FORWARD {
type filter hook forward priority filter; policy accept;
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
}
}
table ip mangle {
chain PREROUTING {
type filter hook prerouting priority mangle; policy accept;
}
chain INPUT {
type filter hook input priority mangle; policy accept;
}
chain FORWARD {
type filter hook forward priority mangle; policy accept;
}
chain OUTPUT {
type route hook output priority mangle; policy accept;
}
chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
oifname "virbr1" meta l4proto udp udp dport 68 counter packets 0 bytes 0 # CHECKSUM fill
oifname "virbr0" meta l4proto udp udp dport 68 counter packets 0 bytes 0 # CHECKSUM fill
}
}
table ip nat {
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
}
chain INPUT {
type nat hook input priority 100; policy accept;
}
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
ip saddr 192.168.122.0/24 ip daddr 224.0.0.0/24 counter packets 0 bytes 0 return
ip saddr 192.168.122.0/24 ip daddr 255.255.255.255 counter packets 0 bytes 0 return
meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535
meta l4proto udp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535
ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade
}
chain OUTPUT {
type nat hook output priority -100; policy accept;
}
}
table ip sshguard {
set attackers {
type ipv4_addr
flags interval
}
chain blacklist {
type filter hook input priority filter - 10; policy accept;
ip saddr @attackers drop
}
}
table ip6 sshguard {
set attackers {
type ipv6_addr
flags interval
}
chain blacklist {
type filter hook input priority filter - 10; policy accept;
ip6 saddr @attackers drop
}
}
table inet my_filter {
}
root@zippy:~# nft list ruleset
table ip filter {
chain INPUT {
type filter hook input priority filter; policy accept;
iifname "virbr1" meta l4proto udp udp dport 53 counter packets 0 bytes 0 accept
iifname "virbr1" meta l4proto tcp tcp dport 53 counter packets 0 bytes 0 accept
iifname "virbr1" meta l4proto udp udp dport 67 counter packets 0 bytes 0 accept
iifname "virbr1" meta l4proto tcp tcp dport 67 counter packets 0 bytes 0 accept
iifname "virbr0" meta l4proto udp udp dport 53 counter packets 0 bytes 0 accept
iifname "virbr0" meta l4proto tcp tcp dport 53 counter packets 0 bytes 0 accept
iifname "virbr0" meta l4proto udp udp dport 67 counter packets 0 bytes 0 accept
iifname "virbr0" meta l4proto tcp tcp dport 67 counter packets 0 bytes 0 accept
}
chain FORWARD {
type filter hook forward priority filter; policy accept;
iifname "virbr1" oifname "virbr1" counter packets 0 bytes 0 accept
oifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
oifname "virbr0" ip daddr 192.168.122.0/24 ct state related,established counter packets 0 bytes 0 accept
iifname "virbr0" ip saddr 192.168.122.0/24 counter packets 0 bytes 0 accept
iifname "virbr0" oifname "virbr0" counter packets 0 bytes 0 accept
oifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
iifname "virbr0" counter packets 0 bytes 0 reject
iifname "virbr1" counter packets 0 bytes 0 reject
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
oifname "virbr1" meta l4proto udp udp dport 68 counter packets 0 bytes 0 accept
oifname "virbr0" meta l4proto udp udp dport 68 counter packets 0 bytes 0 accept
}
}
table ip6 filter {
chain INPUT {
type filter hook input priority filter; policy accept;
}
chain FORWARD {
type filter hook forward priority filter; policy accept;
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
}
}
table bridge filter {
chain INPUT {
type filter hook input priority filter; policy accept;
}
chain FORWARD {
type filter hook forward priority filter; policy accept;
}
chain OUTPUT {
type filter hook output priority filter; policy accept;
}
}
table ip mangle {
chain PREROUTING {
type filter hook prerouting priority mangle; policy accept;
}
chain INPUT {
type filter hook input priority mangle; policy accept;
}
chain FORWARD {
type filter hook forward priority mangle; policy accept;
}
chain OUTPUT {
type route hook output priority mangle; policy accept;
}
chain POSTROUTING {
type filter hook postrouting priority mangle; policy accept;
oifname "virbr1" meta l4proto udp udp dport 68 counter packets 0 bytes 0 # CHECKSUM fill
oifname "virbr0" meta l4proto udp udp dport 68 counter packets 0 bytes 0 # CHECKSUM fill
}
}
table ip nat {
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
}
chain INPUT {
type nat hook input priority 100; policy accept;
}
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
ip saddr 192.168.122.0/24 ip daddr 224.0.0.0/24 counter packets 0 bytes 0 return
ip saddr 192.168.122.0/24 ip daddr 255.255.255.255 counter packets 0 bytes 0 return
meta l4proto tcp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535
meta l4proto udp ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade to :1024-65535
ip saddr 192.168.122.0/24 ip daddr != 192.168.122.0/24 counter packets 0 bytes 0 masquerade
}
chain OUTPUT {
type nat hook output priority -100; policy accept;
}
}
table ip sshguard {
set attackers {
type ipv4_addr
flags interval
}
chain blacklist {
type filter hook input priority filter - 10; policy accept;
ip saddr @attackers drop
}
}
table ip6 sshguard {
set attackers {
type ipv6_addr
flags interval
}
chain blacklist {
type filter hook input priority filter - 10; policy accept;
ip6 saddr @attackers drop
}
}
table inet my_filter {
chain my_input {
type filter hook input priority filter; policy drop;
jump my_prologue comment "deal with boring conntrack/loopback/ICMP/ICMPv6"
tcp dport 22 accept
jump my_epilogue
}
chain my_forward {
type filter hook forward priority filter; policy drop;
jump my_prologue comment "deal with boring conntrack/loopback/ICMP/ICMPv6"
jump my_epilogue
}
chain my_prologue {
ct state vmap { invalid : drop, established : accept, related : accept }
ct status dnat accept
meta iiftype loopback accept
icmp type echo-request accept
icmpv6 type { echo-request, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept
}
chain my_epilogue {
}
}
root@zippy:~# cat /etc/nftables.conf
#!/usr/sbin/nft --file
## NOTE: we add+delete each table (not "flush ruleset"), because
## otherwise we would wipe out sshguard & libvirtd tables.
#flush ruleset
add table inet my_filter # idempotent
delete table inet my_filter # not idempotent
table inet my_filter {
chain my_input {
type filter hook input priority filter
policy drop
jump my_prologue comment "deal with boring conntrack/loopback/ICMP/ICMPv6"
# YOUR RULES HERE.
# NOTE: service names resolve via nss (/etc/hosts) only in nft 0.9.1+!
tcp dport ssh accept
jump my_epilogue
}
chain my_forward {
type filter hook forward priority filter
policy drop
jump my_prologue comment "deal with boring conntrack/loopback/ICMP/ICMPv6"
# YOUR RULES HERE.
jump my_epilogue
}
# We want output to be "allow all", so we don't even create a chain.
#chain my_output {
# type filter hook output priority filter
# policy accept
#}
chain my_prologue {
ct state vmap { established: accept, related: accept, invalid: drop }
ct status dnat accept
iiftype loopback accept
icmp type echo-request accept
icmpv6 type {
echo-request,
nd-neighbor-solicit,
nd-router-advert,
nd-neighbor-advert } accept
}
chain my_epilogue {
}
}
# This is here to aid debugging.
# Note that its output WILL NOT MATCH a later "nft list ruleset".
list ruleset
root@zippy:~# dpkg-query -W nftables
nftables 0.9.3-2~bpo10+1
root@zippy:~# nft --version
nftables v0.9.3 (Topsy)
root@zippy:~# uname -a
Linux zippy 5.4.0-0.bpo.4-amd64 #1 SMP Debian 5.4.19-1~bpo10+1 (2020-03-09) x86_64 GNU/Linux
root@zippy:~#
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-04-30 8:05 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-04-19 2:12 Is viewing a "candidate" ruleset in 'nft list ruleset' format possible? Martin Gignac
2020-04-22 4:51 ` Trent W. Buck
2020-04-22 16:34 ` Martin Gignac
2020-04-23 2:06 ` Duncan Roe
2020-04-23 12:10 ` Martin Gignac
2020-04-30 3:25 ` Trent W. Buck
2020-04-30 8:05 ` Trent W. Buck
2020-04-30 3:10 ` Trent W. Buck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox