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

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

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

I'd rather have the gateway crash, too.  Certainly you aren't claiming that
someday, someone isn't going to find a way to push code onto a
gateway machine by sending illegal, manufactured packets?  Either
a bad SPF implementation or bad IP stack could suffer from this.  If
an AG vendor relies on the IP stack that comes with the OS, they can't
prevent it.  A really sharp SPF vendor could stop it, if they put enough
forethought into things.   Remember, I was originally using the NT
IP stack as an example :)

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

Not sure I'm following you... I think you saying that some SPF vendors
have "the worst of both worlds"  where they use SPF to gateway some
things, and AG for others?  You'll get no arguement from me that most
SPF vendors on the market now are very sloppy.  It makes it hard
to argue in favor of the SPF concept when most of the commercial
SPF vendors do the *minimum* they need to to get things to pass.

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

I guess that means that for an AG vendor to be able to truly do a good
job, they HAVE to write their own IP stack.  I don't know enough about
the B2 OS requirements to speak to that... but if the IP stack itself
still runs in something like a kernel, it doesn't help for low level
attacks.
What would really need to happen would be for the IP stack to run
in user space of a restricted user, as well as the AG code. That
means that the OS itself isn't handing out sockets, which is...
well, I guess that is my earlier definition of an SPF.

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

SNPA?  Define, please.

In reality, you can't completely trust anything, even if you
write it yourself.  Realisically, what you do is watch the lists for
problem reports, and patch things quickly, AG or SPF.

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

As I've pointed out in a seperate note which probably hasn't hit the list
yet,
you can get a little extra info about the packet that came in with
the SPF implementation than you can with the AG implementation.
I get a lot of people claiming that tables that maintain transport info
are too hard.  I haven't written an IP stack, but isn't that what they do?

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

Current SPF vendors do it the wrong way, described above.  AGs
are in the same position, though.  Well, their IP stack they sit
on, really.  They've just gone through the iterations needed over the years
to figure out what to pass and what not to pass.  The question to ask is
whether that logic learned from 20 years of doing decent IP stacks
can be translated to SPFs.  I haven't written either, so I'm not
qualified to comment.

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

I'm trying to show that an SPF IP handler can be equivalent to an
OS IP stack.  You can take a good HTTP proxy and slap it on
top of an SPF IP handler to the same effect.

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

Depends on how you want to track application layer state.  Using
a "stateful packet filter" doesn't mean you have to interface with
it with a state machine.  On the other hand, you could if you wanted.

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 ;)

How about an example?  Cisco routers can do VPNs.  Cisco
routers can now do secure TTY access.  Would you consider
those to be more like SPFs, or AGs?  I suspect Cisco is
not going to let you review their source-code, though.

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

Slap your favorite HTTP AG code on top of your SPF IP handler.

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

an OS IP stack has the same challenge as an SPF IP handler of needing
to do good data validation, and be able to handle new attacks, hopefully.
Realistically, either will fail to anticipate something, and hopefully your
vendor reacts quickly with a patch.  A possible security advantage of
an SPF is that it's not part of the kernel, and can live in user space.
Maybe that makes the unanticpated attack less serious.  The challenge
is to get a good SPF implementation in user space without screwing
something up that the IP stack vendors fixed 15 years ago.

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

This is a difference of definition.  I can see where the idea of
SPFs only handling one, whole packet at a time comes from.
That's not the definition I use, and not where the market went.

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

A long as it's just DoS, that's fine.  For an example where it's not fine,
look at the panix.com situation when the whole SYN flooding attack
thing began.  For any commercial OS or SPF, you'd be stuck waiting
for  a patch.   If you've got source, conceptually for me it's pretty easy
to see how to solve that problem in the SPF (that the SYN-flooded
machine is behind.)  But then, I'm a layer-1 up type of person.
Possibly for a OS down type of person the code needed to
fix the unix kernal would be as trivial.  My understanding is that it's
a fairly involved kernel mod.  Most OSes seem to have only bumped
the number of buffers up, not really solved the base problem.

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

Thomas Ptacek has done a lot more checking into this area than
I have, and he says that it's a really hard problem.  I'll take
his word for it until I can catch up on his paper.  I'd be willing to
believe
that this would be hard for traditional packet filters that can't change
the packet structure much.  If an AG helps because it rebuilds
the packet, then I ask if an SPF can't reassemble/rebuild/normalize
packets in much the same way to get the same protection.  I suppose
neither will help if someone finds someday that a certain IP stack
hands over root or admin if it gets a TCP connection with "xyzzy"
anywhere in the stream.

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

Real simple.  Take the AG code, and link it with a library that
makes it think it's running on the OS IP stack, when in reality
it's allocating table entries from the SPF rather than sockets
from the OS.

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

What sets me off is blanket statements like "SPFs are always less secure
than AGs" or "State tables are too easily corrupted."  People believe
this stuff.  A really good SPF can be written, and probably will someday.
If someone wants to say that Firewall-1 shouldn't be used because
of x,y, and z, I won't argue that.  Don't get me wrong, there are some
really good
AGs out there, with the vendor having the exact right attitude on what to
limit.
Having a barrier between IP stack and AG code, with good code for each,
is a really good model, is well understood, and is modular.  I won't tell
anyone to
not implement the best AG on the market in favor of some SPF solution if
the AG handles all the protocols desired.

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

Thanks, I'm curious.

                    Ryan