Re: I don't need no stinking firewall!

[harbor235 <harbor235 () gmail com>]

I think we are over looking what an enterprise class firewall accomplishes
from a security perspective and what a firewalls function is in the overall
security posture of a network.

First, statefull inspection by itself is not the only security feature of a
firewall, it is one security feature of a firewall. Couple that with other
security features and now you have a security device.

Other security features in an Enterprise Class firewall;
    -Inside source based NAT, reinforces secure traffic flow by allowing
outside to inside flows based on
        configured translations and allowed security policies
    -TCP sequence number randomization (to prevent TCP seq number guessing)
    -Intrusion Detection and Prevention (subset of most common signatures)
        recognize scanning attempts and mitigate
        recognize common attacks and mitigate
    -Deep packet inspection (application aware inspection for common network
services)
    - Policy based tools for custom traffic classification and filtering
    -Layer 3 segmentation (creates inspection and enforcement points)
    -Full/Partial Proxy services with authentication
    - Alarm/Logging capabilities providing info on potential attacks
    -etc ......

Statefull inspection further enhances the security capabilities of a
firewall. Another point is
that a firewall by itself is not security, "Defense in Depth" means that
every node on the network has it's
role in the overall security architecture, no one or two devices is security
in itself.

You may choose not to use a firewall or implement a sound security posture
utilizing the "Defense in Depth" philosophy, however you chances of being
compromised are dramatically increased. So, I would be more interested in
implementing a sound security architecture than whether or not a firewall
provides security to my networks.



my two cents,

mike


On Fri, Jan 8, 2010 at 11:18 PM, Joel Jaeggli <joelja () bogus com> wrote:

> Dobbins, Roland wrote:
> > On Jan 9, 2010, at 7:52 AM, Joel Jaeggli wrote:
> >
> > > see my post in the subject, a reasonably complete performance
> > > report for the device is a useful place to start.
> >
> > The problem is that one can't trust the stated vendor performance
> > figures, which is why actual testing is required.  I've seen
> > instances in which actual performance is 5% or less of vendor
> > assertions (i.e., vendor constructed a highly artificial scenario in
> > order to be able to make a specific claim which doesn't hold up in
> > real life).
>
> I'll go out on a limb and just quote myself since you didn't fully.
>
> > > if you know what the maximum session rate and state table size for
> > > the device are, you have a pretty good idea at what rate of state
> > > instantiation it will break. rather frequently it's more than two
> > > orders of magnitude lower than the peak forwarding rate.
>
> two orders of magnitude lower is 1% of forwarding rate. It could be
> lower but it's probably not 3 orders of magnitude.
>
> rfc 3511 testing won't tell you that much that's useful in the real
> world. but it will tell you how many concurrent sessions you can
> establish (which is almost purely a function of the amount of ram for
> that data strcture) through the DUT and how quickly you can establish
> them (which may vary with your rule base but will almost certainly never
> get better). vendors are mostly honest about that becuase you can
> trivially replicate that test even with fairly low end equipment on all
> but the biggest stateful devices.
>
> > Also note that most vendors don't perform negative testing,
> > astonishing though that may seem.
>
> > -----------------------------------------------------------------------
> >  Roland Dobbins <rdobbins () arbor net> //
> > <http://www.arbornetworks.com>
> >
> > Injustice is relatively easy to bear; what stings is justice.
> >
> > -- H.L. Mencken