Hi,
[...]
> 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."
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.
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. 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.
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.
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.
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.
[...]
> 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.
[...]
Thanks
-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.]
