Actually, the 'Firewall FAQ' ( http://www.interhack.net/pubs/fwfaq/ )
has a blurb on this subject (Section 3.12).
---Quote---
3.12 How can I restrict web access so users can't view
sites unrelated to work?
A few years ago, someone got the idea that it's a good idea to block ``bad'' web
sites, i.e., those that contain material that The Company views ``inappropriate''.
The idea has been increasing in popularity, but there are several things to consider
when thinking about implementing such controls in your firewall.
It is not possible to practically block everything that an employer deems
``inappropriate''. The Internet is full of every sort of material. Blocking
one source will only redirect traffic to another source of such material, or
cause someone to figure a way around the block.
Most organizations do not have a standard for judging the appropriateness
of material that their employees bring to work, i.e., books, magazines, etc.
Do you inspect everyone's briefcase for ``inappropriate material'' every
day? If you do not, then why would you inspect every packet for
``inappropriate material''? Any decisions along those lines in such an
organization will be arbitrary. Attempting to take disciplinary action
against an employee where the only standard is arbitrary typically isn't
wise, for reasons well beyond the scope of this document.
Products that perform site-blocking, commercial and otherwise, are
typically easy to circumvent. Hostnames can be rewritten as IP
addresses. IP addresses can be written as a 32-bit integer value, or as
four 8-bit integers (the most common form). Other possibilities exist, as
well. Connections can be proxied. Web pages can be fetched via email.
You can't block them all. The effort that you'll spend trying to implement
and manage such controls will almost certainly far exceed any level of
damage control that you're hoping to have.
The rule-of-thumb to remember here is that you cannot solve social problems
with technical solutions. If there is a problem with someone going to an
``inappropriate'' web site, that is because someone else saw it and was offended
by what he saw, or because that person's productivity is below expectations. In
either case, those are matters for the personnel department, not the firewall
administrator.
--End Quote--
Michael T. Babcock writes:
> It should almost be a FAQ for this list -- implemente policies in writing
> first, not on the firewall. If users are not allowed to use Napster, chat
> clients, etc., then H.R. needs to deal with that. If you have a bandwidth
> congestion problem, install a router that can do one of the many fairness
> queuing protocols to even out bandwidth use between protocols. Using snort
> to watch for breaches in the policy and then reporting those to H.R. are
> more productive than doing hidden 'user vs. I.S. admin' wars.
>
> On the note of fairness queuing: I set up any gateway machine (intranet or
> internet) to prioritise known traffic over unknown. That way I can leave
> open internal ports above 1023 and not worry about bandwidth congestion
> (anything destined to port 80, 443, 21, 22, 3128, etc. get priority over the
> rest). Monitoring bandwidth use of 'known' protocols then allows me to know
> how congested the network really is (it may be at 80% use, but only 20%
> known traffic -- so I know no network upgrade is needed).
>
> ----- Original Message -----
> From: "Daniel Crichton" <[EMAIL PROTECTED]>
>
>
> I totally agree here - we now have a policy that outlines what may be used
> on
> the company network, and Napster and Gnutella are on the banned list. The
> one person we had who sparked off our whole Napster/Gnutella "manhunt"
> here managed to shift over 750Mb of MP3s in 3 days, and it was only by
> trawling the firewall logs that we spotted it. ... We now run Snort
> and other packet sniffers to watch out for traffic for protocols we don't
> allow
> and get alerts fired to all security admins when something suspicious is
> found, and we're investigating the use of Snort to automatically close the
> connection using the new ability to intercept the connection and send the
> RST packets.
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
