> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 19 May 2000 7:37 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Firewall
>
>
> The key to deploying a proper security infrastructure is to know what
> each
> component is designed to do.
>
> STATEFUL INSPECTION
> Stateful Inspection firewalls can see everything a proxy
> firewall can see
>
> (layer 4-7) in addition they can match and prevent protocol-level
> attacts
> (Layer 1-3)
> more efficiently.
I think this is misleading. Protocol level attacks (ISO layers 2 - 4 if we
want to get picky) are _harder_ to mount on an internal system through an
ALG. A stateful filter may be able to prevent this kind of attack _faster_
but I'd hardly call it more efficient. You can mount stack attacks against
an ALG itself but it's supposed to be able to take that sort of stuff.
Realistically, a pure TCP/IP stack attack that leads to a remote root
exploit is kind of hard to believe in (although possible, yes).
> Drawback not application aware and
> require 3rd party
>
> filtration or services for protocol stream level scrutiny.
Well....not always. Cisco IOS FW and PIX do some application level
inspection and they don't use any third party hooks to do it. They are,
however, affected by a problem that is endemic to this kind of firewall -
you can trick them. Say you want to mount an SMTP attack using a bogus
command...normally the firewall would see the command and block the traffic.
If you break the data up into lots of packets, however, you can extend the
delivery of the command outside the window of data reassembly that is
possible in the box - net effect, command gets through. This is not a Cisco
problem - it's a problem with this _kind_ of firewall. Because they are only
passing the data through they can only look at a certain "window" of the
stream - after that they have to pass it through or they will run out of
time/space/storage.
> Best usage:
>
> Entry point
> barricade to protect public servers or DMZ due to speed, versatility,
> and
> ability to perform packet by
> packet analysis of current, previous, and next session state against
> your
> security policy.
SPF or Stateful Inspection boxes are okay provided that you know what you're
getting yourself into. ALGs are more secure in theory but my faith in the
individual proxies written for each protocol is pretty low. Personally I
think that there's a lot ot be said for using good stateful inspection boxes
at the moment because of the speed. I think (?) that the ipfilter stuff also
lets you bust some streams out to userspace for processing by a custom
proxy, should you so choose - kind of the best of both world. I know that
you can do the same thing with FW-1, for example, but current opinion seems
to be that the means for doing so is arcane and poorly documented.
>
> APPLICATION PROXIES
>
> Application - Layer Proxies can look at the protocol stream
> and inspect
> the
> stream for
> specific anomalies and application specific state detection. The
> drawback
> is
> that they can open up to protocol level attacks (Layer 1-3)
This is Just Wrong (tm) as covered above.
> and are
> very difficult to implement due to protocol & SW specific knowledge
> needed
> to customize a defence (i.e. ICQ, BACK ORIFICE etc..)
Absolutely. Gauntlet 5 had about a dozen more proxies than 4. v4 had about
the same number. I'd love to be corrected, but I suspect that most of the
new proxies are little more than plugs that pass traffic. An "Adaptive
Proxy" as mentioned by the original poster is even worse - only the setup of
the connection is really looked at and the rest gets dropped through to a
fast shunt.
> Another drawback
> is
> Operating System flaws and patches dependency (NT/UNIX).
No. Insofar as this problem affects any firewall it affects all firewalls
equally. If you run a FW on top of NT (for example) then everything that
comes up through the TCP/IP stack gets handled by the firewall. If the stack
is bad, running one or the other type of FW isn't going to make any
difference. There has often been rumour of this-vendors-firewall replacing
the TCP/IP stack completely. AFAIK this is bunk. A *nix firewall is much
more likely to be able to be able to rejig the kernel but I don't think that
any do (corrections? examples?). NT implementations Just Don't (lots
"harden" the stack by applying lots of relevant patches and fixes and
closing common holes). As a test, fingerprint your OS with nmap before and
after a FW install and see what it comes up as.
> and slow
> performance.
> Best usage: Backend firewall between your Stateful Inspection firewall
> and
> the
> internal network where your Database servers reside.
Yeah, I guess, but only assuming that you trust (or wrote) the proxy that
does the database access. I wouldn't just whack in Gauntlet, enable the
SQLNet proxy and sit back thinking "Ah HA! Hack me NOW you little
bastards!".
>
> A best of breed practice approach for each component in the area they
> were
> designed to
> to shine is always prudent.
Understanding the technology and knowing what tradeoffs you are making is
the key, IMO.
Cheers,
--
Ben Nagy
Network Consultant, Volante IT
PGP Key ID: 0x1A86E304 Mobile: +61 414 411 520
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
