Yes I agree there wasn’t a mention of efficiency, I was just introducing it for thought because it is a very valid rationale. If something can reduce attack surface and has no consumption of resources, it helps in the case for it to be implemented is all 
Let us be more fundamental.
All computer applications are just tools for the human mind (brain?).
Thus we can minimize the use of artifiial tools by maximizing the use of our brain ( which is by the way more efficient in many decisions than the average computer based ‘brain’ ).
Just my 2c
Hi,
to repeat myself on why we do not implement ${something} tampering with DNS responses:
[…] Another question frequently asked is why IPFire does not support filtering DNS replies for certain FQDNs, commonly referred to as a Response Policy Zone (RPZ). This is because an RPZ does what DNSSEC attempts to secure users against: Tamper with DNS responses. From the perspective of a DNSSEC-validating system, a RPZ will just look like an attacker (if the queried FQDN is DNSSEC-signed, which is what we strive for as much of them as possible), thus creating a considerable amount of background noise. Obviously, this makes detecting ongoing attacks very hard, most times even impossible - the haystack to search just becomes too big.
Further, it does not cover direct connections to hardcoded IP addresses, which is what some devices and attackers usually do, as it does not rely on DNS to be operational and does not leave any traces. Using an RPZ will not make your network more secure, it just attempts to cover up the fact that certain devices within it cannot be trusted. […]
(source)
Whatever your problem is, DNS filtering/blackholing/… won’t solve it.
Thanks, and best regards,
Peter Müller
1 Like
Whatever your problem is, DNS filtering/blackholing/… won’t solve it.
Hello Peter,
I must disagree with you. You are focusing on the threat being tampered DNS queries, this is not the threat at hand. The threat at hand is Phishing URLs. So instead of binance.com, a bad actor registers binance-support.com as an example. The binance-support.com is owned by the attacker, and so it is issued correctly and DNSSEC signatures all pass as it is fort all intents and purposes a legitimate domain, not spoofing a domain. But the reality is that it is a scam domain, phishing for users credentials by pretending to be binance.com in emails that are sent to the users.
You seem to perceive the threat as DNS tampering but that is completely wrong. As I’ve mentioned, it’s to stop emails with scam links phishing for users credentials. Currently if I owned ooutlook.com (extra o) I could set it up and it passes DNSSEC checks and start sending emails to users behind ipfire, telling them I am outlook.com and catch the 5% that fall for it and get their credentials. Sure some email anti-spams will catch it, but not all and not always.
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? It does not protect them from that. So you are disregarding my very legitimate threat and removing my posts as well. I had to wait 16 hours to write this as I was rate limited.
Also, I am aware it doesn’t block hardcoded IP addresses, nor does it block cahced results. but that’s not the threat. The user opening and email doesn’t mistake https://100.15.67.1/ to be https://outlook.com.
But the user may mistake https://ooutlook.com for https://outlook.com. Also if they have previously visited the ling and the DNS query is cached, then they’re likely already compromised. It’s not designed to stop traffic going to bad domains or anything like that. It’s to stop brain farts from users clicking on crafted emails. They’re not trying to enter hardcoded IPs and get around the system.
I am all ears for your solution on how I can catch these fake https URLs using ipfire as it is today, in a simple and efficient way as DNS blackholing, and not requiring a conventional proxy to be set on each client. FYI pfsense has add-ons to do this, as I believe does OPNsense. It’s a real thing but from what I’m seeing you guys seem to have some bizzare dissolution about DNSSEC being a cure all for everything, and from what I also can see, it stems from some hatred of Pi-Hole that is IMO holding this project back. I look forward to your solution on how I can protect my users who receive these copycat URLs in their emails using ipfire, just as I can do with pfsense, else I have no choice but to pivot to a solution that protects my users because you are refusing to acknowledge real threats and instead telling me some silly response that DNSSEC is king.
Nobody said, DNSSEC is the right tool to filter bad URLs.
But DNS filtering isn’t the ultimate tool either.
You can’t suppress scam emails without doing sort of MITM attacks ( which are BTW illegal in many civilized countries ).
What you can do is filtering the web access ( through URLfilter in a non-transparent proxy ), educate your users ( yourself ) to examine exactly which links are to be clicked.
BTW: The most secure network is a switched-off network. 
SCNR
This statement is completely false. I’ll point you to Barracuda’s ESS for starters.
What you can do is filtering the web access ( through URLfilter in a non-transparent proxy )
Why do I need to push proxy settings to every device when I can simply catch the DNS requests? Why do I need to introduce overhead on my bandwidth throughput to perform https URL inspection, when simply sending back a dead IP in the DNS response will suffice? You are telling me to climb Mount Everest to tie my shoelace… it is illogical.
educate your users ( yourself ) to examine exactly which links are to be clicked.
This is such an ignorant IT guy response. I used to think like that, and then one day I was sent a url that was using a special unicode character that my eye didn’t see the tiny little dot under the letter “n” that made it different from the legitimate URL (It blended into the underline). Lucky for me there were no dire ramifications, however I learned from the experience enough to know that saying “you should just be more educated” doesn’t cut it I’m afraid.
https://biṇance[.]com was the URL that got me. I didn’t see the little dot under the n. It came up as like the first result in a google search I did for binance, and only when I started getting email notifications that an API key had been made on my account etc. that I clued on and looked at my URL history and saw the character. Luckily my binance account was brand new I’d only just made it the day before and it had nothing in it yet. But it was a good experience to learn. It’s an easy mistake to make no matter how “educated” you may think you are. You add an underline to that link and that dot gets really hard to see. DNS blackholing would have protected me if that URL was on a community list.
So absolutely DNS blackholing solves the problems that I don’t just think, know, exist.
Here is a picture of that URL with an underline, tell me how well you spot the dot.
Why does anyone need to bother with DNS response tampering when they can deploy these attacks and ipfire offers zero protection against such attacks short of forcing every client to set a proxy and have their URLs filtered? A far easier attack to pull off than DNS hijacking, with a trivial mitigation, is disregarded by ipfire because of why? Coz you can force everyone to use a proxy? Not always, people working from home who VPN in, they don’t want proxy settings on their personal device and I don’t blame them.
And it is these 2bit, 5yo attacks that claim 95% of victims. Ya’ll so busy trying to stop China intruding into your basement that you let the script kiddies walk right in with these how to social engineer 101 attacks.
1 Like
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
1 Like
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 case you hadn’t noticed, we’re in the middle of a shift where people are pivoting to work from home. So the usual is becoming less usual.
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.
Why do you have this misconception that because a user can do something that bypasses a protection that protection is invalidated? Also we can of course manage mobile devices and using sandboxing apps like Air Watch and these kinds of things we can keep them in our infrastructure while using their smartphone if that is a route we choose to take. Also if the phone is connected to wifi at work, they are covered by the our DNS there so your statement is true for some situations such as using email on personal device at home in an unmanaged app, yes, but I wouldn’t use that as a reason not to protect someone like this. And also what is more likely a scenario? A user connects their phone to office wifi and uses it, or a user puts the work proxy server into their phone’s browser so the work proxy can catch the URL… what of those two do you think is most likely to occur? Your own argument here is lacking. Whether it’s a DNS server or a proxy server, either could be bypassed on a personal phone.
It does not make sense to filter DNS replies if you cannot ensure you are observing them all.
But I can observe them all… if instead of replying with 127.0.0.1 for e.g. i can reply with my own nginx endpoint that displays a “Your request has been filtered page” and I can log the request then and there. It could also be logged by the DNS responder, check out Pi-Hole if you need to see how this can be done. In fact I’d suggest you could learn a lot if you just fired up a Pi-Hole for a day and had a play with it. it’s a great bit of kit.
DNS is not made for filtering
And yet ISPs do it every day.
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 you have no idea if they were even trying to access phishing sites. The latter would be especially interesting to know, wouldn’t it?
100% incorrect. By sending a DNS response that redirects the traffic to my nginx endpoint I can show them a page that informs them exactly why the request was blocked, and how to request access if they believe it is legitimate. And I’ll feed nginx logs into my ELK SOC that informs me who tried to access what.
You cannot distinguish an attacker from your own security mechanism. Both eventually cause DNSSEC validations to fail.
It has absolutely nothing to do with DNSSEC. Stop bringing DNSSEC into it, it has no place in this discussion. DNSSEC is literally just DKIM for domains. The DNS request is received with a valid signature, an invalid signature, or no signature. There is no breaking of DNSSEC occurring here.
It is not the threat you are trying to fight against. To others, it is.
Understood, and they can continue to fight those threats using means appropriate for those threats… But for me and my threat, my best mitigation is DNS blocking, it’s quick, clean and effective. It isn’t a cure all, nor does it need to be one.
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.
If it were so unsustainable how is it that my Pi-Hole is protecting people everyday by doing DNS filtering? It is doing a lot more protecting than ipfire is, I was hoping to do away with my Pi-Hole and drop in an ipfire as a kind of all in one solution with Suricata as well, but I’m not willing to put my users at risk and switching to ipfire is 100% a decrease in my user’s security as it stands. That’s a fact.
You cannot distinguish an attacker from your own security mechanism. Both eventually cause DNSSEC validations to fail.
Why are we still talking about DNSSEC? It has nothing to do with DNSSEC. Zero. Stop going on about DNSSEC, it’s just DKIM for Domains, it’s not that great… sorry to disappoint you. And really all you’re doing here is pushing people to either pfsense or OPNsense etc. where they can drop in a DNS blocker, run a Pi-Hole side by side with ipfire and bypass the ipfire DNS, or just go with a straight Pi-Hole. If you want people to put more focus on DNSSEC wouldn’t you be better off giving them a DNS server in ipfire that does DNSSEC properly AND DNS filtering? Because like I said, I have no choice but to not use ipfire DNS as it is inadequate for the purpose of protecting my users. This might come as a shock to you but my users are generally not getting malformed or hijacked DNS queries… but they are getting a metric f ton of copy cat URLs. So where am I going to focus my efforts on protecting them do you reckon???
Again, how do you ensure they won’t just use their local DNS resolver, which is completely out of your control?
Because the VPN is setting them to use my DNS server. Sure they can change it to their own DNS server if they have admin privileges, but that’s at their own peril tho…
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.
Did you not pay any attention to my example at all? So you consider me stupid because I didn’t see the little dot in the link that came up in my Google result? This is yet another poor statement, dead set this project is pretty toxic if consensus is that every user who clicks on a crafted URL is stupid.
All this blabber jabber about DNSSEC blah blah it’s just nonsense. Yes maybe 1% of some attacks could involve some DNS hijacking but it’s not the main threats. As I said, you’re protecting your basement from state level actors, and you’re leaving the door wide open to script kiddies. My comment still stands. You have some massive obsession with DNSSEC and it’s not even relevant in this discussion.
DNS filtering is also not really relevant when it comes to defend against the ‘bad boys’.
As in real life, one should use his brain and experience in communication with persons/organisations not really known.
The tool you dream of needs deep confidence in his origin. This isn’t possible. Thus rules outside the system are necessary.
But this makes the thread much more OT. As Peter suggested, we should start a new discussion. The opening topic was just another question.
Regards,
Bernhard
2 Likes
Hi,
why? If your employees use devices managed by their organisations, their location does not matter.
BYOD is a different problem.
Of course, if there is no firewall rule in place preventing direct internet connections from clients, a web proxy is pointless. I presumed it would not be necessary to mention that… 
Yes, this is true. Being focused on 127.0.0.1, I missed that.
Cool argument. People kill other people every day, so it’s fine to do so if that solves your problem.
Yes, it has: As soon as there is a machine validating DNSSEC behind a reslover which is stripping out or tampering with DNS responses, it cannot do DNSSEC validation successfully anymore - and we are trying to move this as close to the users’ system as we can get.
In the above case, there is.
It is quick and it might be effective. But it is definitely not clean.
What about their browsers using DoH?
I have never said that. Please do not read anything into my posts which was not written there.
Aside from that, I told you via DM before and now do in public: Watch your tone. Given your aggressive language and personal accusations, I am getting the feeling you are not interested in an objective discussion after all.
Thanks, and best regards,
Peter Müller
2 Likes
OT. jon thanks for splitting this.
1 Like
If your employees use devices managed by their organisations, their location does not matter.
You should leave the worrying about my users devices to me. Maybe they will use a mixed mode corporate + personal devices. It is not acceptable to just operate on the principle that all devices should be corporate owned and controlled, at least not in my case.
Of course, if there is no firewall rule in place preventing direct internet connections from clients, a web proxy is pointless.
Not just that, if they switch to cellular instead of wifi, they are now bypassing the firewall as they are on the cellular providers network. You’re trying hard to justify proxying as a valid alternative but I’m not seeing it.
Cool argument. People kill other people every day, so it’s fine to do so if that solves your problem
Not even an argument, a statement of fact. Do I agree with it? No I don’t, but that doesn’t mean I can’t apply the same principle for good instead of IMO evil.
As soon as there is a machine validating DNSSEC behind a reslover which is stripping out or tampering with DNS responses, it cannot do DNSSEC validation successfully anymore
This is not true. You are placing significantly more functionality on DNSSEC then the reality. All DNSSEC does is verify if a signature is valid, invalid, or not exist. A query will meet one of those three conditions. We can still drop any DNS queries that we receive with invalid signature, so DNSSEC still works 100% as intended.
It is quick and it might be effective. But it is definitely not clean.
Very clean.
What about their browsers using DoH?
What about it? Their DNS queries are obviously transported via HTTPS to a completely different resolver in this case. You would either have to disable DoH in the browser or accept it. I can’t control infrastructure that’s not managed by me. In the proxy situation what would you do? Drop any packets to the DoH URL? Then what the client has no DNS resolution or does it fall back to system DNS? I don’t know but it’s also not my concern if they are choosing to use DoH or I allow it then that’s on them. I am purely interested in the DNS I am supplying.
I have never said that.
This is exactly what you said in the context of people (myself included) clicking malicious URLs:
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.
Watch your tone. Given your aggressive language and personal accusations, I am getting the feeling you are not interested in an objective discussion after all.
From someone who is calling end users stupid if they make a mistake, I don’t feel like I’m being aggressive, I am putting my point forward you will accept it or not. Already you have made up your mind, it seems that ipfire is in this weird cult where DNSSEC is all things DNS, so people actually using it to protect their clients have to resort to scripts like this one: GitHub - sfeakes/ipfire-scripts: Scripts for ipfire because evangelicals such as yourself fail to acknowledge and adequately mitigate the most common attacks, and worse yet, you do so with an incorrect belief that the mitigation breaks DNSSEC. You are completely wrong.
Just two little questions:
How is the system, you want to manage structured ( SOHO / small company / … )?
What about the more fail-save structure IPFire as internet access, PiHole as DNS server with the filtering?
1 Like
A warm hello into the round,
apart from the DNS handling, we did that also longer time ago with the URL-Filter with lists which Ian posted above. We used a script for this --> https://forum.ipfire.org/viewtopic.php?f=27&t=14895&hilit=custom+malware+filters#p90374 to update and extract a domains.db/urls.db into BDB format for blacklisting. This script is kind of old and can surely be extended.
I use currently only IPSet --> https://wiki.ipfire.org/configuration/firewall/ipset in conjunction with Firehols update-ipset and their IPLists --> http://iplists.firehol.org/ and https://github.com/hslatman/awesome-threat-intelligence which provides also a wider range of potential threads. IPSet delivers also a simple logging method which looks like this
...
Sat Dec 12 01:25:03 CET 2020
167.248.133.0/24 packets 2 bytes 112
64.4.0.0/18 packets 1074 bytes 82277
178.128.0.0/16 packets 12 bytes 856
216.239.36.21 packets 13 bytes 784
Sun Dec 13 01:25:04 CET 2020
167.248.133.0/24 packets 2 bytes 112
64.4.0.0/18 packets 332 bytes 25396
178.128.0.0/16 packets 4 bytes 272
162.142.125.16 packets 2 bytes 112
216.239.36.21 packets 6 bytes 360
...
Just to open up also other ideas to this discussion 
.
Best,
Erik
2 Likes
Thanks Erik,
I think it is a nice idea to block the IPs in iptables, but one concern I have is where the phishing urls are hosted on same endpoints as legitimate sites (Cludflare, AWS and such), we will end up blocking the legitimate sites as well so for that reason I am not so sold on blocking based on IPs.
But happy to hear otherwise if you think.
1 Like
if you have read the wiki article about ipsets and studied Firehols update-ipset and their IPLists you’ll see that it is not only IP blocking.
IPsets can be port specific and the update script also resolves URLs by DNS requests.
Thus it is possible to name the ‘bad guys’ very specific. If this isn’t possible, a whole domain may be blocked. But this is IMO okay. If I can’t identifiy the misbehaving individuals in a group, I can’t trust this group as a whole.
@ummeegge,
how did you manage the use of the iprange tool from Firehol in the update script?
Bernhard
if you have read the wiki article about ipsets and studied Firehols update-ipset and their IPLists you’ll see that it is not only IP blocking.
“IP Sets” allow for optimized use of complex sets of filters used with the IPTables firewall.
As far as I am aware, iptables only drops based on ip:port and doesn’t do any DNS resolution.
update script also resolves URLs by DNS requests.
I understand this, and this is exactly the problem. You are resolving the URL to an IP and then blocking that IP via an iptables rule. That is exactly the problem and a great way to start blocking sites legit hosted on Cloudflare and AWS/Azure/Google Cloud etc.
I’d recommend that nobody does this, lot of legit content on Cloudflare for DDoS protection, all it takes is a few baddies and you’re going to start blocking access to legitimate content hosted on Cloudflare. Same for stuff sitting on CDNs like Akamai, you get a few baddies reported with stuff hosted there and you’re going to kill anyone accessing legit stuff from that CDN. That’s a fantastic way to cause problems for yourself 
Hello all,
sorry for the confusion but it seems that i have been misunderstood. Just a short explanation.
-
We used for lists like Ian posted it here --> Protect users who get spammy phishing links in emails the custom blacklist capabilities from the URL filter via script (please see the link above) to update/sort them. We did not convert domains/URLs to IPs.
Logging should also be nicer since the URL-Filter are also findable via WUI. Please read through the topic if there is interest. -
I use IPSet with the lists mentioned above which are also vast and for very different kinds of threads.
Both possibilities has been tested at the end by a larger group of peoples with no problems at all or in other words we haven´t deleted the internet 
.
@bbitsch
iprange is part of the firehol package and will be used by update-ipsets. We have had a little help and a good conversation with ktsao (core dev and i think founder of Firehol) in the old forum where all has been better explained --> https://forum.ipfire.org/viewtopic.php?f=50&t=15124&hilit=ipset&start=15#p93621 .
Hope all lucidity has been eliminated 
bitte äppelsche net mit birnsche verwechsle gell
Best,
Erik
I use IPSet with the lists mentioned above which are also vast and for very different kinds of threads.
Is IPSet not filling your IP tables up with rules from the lists? Isn’t that the point of IPSet to manage lists of IPs in iptables?
@ummeegge
Hi Ian,
yes IPset uses IPs and CIDRs from Firehol. IPSet stores IPs and CIDRs in bitmap or hash format, so also big lists are not a problem.
Best,
Erik