We have Squid running on a RHEL server. We want to block users from getting to Facebook, other than a couple specific sites, like our organization's page. Unfortunately, I can't get those specific pages unblocked without allowing ALL of Facebook through.


# Local users:
acl local_c src

acl Safe_ports port 80 443

# File containing blocked sites, including Facebook:
acl blocked dst_dom_regex "/etc/squid/blocked_content"

# Whitelist:
acl whitelist url_regex "/etc/squid/whitelist"

# I do know that order matters:
http_access allow local_c whitelist
http_access allow local_c !blocked
http_access deny all





My biggest weakness is regular expressions, so I'm not 100% sure about if this is all correct. If I remove the "!blocked" part of the http_access rule, all of Facebook works. If I remove "facebook.com" from the blocked_content file, all of Facebook works.

Right now, visiting facebook.com/OurOrganization gives a "The website declined to show this webpage / HTTP 403" error in Internet Explorer, and "Error 111 (net::ERR_TUNNEL_CONNECTION_FAILED): Unknown error" in Chrome.

WhereGoes.com tells me the URL redirects for that URL goes like this:

facebook.com/OurOrganization --> [301 Redirect] --> http://www.facebook.com/OurOrganization --> [302 Redirect] --> https://www.facebook.com/OurOrganization

I tried turning up the debug traffic out of squid using "debug_options ALL,6" but I can't narrow anything down in /var/log/access.log and /var/log/cache.log. I know to issue "squid -k reconfigure" whenever I make changes to any files.

closed as not constructive by HopelessN00b, mdpc, Ward, pauska, jscott Nov 29 '12 at 13:58

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Do you know all of the subdomains that Facebook uses for authentication? You won't be able to get very far if you can't log into it. Honestly, if you need to get to part of a tangled web like Facebook, it's usually an all or nothing situation. – MDMarra Nov 26 '12 at 19:24

First thought is "Don't block websites". This is fundamentally a management/HR problem, not a technical one. If you really have problems with employees screwing-off instead of getting their work done, time for new employees. No that isn't a pleasant process, but I absolutely guarantee you'll be happier, more productive, and more profitable in the long run.

Besides, you can't stop employees from screwing off, if Facebook is blocked they'll just use their smart-phone; or just stare at their desk for an hour, it looks like they're doing work, probably another hour after lunch too. In a given week they probably only do about fifteen minutes of real, actual, work.

I highly doubt all of your 200+ workforce would use Facebook or similar if you simply told them not to. You're blocking it now, check your logs, I'll bet 90%+ have never even tried to get on FB. Even if true, that all you're employees are screw-offs, the company would still be in better shape if you replaced them all with efficient workers who want to do their job. Bonus: You wouldn't be wasting time on blocking websites and could concentrate on supporting profit-generating activities.

You're job is also to advise management. You're not mindless, you don't only follow instructions. If that was the case a robot could do the same thing and cheaper. There are plenty of studies available with both statistics and emotional reasons (the two main decision motivators) why blocking websites is bad for the bottom line, moral, efficiency, etc.

  • 4
    If you really have problems with employees screwing-off instead of getting their work done, time for new employees. I'm reminded of my workplace, where our webfiltering inspires employees to read paperbacks and play solitaire instead of unproductive websurfing. Three cheers for shuffling the problem around instead of solving it. – HopelessN00b Nov 26 '12 at 18:29
  • 4
    @HopelessN00b behind every over-zealous filtering system there is a manager who can't tell the difference between a message and the medium carrying it. – Rob Moir Nov 26 '12 at 18:31

I use pfsense and just blocked entire fb subnets then allowed specific URL on squid whitelist. Was easier and quicker to shut management up and once they realized their fb was blocked too they dropped the whole thing


You simply can't have it both ways: Something is blocked, or it's not.
If you start punching pinholes people will find ways around your blocks. Users may not be the brightest bulbs on the Christmas tree, but they're quite resourceful when it comes to getting their Farmville fix.

If you want certain employees to have access to Facebook that can be done pretty easily: presumably you all authenticate to Squid with a username/password. Even if you don't right now it's easy to have certain users do so. Give them a separate, less restrictive whitelist and you're done.

As ChrisS mentioned this probably isn't even a problem -- if it is then a blanket block (or a block with specific employee exceptions) is the way to deal with it. (Need to convince Management? Show them a list of your other business-critical projects that you're not working on because you're dealing with this.). Alternatively don't block it at all and pull the proxy logs for a couple of weeks: anyone found spending an "excessive" amount of time on facebook gets a formal reprimand ("excessive" can be defined by management).

Both of these solutions waste less of your time, and put dealing with the problem with HR/Managers where it should be.

Not the answer you're looking for? Browse other questions tagged or ask your own question.