Hi,
first of all, I would have loved to move these posts to a new thread, since this is now heading for a general debate about why and why not to do DNS filtering/blackholing. This differs from OP’s intention as far as I understood, but either Discourse does not provide the feature to move posts or I am too stupid to do so.
From my point of view, you have made pretty clear what threat you are talking about - and I am sure we all know how phishing works, so there is no need to explain it lengthy step by step.
(Besides, please post malicious domains like example[.]com, so they are not converted in clickable links. We do not want to spread evil further here, do we?)
Can you please explain to me how DNSSEC protects my users from emails containing URL ooutlook.com pretending to be outlook.com and asking them to enter their credentials?
I have never stated DNSSEC protects against phishing and am sorry if this was misguiding. DNSSEC is just the reason why we have decided not to tamper with DNS in any way, since that would contradict our efforts to protect users against it.
To avoid misunderstandings: I removed some of your posts since you scattered that topic across four threads, while it was completely off-topic to some of them. This is a legitimate reason to delete posts (since I was/am unable to move them, as stated above) and I have sent you a DM about it, asking to open up one thread for one question.
Anyway, back to topic: Your problem seems to be phishing, which of course is a serious threat to everyone on the internet. From my point of view, DNS filtering does not solve it for the following reasons:
- The malicious link already reached the user - and if they really want to open it, they will do so on their smartphone, bypassing your infrastructure.
- It does not make sense to filter DNS replies if you cannot ensure you are observing them all. Things like public DoH providers enabled as a default in some browsers come to mind - or even users setting their system’s DNS to something else than your resolver.
- You cannot distinguish an attacker from your own security mechanism. Both eventually cause DNSSEC validations to fail.
- DNS is not made for filtering, but web proxies are. Of course, you can just let your employees/customers/whatever deal with an error page, but there is no way to tell them why they cannot access the site (and they should not try to reach it from their private devices) - and you have no idea if they were even trying to access phishing sites. The latter would be especially interesting to know, wouldn’t it?
If somebody is forced to configure a proxy, it is absolutely clear that no direct communication to the internet is allowed, and there is something in between which might deny his/her request. DNS filtering causes things to fail silently and can be really a pain if you need to debug something (I have spend several days at various customers trying to figure out what is going wrong in their DNS, when they eventually told me about DNS filtering). - In case your source is not listing the domain in question, there is no security benefit in filtering DNS. Do you have an idea how many malicious files are distributed via legitimate services such as Google Drive, Dropbox or similar? No source can ever list these domains, that would cause an outraging number of False Positives.
It is not the threat you are trying to fight against. To others, it is.
As stated above, DNS filtering is not a sustainable solution, abusing a technique for something it was not made for at all, while breaking another one we have tried to bring to the masses for the last 20 years.
From my point of view, it’s damage is simply greater than it’s benefit.
Let’s be honest: The problem with people like these is that they are so stupid that they have no idea how stupid they are.
If an attacker is not getting your users by a similar-looking domain, he will send them a ${Dropbox} link, claiming to be the CEO having do upload things to this service because of technical problems. If a user really wants to access a resource, he will find a way to do so.
Unfortunately, you cannot completely cure stupidity in front of the screen by technical countermeasures.
Because something sounds easy to do, it does not necessarily mean it is also a good idea to do so.
I agree, rolling out proxy configurations can be a challenge, especially if you are dealing with BYOD environments. For managed networks, however, it is usually no problem at all.
In addition, you do not need HTTPS inspection to observe the FQDN somebody connects to, since it is transmitted in plain text to the proxy (who has to know which destination should be queried). This does not require a significant amount of bandwidth at all - as long as most websites come with several MBytes of JavaScript, you will not even notice the difference.
https://biṇance[.]com was the URL that got me. I didn’t see the little dot under the n.
Again, please do not post malicious domains in clear text.
IDN phishing is quite easy to detect if you do not display such a domain decoded, but encoded (called “punycode”):
[user@disp1321 ~]$ python3
Python 3.8.6 (default, Sep 25 2020, 00:00:00)
[GCC 10.2.1 20200723 (Red Hat 10.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import idna
>>> idna.encode("biṇance.com")
b'xn--biance-xt7b.com'
To my knowledge, this behaviour can be configured in every major browser, and it is trivial to flag mails containing such links as suspicious.
If it was, yes. If you had used the same list in a web proxy, it would have protected you as well.
Again, how do you ensure they won’t just use their local DNS resolver, which is completely out of your control? Speaking about users’ desires: Usually, companies have strict policies what users are and are not allowed to do. In case a user does not want to comply to these, it should be curtains instead of trying to build the whole IT around them.
Thanks, and best regards,
Peter Müller