Ben Nagy wrote:
> > -----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.
Perhaps, but it does so at the expense of higher layer processing and OS
overhead, while a stateful inspection engine hits it below the Kernel below the
network layer analyzing every packet before it hits the network driver.
>
> 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.
Please - do not confuse the PIX product with that of a compliant stateful
inspection device...
> 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.
Hence, supports my point "not application aware and require 3rd party
filtration or services for protocol stream level scrutiny."
>
>
> > 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.
ZZZZZzzzzzz.... Is that your final answer? No crazy Ivan's - Agree/Disagree?
>
>
> >
> > 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.
Intrinsic to the ALG is the layer where it sits - hence as I'm sitting above
the kernel/OS/ layer 3 + I'm
subseptible to all attacks thereof.
>
>
> > 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.
Stateful inspection (as stated above), even CheckPoint's bloated software
flavor of a FW, occurs at the kernel space -BELOW an even MORE bloated NT O/S.
> 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!".
Plosives not welcome...
>
>
> >
> > 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.]
Ciao!
Jennifer
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
