Firewalls - Ease of Use and Maintenance?
-Hammer-
bhmccie at gmail.com
Wed Nov 9 15:00:50 UTC 2011
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
>>
More information about the NANOG
mailing list