On Mon, 8 Apr 2002, Mikael Olsson wrote: > > Perhaps. > > "Perhaps"? "PERHAPS"?! How do you expect me to be able to roast > you properly on a measly "perhaps"?! :)
After the wire brush quote, I figured you'd have the ammo ;) > 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?) I think these days it's about the same degree of difficulty for proxy products that support multiple interfaces well. Back when I started with commercial products, I had as many token ring interfaces as I could stuff into an IBM 55L doing a bit of both (proxy and filtering) and never had a problem with rulesets (but I had a pretty static policy.) > 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?) If you're filtering without a proxy, the client needs to look up www.wirebrush.com to start its connection. In a (non-transparent) proxy situation, ONLY the proxy must resolve DNS, the client must simply pass the request to the proxy. > 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. Exactly. > > 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 :) ICMP unreachables to the external interface is much less dangerous than to every client. > > 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! :) Old, but still probably a default block in mainstream commercial products. It's illustrative of the transport layer issues surrounding many clients versus one client. > > 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? Reordering "properly" is OS dependent. That's why multiple overlapping frags are "interesting" IDS attacks. > > 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.) This is indeed not very common. > > 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 :)) Having had to do this once or twice, I put this one high on my list (fixing, not shooting.) That's why after having played with most of the commercial products, I still lean toward source-available implementations. Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact." _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
