Well, as I said, there would occur no DNS lookup at all if you put a row in the client computer's hosts file (/etc/hosts in GNU/Linux and OSX, C:\Windows\something\something\hosts in Windows). When a FQDN is processed, a computer looks first in this file, then consults a DNS server.
It of course depends on how hard you've locked down the clients at a local level. Users should not be able to alter system files, so company-owned stationary computers wouldn't be able to alter the hosts file, but if users are bringing their own laptops don't imagine your block will slow down a moderately savvy user for more than a few minutes. Fortunately, most computer users today are utter fools, so I think your setup is adequate. :) sanga collins <[email protected]> wrote: >There is no outbound traffic unless its either going through the proxy >(80 >and 443) or going to a company service or website. So users can't use >their own dns. Surf by ip or connect to other proxy or VPN type >services. > >On Saturday, October 13, 2012, [email protected] wrote: > >> (Also, your system could be defeated by modifying the hosts file,of >the >> client computer, bypassing DNS lookup for Facebook activities. Or you >could >> just surf to the IP directly and pass the vhost HTTP header with a >suitable >> browser plugin. And so on.) >> >> sanga collins <[email protected]> wrote: >> >> We use our own DNS server and squid + dans guardian. In our firewall >I >> block all outbound from the entire LAN except for the squid server. I >then >> make a Facebook.com entry in the DNS server that points to the ip of >our >> web server that hosts the terms of usage page for the company. >> >> On Saturday, October 13, 2012, [email protected] wrote: >> >> If the issue is bandwidth, then surely there are heavier sites than >> Facebook to fear. And then the same would hold true for every heavy >site on >> the Internet, and you can't block them all. Unless you use a >whitelist >> instead, where you block *everything* except the sites in the list. >But >> such a solution is not feasible in many lines of work, for obvious >reasons. >> Nevertheless, my proposal to treat employees as co-workers and not >like >> adversaries in a digital skirmish should address bandwidth issues as >well. >> >> If I may digress: One should consider a caching proxy server if one >has >> bandwidth problems at work. That way, each resource will be fetched >only >> once over the Internet connection, with any subsequent requests being >> served from a cache on the local network. If two people on two >computers >> are browsing the same web page, why waste time and money on >downloading >> everything twice? >> >> Kyle Spencer <[email protected]> wrote: >> >> Sometimes the issue is bandwidth. >> On Oct 13, 2012 5:09 PM, "Kizito Thomas" <[email protected]> >wrote: >> >> Thank you Benjamin, >> I remember a similar thread on Linux Admin(some mailing list). All >> technical solutions didn't pass the test but this (Benjamin's >Proposal) >> did. >> May be it is better to involve the staff into the advantages of >working >> and not spending time on facebook. otherwise even when you block >> facebook they will come up with other social sites or activities to >> waste time. >> I think monitoring workers on how much time they spend at work is >wrong, >> but how much they have accomplished will make a difference! >> -- >> Kind regards; >> KTM >> +256752602550||+256782062708 >> "Mother of God-Pray for us sinners" >> >> >> On Sat, 2012-10-13 at 13:05 +0200, [email protected] wrote: >> > Since all attempts at blocking are ultimately possible to >circumvent, >> > it might be worthwhile to approach the problem from another angle >by >> > asking oneself why the blocking is even needed. If it's a work >> > environment and Facebook threatens productivity, then stricter >> > policies could be put in place. If you are caught using Facebook at >> > prohibited hours, you're fired. Or, use Facebook how much you want, >> > but if you haven't completed your tasks at the end of the day/week, >> > you're fired. >> > >> > Ultimately, you don't want people working for you whom you have to >> > shepherd into action. You're running a business, not a daycare. >> > >> > Edmonds Namasenda <[email protected]> wrote: >> > Godfrey & Justus, >> > The LinkSys might offer you a solution but with time (as >you >> > have seen Godfrey) users always find ways to beat the >system. >> > >> > Atop what the rest have suggested, the long haul would be a >> > proxy. I have used SafeSquid (commercial) and now tinker >with >> > Squid (free) for much of my time when such need arises. >> > >> > Depending on your needs (present and future), the hardware >> > requirements are often ordinary. >> > >> > # Edz >> > >> > On Sat, Oct 13, 2012 at 1:37 PM, justus byamukama >> > <[email protected]> wrote: >> > Hi all, i too have the same challenge, any >assistance >> > will be great! >> > >> > >> > On Sat, Oct 13, 2012 at 11:36 AM, >> > [email protected] >> > <[email protected]> wrote: >> > Yes. DNSmasq plus blocking of port 53 >outbound >> > should do the trick. >> > >> > It won't catch tunn >> >> > >-- >Sanga M. Collins >Network Engineering >~~~~~~~~~~~~~~~~~~~~~~~ >Google Voice: (954) 324-1365 >E- fax: (435) 578 7411 > > >------------------------------------------------------------------------ > >_______________________________________________ >The Uganda Linux User Group: http://linux.or.ug > >Send messages to this mailing list by addressing e-mails to: >[email protected] >Mailing list archives: http://www.mail-archive.com/[email protected]/ >Mailing list settings: http://kym.net/mailman/listinfo/lug >To unsubscribe: http://kym.net/mailman/options/lug > >The Uganda LUG mailing list is generously hosted by INFOCOM: >http://www.infocom.co.ug/ > >The above comments and data are owned by whoever posted them (including >attachments if any). The mailing list host is not responsible for them >in any way.
_______________________________________________ The Uganda Linux User Group: http://linux.or.ug Send messages to this mailing list by addressing e-mails to: [email protected] Mailing list archives: http://www.mail-archive.com/[email protected]/ Mailing list settings: http://kym.net/mailman/listinfo/lug To unsubscribe: http://kym.net/mailman/options/lug The Uganda LUG mailing list is generously hosted by INFOCOM: http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The mailing list host is not responsible for them in any way.
