Interesting article: CNAME Cloaking

Security
1

I thought this was an interesting article about CNAME Cloaking. I had never heard of it before.

Hopefully in the future it will be preventable…

 

EDIT: forgot this part…

2 Likes
2

I agree, it is very interesting.
Is there anything that could reveal and protect from CNAME cloaking
in combination with the URLfilter?

3

Hi,

hm, I don’t really think so.

From a web proxy perspective, the cloaked domains are not to spot as such unless the CNAME resolving chain is taken into account. Squid, as far as I am aware, does not support such additional DNS inspections, and given the fact that many legitimate sites resolve via a couple of CNAMEs as well, this would be a tedious job to do.

Blocking the IP address of the advertising/tracker server is possible, but I would expect professional tracking services to host their stuff behind large CDNs, making them unblockable via the IP addresses, since one IP serves thousands of websites. (Someone once said Cloudflare is today’s biggest darknet, and in a way, that’s true… :expressionless: )

Therefore, I am afraid the web proxy won’t really help here unless it has an up-to-date list of these tracking subdomains at hand. The rest is up to the browsers, and in doubt, I think putting the shields up there is more worth the effort.

Thanks, and best regards,
Peter Müller

1 Like
4

Thank you Peter,
Oh yes almost every Wordpress website is using Cloudflare.

I see these fellows are thinking about a similar idea,

@mutley created a script that can do CNAME inspection:

I wonder if this would help. This list is being updated every morning at 5:00 UTC
https://hosts.oisd.nl/basic/ with 60000 domains
or even the full list
https://hosts.oisd.nl/ with 1.8 million domains

If anyone is interested, here are some partial screenshots regarding the list:

basc
basc338×544 51.8 KB

inc
inc927×654 68 KB

5

I had not heard it called CNAME cloaking before, but yes a DNS style blocker such as my script above is well suited to prevent this. This is the reason why I added the -r / --dns option to the script. When using that option, the script will simply block every subdomain from the highest level listed, and the blocklist maintainer doesn’t need to add every subdomain that pops up every few days. But you should also be more careful in selecting quality blocklists when using this option.

The script has to do a lot of pre-processing work to calculate the highest level domain and remove all of duplicates. It would be interesting to see if block-list maintainers start to create lists designed around this style of blocking, as it they would be far smaller / easier for them to maintain and also be more efficient to block at DNS level.

1 Like
6

I got it, do you mean a blocklist that contains regex? just a single line blocking hundreds of domains.
like this

^(.+[_.-])?(facebook|fb(cdn|sbx)?|tfbnw).[^.]+$

or

7

@trish Not really regex just block at the highest level. An example of the usual block list is below

junk1.doubleclick.net
junk2.doubleclick.net
google.junk.doubleclick.net
googleadds.junk1.doubleclick.net

With the CNAME problem listed above, you might get tone of new junk3.doubleclick.net…junk1000.doubleclick.net which all need to be added to the blocklist.

To overcome the CNAME domain blocking (like the NXDOMAIN in my script) you just need something like below, and every subdomain is automatically blocked.

doubleclick.net

That’s a lot smaller lists to maintain / read and less overhead for the list maintainers.

1 Like