Paul Robertson wrote:
>
> On Thu, 11 Apr 2002, Mikael Olsson wrote:
> > Then AGAIN, linux machines deliver all fragments "backwards",
>
> Yep, the stack is um..."quirky" in behaviour. Fixing it isn't
> easy either.
Fixing it would be a Good Thing(tm).
When I first realized what the Linux IP stack was doing, I ...
well, let's just say that the wire brush quote was composed of
mild language in comparison. And short. Very short. And didn't
involve nearly as many instantiations of the phrase
"Happy Hacking".
> > By the way, did you know that you can DoS fragment reassembly on an
> > entire LAN of NT4SP0--5 machines (I believe Win2K without servicepacks
> > too) through the bandwidth equivalent of a 300bps modem and still have
> > enough bandwidth for a (laggy) IRC session? :)
>
> Hmmm, I assume broadcast addressed frags?
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 >:]
> > > [on proper software design]
> > > That's true of anything that may see duress, however your "if" isn't even
> > > close to the norm. It'd be interesting if all the firewall vendors
> > > published known bugs/kloc specs for their development teams.
> >
> > "For their development teams to see" or "for anyone to see"?
> > (And what's a "kloc"? :))
>
> "For anyone to see," and thousand lines of code.
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 :)
> > 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! :)
> > 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? :)
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
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 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.
- 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. :))
- 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.)
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.
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!).
<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>
> 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".
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.
*phew* This mail has taken far too long to write. I feel like there
might be a couple of points that I should have added, but I'm too
tired to think of them right now. I need to get some sleep, lest I
put myself in a situation where I won't dare touching security-
sensitive code tomorrow.
Now you're welcome to rip this apart :)
/Mike
--
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
[1] Interestingly ironic rotism in the end there, given country
of origin.
[2] No, you don't get to tell me that there are many examples
of not-so-well-designed. Those were instantiation problems,
remember? :)
[3] I foresee much and heated discussion on this point. Don't
disappoint me now. (And anyone with a valid point is warmly
welcome to chip in :))
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
http://lists.gnac.net/mailman/listinfo/firewalls
