Re: Firewalls - Ease of Use and Maintenance?

[-Hammer- <bhmccie () gmail com>]

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
> >