Re: Proxy 2.0 secure? (AG vs. SPF)

["Ryan Russell" <ryanr () sybase com>]

> And so on, and so forth.

> It will be difficult for us to discuss the tradeoffs between packet
> filtering and proxying if we cannot agree on definitions. Your definition
> of stateful filtering:

> > Know what the difference between an AG and an SPF is?
> > The AG allocates the socket from the OS.  The SPF allocates
> > the connection from itself.  If one wants to write an SPF that
> > answers the system calls that allocate sockets, you can have
> > all the security you like at the application layer, and get the extra
> > security available with a really well written SPF.  Anyone know how

> ... is very far removed from my definition, which is "a device which
> filters packets". The basic concern I have with your argument at this
> point is that much of what you suggest as an improvement for a stateful
> filter would turn the machine into a proxy.

> I understand that a stateful filter can reassemble fragments. However, by
> my definition, as soon as the firewall collects and reassembles fragments,
> and transmits the reassembled fragment, it has ceased "filtering" --- the
> firewall did not allow any external traffic through, but rather
> interpreted the packets itself and sent the internal hosts it's
> interpretation. This is a defining difference between a packet filter
> and a proxy.

If I may read a little into what I think you're trying to say....

As soon as an SPF does something like fragment reassembly
or buffering a couple packets, it's now a proxy.  All it's allowed
to do is look at one packet at a time, and forward it, possibly
using some flag it set based on previous packets.  Fair?
This is regardless of whether or not it uses the IP stack
of the host OS.

If that's the case, then there aren't any SPF firewalls on the market.
Any SPF firewall that wants to sell a copy has to handle FTP.  If
they want to handle FTP, then they have to be able to buffer enough
of the datastream to get and modify the port command.

If what you say is the case, then Checkpoint is making AGs
look really bad.

I still like my definition better:  An AG relies on a traditional IP
stack (good, bad, hardened, indifferent) and SPFs don't.
AGs allocate sockets from the OS, and SPFs don't.  AGs get
to take advantage of the properties of the IP stack (good or
bad) and SPFs have to create the same functionality themselves.

> Your concern with application gateways is that they have increased
> vulnerability to attacks against their own IP stack. This is a valid
> point. However, you must keep in mind that this vulnerability is a result
> of the fact that the A-G needs more code to function than a typical
> stateful filter. As you add more code to a stateful filter, to make it
> approximate normal IP stacks, strip off protocol data, or reassemble
> fragments, you make the filter more like a proxy, with all the attendant
> risks.

Yup.  The bigger the codebase, the better the chance you'll screw up.
Perhaps there is some advantage to being able to choose a weaker
checker if one feels the protocol warrants it, i.e. the equivalent of
a circuit-level proxy.

> Now, my concern with a firewall implementation doesn't linger too long on
> the security of the firewall's own IP stack --- not because this isn't an
> issue, but because it's a simplifying assumption for my research that a
> given firewall is implemented carefully enough so that it isn't vulnerable
> to direct attacks.

So you like the IP stack as an arbitrary abstration layer.

> If the security of the firewall machine itself is more
> of a concern to you than the overall security of the network with the
> firewall installed on it, you may have a valid reason to distrust
> application gateways, as opposed to simple stateful filters. Personally, I
> think the firewall's effectiveness at it's job is more important.

I'd like both, but if the firewall gets compromised, I'm totally screwed.
If one inside machine gets compromised, I may not be screwed
quite as bad.  If lots of inside machines get compromised, I'm
probably as screwed as if the firewall got compromised.  SPFs
will tend to be an all-or-nothing proposition.  AGs will tend to be
split along the line of IP stack problems on the gateway, vs.
bad protocol checking at the AG level.  Which is appropriate
depends on your risk assesment.  Currently, AG vendors
have the advantage that they've been doing it longer, and
the good ones seem to care about checking data better.

> Your argument continues with some poor assumptions, which I'll point out
> but try not to linger on:

> > So... if there was some IP-layer root compromise was discovered, the
> > machine running the AG would get compromised.  For a bad

> > An SPF doesn't have to know how to deal with every IP stack it protects.

> It absolutely does. Remember, a defining difference between filtering and
.proxying is that in filtering, original packets are forwarded to internal
> hosts. This forwarding is "guarded" by a filtering engine which attempts
> to make determinations about the implications of each packet. If the
> filtering engine does not know how an end-system will react to a given
> packet, it has a reduced capability to make conclusions about the security
> of the packet.

That's your definition of SPF.  I reserve the capability to rebuild
the entire packet as part of my definition of SPF.  None do this
well currently.  I think most people would call FW1 and PIX SPF
products (leaving out the AGs that FW-1 can also use) and
they can rebuild packets.

> There are two different outcomes of this problem: either the filter will,
> as a precaution, block any ambiguous traffic it sees, thus damaging
> connectivity by filtering legitimate traffic, or it will allow ambiguous
> traffic to be forwarded, thus damaging the security of the network by
> allowing packets with unknown implications to be forwarded.

Or rebuild the packets, or buffer until they get later packets.

> An SPF filter that does "the same job" as a proxy is a proxy. There is no
> way to do the same job as a proxy without becoming an endpoint in network
> communication (in other words, generating your own traffic to send).

It's quite possible to do the job of a proxy (if you define it as the
resulting bits on the wire) with an SPF.  Why not?

> > With a bad SPF, sure.   Again, I claim that SPFs can do as much, or
more,
> > than "real" IP stacks.

> I don't understand the logic behind this assertion. By definition, a
> packet filter does less than an IP stack. IP stacks have free rein to do
> whatever they want with traffic.

I phrased that badly.  What I meant to say is that a good SPF can take into
account things all the way down to layer 1, and up to layer 7.  So, an
AG can't make any decisions about forwarding a connection based
on stuff below layer 5 typically.  For example, take winnuke.  An AG
would automatically strip off the URG flag, and pass the data into
the protected NT box.  The NT box would be fine, since it didn't get
the URG flag.  The AG also can't record the fact that someone
tried to winnuke your NT box.  The SPF could.

> > But any AG running on NT with the MS stack was?

> No, even A-G's running on NT did not create this vulnerability. The reason
> this NT fragmentation bug was a serious security problem was because it
> allowed fragments to be forwarded through firewalls without having their
> security implications properly evaluated. Even on NT, an application
> gateway doesn't forward fragments. While it is possible to send an invalid
> stream of fragments to an NT A-G and have them reassembled, this does not
> impact the security of the network.

My question was:  Would the NT box, running the AG software, using
the default MS IP stack, crash?

> > I imagine the IDS vendors will have to start assembling fragments,
> > and checking for valid frag pointers.  Are you implying that they
> > can't, won't, or it's too hard?

> Yes. See http://www.secnet.com/ids for a 60+ page technical report that
> explains why we think it is "too hard" for a sniffer-based IDS to perform
> tasks like fragmentation reassembly accurately. Key point: there are
> pathological fragmentation streams which will be reassembled in two
> different ways by two different stacks. Again, exploitable inconsistancy.

I'll re-read it.  I only skimmed it before.  I can see you point about
different
stacks reassembling different ways.  From an IDS point of view, would it
only be "illegal" fragment streams that have the behavior of reassembling
deifferently on different machines?  If so, could the IDS always flag that
as an intrution attempt?  For firewall purposes, is there always a
"right" way to reassemble fragments?  If they fragments won't reassemble
properly because of someone diddling with the pointers, would it not
always be a good idea to drop those?

> > Then why does it matter if the security is in two seperate pieces..
> > IP stack and AG code, versus one piece, well written SPF?

> Because you are comparing apples to oranges, and confusing the comparison
> by putting it the context of an implementation question, which has little
> to do with this argument.


You seemed to indicate that some extra security was gained from having

this abstraction layer of IP stack and proxy software, as opposed

to a one-piece solution.  This appeared to me to be an implementation
      issue.

You've since clarified, and claim the if the SPF hangs onto a packet, it's
      now

an AG, so I can more easily see why you make the distinction.



                         Ryan