OH yeah!
MANAGEMENT: If you have a few FWs and you manage them independently life
is grand. But what if you have 20? 50? 100? and if 30-40 percent of the
policy is the same?
Cisco: NOTHING. Don't let them lie to you.
CheckPoint: Provider 1 and SmartManager.
Juniper: Not sure.
BSD/PFSense: Nothing I know of
Others: ???
Disclaimer: We are currently a CheckPoint/FWSM/PIX/ASA/Juniper shop.
This is the byproduct of mergers/acquisitions/etc. We have standardized
on CheckPoint and are phasing out the other vendors as they sunset. A
major factor in the decision was management. In the end, if you separate
the functions like we do, a FW is a FW is a FW. L3/4 isn't that
complicated these days. It's L7 FWs that get the attention. So if the
product is stable and has a good MTBF then it's not a huge difference to
us as far as the capability of the FW to perform it's function. They all
do it well.
-Hammer-
"I was a normal American nerd"
-Jack Herer
On 11/09/2011 08:52 AM, -Hammer- wrote:
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
