Have to agree with the above comments...
There are better solutions. One of which is to get space at the other end of your "bit of string" so that the content filter isn't bandwidth limited.
Then a local HTTP caching server with a decent DNS caching server (if you want to be mean then add a half second delay to "other" DNS traffic, to degrade it's performance and improve the apparent performance of the local DNS solution - there is no way you can override the hosts file on the local machine anyway)
Of course with so much stuff being HTTPS nowadays you might find that the caching isn't as effective as you'd like...
Run something over the weak connection to ensure decent utilisation - Something like VoIPbox (which is available on titchy (replaceable) hardware) could improve the observed performance of the network, particularly if you have a good amount of "small packet" traffic. The underlying software is available on it's own, but the productised version probably has support advantages.
Heck, you could even go the whole hog and use the same vendor for a few things; CACHEbox will handle squid - potentially doing so at both ends, the remote end with a content filter (and maybe not even doing any actual caching?), the local one then doesn't need the constant filter updates; DNSbox does very well as a caching server... There are other vendors, offering similar packages...
Then you just need a firewall - and there are plenty of options there, many of which have a much nicer interface than raw iptables (which is what *I* use, but I wouldn't foist it on others...)
OK - I've just put 5 boxes in, to two locations. But they are relatively cheap, commodity hardware, with phone support and a company to post replacement boxes out (and collect the dead unit). Total space is less than 5U, possibly much less. Nice web interfaces, easy config backup/restore...