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