DNS over HTTPS update
OK, as I have promised to do some more digging, these are my preliminary findings:
Secure DNS is beginning to take traction with multiple vendors and open source community actively working on number of products intended for this purpose.
For now, it is still feasible to monitor and control this traffic to some degree as it is being forwarded to well known or advertised IPs and is often recognizable by resource names.
So, if you are not using HTTPS inspection and depending on your company's security posture, you can either block traffic addressed to these servers completely, or implement your own Secure DNS proxies to retain the ability of blacklisting or whitelisting the sites and the categories accessible by users.
If you are using HTTPS inspection, you are marginally better off, as it allows you, in the case of a more mainstream secure dns providers, to see that the DNS query is being performed, but the payload of those queries is still invisible.
Below is the example of the query performed from the Secure DNS proxy running DNSCRYPT with Cloudflare as a resolver:
root@CLFRDNSPRXY1:~# dig https://www.hackaday.com
; <<>> DiG 9.10.3-P4-Ubuntu <<>> https://www.hackaday.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41178
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0257 , udp: 1536
;; QUESTION SECTION:
;https://www.hackaday.com. IN A
;; ANSWER SECTION:
https://www.hackaday.com. 599 IN CNAME hackaday.com.
hackaday.com. 599 IN A 192.0.79.32
hackaday.com. 599 IN A 192.0.79.33
;; Query time: 175 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Apr 10 16:50:02 EDT 2018
;; MSG SIZE rcvd: 159
root@CLFRDNSPRXY1:~#
The gateway sees the request, but not the payload:
Id: c0a8071f-0100-00c0-5acd-23b700000000
Marker: @A@@B@1523332800@C@112360
Log Server Origin: 192.168.7.30
Time: 2018-04-10T20:51:03Z
Interface Direction: outbound
Interface Name: eth1
Connection Direction: Outgoing
Id Generated By Indexer: false
First: false
Sequencenum: 9
Xlate (NAT) Source IP: XX.XXX.XXX.XXX
Xlate (NAT) Source Port: 36248
Xlate (NAT) Destination Port:0
NAT Rule Number: 16
NAT Additional Rule Number: 1
Hll Key: 12784207492398244274
Context Num: 1
Source Zone: Internal
Destination Zone: External
Service ID: https
Source: 192.168.7.34
Source Port: 47494
Destination: 1.0.0.1
Destination Port: 443
IP Protocol: 6
Security Outzone: ExternalZone
Protocol: HTTPS
Sig Id: 0
Lastupdatetime: 2018-04-10T20:51:03Z
Action: Accept
Type: Connection
Policy Name: MobileAccess_for_GW8010
Policy Management: SMS8010
Db Tag: {4FD7C570-BB91-8C47-9F47-12F26CF733F0}
Policy Date: 2018-04-10T20:37:07Z
Blade: Firewall
Origin: GW8010
Service: TCP/443
Product Family: Access
Logid: 7
Action: Inspect
Access Rule Number: 6.2
Rule UID: ac190fa4-a3d5-48cb-986a-9d4a30a02e5e
Layer Name: APCL_and_URLF
Interface: eth1
Description: https Traffic Accepted from 192.168.7.34 to 1.0.0.1
Interestingly enough, even though the session is clearly identifying client type and user agent as dnscrypt-proxy, the corresponding application filter is not seeing it as such:
Time: 2018-04-10T20:10:35Z
Interface Direction: inbound
Interface Name: eth0
Connection Direction: Outgoing
Id: c0a8071f-2d16-0000-5acd-1a3b00000000
Sequencenum: 2
Hll Key: 12784207492398244274
Duration: 2460
Last Update Time: 2018-04-10T20:51:33Z
Update Count: 6
Connections: 11
Aggregated Log Count: 42
Creation Time: 2018-04-10T20:10:35Z
Source: 192.168.7.34
Destination: 1.0.0.1
Destination Port: 443
IP Protocol: 6
Client Type Os: Unknown
Client Type: Other: dnscrypt-proxy
User Agent: Other: dnscrypt-proxy
Protocol: HTTPS
Sig Id: 0
Service ID: https
Source Zone: Internal
Destination Zone: External
Application ID: 3876370621
Method: POST
Action: Accept
Type: Session
Policy Name: MobileAccess_for_GW8010
Policy Management: SMS8010
Db Tag: {4FD7C570-BB91-8C47-9F47-12F26CF733F0}
Policy Date: 2018-04-10T20:37:07Z
Blade: URL Filtering
Origin: GW8010
Service: TCP/443
Product Family: Access
Logid: 320
Action: Inspect
Application Name: cloudflare.com
Primary Category: Computers / Internet
Matched Category: Computers / Internet
Additional Categories: Computers / Internet,URL Filtering
Application Risk: Unknown
Marker: @A@@B@1523332800@C@112445
Log Server Origin: 192.168.7.30
Orig Log Server Ip: 192.168.7.30
Lastupdatetime: 1523393495000
Lastupdateseqnum: 2
Severity: Informational
Rounded Sent Bytes: 16544
Confidence Level: N/A
Rounded Bytes: 61760
Stored: true
Rounded Received Bytes: 49024
URLs: 16
Packets: 59
Total Bytes: 61780
Client Inbound Packets: 28
Client Outbound Packets:31
Server Inbound Packets: 22
Server Outbound Packets:33
Client Inbound Bytes: 3120
Client Outbound Bytes: 7503
Server Inbound Bytes: 8355
Server Outbound Bytes: 2968
Received Bytes: 49052
Sent Bytes: 16552
Access Rule Number: 6.2
Rule UID: ac190fa4-a3d5-48cb-986a-9d4a30a02e5e
Layer Name: APCL_and_URLF
Interface: eth0
Description: https Traffic Accepted from 192.168.7.34 to cloudflare.com(1.0.0.1)
Resource: https://dns.cloudflare.com/dns-query, https://dns.cloudflare.com/dns-query
Layer Uuid Rule Uuid: 9457d7fd-104e-494a-bf23-522eae8d2530_3c504c20-576b-4d87-b97b-d51aa5c7f613, 38746d3a-ecc1-459a-a373-e4cecb87e246_ac190fa4-a3d5-48cb-986a-9d4a30a02e5e
Bytes (sent\received): 60.3 KB (16.2 KB \ 47.9 KB)
And the rule defined to log it, does not (DNSCrypt is an object predefined by Check Point):
Another little bug here is the absence of hits on the rule that clearly should have some:
By my count, there are some 2,999,982 hits missing
We cannot expect that all of those working on Secure DNS solutions will be as obliging as Cloudflare and provide us with either convenient target IPs or a resource proclaiming its intent (i.e. https://dns.cloudflare.com/dns-query).
I think that there should be a dedicated category created and maintained for DNS obfuscation applications and it should be dynamically updated.
Interested in hearing your thoughts on this subject.
Cheers,
Vladimir