Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Track DNS queries and prefer the queried name rather than a CNAME #176

Closed
ansell opened this issue May 26, 2018 · 6 comments
Closed

Track DNS queries and prefer the queried name rather than a CNAME #176

ansell opened this issue May 26, 2018 · 6 comments

Comments

@ansell
Copy link
Contributor

ansell commented May 26, 2018

It would be useful to track original DNS queries, and prefer the names that were queried for when making a rule, rather than only observing the DNS responses, which can link the IP address to a separate CNAME, rather than the original.

In my example, the query was for s3.amazonaws.com, which sends a CNAME response back to add s3-1.amazonaws.com to the chain, and assigns the IP address to that. s3.amazonaws.com was included in the response, but was not shown in the opensnitch user interface, which instead showed s3-1.amazonaws.com. In this case, it isn't too difficult to identify, but for others, the CNAME may not be useful for deciding whether to allow the request or not:

$ dig s3.amazonaws.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> s3.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50740
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;s3.amazonaws.com.		IN	A

;; ANSWER SECTION:
s3.amazonaws.com.	3290	IN	CNAME	s3-1.amazonaws.com.
s3-1.amazonaws.com.	5	IN	A	52.216.229.149

;; AUTHORITY SECTION:
s3-1.amazonaws.com.	1491	IN	NS	ns-1084.awsdns-07.org.
s3-1.amazonaws.com.	1491	IN	NS	ns-1726.awsdns-23.co.uk.
s3-1.amazonaws.com.	1491	IN	NS	ns-482.awsdns-60.com.
s3-1.amazonaws.com.	1491	IN	NS	ns-782.awsdns-33.net.

;; Query time: 248 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat May 26 10:22:42 AEST 2018
;; MSG SIZE  rcvd: 217

In addition, if I want to create a permanent rule, I would prefer to make it on the DNS name that was actually requested rather than the CNAME, which the website owner could change over time.

@Northern-Lights
Copy link
Contributor

Northern-Lights commented Aug 24, 2018

I think #116 is required before this can be done, or at least done efficiently.

But I agree, it's a lot more useful to make decisions when you're presented with a domain name rather than an IP address.

Edit 2: Wait, are you saying that you do see a domain name when you get the allow/deny prompt? I had thought that your issue was regarding no domain names being displayed at all, since that is an issue that I am seeing. Apparently the facilities already exist for tracking DNS to connect IP addresses to domains, but because the rule for capturing DNS in iptables is too low in the chain, it was not working for me. I made a modification to the iptables rule placement, and you can see the before and after attached (where one does not show a domain name and one does.) Is this the issue you were having, or part of it?

Edit 3: Bummer, looks like I can't upload files. Well, one simply says:

curl is trying to connect to xxx.xxx.xxx.xxx on port 80

And the other says:

curl is trying to connect to www.google.com on port 80

@ansell
Copy link
Contributor Author

ansell commented Aug 27, 2018

@Northern-Lights

To clarify, this is a feature request rather than a bug.

I am talking about outgoing connections. The current code looks for records where the IP address is the value for an A/AAAA record, and uses the DNS name in that record. In my example above, it did successfully show s3-1.amazonaws.com in the dialog and allowing that worked.

I would like some slightly more complex logic/state to track which DNS names were in request packets. Then, I would like to have logic that attempts to track the original DNS name through any result CNAME records to the final IP address(es) that appear in A or AAAA records, when deciding which DNS name to show in the dialog and use in the rule that is created.

If it can't find a request that matches the response, then defaulting to the current behaviour of just showing the DNS host in the A/AAAA record matching the IP is a consistent fallback state.

Northern-Lights added a commit to Northern-Lights/opensnitch that referenced this issue Aug 28, 2018
@Northern-Lights
Copy link
Contributor

Northern-Lights commented Aug 28, 2018

Check out https://github.com/Northern-Lights/opensnitch/tree/syscall-fix. Not sure why the update to the branch isn't showing up in the PR and being referenced here, but I basically put CNAMEs into the map to try to keep going back to the "root" domain. It works, showing s3.amazonaws.com rather than s3-1.amazonaws.com when doing a curl for the latter.

Edit: guess it takes a moment for it to show up in the PR...

@gustavo-iniguez-goya
Copy link
Collaborator

If this issue still relevant? Now we get and display the original DNS request.

@ansell
Copy link
Contributor Author

ansell commented Jan 15, 2021

@gustavo-iniguez-goya I am not currently using opensnitch and I would not be able to setup a test environment for a few weeks at least. If you are confident that it is fixed, then feel free to close this issue.

@gustavo-iniguez-goya
Copy link
Collaborator

well, we have now deb, rpm and aur packages ;)

Latest versions obtain the domains that an application is trying to resolve (without waiting for the DNS response), which is one of the things you requested. We only display one domain on the pop-ups, but as far as I can tell, I haven't seen more than one.

I would like to have logic that attempts to track the original DNS name through any result CNAME records to the final IP address(es) that appear in A or AAAA records, when deciding which DNS name to show in the dialog and use in the rule that is created.

once a domain is resolved, we save all the IPs and records, but it may be there several domains for the same IP. There's no logic to get the correct domain in such case. I haven't noticed any problem with this though.

I'll close it now, but if you have the chance to test it again and notice any problem or that this feature/bug is incomplete, please open a new issue.

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants