Hi Tomas,
At 12:38 01/09/00 +0200, Thomas Lopatic wrote:
> > second to none, breaking FW1 means that FW1 has problems, not that
> > firewalls have problems. It's never good to be fast to conclusions...
> > (If not convinced, ask your girlfriend).
>
>Well, she said that every piece of software has potential problems.
>Transferring your conclusion to the area of high availability, she
>added, would mean "Hey, do not use a hot standby machine. It is better
>to select hardware and software that will never ever fail to build the
>active machine."
She may be right, but this has nothing to do with the question.
I'v never said you should not select hw/sw well, nor did I claim that there
are software without potential problems.
My point was that one shouldn't use problems discovered in one product
to _incriminate_ all products.
>Of course this would be better - if it was possible. And that's exactly
>why we use redundancy in HA. And I still think that redundancy is also
>good for enforcement of a set of filtering rules, i.e. for firewall
>installations, no matter what product you choose.
Redundancy can't make a vulnerable product invulnerable. if you allow someone
to connect to a service, and this service is vulnerable to some attack, then
you can put thousand machines, thousand ethernet cards... this won't help.
redundancy is a feature that may or may not be desired/required, depending on
the site policy.
>Earlier this year John and I had a look at the Linux ipchains code and
>found a fragmentation problem. Then Dug, John and I had a look at
>FireWall-1 and found the suite of problems that we presented at the
>Black Hat Briefings. We did not yet look at Gauntlet, PIX or any other
>product. Still, since these products have been developed by humans as
>well as Linux or FireWall-1, they are prone to error.
The fact that humans are prone to errors has never been a justification to
anyone's bad actions, be them bugs, crimes, or anything.
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?)
>Hence, our
>suggestion is to use two firewalls, e.g. a filtering router and a
>FireWall-1, to obtain redundancy in the enforcement of your security
>policy.
will this solve the s/key problem that you found? clearly no.
>If someone finds an implementation bug that enables an attacker to
>circumvent your first line of defence, then you still have reason to
>hope that the vendor of your second line of defence did not make the
>same implementation mistake. This will give you the time you need to
>either work around the bug in the first line or obtain a vendor patch
>for it. Otherwise the attacker might be sitting right in your internal
>network, before you have had a chance to fix your firewall.
Setting up many gateways can certainly block certain vulnerabilities,
but it can also open ones.
While there are valid reasons to use multiple boxes, there is still a need
to correctly chose the boxes. extraball...
>Of course all this really depends on what your needs are. If nobody is
>particularly interested in breaking into your network, you will be fine
>with relying on one component. However, if you have to face attackers
>that are willing to get to know the firewall which you use by means that
>go beyond reading the manual - e.g. by reverse engineering it, which is
>not that hard after all - and hunt for vulnerabilities, then you might
>be better off if you have a second line of defence and you might want to
>accept the higher administrative cost.
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.
>Well, one could argue now that also the second line of defence can be
>compromised, since any piece of software probably contains errors. It
>possibly could, but the first line significantly reduces the risk. The
>attacker is forced to get IP traffic through your first line of defence,
>which severely restricts his options of how he or she crafts his or her
>IP datagrams.
>And with these restrictions it becomes much unlikelier
>that he or she will be able to penetrate the second line of defence.
>Let us consider the example of an ipchains box with the fragmentation
>issue as the first line, and a FireWall-1 as the second line of defence.
>The attacker would then have to send malformed packets which get past
>ipchains, but which are dropped by the integrity checks of FireWall-1.
>Therefore, none of our presented vulnerabilities in FireWall-1 could be
>exploited. The same thing is true for the reversed order. The first
>line, now the FireWall-1, would perform virtual defragmentation even
>when our vulnerabilities are exploited and prevent the fragmentation
>attack from being mounted against the second line, i.e. the Linux box.
>Each line of defence has its problems but together they are quite
>strong.
I disagree. how will ipchains protect against the s/key attack?
another example? how would you protect against the cyberpatrol-related
bug of Gauntlet by just setting up a FW1 somewhere?
If one of the firewalls can be crashed if certain "seemingly legitimate"
packets are sent, how do other boxes protect against that?
Again, multiple lines of defense help, but that's not all. One OpenBSD is
bettere than 10 NTs.
>[...]
>
> > Finally, if the event shows that FW1 is vulnerable, then my recommendation
> > is o switch to another product, such as the Gauntlet (I don't work for NAI,
> > it simpy happens that I know this one better than others).
>
>I think it would be wrong to conclude from the issues with FireWall-1,
>that FireWall-1 is necessarily in any respect worse than any other
>firewall product out there. I believe that there still are and will
>always be implementation errors. In any product and any firewall. It's
>complex software that we are talking about and we are all fallible.
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.
cheers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
