Firewall Wizards mailing list archives
Re: Proxy 2.0 secure? (AG vs. SPF)
From: "Paul D. Robertson" <proberts () clark net>
Date: Tue, 7 Jul 1998 13:38:43 -0400 (EDT)
On Tue, 7 Jul 1998, Ryan Russell wrote:
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?
Yet running as nobody *still* has Web servers as the most exploited method of intrusion. Once again, running in user space won't stop intrusions.
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.
Bugs will happen, the design, except under the most generic of configurations can definitely save you when they crop up.
It isn't a participant in the conversation, that's why.Why can't it be?
Because then it's an application layer gateway, not a _filter_.
You're leaving out things like ping-of-death, stacks that believepacketswith 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.
My application gateway code gets to bind to a specific interface. Once again, to exploit the mis-addressed packet thing requires access to the MAC layer, and I don't engineer my gateway in such a way that it would work (unless you can compromise the router to the segment, but in that instance, "game over" anyway).
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 problemMy 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.
I don't. We haven't added additional state mechanisms or filtering at this point, we've simply moved the code to user space.
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.
Some people have, but then we know the scope of risk with X, and nobody's reinvented that wheel yet either. :(
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.
Well, sign me up for a "really good IP thingy", I can definitely use one of those. :)
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 currentconversationin 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 point is that as an AG, it doesn't *need* to know which packet was flagged as URG, it gets the reassembled TCP stream.
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.
No, as an AG, it won't pass it unless the application was made to do so explicitly. Once again, I'd rather have the AG go down than the supposedly protected machines, which is the exact scenerio with the Microsoft URG bug, except that Unix based AGs didn't go 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?
Larger actually, and yes, so far.
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.
I'd route them to a server that handled slower connections based on their AS probably.
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..
That's why you've not hit the problem. That's not a significant load, and most of the stacks are fixed now anyway. Best problem to date: Stack taking too long to assign the next available socket because it was linear, and the connection was timing out before it could walk the serial list. Whee, IP can be fun...
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 also depends on the nature of your traffic, not just the volume, some sites don't have a large number of images, or are very interactive, slowing down the user populace.
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.
Both. Depends on the vendor and your hardware.
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.
Moving the millions of pending connections doesn't absolve you of the problem of handling them, it just puts it somewhere else.
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?
Both, syn flood detectors can spoof RSTs to clear a host so the host can be dumb.
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?
Nope, I certainly wouldn't. I'm not a VPN fan, so you could truncate that at the word VPN though.
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.
I'd think it more efficient for the border routers to reassemble frags, there shouldn't be a reason for an internal traffic domain to accept external fragments IMO. Since an AG gives you that functionality though, it seems to be an adaquate solution.
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.
Yep, it's impossible to build an automated system to recognize all types of *anything*.
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.
It keeps state, it's a state-machine, no?
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?
Doesn't matter, it only leaks onto DMZ-like subnets with screening routers, so unless you've got physical access, or compromised a router the leaks don't go anywhere.
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.
I'd agree to less deep, but not smaller. Since root would give you an easier path to ensuring continued compromise, whereas the filtering context would just give you carte blanch for the duration of the initial compromise, and/or as long as it took to get root. 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
Current thread:
- Re: Proxy 2.0 secure? (AG vs. SPF), (continued)
- Re: Proxy 2.0 secure? (AG vs. SPF) Paul D. Robertson (Jul 03)
- Re: Proxy 2.0 secure? (AG vs. SPF) Ryan Russell (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Paul D. Robertson (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Marc Heuse (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Ryan Russell (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Paul D. Robertson (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Bennett Todd (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Ryan Russell (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Paul D. Robertson (Jul 08)
- Re: Proxy 2.0 secure? (AG vs. SPF) Ryan Russell (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Paul D. Robertson (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Joseph S. D. Yao (Jul 08)
- Re: Proxy 2.0 secure? (AG vs. SPF) Ryan Russell (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Bennett Todd (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) tqbf (Jul 12)
- Re: Proxy 2.0 secure? (AG vs. SPF) Ryan Russell (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Bennett Todd (Jul 07)
- Re: Proxy 2.0 secure? (AG vs. SPF) Ryan Russell (Jul 12)
- Re: Proxy 2.0 secure? (AG vs. SPF) Paul D. Robertson (Jul 12)
- Re: Proxy 2.0 secure? (AG vs. SPF) tqbf (Jul 12)
- Re: Proxy 2.0 secure? (AG vs. SPF) Ryan Russell (Jul 12)