Ngh. I'm not really in the right mood for this right now; I think I got too worked up over UPnP. Ah, heck, I'll give it my best shot. :)
<quote> <quote> <dissect> <attempt to avoid stupid 10KB message limit> Paul Robertson wrote: > > On Mon, 8 Apr 2002, Mikael Olsson wrote: > > > (Or strip URG data, which is what a proxy usually would be doing ;)) > > Not really, the proxy would be using URG if it was necessary in its role > as a client. And the same could be argued about a stateful box, given fine-grained enough protocol definitions. Perhaps not relaying URG at the "exact right moment", but at least only relaying it to an application that can be expected to treat it correclty (FTP, telnet) which should be good enough as far as this particular issue is concerned. (Although I don't know of one that actually does. I really should get back up to date on what people are doing. And make a note of that idea.) > > Isn't there an interesting flip-side to this? That since the firewall > > needs to know about all of this (it being properly upgraded and > > professionally administered and all), it can also trigger alerts on > > these events? > > Perhaps. "Perhaps"? "PERHAPS"?! How do you expect me to be able to roast you properly on a measly "perhaps"?! :) > > I think my original question was more aimed at > > commercially available stuff > > [about the proxy cluster from hell] > The U2/multiple QFE solution was commercial, and Internet-facing. The > Linux/Open Source stuff was to firewall WAN links (proxy-to-proxy.) > I was sticking to my experiences fielding such things- and without > the enterprise license from hell, it gets expensive to go with the > commercial alternatives. Score one for stateful boxen where this is easier to do on a single box, and hence easier to to justify in a cost/protected value calculation? Or get done in the first place, since you already have the box? :) (Yeah, yeah, I know the comeback: stateful boxes also have the potential make a much better mess of one's proverbial foot when mishandled.) > > [on open source] > > you also trg gb or fpnerq fuvgyrff ol fbzr crbcyr'f (ynpx bs) > > pbqvat cenpgvprf. > > FWIW, I'm more scared by what I've seen out of vendors. Point well taken. No project is immune to stupidity. Scratch that particular discussion. It doesn't belong here. So, in the completely general case, my above point only applies to hardware cost. Question: I believe you've had the chance to go hands-on in real-world situations with more firewall makes and models than I have. In my opinion, network segmentation (physical interfaces) is easier to do on stateful boxen than proxies, generally speaking. Am I just way off base here? (Or is there simply a few choice exceptions to this rule?) Oh yeah, I just ran across this from you in another subthread that I've neglected. I'll just quote it right here: > 1. No need to pass DNS to all the clients, eliminating resolver attacks, > DNS tunneling, etc. Since when is passing raw DNS to all the clients a necessity in a filtered environment? (And doesn't DNS tunneling work just as well through a cacheing resolver?) Unless, of course, you mean the (not so common any more?) case where all internal clients are configured to access the outside world through "real" proxy mechanisms rather than configuring your proxy firewall to be transparent to the inside. > 2. Ditto ICMP without breaking unreachables, etc. I'm not quite following you here. Unless of course you're talking about a transparent proxy doing some ICMP error magic that I'm not familiar with, in which case you just invalidated your previous point :) > 3. IP transport layer issues such as the old URG pointer stuff in Windows > products that are unknown by the designer don't get to kill all the > "protected clients." Ooold! You need to give me something better! :) > 4. Fragment overlap attacks and attempts aren't handled inconsistantly by > different "protected" machines since they're all handled by the proxy. (Warning: generalization based on what I've designed myself. Again, I should probably go do more testing with current makes and models.) Don't most of the "recognized" SPF vendors (pseudo-)reassemble and reorder properly by now? > 5. No need to worry about sequence number preditiction attacks for > thousands of clients, just one host. Hmm.. I realize that the following has a very real potential of making me look like a marketroid. I apologize for this up front; I just don't know of another example. We offset all sequence numbers by random numbers generated by the Yarrow PRNG. I'd say that this is an order of magnitude better than what general-purpose TCP/IP stacks in general do. (OTOH, maybe this isn't a very common think for SPFs to do.) > 6. Potential to "fix" contetent and protocol issues at the proxy > instead of normally having to do so at each individual client. Score one for properly ALG-enabled firewalls (and I'll readily agree that grepping for strings in raw TCP isn't "properly"). This all given a responsive enough vendor, of course. (Or the possibility to roll your own; score one for open source, for giving people the possibility to shoot themselves in the foot rather than having a vendor do it for them :)) > > I'll try to stay away from evangelism and flames if you > > do the same, mkay? :) > > What fun would that be? ;) Uhm. You got me there :) -- Mikael Olsson, Clavister AB Storgatan 12, Box 393, SE-891 28 �RNSK�LDSVIK, Sweden Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05 Fax: +46 (0)660 122 50 WWW: http://www.clavister.com _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
