On Fri, 12 Apr 2002, Mikael Olsson wrote:
> Fixing it would be a Good Thing(tm).
Yeah, but it would probably slow things a little, as running back up the
skbuff chain is quick, and if I recall correctly, you'd have to fix it in
something like four places...
/me resists peeking at the code
> Yes. Without broadcast, you can only DoS reassembly on a single
> host with those 300bps. OTOH, you can DoS reassembly on a hundred
> hosts with a 28.8Kbps modem. And that is with VJ header compression
> disabled >:]
I wonder if it's really better under 2k+patches, or if the threading is
just better?
> Actually, just making software developers browse the entire bug
> tracking system (assuming you have one, of course) before they start
> coding on a project would probably help in certain cases :)
In some cases, that would take *years*[1].
> > > Let's see now, what more mud slinging can I do.. Oh yeah, Barbie(tm)
> > > software with buffer overruns in it, pre-installed on proxies!
> >
> > Instantiation problem, not architectural
>
> Woho! I believe you just shot your own argument to pieces! :)
>
> Using the same logic, I hereby decree that rirel obk fuvccrq sebz
> $evqvphybhfyl_uhtr_sverjnyy_iraqbe [1] is, in and of itself, an
> instantiation problem! :)
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! :)
> > > And sendmail used as mail proxy! And BIND as DNS proxy!
> >
> > I haven't run Sendwhale in about 8 years, so I'll counter with Postfix as
> > an SMTP proxy. And I'll up your BIND to BIND 9 ("|grep vixie" returns
> > null.) and accept it on the box as a client, but not as a proxy-- since
> > that's not _necessary_ in a proxy-only scenerio. Now, let's take a
> > resolver problem, and see how many "protected" machines need patching in
> > each scenerio...
>
> Angh. I'm very close to just sending you that beer and be done
> with the pain, but, damnit, not just yet. :)
>
>
> Here's another go at an abstract reason why I believe SPFs are
> better firewalls than proxy firewalls.
>
> Of course, first of all I must agree with one of your earlier
> points: for 95%+ of all installations, using just one "firewall box",
> (properly coded of course) it won't make a difference either way.
> What we're talking about here is "the best security available",
> short of installing an A-1 firewall.
>
> I also assume that chaining an SPF with a Proxy firewall is out
> of the question, since that invalidates the topic, and we
> wouldn't want that, now would we? :)
WE wouldn't, but I'd guess that maybe 15,000 others might just vote for
that option ;)
> Now, I believe that given the (relatively, as compared to L7) low
> complexity of L3 and L4 headers, there are only so many possible
> vulnerabilities. I believe that a well-designed [2] SPF covers
Ah, this is the major flaw in your thinking...
> enough of the possible vulnerabilities (and certainly the known),
> that, in these layers, there is no "real" difference in the
> protection that a proxy firewall affords compared to an SPF. [3]
(I see no footnotes)
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 think we all agree that segmentation is a good thing.
> Segmentation is hard (maybe too hard) to accomplish when:
> - your proxy won't forward necessary protocols.
If we assume circuit-level relays (a la' plug-gw, then that goes away,
without them, we could always assume a stronger deny stance ;) ))
> - And let's not forget routing problems. How many proxies support
> lifting a host out from its LAN and placing it behind another
> interface, without restructuring your IP plan - heck, without even
> touching the IP config of a single host?!
> (Yes, I assume that you've already got boxes scattered across
> your available IP range; not that you have several ready-made
> subnets sitting around just in case you need to create another
> segment some day. I know no admin that has. :))
We had spare _routable_ space reserved at the last company I was
at, but I'm puzzled as to why you think a host route doesn't work on a
proxy server?
> - 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.
> Now, as to internal boxes.
> Internal workstations, as we all know, need to be kept on a tight leash,
> considering who's driving them, who's written the OS, ... whatever.
> I agree fully that their activities need to be
> 1) Restricted on a port/protocol basis. Any dumb filter can do this.
Every dumb filter requires DNS passed to every client.
> 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- you
can't mix and match pieces of an SPF on a per-protocol basis.
> <marketroid warning> (again!!! *sigh* ANYONE with a good working
> knowledge of other SPFs is VERY welcome to
> chip in any time now!)
> Said public servers, and also relays/proxies are probably
> sensitive to traffic overload, which can result in (expensive)
> DoS scenarios. I can name at least one SPF vendor (modesty bids
> me not name the company ;)) that has implemented traffic shaping
> (also with packet rate limits) on the assumption that traffic
> shaping is not only a "feature", but also a valid grab at
> protection from resource exhaustion attacks, and is best done
> at the (multi-legged) firewall itself in order to be able to
> apply said shaping to _all_ flows that need it.
> </marketroid warning>
Traffic shaping and rate limiting can be done with a proxy (though I'm not
familiar with any implementation that does it.) But it's not really an
application layer problem, so it's best left to lower-level gear. That
also makes the firewall simpler ;)
> > I'll counter with Postfix as an SMTP proxy. And I'll up your BIND
> > to BIND 9
>
> Now, given how you describe your set-ups, I'd venture to state
> that my ideal firewalling environment is probably very much the
> same as yours, the difference being that I describe it as centered
> around an SPF with helper relays/proxies, while you call a
> carefully selected collection of relays/proxies "a proxy firewall".
Sure, and my firewall implementations always include some sort of packet
filter (preferably with state)- generally IPFilter/NetBSD behind
non-stateful router filters.
> Yes, you are 100% correct for the internal traffic case if one uses
> the original meaning of the term "firewall": a collection of systems
> that enforces a security policy. I do believe however that we've been
> using the popular meaning of the term "firewall" so far in this topic.
Right, which is how I've been debating the topic.
> Now you're welcome to rip this apart :)
Moi? Rip? ;)
Paul
[0] Really, check again[2]!
[1] Not that that would be a necessarily bad thing in those cases.
[2] There was no [0].
-----------------------------------------------------------------------------
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
