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

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

> > code can have access to low-level info, it can live in userland, and it
> > removes
> > attacks against the gateway itself, while hopefully maintaining the same
> > lvel of protection for the inside hosts.

> Once again, can you provide how running in user mode stops attacks?  I'm
> sure the Web server people would be happy to hear it.

And do the web folks recommend that you compile your web server
into the kernel, or run as user nobody?

> It's got to do with the fact that everything runs with a capability and
> MAC (as well as DAC) level.  No authority to anything really means no
> authority, not "no authority until you get root."

Again, the B2 terminology does me no good...  I'm perfectly
willing to believe that there will be much fewer security problems
with a system that has been designed with that in mind, and I also
believe that some purposeful object seperation can help if
done right, but I don't believe that bugs will be non-existant, and
that the design will save you when they crop up.

> It isn't a participant in the conversation, that's why.

Why can't it be?

> > You're leaving out things like ping-of-death, stacks that believe
packets
> > with a from address of one of their own address, from addresses of
> > 127.x.x.x, etc... It hasn't been that problem-free.

> The addressing thing wasn't all pervasive, oversized packets were.

Doesn't matter.  It's still a problem, and should really be fixed in the
stack, no?
Your AG software should have to be bothered checking if packets appear
to have come from itself or 127.0.0.1.

> > Which is it?  Is taking the IP stack to userland "a trivial change"
> > or a "new piece of complex software?"  It helps greatly with the problem

> My IP stack is trivial, your SPF is a new piece of complex software,
> sorry it wasn't clear.

This argument only holds if you don't think that an IP stack
that has been decoupled from the OS is a type of SPF.
If you believe they are, as I claim, then you apparantly think
an SPF that has the logic of an IP stack is trivial to implement.

> > Not infinite, just a really big finite number :)  Like, to prove there
> > isn't a problem (without proving the source code is correct) I'd
> > want to see 2 raised to the power of the number of bits possible
> > in some maximum number of packets.  A daunting proposition for
> > any gateway software.

> That assumes that any packet can cause a problem, where the scope of
> risk is really about sizes, fragments, and source and destinations, no?

I don't really think the problem is that hard, no, but that's what it
would take to prove correctness.  I don't think we really know what the
total
scope of risk is, or someone would have likely written a stack with
that in mind already.

> > It would need to sanity-check the data, just like stacks should/do now.

> Again, wouldn't there be much more gain in sanity checking a stack,
> since that would also help the application servers and clients?

There will always be a need for good stacks... But for a gateway,
if I could have anything I want, I'd like a really good IP thingy
in userland.

> I'm sorry, an application *does* know that the URG flag is set in the
> conversation (how else would telnetd recognise it?), and it normally
> *doesn't* need to pass it because it's specific for the current
conversation
> in most instances, and it's an endpoint,

I should be more careful... It knows it got urgent data at some point,
but has no clue about which packet it arrived on, what else was in that
packet, was it fragmented, etc..  All it knows is that it has some data
in the urgent buffer.

> The SPF folks have to
> know if the particular applaction needs to handle the URG pointer, in
> advance as do the AG folks, however the SPF folks don't know by default
> if it's a good or a bad thing, and hence the blockage by most current
> implementations by defaut.  Now lets say there's a similar bug in NT 5.0
> by the PUSH flag... AG wins.

Or maybe it passes it because it didn't know ahead of time that it
shouldn't
have, or maybe your AG goes down.

> The same thing, I'm just able to tune how long I'm in SYN_RECEIVED,
> FIN_WAIT, FIN_WAIT2, etc.

So your point was that you've tuned the timers in such a way that the
number is packets it would take to SYN flood you completely is the
same number of packets it would take to fill your pipe?  Are you
able to keep them tuned if you get a much larger pipe?

> There's your preidcate, I don't wait two minutes, and I don't know any
> users who'd wait that long for a connect to a site.

Two minutes is a bit long, but I get some really slow users with
modems on the other side of the world.

> My buffer space is allocated quite large, it was necessary to handle the
> traffic load alone, not even to worry about attacks.  Your site probably
> isn't on that scale, so I understand that you've not had to go through
> the exercise prior to seeing the SYN flood attack.  We saw it from
> normal usage well before the attack was rampant.

My web folks tell me we get something like a million hits a day..
It terms of bandwidth, it doesn't seem to be that much to me.  We never got
SYN
flooded, and I haven't felt a need to turn the feature on yet.  Performance
problems we
had weren't related to the start of the connections.

> > It's not too much work for an external box to maintain a table with
> > a millon connections waiting to finish handshaking.

> It's not too much for a Web server either FWIW.

HTTP connections or SYN connections?  From what I've
seen for a "fix" to the SYN flooding problem from vendors,
they don't come close.

> If it detects it as such, otherwise you've got the same resource issue
> in the state table.

It doesn't have to detect anything.  You can just set it to always
handle the three-way handshake for your server.

> Sending out RSTs is one way of alieviating SYN floods, and I mispoke, it
> certainly could do that.

If they're coming with the real source address.  The most effective SYN
floods use fake source addresses that don't have anything answering
on them.  Or do you mean sending a RST as a way for the attacked
OS to clear it's own buffers?


> If you pass encrypted traffic, you obviously aren't as worried about
> tunnels, therefore you probably won't accept my stance.

So you wouldn't consider using a VPN gateway that wasn't also
the firewall?

> Yes, and the http proxy has different info from the ftp proxy, log
> reconciliation isn't too difficult, and can easily be automated, proxies
> aren't IDS' and probably shouldn't be (fox guarding the henhouse.)

If I may read some things into others' statements... From another branch of
this
thread, it looks like there may be some neccessity to have the box that
reassembles frags also do some of the IDS.  When a traditional
(at least existing) IP stack reassembles weird frags, there isn't
any record that it happened.  It appears that the IDS' can't
effectivly watch for fragged attacks.

> It may or may not be worse than a DOS.  From my perspective it isn't,
> since external machines can't get inside unless they're tunneled, and
> I'm watching for tunnels.

It's impossible to build an automated system to recognize all
types of steganonography.

> You don't need state for any of that though, that's where I was missing
> something I guess.

The word "state" comes from (by my thinking) that the (currently
primitive) SPFs keep information about what went before, where
regular PFs don't.  I don't think that should limit you to writing your
SPF as a state-machine.

> This, of course depends on your policy.  In my current situation,
> anything going outside is for an external resource, and you won't make
> it to the DMZ coming inside, so you won't see leaky packets.  Perhaps
> you engineer your systems differently, but my layers and equipment don't
> mind if the user's AG leaks because it's not the exterior defense by a
> large margin.

But what if it's the gateway itself that has the leak, and not the machine
it's protecting?

> And how does running in user space stop this as an attack method?  If
> you're the user running the protection mechanism, then I don't *need*
> root, I just need your context, no?

It's a smaller compromise, that's all.  It may or may not be a major win
depending on your point of view, but I'd like to have it were it available.


                              Ryan