From: Kerin Millar <kfm@xxxxxxxxxxxxx>
Sent: Saturday, March 30, 2024 2:28 AM
Hi,
> You have not fulfilled this requirement because your priority level is define as -140 (-150 + 10). Below is an
> example of how one might correctly employ notrack. It presumes that the DNS server is running at the same
> host as bears the ruleset.
I had read that and tried this and many variations that did not work. Below I tried to create your suggested chains, but also failed. Some good news is that this led me to a working solution.
Suggested solution denied traffic:
# nft add table inet raw
# nft add chain inet raw PREROUTING { type filter hook prerouting priority -300 \;policy accept\;}
# nft add rule inet raw PREROUTING fib daddr type local udp dport 5353 notrack
# nft add chain inet raw OUTPUT { type filter hook output priority -300 \;policy accept\;}
# nft add rule inet raw OUTPUT udp sport 5353 notrack
# nft add rule inet raw OUTPUT oifname "lo" notrack
The resulting new table (just the new table shown, the firewalld table is the same, except without the 2 mark rules I added in my initial post):
table inet raw {
chain PREROUTING {
type filter hook prerouting priority raw; policy accept;
fib daddr type local udp dport 5353 notrack
}
chain OUTPUT {
type filter hook output priority raw; policy accept;
udp sport 5353 notrack
oifname "lo" notrack
}
}
The chains in the firewalld table that are different from my original post (no " udp dport 5353 notrack meta mark set 0x00000035" in mangle_PREROUTING or "meta mark 0x00000035 accept" in filter_IN_public_allow):
table inet firewalld {
chain mangle_PREROUTING {
type filter hook prerouting priority mangle + 10; policy accept;
jump mangle_PREROUTING_ZONES
}
chain filter_IN_public_allow {
tcp dport 22 ct state { new, untracked } accept
udp dport 53 ct state { new, untracked } accept
tcp dport 53 ct state { new, untracked } accept
Testing results:
>From client (192.168.1.2):
# dig @192.168.1.1 +timeout=1 +retries=1 1.0.0.127.in-addr.arpa ptr +short -p 553
; <<>> DiG 9.16.23-RH <<>> @192.168.1.1 +timeout +retries 1.0.0.127.in-addr.arpa ptr +short -p 53
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
# dig @192.168.1.1 +timeout=1 +retries=1 1.0.0.127.in-addr.arpa ptr +short -p 553
; <<>> DiG 9.16.23-RH <<>> @192.168.1.1 +timeout +retries 1.0.0.127.in-addr.arpa ptr +short -p 53
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
On system with DNS server and nftables config, there were no connections:
# cat /proc/net/nf_conntrack|grep 192\.168\.1\.2
But the log_denied messages on the DNS server:
Mar 30 14:26:55 qip1250re-2 kernel: filter_IN_public_REJECT: IN=eth0 OUT= MAC=c4:5a:b1:b2:95:a4:c4:5a:b1:a5:ea:1d:08:00 SRC=192.168.1.2 DST=192.168.1.1 LEN=91 TOS=0x00 PREC=0x00 TTL=64 ID=26795 PROTO=UDP SPT=53369 DPT=53 LEN=71
Mar 30 14:26:56 qip1250re-2 kernel: filter_IN_public_REJECT: IN=eth0 OUT= MAC=c4:5a:b1:b2:95:a4:c4:5a:b1:a5:ea:1d:08:00 SRC=192.168.1.2 DST=192.168.1.1 LEN=91 TOS=0x00 PREC=0x00 TTL=64 ID=27658 PROTO=UDP SPT=57512 DPT=53 LEN=71
Looks like the filter_IN_public is still denying the traffic (so I don't see the connections like in my initial post where traffic is allowed):
chain filter_IN_public {
jump filter_INPUT_POLICIES_pre
jump filter_IN_public_pre
jump filter_IN_public_log
jump filter_IN_public_deny
jump filter_IN_public_allow
jump filter_IN_public_post
jump filter_INPUT_POLICIES_post
meta l4proto { icmp, ipv6-icmp } accept
log prefix "filter_IN_public_REJECT: "
reject with icmpx admin-prohibited
}
To get the traffic accepted, but not tracked:
Flush the ruleset and restart firewalld
# nft flush ruleset
# systemctl restart firewalld
Run nft commands to setup the suggested new raw table and add the extra input chain accept:
# nft add table inet raw
# nft add chain inet raw PREROUTING { type filter hook prerouting priority -300 \;policy accept\;}
# nft add rule inet raw PREROUTING fib daddr type local udp dport 5353 notrack meta mark set 53
# nft add chain inet raw OUTPUT { type filter hook output priority -300 \;policy accept\;}
# nft add rule inet raw OUTPUT udp sport 5353 notrack
# nft add rule inet raw OUTPUT oifname "lo" notrack
# nft insert rule inet firewalld filter_IN_public_allow mark 53 accept
Resulting new table and updated chain:
table inet raw {
chain PREROUTING {
type filter hook prerouting priority raw; policy accept;
fib daddr type local udp dport 5353 notrack meta mark set 0x00000035
}
chain OUTPUT {
type filter hook output priority raw; policy accept;
udp sport 5353 notrack
oifname "lo" notrack
}
}
table inet firewalld {
chain filter_IN_public_allow {
meta mark 0x00000035 accept
tcp dport 22 ct state { new, untracked } accept
udp dport 53 ct state { new, untracked } accept
tcp dport 53 ct state { new, untracked } accept
}
On the Client, both authoritative and recursive queries are answered:
# dig @192.168.1.1 +timeout=1 +retries=1 1.0.0.127.in-addr.arpa ptr +nocmd +short -p 53
localhost.
# dig @192.168.1.1 +short www.google.com
142.250.80.36
On system with DNS server and nftables config, there were no connections for DNS:
# cat /proc/net/nf_conntrack|grep 192\.168\.1\.2
There are no logged reject/denied messages for DNS packets on the DNS server either
I thank you very much for the pointers to successfully configuring notrack of the DNS packets.
Now that I know the underlying nftables configuration, I need to incorporate this configuration into the firewalld configuration. I understand if this is off-topic and I may need to post in a different forum.
I see that firewalld says that direct rules is deprecated, and to use policies.
Unfortunately policies do not support notrack, and the necessary arguments that I have tried in direct rules are invalid. I have also come to find that the firewall direct rules only support iptables, while my firewalld.conf is set to use nftables; thus, unable to see nftables tables and chains setup by firewalld. Maybe the nftable rules from firewalld override the iptables rules from firewalld direct?
At the moment, I created some workaround scripts from the information in this post, and call the in the systemd ExecStartPre= for DNS service start. I remove them in ExecStopPost=.
Cheers,
Blaine
