Firewalls - Ease of Use and Maintenance?

Wed Nov 9 14:52:52 UTC 2011

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
>    