Score:1

Desktop Ubuntu-20.04.3 iptables problem

in flag

I want to test some iptables rules the rule is to deny all outbound traffic except DNS.
so I changed the OUTPUT default rule of filter table to DROP using this command.

sudo iptables -t filter -P OUTPUT DROP

then I appended this rule to ACCEPT DNS traffic.

sudo iptables -t filter -A OUTPUT -p udp --dport 53 -o ens33 -j ACCEPT

and I run this command to test the policy.

nslookup google.com

and before running this command I run wireshark on my vm and host.
then nslookup command toke some time and gave me this message.

connection timed out; no servers could be reached

and wireshark (on vm and on host) did not captcher any packets.

so I deleted this rule and added another one.

sudo iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT

and did the same thing as before.
the same message appear again but wireshark (on vm and on host) captcher the packets (the request and response).

then I deleted this rule and added the next rule.

sudo iptables -t filter -A OUTPUT -p udp -j ACCEPT

and did the same thing as before.
this time nslookup command return with the result and wireshark captcher the packets.

So why this happen?

before these tests I installed snort (on a different vm) and I tried to drop some packets but it didn't.
the packets are logged but not dropped.
I don't know if these cases are related or not.

Score:0
gn flag

Your question is really a good one. There are no error messages and everything looks correct with various iptables inquiry tools.

However, you need to allow traffic to/from the local loopback interface, lo. So you need one other rule. By the way, you do not need the -t filter part. So, and modified for my test computer network interface, and I use tcpdump instead of wireshark, and I have two occurrences running, one on lo and one on my NIC:

sudo iptables -A OUTPUT -o lo -j ACCEPT
sudo iptables -A OUTPUT -p udp --dport 53 -o br0 -j ACCEPT
sudo iptables -P OUTPUT DROP
nslookup google.com
Server:         127.0.0.53     <<<<<<< NOTE:
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   google.com
Address: 142.251.33.78
Name:   google.com
Address: 2607:f8b0:400a:806::200e

and:

doug@s19:~/iptables/tmp$ cat c06.txt
2021-11-21 09:41:07.851723 IP 192.168.111.136.37847 > 192.168.111.1.53: 52661+ [1au] A? google.com. (39)
2021-11-21 09:41:07.879409 IP 192.168.111.1.53 > 192.168.111.136.37847: 52661 1/0/1 A 142.251.33.78 (55)
2021-11-21 09:41:07.884300 IP 192.168.111.136.52279 > 192.168.111.1.53: 58740+ [1au] AAAA? google.com. (39)
2021-11-21 09:41:07.899157 IP 192.168.111.1.53 > 192.168.111.136.52279: 58740 1/0/1 AAAA 2607:f8b0:400a:806::200e (67)

and:

doug@s19:~/iptables/tmp$ cat l01.txt
2021-11-21 09:41:07.850815 IP 127.0.0.1.51470 > 127.0.0.1.51470: UDP, length 1
2021-11-21 09:41:07.851625 IP 127.0.0.1.46738 > 127.0.0.53.53: 31736+ A? google.com. (28)
2021-11-21 09:41:07.879486 IP 127.0.0.53.53 > 127.0.0.1.46738: 31736 1/0/0 A 142.251.33.78 (44)
2021-11-21 09:41:07.884223 IP 127.0.0.1.35841 > 127.0.0.53.53: 58878+ AAAA? google.com. (28)
2021-11-21 09:41:07.899259 IP 127.0.0.53.53 > 127.0.0.1.35841: 58878 1/0/0 AAAA 2607:f8b0:400a:806::200e (56)

So why does the server appear to be local? By default Ubuntu runs a local resolver for buffering dns records and such:

doug@s19:~$ sudo ss -tulpn | grep ":53"
Netid  State  Recv-Q  Send-Q         Local Address:Port  Peer Address:Port                         Process
udp    UNCONN  0       0              127.0.0.53%lo:53            0.0.0.0:*      users:(("systemd-resolve",pid=834,fd=12))
tcp    LISTEN  0       4096           127.0.0.53%lo:53            0.0.0.0:*      users:(("systemd-resolve",pid=834,fd=13))

see also results from sudo systemctl status systemd-resolved and the related man pages.

keroles gamal avatar
in flag
Thank you very much I did as you said and it worked but nslookup response message is not what I expected could you please explain why nslookup response message says that the server is my loopback "127.0.0.53" ? I expected 8.8.8.8 I tried many domains and still the server is my loopback "127.0.0.53" what happens behind the scene ?
Doug Smythies avatar
gn flag
answer edited with a reply to your comment.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.