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

Anonymous Proxy Sites

ASG 6.3xx

Is there anything in this log entry that I could look for in order to block access to these type of sites?

2008:03:24-11:38:50 (none) squid_access[4755]: 1206376730.924 118 192.168.14.41 TCP_MISS/200 5215 GET http://plainbrownenvelope.com/index.php? - DIRECT/67.159.44.49 application/x-javascript


I guess I could disable the javascripts, but that would probably cause me more trouble than it would the students.


The site listed was properly catagorized for v7, but was improperly catagorized for v6.  I turned it in, and it has been corrected, but I am just trying to get ahead of the game instead of dragging up the rear constantly.


This thread was automatically locked due to age.
Parents
  • You could block that site using the adult site blocking feature of opendns. I checked that particular site and it would have been blocked. You could use that in combination with Astaro's blocking features to enhance what Astaro does. You would have to set up an account at opendns but it is free. I haven't tried this specific feature with opendns, but I've been using their servers for quite some time now and are very satisfied. Let me know if this works out for you, I will want to try it too!

    http://opendns.com/features/adult
  • You could block that site using the adult site blocking feature of opendns. I checked that particular site and it would have been blocked. 
    http://opendns.com/features/adult



    I have setup a account with them, and when I turn off the HTTP content filter and visit sites using just the OpenDns, it is only blocking the more popular adult sites(Big name magazine types).  It doesn't even catch "www.s.e.x.com", which, at least to me, would be pretty obvious to include.

    I also had no trouble accessing the http://plainbrownenvelope.com site.  I have proxies and adult content checked on that site, but it still goes through.  I'll leave it as my forwarders, since it didn't appear to break anything, but it is most definately not a replacement for the ASG content filtering.

    Which you never said it was :-).  And it is free, so I guess I got my moneys worth.
  • Anonymous proxies can be difficult to block with just a url filter. There are a few more threats to think about once uncovering http proxies such as ssl proxies, tor, and ultra surf. These services easily defeat the security of a url filter.
  • I tried setting up an account with opendns and it did block plainbrownenvelope.com. It did take a couple of minutes to start blocking, as noted when you configure the opendns dashboard:

    "Settings saved. Wait 3 minutes for your preferences to be pushed to all servers. Clear your local resolver cache if the domain has been visited recently."

    If you're not on a static IP, of course you'll need a to setup a DDNS/DNS-o-Matic client.
  • We have static IPs, so that isn't a problem.  It is blocking it now, but I tried it about 20 minutes after I got the account setup this morning and it wasn't.  

    Either way, I have already gotten some "fan" mail due to the anonoymous sites being blocked that the content filter had missed, so it's a good deal at twice the price!

    Thanks for the heads up!
  • lol. I get "fan" mail all the time - mostly about vaigra etc - luckily google sorts it so well that I never need to see it. [:)]

    You might want to double check that astaro will redirect all DNS queries to OpenDNS. It may be possible for a user to change the DNS servers on the client desktop to bypass OpenDNS and surf freely.

    Glad it worked for you. I ended up using it myself!

    Agreed about tor, etc - those are a different type of threat that dns won't help you with.
  • Maybe someone there can explain why this would happen - I sure can't.

    In an attempt to stop the anonymous proxies, I resorted to setting up a Opendns account.  I have set the v6 DNS proxy to forward to their servers, and have set the forwarders in all my AD DNS servers to their sites as well.  Everything seemed to be working ok.

    Our high school has 25 older Wyse 3230LE thin clients and 5 newer Wyse S10 clients.  The older ones use Win CE.

    Both styles have static IPs and have the same DNS/Wins settings configured.  All units connect to the TS by IP address.

    The terminals are normally left on during the week, turned off only for weekends or holidays.

    Yesterday when they started the terminals, only the newer terminals would connect to the terminal server.  

    After they notified me of this today, I went out there and tried many different things and wasted a lot of time.  Not even a blip in the event logs on the terminal server. Finally, I opened up the packet filter to see if the router was sending the packets to the wrong location.

    What I found was that the RDT packets were being sent to 208.67.217.130, which resolves to hit-nxdomain.opendns.com.

    The packets should have been going to 192.168.13.1, from 192.168.13.xx

    Why this was happening is a mystery to me.  The quickest solution at the time was to delete the DNS settings from the boxes that would not connect.  After I did that, things went back to working.

    Any idea as to why RDP packets would be sent to the OpenDns site instead of to the site they were specifically setup to connect to?
Reply
  • Maybe someone there can explain why this would happen - I sure can't.

    In an attempt to stop the anonymous proxies, I resorted to setting up a Opendns account.  I have set the v6 DNS proxy to forward to their servers, and have set the forwarders in all my AD DNS servers to their sites as well.  Everything seemed to be working ok.

    Our high school has 25 older Wyse 3230LE thin clients and 5 newer Wyse S10 clients.  The older ones use Win CE.

    Both styles have static IPs and have the same DNS/Wins settings configured.  All units connect to the TS by IP address.

    The terminals are normally left on during the week, turned off only for weekends or holidays.

    Yesterday when they started the terminals, only the newer terminals would connect to the terminal server.  

    After they notified me of this today, I went out there and tried many different things and wasted a lot of time.  Not even a blip in the event logs on the terminal server. Finally, I opened up the packet filter to see if the router was sending the packets to the wrong location.

    What I found was that the RDT packets were being sent to 208.67.217.130, which resolves to hit-nxdomain.opendns.com.

    The packets should have been going to 192.168.13.1, from 192.168.13.xx

    Why this was happening is a mystery to me.  The quickest solution at the time was to delete the DNS settings from the boxes that would not connect.  After I did that, things went back to working.

    Any idea as to why RDP packets would be sent to the OpenDns site instead of to the site they were specifically setup to connect to?
Children
No Data