Hello Michael,
I did some trials and now I don’t understand why I actually need the non-transparent mode to make the web-filter work in HTTPS. It seems that setting 10.16.1.254:800 as the HTTPS-Proxy is enough to make it work regardless of whether in transparent or non-transparent mode.
Am I missing anything?
Micheal means only that you have to specify the proxy in the config and block the direct way for https domain filtering.
The “transparent” field is only valid for http. (It redirect all port80 connections to proxy:800)
There is no need to disable the “transparent mode” for http to catch the traffic of browsers without the config.
…and this is done via an extra Firewall rule, right?
Thanks a lot!
One of the easier ways to do URL filtering via HTTPS, if you don’t like taking the proxy off transparency is to block the resolve.
You would do this by forcing all DNS traffic from the LAN to the firewall.
For example:
Edit the firewall.local and add the required entries below the line that reads ## add your ‘start’ rules here
vi /etc/sysconfig/firewall.local
# Force DNS for green to query the firewall, and not an outside DNS server
iptables -t nat -A CUSTOMPREROUTING ! -o green0 -p udp --destination-port 53 -j REDIRECT --to-ports 53
iptables -t nat -A CUSTOMPREROUTING ! -o green0 -p tcp --destination-port 53 -j REDIRECT --to-ports 53
That ^ is my preferred option. It works, and that’s what counts for me.
Alternatively you can try and figure out how to do it in the Firewall GUI, but there you would be on your own….
I guess it could look something like this
Source = Firewall : GREEN
NAT = n/a
Destination = Standard networks: ANY
Protocol = TCP/53 & UDP/53
Accept/Drop/Reject = REJECT
Additional Setting = Remark: DNS BLOCK
Source = Standard networks : GREEN
NAT = n/a
Destination = Standard networks: RED
Protocol = TCP/53 & UDP/53
Accept/Drop/Reject = ACCEPT
Additional Setting = Remark: DNS
Source = Firewall : RED
NAT = n/a
Destination = Standard networks: ANY
Protocol = TCP/53 & UDP/53
Accept/Drop/Reject = ACCEPT
Additional Setting = Remark: DNS
… but as said, no clue on that.
I suppose the iptable entries would end up look something like
# Maybe checkup, I might not be right :)
iptables -I INPUT 1 -s <insert your LAN IP range> -d ANY -p udp --dport 53 -j REJECT
iptables -I INPUT 1 -s <insert your LAN IP range> -d ANY -p tcp --dport 53 -j REJECT
iptables -I INPUT 1 -i green0 -d red0 -p udp --dport 53 -j ACCEPT
iptables -I INPUT 1 -i green0 -d red0 -p tcp --dport 53 -j ACCEPT
iptables -I INPUT 1 -i red0 -d ANY -p udp --dport 53 -j ACCEPT
iptables -I INPUT 1 -i red0 -d ANY -p tcp --dport 53 -j ACCEPT
And I guess you could even add that to /etc/sysconfig/rc.local …many roads lead to hours of frustration or how the saying goes.
I prefer the redirect option instead.
Any how… Once you now have forced all DNS queries via the firewall, irrespective of what DNS servers the LAN user wants to use, the firewall redirects that query to itself and responds.
Now you could add in either a DNS service that does the filtering for you, i.e. 185.228.168.168 for family friendly, or 185.228.168.10 for adult filter, as an example, I’m sure there are more.
Or alternatively you could go nuts like me and create a script (no longer works under core 142 correctly) that generates a blacklist for the unbound DNS from a source like http://dsi.ut-capitole.fr/blacklists/download/porn.tar.gz or if you already have the URL filter enabled you could just use the source /var/ipfire/urlfilter/blacklists/porn/domains instead. No point in downloading anything if you already have it available for abuse.
As said the script I created seems to break unbound.conf and until I have figured out which part of it is to blame, I cannot provide it.
The nice part about this approach, elegance aside and can be debated, is that you can add additional filtering as needed and unless the user goes nuts with vpn etc. there is no way around it. Unlike the url filter, this method prevents the resolve, no IP, no connection, problem solved.
I hope this helps you.
cheers
For this firewall.local solution you should also define the stop rules!
Oh …oops. Absolutely correct, or you would just keep adding the same custom NAT rule, until you restart the box, on reloads.
To fix that edit …
vi /etc/sysconfig/firewall.local
## add your 'stop' rules here
/sbin/iptables -t nat -F CUSTOMPREROUTING
Leave the ;; in place
If memory services me correctly rc.local only gets loaded during boot time.
This means no stop rule needed, as all rules are flushed and reloaded during a reboot.
What do you mean by this? Is it the same problem as described in this thread : [issue] unbound restart / reboot need to long after update 139->141 - #3 by psyops
I made a script which use the same blacklist, it worked with core 139 but needed modifications for core 142. But with core 142, unbound need half an hour to start…
Nope they seem to be unrelated. However to be honest, I have not actually checked how long unbound takes to come up. All I know is if I go TSL I get
Mar 28 19:25:53 unbound[14097:0] error: can’t bind socket: Address already in use for 127.0.0.1 port 8953
Mar 28 19:25:53 unbound[14097:0] error: cannot open control interface 127.0.0.1 8953
errors.
Which is odd, as nothing is running on port 8953, apart from TLS when enabled that is
UDP fails over time, as though it is degrading, swapped to TCP which resolved that problem.
Regarding the script, it had the same results, irrespective of the network protocol I chose to use.
It seems to hang during a specific process, when I kill it and try to do a /etc/init.d/unbound restart, it complains about unbound.config being in use. So unbound fails to load, and then only way to get out of this is to delete the unbound-blockporn.conf file that was created, and edit the /etc/unbound/unbound.conf file and remove the reference to it. Doing a /etc/init.d/unbound restart then actually works.
This tells me something with the way the script creates the blockporn file is borked.
As said, I have been editing the file since I discovered it (when I get time), but yet have to find a fix.
I would post the script, but it’s off topic. I also think there may still be a copy of it on the old forum page.
I had the same Problem: Long delay at startup, plus i do an unbound URL-Filtering too. I did not developed a custom script, but used the one Mike Kuketz recommended here.
My Problem was a wrong configuration in the DNS-Settings, you may read further here. After i switched the “Protocol for DNS queries” to “TCP”, all my Problems are gone especially the long delay at Unbound-Startup.
Stay healthy!
Regards,
Olaf
I’m an idiot by the way… I kept using the wrong port for DNS over TLS.
Not port 8953
It should be 853
yes it’s working now…duh! 