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

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

> > AGs are completely vulnerable to problems in the lower layers
> > of IP stacks.

> No. A-G's are completely vulnerable to problems in their own IP stack,

Thats what I was trying to get across.

> but completely invulnerable to problems in other IP stacks.

That's going a bit far, but it's more true than not.

> Packet filters, on the other hand, have reduced vulnerability to direct
attacks on their own
> IP stack (because they have less of a stack, see Bellovin's principle)

Agreed,  If they do it right.

> --- but they have increased vulnerability to problems in other IP stacks,
> because they are allowing remote hosts to communicate directly with those
> stacks.

I disagree with this assumption.  Current SPF implementations do this.  It
doesn't mean someone couldn't write a better one.

> It is valid to assume that the IP stacks of end-systems are less secure
> than the IP stack of the firewall. If nothing else supports this
> assertion, we assume that there are (or will potentially be) multiple
> different IP stacks on the network, each of which has it's own unique
> bugs. One stack is more secure than many stacks; all stacks have bugs,
> general-purpose stacks have more bugs than hardened stacks, and it is
> easier to manage the security of one centralized piece of code (the
> firewall IP stack) than the security of distinct programs from multiple
> vendors.

Agreed.  Pretty much why you want a firewall to begin with.

> A well-designed proxy server does not allow *any* external network traffic
> to reach the internal network.

I assume you're speaking of up to layer 3/4?

> Instead, it completes all interactions
> between the inside and the outside, relying on the internal machines only
> to provide the actual data needed for those connections. Internal machines
> only receive traffic that originated from the proxy server, and we can
> thus assume that, at least at the low level of TCP/IP, that traffic is
> safe.

If you completly trust the IP implementation running under the AG, yes.

> Packet filtering firewalls work by allowing *some* external network
> traffic to reach the internal network.

If you're still speaking of up to layer 3/4, it wouldn't be that hard to
write a SPF to redo all that info.  SPFs that do NAT already do
much of it.

> Security is improved by interposing
> a packet filtering engine that attempts to make a determination about the
> security of each packet. Stateful packet filters simply support this
> reasoning by considering each packet within the context of a network
> traffic stream (a TCP connection, for example). Internal machines only
> receive traffic from the outside world, and we cannot assume that any of
> that traffic is safe.

Most SPF implementations currently allow a lot of the original reply
through.  This is appropriate for some protocols, and obviously
not for others.  An SPF can be written to strip off as much as you like.

> The choice between application-gateway and packet-filtering firewalls
> comes down to this simple issue: we can decrease the exposure of
> end-system IP stacks by increasing the exposure of the firewall IP stack.

So... if there was some IP-layer root compromise was discovered, the
machine running the AG would get compromised.  For a bad
SPF gateway, some inside machine might get compromised.  Neither
one sounds great.  So... you'd want an AG with a really good IP
stack, or an SPF with a really good IP handler?

> The reason that application-gateway firewalls are more secure than packet
> filters is that it is easier to maintain the security of one stack
> (especially when it's well-understood that it's pivotal to the security of
> a whole network, and especially when it is specifically designed for
> security) than it is to maintain the security of many stacks.

An SPF doesn't have to know how to deal with every IP stack it protects.
To get the equivalent protection of an AG, all it has to do is emulate
the behaviour of a good IP stack, like the one you hope your AG is running
on.

> There are application gateway firewalls that rely
> entirely on general-purpose vendor IP stacks. The TIS firewall toolkit is
> a good example. Naturally, a firewall that rides a standard stack is
> vulnerable to attacks against that stack. Indeed, it is probably true that
> an application-gateway firewall riding on, for instance, the Solaris
> TCP/IP stack is LESS secure (considered as a whole, implications to the
> internal network included) than a stateful packet filter.

> Of course, the response to this point is "So what?". I can design a
> stateful packet filter that won't perform stateful inspection of IP
> fragments, instead passing them directly through and assuming them to be
> safe. Does this mean stateful firewalls are insecure? Of course not. It
> simply means that it is possible to design a bad stateful filter, which is
> an obvious point.

So.. an SPF may be better than an AG running on a bad stack
(my original point) and bad SPFs can be written (like the ones
currently on the market.)  No argument there.

> While it is true that, as a practical matter, we must consider the actual
> implementations of A-G and filter firewalls when discussing their
> security, and, in light of that consideration, the stateful filter market
> may very well have a better track record than the A-G market (I doubt it
> does, but it's possible),

It doesn't so far.

> the point I am making is that, by design, A-G is
> the more secure approach.

I disagree.  I won't argue that you couldn't easily buy an AG right
now that would be better than any SPF (that I'm aware of) that
you can buy right now.  I do believe the SFPs can provide more
comprehensive security when done right, and I expect to see
the market reflect that in the future.

> In other words, if you compared the best A-G to the best stateful filter,
> the A-G would be conclusively more secure.

I disagree.  I haven't seen many great AGs, and I know for sure I
haven't seen any really good SPFs.  The comparison can't be made
presently, as I doubt "the best" exists yet.   As mentioned above,
if you change that to "best on the market right now" you're probably
right.  The basis for my conviction is that SPFs have access to
more of the data, and therefore could make better decisions.  It
remains to be seen if they ever will.

> Security isn't the only issue. Performance is a major issue. The fact is
> that it takes more code to perform high-level proxying than it does to
> evaluate and filter network traffic. Stateful filters are faster than
> proxies (right now, significantly so); this speed comes at the expense of
> a design goal (minimize exposure to external traffic).

This is a result of current SPF vendors doing a sloppy job.   If you
write a SPF filter to do the same job as a good app proxy, it will
likely take as much code.  The SPF may be slightly faster still,
as it would have a little less overhead.  At that point, the speed
advantage would probably be negligable.  Speed is irrelevant to
security, anyway, except where it causes PHBs to force you to
pick weaker security in favor of speed.

> On the other hand, a stateful filter is vulnerable to fragmentation
> attacks designed to confuse traffic analysis as to the "state" of a
> reassembling fragmented packet. The stateful filter must either block all
fragments until the complete packet arrives (in which case the firewall is
actually proxying fragments), or else allow fragments to pass without
knowing what future fragments will arrive.

Nothing wrong with SPFs doing reassembly.  No, it's not doing "proxying"
by most people's definition that I've argued with before.

> If an attacker can find an
> exploitable inconsistancy between a vendor IP stack on the internal
> network and the stateful filter, she can slip arbitrary fragments through
> the filter.

With a bad SPF, sure.   Again, I claim that SPFs can do as much, or more,
than "real" IP stacks.  Heck, it would be pretty easy to pick a random
number
of bytes out of the datastream, and buffer outside packets until you had
that many, and then make a new packet to send to the inside machine.
Somewhat similar to how an AG behaves.

> We've already seen one example of this attack --- the Windows NT "start
> reassembly at offset=(n != 0)" bug, which caused NT to reassemble invalid
> fragment streams. No A-G firewall was vulnerable to this attack, because
> A-G's don't pass fragments.

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

> This attack was a recent discovery, and I have
> seen no literature (our IDS paper excluded) that explored the
> ramifications of this type of attack.

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?

> In my opinion, supported by months of experience expirimenting with
> precisely this issue (in the context of intrusion detection), it is
> unwise to assume that the exact same underlying problem won't resurface in
> TCP or stateful UDP traffic.

It's there now.

> A-G's won't be vulnerable

Just the firewall machine itself, and not machine behind it?

> , but the vulnerable
> stateful filters will be, and in the worst possible way; attackers will be
> able to bypass the firewall as if it wasn't even there. Is this a risk you
> want to take with your network? More power to you.

Not particularly.  Might be a good reason to wait before deploying
a SPF firewall.

> > It's a matter of how you like to do your firewall software.  SPFs could
> > do it all in one piece.  AGs do it in at least two pieces, and if the
> > AG comes with it's own IP stack, then the vendor has as much

> Issues of code integration have nothing to do with the security of
> firewall design approaches.

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

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
the transparency kits for the FWTK work?  (I'm not being facetious..
honest question.. I don't know myself.)


                         Ryan