On Fri, 12 Apr 2002, Mikael Olsson wrote: > > [on reassembly DoS] > > I wonder if it's really better under 2k+patches, or if the > > threading is just better? > > It isn't a total system DoS. It just DoSes fragment reassembly. > The CPU load of the target system won't even increase a single > percent.
Right, but I was wondering if the frag reassembly code is now threaded where it wasn't before. > > Ah, but since in my case, the software wasn't proxy software, it > > doesn't count as part of the architecture, where as in your case > > it does! :) > > The barbiesoft URL filter wasn't a proxy? *boggle* :) Nope, it was a content filter sitting behind a proxy :-P > > > > in these layers, there is no "real" difference in the > > > protection that a proxy firewall affords compared to an SPF. [3] > > > > The proxy is the only client that needs patching in client-side issues, > > and the only place that needs content filtering in content issues. *Some* > > content issues can be negated with an SPF, but not all and certainly the > > range of client issues that can be fixed is significantly less. > > I was talking about L3 and L4 only in this paragraph. > And even when/if a problem is found in L3/L4 filtering/logic > on an SPF, the SPF is the only box that needs to be patched. Ah, but a firewall isn't just a L3/4 protection device, and clients aren't just L3/4 devices. The essence of "more secure" is "less places exposed to high risk." > Assume two boxes want to speak NetBIOS to eachother. (Yes, I know, > horrid. Let's assume that the server is a very stripped-down samba.) > > Assume box 1 behind if1 has IP 1.2.3.9, and wants to communicate > with hosts behind if2 with IPs 1.2.3.1--254 (sans .9 of course). > Tell me how a host route on _an available proxy firewall package_ > solves this. Absent the broadcast stuff, proxy ARP for the target victim and something plug-gw-ish should work just fine. I'm pretty sure I could write a "transparent" proxy that would include the broadcast stuff (and MAC target the broadcasts to the specific victim on the other end (SOCK_RAW is your friend.) I have zero experience with any available firewalls which cliam NetBIOS proxy support, so I can't say how/if they'd make anything possible- there's no way in hell I'd ever let it in/out through a firewall. If they work with subnets though, I can't see a reason they wouldn't work in a host-specific scenerio unless there's a broadcast issue- and most of that should be solvable with WINS or LMHOSTS unless there's something broadcasty other than name service about NetBIOS (it's been years since I had to support NetBIOS.) > Yes, I know, you can always get more routable space. Or rearrange > your IP allocations. But I've seen enough cases where people > DON'T segment their servers as much as they'd really like, just > because firewall boxes with rigid subnetting rules and poor > segmentation support functions puts the effort bar too high. Subnetting support is an OS function- ever since Solaris 2.6 the Variable Length Subnet Mask problem hasn't been an issue for anything I can think of, and before 2.6 you could use a VLSM as long as it was for a local interface (which was your scenerio,) the route command simply didn't support them before 2.6. Once again, it's also possible to hyper-address a physical network with multiple logical networks. Since I don't know anyone sane who'd still be running a firewall on Solaris 2.54, I think you lose this one. :) > > > - And.. important.. speed. When you segment dozens of servers, they > > > very often still need to be able to talk to each other at high > > > speeds. (Think web server -> backend DB. Think backups.) > > > > Speed is the only point I'll readily concede. > > Hey. I just thought of another one: > - For many protocols, a thorough ALG is a very complex beast. Enough > so that at least _I_ don't want to trust it to be immune to > exploits that give you (partial) control of the machine it is > running on. > (Very good case in point: a content and virus scanning HTTP proxy.) > If I center my firewalling environment around an SPF with good > segmentation support functions, I can (easily) put such a box on a > separate segment and only allow required communication to and > from that box. With the (not poorly written) SPF sitting on > a separate box, I can be reasonably assured that said proxy box > won't gain control over the entire packet flow, or be able to > connect anywhere it damn pleases. If you're going to add additional boxes, I can proxy-to-proxy my ALG to a content inspecting thing on a different subnet as well. > > > [on the protection that internal boxes need] > > > 2) Analyzed on the application layer. > > > I believe that this is best done by specialized relays/proxies > > > (NOT! a proxy firewall with everything from a single vendor or > > > organization!). > > > > A proxy firewall doesn't have to be a single box, and a single box doesn't > > have to run everything from the vendor. For instance, ever since I > > started using Postfix in production (2nd Alpha version), for instance, > > I've ripped out the native SMTP proxy and replaced it with Postfix > > I still think that you're talking about the same thing as I. :) Yes, but the *important* point there is that with an ALG you can pick the BEST per-protocol gateway available. With an SPF, you're stuck with whatever protocol support the vendor chose (e.g. I could put Raptor's SMTP gateway on a Guantlet, while you couldn't put Checkpoint's SMTP stuff on a PIX.) > > you can't mix and match pieces of an SPF on a per-protocol basis. > > I believe this is a good quality in SPFs. I want my "traffic control > filtering box" to be compact enough that I can assume that it does > what it is told and nothing else. If equipped with login shells, > multiuser environment, compilers, etc etc etc, that you'd need for > installing postfix on it, this is no longer true. Not by a long shot. I don't need a compiler, or a multi-user environment to install an ALG on a target host. I could use the same sort of maintenance and configurations an SPF uses, but the point is moot- I don't *need* remote management on either type of firewall, so the exposure is able to be limited to be pretty-much nil (even staying away from B2ish ALGs, which are a whole new set of fun, and provide an interesting level of segmentation that doesn't happen in SPFs!) > > Sure, and my firewall implementations always include some sort of > > packet filter (preferably with state)- generally IPFilter/NetBSD > > See? :) What, that hybrids are a solution? That I don't rely soley on SPFs? > > [0] Really, check again[2]! > > [2] There was no [0]. > > *bzzt* brain stalled.. *bzzt* infinite loop.. *bzzkktt* *boom* 's watcha get for including footnote references without including the footnotes :-P 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
