Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 27 subscribers
  • Views 2343 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

More problems with SafeSearch filtering - bing can be bypassed

PowerPete

Hello all,

I'm having a terrible time getting SafeSearch filtering to work correctly/reliably. Here's where I'm at:

1) After enabling it in the web policy, and applying the policy to both IPv4 and IPv6 traffic (that 2nd step drove me crazy for a bit but I finally got it to work), filtering is being applied correctly to Google 100% of the time.

2) However, on Bing, the initial search will always have safesearch enabled, however you can simply bypass it by selecting "SafeSearch: disabled" in the results.

If the XG is enforcing SafeSearch through the DNS redirects (which is how I did this on the old UTM with zero issues and no HTTPS filtering) this shouldn't be possible .

My guess is that it appears that the older method of modifying/appending the GET request may be what is in use, which is causing problems because once the HTTPS session is established, changes within the session aren't seen at the URI level.

Note that I currently can't do HTTPS filtering.

Is there a way to manually publish the CNAME redirects internally on the XG's DNS so that it will force the traffic to safesearch?



This thread was automatically locked due to age.
Parents
  • 0

    It should be applied in Bing all the time, it uses the CNAME DNS method similar to Google (since 17.1), and very similar code to the UTM.  It is the first I've heard of any issues.  We made some changes in 17.5 - mostly in how it is configured (global option versus per web policy).  Make sure that you are using 17.5 and that you have it turned on in every web policy you are using (note that it cannot be turned on if you are using Allow All).
     
    Go to Log Viewer, Web filter.  You can filter on your source IP or do a search for bing.
    When you see the "dst ip" it should be the same as what strict.bing.com resolves to.
     
     
Reply
  • 0

    It should be applied in Bing all the time, it uses the CNAME DNS method similar to Google (since 17.1), and very similar code to the UTM.  It is the first I've heard of any issues.  We made some changes in 17.5 - mostly in how it is configured (global option versus per web policy).  Make sure that you are using 17.5 and that you have it turned on in every web policy you are using (note that it cannot be turned on if you are using Allow All).
     
    Go to Log Viewer, Web filter.  You can filter on your source IP or do a search for bing.
    When you see the "dst ip" it should be the same as what strict.bing.com resolves to.
     
     
Children
  • 0 in reply to Michael Dunn

    Appreciate the response and comments. I retested it today, and it seems to work and now cannot be bypassed - there must be some sort of cache that hadn't cleared.

    I had restarted all the DNS services and cleared the cache on all of the systems in question, but the issue persisted, so not sure what may have been cached, but it is working correctly now. Thanks!