(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 tunnelled traffic, of
>course,
>> >                         but there's only so much you can do without
>> >                         the line becoming useless for legit work.
>> >
>> >
>> >                         Kyle Spencer <[email protected]> wrote:
>> >                                 Use an internal DNS and force
>people
>> >                                 to use that DNS.
>> >
>> >                                 On Oct 13, 2012 11:05 AM, "Godfrey
>> >                                 Baluku" <[email protected]> wrote:
>> >                                         Hello Lugers,
>> >
>> >
>> >
>> >                                         I want Facebook to be
>accessed
>> >
>>
>>
>
>-- 
>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.

Reply via email to