2003-05-04, v keltezéssel Mikael Olsson ezt írta:
> > Also, PIXen are not just too suboptimal to be called firewalls,
> > but also for intranet firewalling you need a level of flexibility
> > you cannot achieve with a blackbox-style product, and with the
> > so-called market leader firewalls.
>
> You're raising a big stink here. Especially when you continue
> by touting a firewall that you contribute to yourself.
I was telling the truth. We have found that no useable firewalls
on the market, so we had to develop one.
Just check what you can do with Zorp -even with the GPL version-,
and other firewalls.
I'm sorry for being ahead of state of the art.
> People are running various types of "blackbox non-firewalls" in all
> kinds of scenarios, including hosting centers and other large-scale
> facilities quite successfully.
You are succesful when you are able to withstand attacks, not when
you are able to get the traffic through. Thank you, I know how the
average firewall admin responds to problems which cannot be solved
with his firewall. Opens everything. I have seen lots of setups in
this kind.
> > So prepare for a big work. We are doing it for five years, and have
> > at least another five years ahead. And we are not even multinational.
>
> "a big work"? Please tell me you're joking.
I an NOT joking.
>
> I don't think you fully realize the scale of what you are suggesting.
> You're mentioning "flexible OS base". This would suggest that they
> spend some unquantified amount of time tweaking it. You are also
> suggesting that they run application layer gateways for 150 servers.
I have seen application layer firewalls with saturated Gigabit legs.
But anyway, I haven't told to defend 150 servers with one firewall.
It would give too coarse grained protection.
>
> I'm thinking that one single ALG box isn't enough for a single choke
> point to a 150-server segment. You likely need more. Then we move on
> to segmentation. How many boxes can one reasonably assume that they
> have the time to care for and feed, not to mention tinker with and
> customize?
4 good people is enough for approx 80 _intranet_ firewalls. I emphasized
intranet firewall, because they tend to be more complex than internet
ones. I have yet to find an internet firewall with 12 interfaces.
Of course you need good people, and good tools.
> Those "blackbox-style products" that you so rapidly dismiss as
> useless will in many cases prove more valuable than any kind of
> home-grown solution. When something is too costly to maintain -
> in terms of money or time (often the latter) - to maintain, it
> doesn't get done. It's that simple.
If you do not know what you are doing, than do not do that, because
you will do more harm than good. It's that simple.
> We all know that installing and configuring MAC based stuff on a
> server raises the bar considerably. Hands up now: how many have
> actually had the time? And if you did actually find the time, are
> you sure you shouldn't have been spending the time required to
> correctly configure and maintain that _one_ server doing something
> else? Perhaps _several_ network/organization-wide countermeasures
> that, when taken together, would have done a lot more for your
> total exposure?
I don't know why do you came with this MAC stuff. Of course I had the
time. And after I have developed a scheme of configuration which is
broadly useable, it is only the matter of normal operation to use that
scheme. See, when we started to introduce CC, most of the developers
gave horrible quotes for writing a ST. After we took a two day workshop
introducing them into CC, they realized that we ask for doable things,
and the quotes were reflecting that. Go configure some MAC systems,
keeping in your head that you have to find a way with which the average
sysadmin can deploy it, and after the third system you will came up
your scheme.
> Here's a free clue: internal networking is quite a bit more than ssh
> and http. I don't even want to try to _guess_ the number of protocols
> in use in a network of this size. I could take a wild stab at the
> number of _standard_ protocols in use, perhaps, but the _legacy_
> ones ...? Is your advice also that they write their own application
> layer gateways for all these protocols? And continually reverse
> engineer changes to these legacy/proprietary protocols?
We can do a contest of "how many protocols do you firewalling,
and how many of them is protected in some way". I would win for sure.
Of course we maintain stringent rules about which protocols
are enabled in the intranet, but also the business is the first
so we also often get hard challenges.
> You _don't_ get to say "but Zorp can do plug proxies/stateful
> firewalling too!", because then you've invalidated your whole
> reasoning.
I could say that, because it can, but won't:)
Zorp has some general purpose tools which are useable in such
situations to mitigate risks further than your firewall can.
[It is outrageous anyway how some firewall wendors are laying about
the features of their firewalls. For some, the capability of "filtering
protocol X" means that they can pass the said protocol through the
firewall somehow, either with a packet filter or a plug, or some
horroristic approximations (see H.323 in PIX or in the Linux kernel).
For the better ones it means that they can control up to ten percent
of the features of the protocol. Pathetic. I would consider shameful
if we would deliver a proxy which cannot control all aspects of its
protocol and its documentation would not start with a warning about
that fact.]
--
GNU GPL: csak tiszta forrásból
_______________________________________________
firewall-wizards mailing list
firewall-wizards_at_honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Received on May 04 2003
Intro
