Hi Mouss,
[...]
> My point was that one shouldn't use problems discovered in one product
> to _incriminate_ all products.
Well, nobody wants to incriminate anything or anyone. I am just stating
that software can and does contain errors. Even OpenBSD does that
sometimes. And I am stating that having two firewalls to redundantly
enforce your security policy is more secure than having a single
firewall.
[...]
> The fact that humans are prone to errors has never been a justification to
> anyone's bad actions, be them bugs, crimes, or anything.
True. Check Point is to blame for the bugs. So would be CISCO if bugs
were found in PIX. Or NAI. Any vendor. But what does this have to do
with our discussion? This still does not mean that Check Point's
engineers are worse than any other vendor's engineers.
> Fragmentation problems? the problem is discussed in RFC 1858,
> which dates to October 1995. why did these guys not read this
> public document. because it is not under the GPL? Com'on.
> (They should take the example of openbsd guys, no?)
The Linux people had very well read that RFC. That's why they made the
mistake. The RFC does not explicitly cover the situation where tiny
fragments are used to overlap port information. It only covers the
situation where you would overlap TCP flags. Had they thought about the
problem themselves, they might have done it right.
[I suggested to use two lines of defense.]
> will this solve the s/key problem that you found? clearly no.
Oh, it will most definitely mitigate the problems with that. Imagine
that you unload the security policy of the FireWall-1, then you still
have the first line of defence, i.e. the ipchains box running a current
version of ipchains. See, it also works the other way around.
> Setting up many gateways can certainly block certain vulnerabilities,
> but it can also open ones.
Hmmmm. Could you elaborate on this?
> While there are valid reasons to use multiple boxes, there is still a need
> to correctly chose the boxes. extraball...
I could not agree more with this. This would introduce further lines of
defence. But this has already been discussed and I absolutely agree.
[Having two lines of defence makes people buy more firewall products.]
> Surprisingly, this makes happy 2 categories of people:
> - firewall vendors
> - security consultants
> and to tell you the truth, when an argumentation makes someone happy, this
> makes me check it twice.
Ah... the ad hominem approach. Perhaps I should have stated from the
beginning that we do not sell any hardware or software, if that's what
is bothering you. We concentrate on independent reviews.
[...]
> I disagree. how will ipchains protect against the s/key attack?
See above. Moreover, as an administrator you might even be less prone to
accidentally ("Allow FireWall-1 Control Connections") let the world
access 256/tcp on your FireWall-1, since you would have to explicitly
allow it.
> another example? how would you protect against the cyberpatrol-related
> bug of Gauntlet by just setting up a FW1 somewhere?
By not allowing the Cyberpatrol port through FireWall-1 and thus protect
Gauntlet? Or if they root the Gauntlet box then they still have a
FireWall-1 to contend with?
> If one of the firewalls can be crashed if certain "seemingly legitimate"
> packets are sent, how do other boxes protect against that?
Well, this is way to general a formulation to be answered. Each and
every firewall passes datagrams that seem to it to be in compliance with
the configured security policy. I could as well ask you this equally
general question: "How can a single firewall protect against seemingly
legitimate packets which are in fact malicious packets in disguise?"
See?
> Again, multiple lines of defense help, but that's not all. One OpenBSD is
> bettere than 10 NTs.
Geez, let us please not get into OS wars here.
[...]
> bugs in software are admittedly inevitable, but the number and types of
> bugs can
> serve to measure the quality of the production process, the level of
> priority a
> company gives to the needs of customers compared to what it does to get
> benefits,
> and whether the company staff puts too much pressure on their developpers
> so that
> code is delivered in a bad state.
You would have to apply the same scrutiny to each firewall. Then this
statement may be true. And I still doubt that the same efforts, e.g. in
terms of man days, have been put into breaking anything apart from
FireWall-1. At least by public organizations. :-) I guess there are
still ugly things lurking in any firewall product.
Hmmm, reading through this again I get the feeling that the only one
incriminating anything or anyone is you: Linux developers, Windows NT,
FireWall-1. See, the ad hominem approach again. :-)
Cheers
-Thomas
--
Thomas Lopatic, TUeV data protect GmbH, [EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
