From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [RFC PATCH 0/8] Provide an easy way to use Safe Search Date: Wed, 01 May 2019 10:51:04 +0100 Message-ID: In-Reply-To: <894049ff-9133-9483-def8-b21ea23cb41f@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0000427375042177231==" List-Id: --===============0000427375042177231== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Thanks for writing. I think this is a very important opinion to have on the r= ecord. I share your view. > On 30 Apr 2019, at 18:52, Peter M=C3=BCller wr= ote: >=20 > Hello Michael, hello *, >=20 > just a few comments from my point of view: >=20 > For a couple of reasons, I have always been against DNS-based > filtering of malware, C&C traffic (including the oh-my-god-its-so-dangerous > DNS tunneling) and other possible unwanted content. >=20 > As more and more web traffic uses HTTPS today, I agree the > proxy based Safe Search option does not make sense any more. >=20 > However, manipulating DNS queries - or, worse, replies - makes > network debugging and troubleshooting more harder, since the > presence of such techniques might not be obvious. It is transparent for the client in that sense that the client sees the CNAME= (for those who use it) and therefore would see =E2=80=9Csafe=E2=80=9D or so = in the name. But if you are on the web browser level then you don=E2=80=99t really see thi= s at all. Agreed. > Talking about DNS replies, such manipulations look like an attack > to DNSSEC-validating resolvers. If they are created "on purpose", > detection of real attacks becomes harder. At this point, best > regards to DNS based ad/tracker filters such as Pi-hole. The search engines are all not using DNSSEC and presumably never will because= they are employing this sort of techniques. However, I have no better idea h= ow to force Safe Search on a network level. > DNS based Safe Search can be bypassed by using a different DNS > server (of course, there have to be firewall rules in place to > prohibit this, which I highly recommend in any given scenario). > In case internet access is granted via local Squid proxy with an > upstream one, administrators need to ensure _this_ machine will > also force the Safe Search domains for resolving. The idea to work on this came from a customer which is running a school netwo= rk. Access to the internet is prohibited for most devices and no access is po= ssible without going through the web proxy - at least for students. Of course this needs some good documentation and a button on the web UI. > Besides of that, I have no objection against this patchset. Although I also disagree with this approach in that sense that it will break = DNSSEC, this works according to the =E2=80=9Cold=E2=80=9D DNS protocol. This is also better than the HTTP request rewrite approach as it protects the= privacy of the search queries. All in all, Safe Search is a necessity for schools. There is no other way to = do this and for this is not too ugly. Please don=E2=80=99t forget to use Git tags. Best, -Michael > Thanks, and best regards, > Peter M=C3=BCller >=20 >> For some users of IPFire, it makes a lot of sense to use Safe Search. >>=20 >> Safe Search is a feature that some search engines provide to filter out >> pornography and other "adult" content from the search results. It makes >> sense to use this in schools or at home with smaller children. >>=20 >> We used to have a checkbox in URL Filter which allowed to modify the >> search URL which no longer works because all search engines are using >> HTTPS. >>=20 >> Some search engines provide a different way to enable Safe Search >> network wide by having special servers that can be contacted which >> always have Safe Search on. Those servers can be reached by changing >> the DNS response from the usual servers to those special ones. >>=20 >> This patchset enables this for Google, Bing, DuckDuckGo and Yandex. >>=20 >> These are all search engines I could find this support this. >>=20 >> This patchset also removes the old URL Filter option. >>=20 >> Please review and test. You can enable this by simply adding >> ENABLE_SAFE_SEARCH=3Don to /etc/sysconfig/unbound. >>=20 >> Michael Tremer (8): >> unbound: Add switch to enable Google Safe Search >> unbound: Enable Bing SafeSearch >> unbound: Enbale DuckDuckGo safe search >> unbound: Move Safe Search zone setup to configuration file >> unbound: Add Yandex Safe Search >> unbound: Fix Bing domain name for SafeSearch >> unbound: Fix domain name for Google Safe Search >> URL Filter: Drop Safe Search feature >>=20 >> config/unbound/unbound.conf | 3 + >> doc/language_issues.de | 1 + >> doc/language_issues.en | 1 - >> doc/language_issues.es | 1 + >> doc/language_issues.fr | 1 + >> doc/language_issues.it | 1 + >> doc/language_issues.nl | 1 + >> doc/language_issues.pl | 1 + >> doc/language_issues.ru | 1 + >> doc/language_issues.tr | 1 + >> html/cgi-bin/urlfilter.cgi | 62 ++--------- >> src/initscripts/system/unbound | 230 +++++++++++++++++++++++++++++++++++++= ++++ >> 12 files changed, 250 insertions(+), 54 deletions(-) >>=20 >=20 > --=20 > The road to Hades is easy to travel. > -- Bion of Borysthenes --===============0000427375042177231==--