I think that firewall/censorship is all semantics. The real question is
the scale of the environment and the culture of your shop and areas of
ownership.
I work in a large enterprise. Combining "functions" such as L3
firewalling with content filtering with url filtering with XXX can be
difficult.
1. Can the platform actually handle all the traffic?
2. Does one group own ALL the separate functions? If not, RBAC becomes
an important (and sometimes political) issue.
3. How easy is it to troubleshoot?
Although modern hardware is quickly catching up with all the glorious
software features people want these days, in our environment we found it
easier and saner to separate these functions. They were owned by
different groups and the number of FWs we deploy vs the number of
content filters didn't add up to make sense when aggregating functions
was discussed.
In a smaller operation a Fortinet or other product that consolidates
these efforts may make sense. In a larger operation in depends on many
outside factors.
I've had the (dis)pleasure of working with PIX/FWSM/ASA since Vietnam.
I've worked with Netscreen/Juniper, IPTables, PFsense, CheckPoint over
Nokia, CheckPoint over Winblows, CheckPoint over UTM, Fortinet,
Sonicwall (say Uncle!) and others. They all have their pros and cons and
in the end it is specific to your shops needs.
More of a UNIX guy? BSD FWs. No we aren't going to talk about how BSD
isn't UNIX. That's a different mailing list.
More of a Linux guy and need to make sure you have a vendor to yell at?
CheckPoint. IPSO/SPLAT/GAEA is all Linux.
Not a UNIX/Linux guy and you need a more reliable vendor? And a
traditionally safer bet? "No one ever got fired for buying Cisco."
Need to save money? Consolidate functions? Confident of the capabilities
of the product? Fortinet.
And the list goes on and on and on....
-Hammer-
"I was a normal American nerd"
-Jack Herer
On 11/09/2011 08:00 AM, Joe Greco wrote:
On Wed, Nov 09, 2011 at 03:32:45PM +0300, Alex Nderitu wrote:
An important feature lacking for now as far as I know is content/web
filtering especially for corporates wishing to block
inappropriate/time wasting content like facebook.
1. That's not a firewall function. That's a censorship function.
A "firewall" is pretty much a censorship function, you're using it to
disallow certain types of traffic on your network. It's simply a matter
of what layer you find most convenient to block things... a firewall
is better closer to the bottom of the OSI layer model, a proxy is better
closer to the top of the OSI layer model.
Is it "censorship" not to want unwanted connection attempts to our
gear, and block unsolicited TCP connections inbound?
Is it "censorship" not to want unwanted exploit attempts to our
gear, and run everything through ClamAV, and use blocklists to
prevent users inadvertently pulling content from known malware sites?
There's no functional differentiation between blocking content for
one reason and blocking it for another. There's certainly a huge
difference in the POLICY decisions that drive those blocking decisions,
but the technology to do them is essentially identical. You can,
after all, block facebook on your firewall at the IP level and I think
we would both agree that that is "censorship" but also something a
firewall is completely capable of. It's just neater and more practical
to do at a higher level, for when facebook changes IP addresses (etc),
so a higher level block is really more appropriate.
2. You can of course easily do that via a variety of means, including
BOGUS'ing the domains in DNS, blocking port 80 traffic to their network
allocations, running an HTTP proxy that blocks them, etc. I presume
that any minimally-competent censor could easily devise a first-order
solution (using the software packages supplied with OpenBSD) in an afternoon.
It's a little trickier to do in practice. I kind of wish pfSense
included such functionality by default, it'd be so killer. :-)
Last I checked, it was possible-but-a-fair-bit-of-messing-around.
Still, vote++ for pfSense.
... JG
