Reverse-Resolving IP to Domain Name, Then Blocking?
-
Hello, all!
I work at a low-budget mission school, and have been beating my head against the wall trying to figure out what to do about HTTPS blocking.
I've tried Squid, but the outcome is (in my mind) unacceptable with throwing certificate errors for every HTTPS site (I don't like the idea of the students/staff becoming accustomed to automatically accept every certificate error they receive), OpenDNS is too pricey for our school (at least for the packages that we require), and pfBlocker I-Blocklist lists aren't necessarily specific enough.
What I'm thinking I may need to go with is Squid/Squidguard for HTTP traffic, and pfBlocker for HTTPS traffic.
Anyway, I was just thinking about it, and I'm wondering something… Since the destination IP of HTTPS traffic is unencrypted, is there a way to set pfSense up so that for all HTTPS requests, it would reverse-resolve (don't know the correct term) the IP addresses into domain names, then check the domain name against the URL blacklist?
Thanks!
ElectroPulse -
No, that doesn't work. It can't work at the firewall level, mostly because of how slow/cumbersome DNS can be (every new connection would need to wait for a DNS query), among other problems.
Also it doesn't work because some sites are hosted on the same IP. If www.somesite.com and www.otherplace.com both are hosted from the same IP address, then reverse DNS wouldn't be accurate. It could either allow too much or too little.
Plus, the reverse DNS entry for a server may not even exist, or it may point to some other location entirely.
One thing we have looked into before is a DNS proxy.Where the DNS queries are sniffed from clients and if a "bad" entry is returned, they receive a bad reply or a block is added for the place to which they're attempting a connection. I'm not sure if/when that may be turning up in usable, public code though.
-
No, that doesn't work. It can't work at the firewall level, mostly because of how slow/cumbersome DNS can be (every new connection would need to wait for a DNS query), among other problems.
Also it doesn't work because some sites are hosted on the same IP. If www.somesite.com and www.otherplace.com both are hosted from the same IP address, then reverse DNS wouldn't be accurate. It could either allow too much or too little.
Plus, the reverse DNS entry for a server may not even exist, or it may point to some other location entirely.
One thing we have looked into before is a DNS proxy.Where the DNS queries are sniffed from clients and if a "bad" entry is returned, they receive a bad reply or a block is added for the place to which they're attempting a connection. I'm not sure if/when that may be turning up in usable, public code though.
Thank you for the reply!
Hmm… I'm wondering then, how do DNS servers block HTTPS then? (I'm thinking of OpenDNS blocking). I thought the only part of an encrypted packet was the IP? And like you said, if there are more than one website at the same IP, there could be problems. Is there some other information they can go off of?
-
They block it by forward resolution, not reverse.
OpenDNS sees the DNS query for www.badplace.com, and returns a record that sends the client somewhere else or nowhere at all. They don't block things by IP and they never see a host record in the query, it's all in DNS (sort of like the DNS proxy I described)
-
They block it by forward resolution, not reverse.
OpenDNS sees the DNS query for www.badplace.com, and returns a record that sends the client somewhere else or nowhere at all. They don't block things by IP and they never see a host record in the query, it's all in DNS (sort of like the DNS proxy I described)
Ah, that makes sense! Hmm… That (I would think) would be much easier than using Squid's method of doing it. Just force clients to direct their DNS queries through pfSense, compare the URLs to a blacklist, and return the IP address of a block page, rather than screwing with certificates and stuff...
Do you know of any free solutions outside of pfSense that do this? I'm looking around for one, and haven't seen one yet.
