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

["Paul D. Robertson" <proberts () clark net>]

On Tue, 30 Jun 1998, Ryan Russell wrote:

> > > 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,

All of which I've seen have been DOS attacks.  Would you rather a DOS of 
one gateway, or random of the thousands behind the gateway?  I know 
where my druthers lie.

> 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.

Except that most people configure them to have their on-board management 
interface features or other native stack based services (such as VPNs in 
one exceedingly popular implementation) available, making both *them* 
_and_ their "protectees" vulnerable to transport and internetwork layer 
attacks.

> > --- 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 doesn't mean that someone can't (a) write a better stack for an 
application layer gateway, or (b) write an applicaiton layer gateway 
that does its stack stuff inside user space on a B2 OS either, no?
    
> > 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?

Well, unless they site security policy was way better than most of us 
are allowed to live with ;) 

> > 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.

Well, I'm not sure you need complete trust.  Trust for lack of bugs 
which would cause an intrusion, certainly.  Trust against easy SNPA's, 
probably, trust against fragmentation bugs, sure.  Trust against DOS 
attacks when IP itself is subject to them doesn't seem overly reasonable 
in an absolute sense.

> > 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.

At which point SPF gains nothing over a stable IP stack, since you're 
into the same ammount of complexity as an AG, and T&V of said 
implementation gets significantly more difficult.  State tables that 
include layer 3/4 information start getting pretty unwieldy to verify.

> > 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.

If you already know what to strip off.  It tends to look like "anything 
wich is explictly denied" as a stance, rather than "anything which is 
explicitly allowed".

> > 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?

I'd take the former over the latter any day, since the IP handler can't 
have worked out attacks at the application layer, wheras the IP stack on 
an AG is about security of the gateway, not its charges.

> > 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.

At which point, being an AG gives it no real advantage, and you're still 
minus application layer protections unless you intend to keep 
application layer state which won't be as easy to verify as the 
application itself.

> > > 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.

This, of course assumes (a) the SPF is well-written, and (b) the SPF 
doesn't need the same services to be as well written.  That means 
console or TTY-only access to the SPF, and no VPNs over IP, since both 
of those need to participate as an application layer service on the 
SPF.  Given both written to the same quality, I'll take the AG any day.  
Given a chance to verify a design and implementation, I'd much rather 
pour over the AG code, even if it does look like http-gw ;)

> > 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.

More comprehensive layer 2/3 security, sure, but application layer 
exploits are still the most popular, and it's very difficult to protect 
at the application layer in an SPF.  Heck, it's been plain amusing 
watching the SPF folks just try to block javascript.

> > 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.

The question remains if the lower level data poses the same kind of risk 
and if the stack can't evolve to mitigate that risk.  If it can, and I 
for one am convinced that it can, then I don't think you're getting any 
value for the complexity of an SPF versus the same quality AG, though 
the percieved need for new protocols may make the market go more towards 
SPFs, I don't think security properties will be the driving force.

> > 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.

I tend to agree with this, speed shouldn't be a factor in most good designs.

> > 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.

Much like plug-gw, it's transport layer proxying, but beyond nothing 
wrong with fragment reassembly, I think it's rather bad to expect an SPF 
not to do reassembly if its to have much security value at all for 
traffic which is passed (as opposed to the value it has for blocked 
traffic).

> > 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.

At which point the SPF has what value over an AG with a good stack?

> > 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?

DOS'ed, instead of random DOS'ing against various internal machines.  I 
know which one I'd rather (a) troubleshoot, and (b) be responsible for 
if I had to pick.  For most companies, which don't *need* the Internet 
every day to continue operations, my guess would be that the choice 
would be the same.

> > 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?

The problem as I see it, is that in the world of IDS, you have to predict 
how the host may view the packet and with N IP implementations that 
means N+ probabilities.  We go from "Is it an intrusion" to "Is it an 
intrusion if the host is running NT?"...

> > 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?

Right, which in a gateway that protects thousands to tens of thousands of 
mission critical machines is the lesser of two evils.

> > , 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

How does the SPF answering system calls give application layer protection?
How is a really well written SPF more advantageous than a really well 
written IP stack?  It would seem to me that the latter is much more 
effective since it could be deployed on the application client and 
server machines themselves as well.  

Not really trying to be facetious, I'm just curious as to why people 
propose SPFs can be well written and IP stacks can't, or why there's 
value to doing so for an SPF that wouldn't be more easily realized in an 
IP stack.  

> the transparency kits for the FWTK work?  (I'm not being facetious..
> honest question.. I don't know myself.)

I'm about to look at this, so I'll try to touch base after I grab the 
code.  Since they appear to be Linux mods, I can think of a few ways to 
do this, so I'm pretty interested myself.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () clark net      which may have no basis whatsoever in fact."
                                                                     PSB#9280