Several applications show as trying to connect to UDP port 53 (DNS)

[comminutus]

Describe the bug Several outbound connections appear in OpenSnitch as going over UDP port 53. OpenSnitch asks permission to connect for these processes even though I have established rules for these already.

Include the following information:

• OpenSnitch version: 1.5.2
• OS: Ubuntu 22.04
• Window Manager: Gnome
• Kernel version: Linux 5.15.0-56-generic

For example, I have a rule to allow process /snap/snapd/\d+/usr/lib/snapd/snapd to ports 443 with protocol type TCP. However, OpenSnitch recently started asked for permissions for this process to connect to api.snapcraft.io on UDP port 53. Several other applications are also trying to reach a host they commonly connect to using port 443/80 but now OpenSnitch shows they are trying to connect to the same hosts on UDP port 53.

Does this have something to do with DNS resolution?

[kcohar]

I believe that's a DNS request. I use port 53 to prevent certain applications from even resolving certain hosts let alone connecting to them.

On Thu, Dec 29, 2022 at 2:41 PM comminutus @.***> wrote:

Describe the bug Several outbound connections appear in OpenSnitch as going over UDP port

53. OpenSnitch asks permission to connect for these processes even though I have established rules for these already.

Include the following information:

• OpenSnitch version: 1.5.2
• OS: Ubuntu 22.04
• Window Manager: Gnome
• Kernel version: Linux 5.15.0-56-generic

For example, I have a rule to allow process /snap/snapd/\d+/usr/lib/snapd/snapd to ports 443 with protocol type TCP. However, OpenSnitch recently started asked for permissions for this process to connect to api.snapcraft.io on UDP port 53. Several other applications are also trying to reach a host they commonly connect to using port 443/80 but now OpenSnitch shows they are trying to connect to the same hosts on UDP port 53.

Does this have something to do with DNS resolution?

— Reply to this email directly, view it on GitHub https://github.com/evilsocket/opensnitch/issues/787, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJKQE4ZXTAWL3WZLSBCI73WPWIJTANCNFSM6AAAAAATMDQZKQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[comminutus]

@kcohar indeed, but why would the DNS request go to application servers? The DNS request should go to the DNS server. For some reason all of the sudden, connections which would typically go over TCP port 80 or 443 (nextcloud.com, githubusercontent.com for example) are trying to make requests to the same hostnames on UDP port 53. I suspect some iptables rule is forwarding the DNS request incorrectly.

[gustavo-iniguez-goya]

As far as I can tell this seems to be normal. Did you realize if the pop-up said something like "Firefox is attempting to resolve xxx.xxx via y.y.y.y , UDP port 53"?

I suspect some iptables rule is forwarding the DNS request incorrectly.

We redirect to the daemon all outbound connections, only to allow/deny them. We don't manipulate the packets.

But it's true that there're some glitches using systemd-resolved or dnscrypt-proxy (that as far as I can tell, are not caused by us).

[comminutus]

So it does say "attempting to resolve," but if I look at the log it looks like it's trying to make connections to various different application's sites via UDP port 53 which never used to occur. This also doesn't happen on another Ubuntu installation I have which works fine. Here are some screenshots

[comminutus]

In order to make anything work I have to allow all processes to access any host on UDP port 53 which doesn't seem right.

[gustavo-iniguez-goya]

As far as I can tell it's working as expected. Apps are trying to resolve domains, and as you only allowed TCP port 443 for snapd for example, it's prompting you to allow connections to port 53 (I have a rule to allow process /snap/snapd/\d+/usr/lib/snapd/snapd to ports 443 with protocol type TCP). Maybe you had

What I do in these cases is allow connections to several ports, for example:

[x] To this port: ^(53|80|443)$

Try allowing port 53 on those rules besides port 443. If you're also filtering by protocol, you'll also need to allow TCP and UDP:

[x] Protocol: ^(TCP|UDP)$

You can also allow an executable only by path ("From this executable: ..."), use the computer as usual, and after a few days, go to Applications tab -> double click on the binary, and inspect to what ports, protocols and domains it has connected to.

And based on the collected data, edit the rule to narrow down what that application can do.

[kcohar]

I think the question was more like - if we allow www.google.com at port 53 (according to the prompt), does it connect to www.google.com at port 53, or does it just connect to our DNS at port 53 asking for google.com's IP address, without connecting to google initially?

On Fri, Dec 30, 2022 at 1:41 AM Gustavo Iñiguez Goia < @.***> wrote:

As far as I can tell it's working as expected. Apps are trying to resolve domains, and as you only allowed TCP port 443 for snapd for example, it's prompting you to allow connections to port 53 (I have a rule to allow process /snap/snapd/\d+/usr/lib/snapd/snapd to ports 443 with protocol type TCP). Maybe you had

What I do in these cases is allow connections to several ports, for example:

[x] To this port: ^(53|80|443)$

Try allowing port 53 on those rules besides port 443. If you're also filtering by protocol, you'll also need to allow TCP and UDP:

[x] Protocol: ^(TCP|UDP)$

You can also allow an executable only by path ("From this executable: ..."), use the computer as usual, and after a few days, go to Applications tab -> double click on the binary, and inspect to what ports, protocols and domains it has connected to.

And based on the collected data, edit the rule to narrow what that application can do.

— Reply to this email directly, view it on GitHub https://github.com/evilsocket/opensnitch/issues/787#issuecomment-1367663688, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJKQEZWXM3CBM7DQEZY43TWPYVTNANCNFSM6AAAAAATMDQZKQ . You are receiving this because you were mentioned.Message ID: @.***>

[gustavo-iniguez-goya]

In this case, you allow DNS requests only to the DNS server:

Firefox is attempting to resolve www.google.com via 1.1.1.1 , UDP port 53
                                                ^^^^^^^^^^^^

It's not connecting to google.com on port 53, but to 1.1.1.1. You can click the advanced button [+] to restrict UDP requests to port 53 only to your DNS servers:

But the problem @comminutus described was not this. It's that snapd was making requests to port 53, having a rule to only allow TCP connections to port 443.

Anyway, if you see a pop-up saying that it's trying to resolve a domain to an IP that's not one of your DNS servers, that's systemd-resolved trying to resolve the domain. But this is a different problem (that I need to analyze). [edit] I think I know the reason for this (bad wording). I'll analyze it.

[kcohar]

Perfect!

On Fri, Dec 30, 2022 at 11:45 AM Gustavo Iñiguez Goia < @.***> wrote:

In this case, you allow DNS requests only to the DNS server:

Firefox is attempting to resolve www.google.com via 1.1.1.1 , UDP port 53 ^^^^^^^^^^^^

It's not connecting to google.com on port 53, but to 1.1.1.1. You can click the advanced button [+] to restrict UDP requests to port 53 only to your DNS servers:

[image: image] https://user-images.githubusercontent.com/2742953/210061232-50a8cc45-71af-4701-a66f-921d96ba3819.png

But the problem @comminutus https://github.com/comminutus described was not this. It's that snapd was making requests to port 53, having a rule to only allow TCP connections to port 443.

Anyway, if you see a pop-up saying that it's trying to resolve a domain to an IP that's not one of your DNS servers, that's systemd-resolved trying to resolve the domain. But this is a different problem (that I need to analyze).

— Reply to this email directly, view it on GitHub https://github.com/evilsocket/opensnitch/issues/787#issuecomment-1367851762, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJKQE5XQRRFFN7S73EOCALWP24NFANCNFSM6AAAAAATMDQZKQ . You are receiving this because you were mentioned.Message ID: @.***>

[comminutus]

@gustavo-iniguez-goya Right, I do have a general rule that systemd-resolved can only connect to my DNS server over port 53. Normally when I install OpenSnitch on any Ubuntu machine I start seeing several of these DNS requests from various application being forwarded to systemd-resolved. This is the first time where it appears that the applications themselves are trying to actually connect to port 53 instead of 80 or 443 to those servers - it seems like a bug. It only started happening after I was messing around with some VPN software - particularly piavpn and proton vpn. I stopped/disabled both of these, I cleared my iptables by doing iptables -Fand iptables -X and then rebooted the machine, but the problem still persists.

[gustavo-iniguez-goya]

What I think is happening is that the applications are sending DNS requests to resolve domains. The requests go to the DNS server (127.0.0.53:53), but we're displaying the domain name that the application is trying to resolve (instead of the DNS server IP, or both).

The column DESTINATION should be 127.0.0.53 (or 1.1.1.1, etc), instead of the domain. This was changed per users request: https://github.com/evilsocket/opensnitch/issues/321 https://github.com/gustavo-iniguez-goya/opensnitch/issues/6

In this particular scenario I don't think there's a bug (software error), but a confusion displaying or interpreting the information. Unless proven otherwise at least :)

You can set the log level to DEBUG (Preferences -> nodes), and filter by udp connections, to be sure that the connections are going against the local DNS server:

$ tail -f /var/log/opensnitchd.log | grep "new connection udp.*53" -A 3

---

Having said that, I'll try to explain how opensnitch works when systemd-resolved is used as DNS server:

• Application A opens a connection to www.google.com on port 443 using connect().
• Via glibc (gethost*) / d-bus (/run/systemd/resolve/io.systemd.Resolve) / etc, the system tries to resolve the domain's IP.

(strace -tt -f -p CHROMIUM_PID)

  [pid 2651618] 20:59:38.407339 connect(27, {sa_family=AF_UNIX, sun_path="/run/systemd/resolve/io.systemd.Resolve"}, 42 <unfinished ...>
  [pid 2651972] 20:59:38.407415 write(25, "{\"phase\":1,\"source\":{\"id\":150271,\"start_time\":\"920684161\",\"type\":1},\"time\":\"920684162\",\"type\":148}", 98 <unfinished ...>

  [pid 2651618] 20:59:38.408432 connect(27, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16 <unfinished ...>

• We intercept the outbound request to 127.0.0.53, and get from the DNS layer, the domain that it's trying to resolve:

  [2022-12-29 19:59:43]  DBG  new connection udp => 40458:127.0.0.1 -> 127.0.0.53:53 uid: 1000
  [2022-12-29 19:59:43]  DBG  [ebpf conn] in cache: udp40458127.0.0.1127.0.0.5353, 1454928 -> /usr/lib/chromium/chromium
  [2022-12-29 19:59:43]  DBG  ✔ /usr/lib/chromium/chromium -> optimizationguide-pa.googleapis.com:53 (002-allow-chrome-ports)

• If there's no rule to allow chromium to connect to port 53, it's when you see the pop-up "...is attempting to resolve...". BUT, when you list the connections, you see that chromium opened a connection to optimizationguide-pa.googleapis.com on port 53 , which is not true. Well, partially, it tried to connect to that domain, but the UDP connection was against the DNS server.

Rergarding why sometimes is systemd-resolved who tries to connect to remote DNS servers, and othertimes the applications, this is what I think it works based on what I've seen until now (I need to analyze more scenarios):

• chromium and others applications firstly try to resolve domains via systemd-resolved d-bus API, and if it fails it fallbacks to UDP (as seen in the log above).
• If the DNS request is made using the D-BUS API, we'll intercept systemd-resolved opening a connection to a remote DNS server (we don't intercept requests to Unix Sockets, so we don't know what the application did).
• If the DNS request is not in cache, we'll also intercept systemd-resolved opening a connection.
• If the DNS request is in cache, or the app fails sending a DNS request via the D-BUS API, then it's when we intercept the connection opened by the app.

[comminutus]

I see, thanks @gustavo-iniguez-goya . I confirmed that DNS requests were being sent to 127.0.0.53 on UDP port 53 by setting up the log level and tailing the log as you suggested. I suppose the reason why I hadn't seen this problem before is that I suspect all of my DNS lookups were going through D-BUS so systemd-resolved would appear as the process making the DNS request. For some reason I suspect that's failing most of the time and the system is now resolving via UDP to 127.0.0.53 as you suggested. I'm not sure why D-BUS lookups are failing all of the sudden.

In any case, I've added a rule to allow any process from any user to connect to 127.0.0.53 on UDP port 53 and that seemed to satisfy all of my previous popus.

[mitsukuri]

I think it would be much less confusing to see in the destination column not e.g. example.org -> 53, but a bit more informative and factual <actual dns server address> -> 53 (resolving example.org), e.g. 192.168.0.1 -> 53 (resolving example.org), or 1.1.1.1 -> 53 (example.org DNS resolution) or something along these lines, whenever there's systemd-resolved in the process column