DNS validation firewall ruleset - $10000
-
Yes, they said they didn't have the time and the budget was too small. Fair enough. I think this might be a case of "the valley of death" where OSS projects can't actually provide a complex feature without a champion who wants to do it for free, but the for-profit sponsor of the project can't take on the bounty work either because of conflicting goals in trying to stay alive (i.e.: would this OSS addition in some way generate recurring revenue or a continuing customer? No.)
JT
-
Interesting idea, but is this not something that would be better handled in Squid or a proxy rather than within the pf Firewall ruleset.
From a security point of view nothing should be allowed out of your network unless you permit that destination IP. Redirecting all DNS port 53 traffic to your resolver and redirecting all web traffic to a proxy would probably be a better point to intercept.
For example a infected IOT device will attempt SSH brute force attacks against legitimate servers with A records in DNS, your ruleset will permit this. Same with spam they will retry to relay of known good accounts and smtp relay servers again both will have valid dns entries.
Don't want to knock security ideas as my god the world needs to get its act together, just not sure you're spending that 10k wisely.
-
Interesting idea, but is this not something that would be better handled in Squid or a proxy rather than within the pf Firewall ruleset.
From a security point of view nothing should be allowed out of your network unless you permit that destination IP. Redirecting all DNS port 53 traffic to your resolver and redirecting all web traffic to a proxy would probably be a better point to intercept.
For example a infected IOT device will attempt SSH brute force attacks against legitimate servers with A records in DNS, your ruleset will permit this. Same with spam they will retry to relay of known good accounts and smtp relay servers again both will have valid dns entries.
Don't want to knock security ideas as my god the world needs to get its act together, just not sure you're spending that 10k wisely.
You're perhaps interpreting this idea a bit more widely that it is intended. It cannot solve all security problems; just a specific subset. And it makes DNS-based blacklists actually useful, instead of just prophylactic, which is the underlying assumption of the feature request. Building exception lists for entire organizations is difficult (or impossible, if you've tried for a technical team of more than 100) and blocking outbound ports is a whack-a-mole game that can't be won. The shortcomings of both the administrative overhead and limited protocol set of squid can be avoided entirely with this method, and lets users have a "more" complete end-to-end Internet, with a single protocol gating network access (DNS.)
I think the firewall (pf) is the perfect and only place to create this gate, because that's the work it does already. It just needs a more active method to implement/remove filters. Why implement gates both in squid AND in pf? Seems redundant.
-
I could think of a way in linux because dnsmasq could dump all IPs to ipset. It was probably made for live updating the firewall.
-
A thought on downsides 1 & 4… could this not be mitigated by performing a reverse lookup (and caching it) on all destination IPs? A cache miss due to reboot or sync issue would simply add more processing time, instead of causing the connection to be blocked.
Anyhow, I like this idea as I too have had cases of random apps connecting directly to obscure IPs...
Sadly I'm ill equipped to really help. Though it sounds like this would be something that would have to at least be partially built into pf itself. Is it possible to execute arbitrary code as part of rule execution?
-
A thought on downsides 1 & 4… could this not be mitigated by performing a reverse lookup (and caching it) on all destination IPs? A cache miss due to reboot or sync issue would simply add more processing time, instead of causing the connection to be blocked.
Anyhow, I like this idea as I too have had cases of random apps connecting directly to obscure IPs...
Sadly I'm ill equipped to really help. Though it sounds like this would be something that would have to at least be partially built into pf itself. Is it possible to execute arbitrary code as part of rule execution?
I'm not clear on what you mean by a reverse lookup. Do you mean in in-addr/ip6.arpa? Those are almost always wrong, and are also overloaded, since it is only possible to have one in-addr, but there may be hundreds (or thousands, or tens of thousands) of A/AAAA records pointed at single IP address. Can you fill this in a bit more since I don't quite follow the logic.
There is possibly someone who is taking the task; more news in this thread if demonstrable progress is made.
JT
-
I'm already working on this, I'm about 70% done. As for the rdns question, there's only two ways of doing that: in-addr.arpa or PTR records, the latter of which are only set for systems that send mail. Also in-addr.arpa responses are not wrong, they return the hostname of the machine with that IP, or NXDOMAIN if it doesn't have one set.
-
The solution is almost complete and I'm currently testing it.
I would just like to clarify the purpose/intent behind the TTL override options. Am I correct in thinking these overrides would apply ONLY to the blocking system, and not unbound also?
-
Bowing out of because the work has apparently already been committed to someone else.
-
Quite a large bounty! What ever happened with this…?
-
This post is deleted!