Frank,
I do agree with you. But it is possible to minimize the hazard as
identified by you.
On Fri, 29 Aug 1997, Frank Willoughby wrote:
>
> I am constantly amazed at the number of companies (who are otherwise
> reputable) performing a Remote Security Testing of firewalls, or
> systems across the Internet.
>
> This is *very* dangerous. IMHO, any who utilizes this service runs
> a *significantly* greater risk of having their firewalls (or systems)
> penetrated than if they didn't use this service.
>
> Here's why.
>
> The bad guys know who the good guys are & which ones are offering a
> Remote Firewall Security Testing Service. Consequently, they already
> know the vendor's IP address. All the attackers need to do is to get
> anywhere on the network (Internet) between the vendor and the customer
> (victim). Frequently, they will take out a local ISP to accomplish this.
> (Truly devious attackers probably offer this as a "free" service which
> may be obtained via their web page.)
>
> At this point, all the attacker needs to do is wait for the vendor
> to initiate the testing of the customer's firewall. Since the
> attackers already know the IP address of the vendor, they only
> need to look at the destination address in the packet headers to
> find the IP address of the customer & their next victim.
You could use several IP-addresses in different ranges for testing -
though most companies might not have the privilege or luxury of having
access to several IP ranges.
When I am testing a firewall remotely I, during the test I will be using
several IP addresses in different Ip ranges. This is also one of the
reasons I like manual testing better that automatic testing, so I have
full control over the tests being done and I am able to switch between
IP addresses during the test. An attacker might have a harder time
in detecting an test-in-progress.
(Even though when I will be using one address, an attacker might have a
hard time detecting a test in progress. He has to wait a long time an has
to collect a lot of traffic and then has to distinguish "attack" packets
from "regular" packets. OK, some attacks have some kind of signature, so
you might filter them out.. Another reason for avoiding automatic testing)
I am lucky that I work for a company with world-wide presence, so
I am able to use several company-owned hops before I got to the
client to be tested (sometimes using encrypted and authenticated
tunnels... another reason for not doing automatically testing :-)).
The attacker then has to follow the track, but probaly isn't able to
recognize a test in progress at all.
> PS - We offer a vendor-neutral Firewall Evaluation/Penetration Test
> Service in which subject the firewall to over 400 tough security
> tests (manual & automated). This helps to ensure that the firewall
> is robust enough to meet the security challenges posed by connecting
> a company to the Internet.
>
> We never have tested firewalls remotely and we never will.
>
I prefer to do the testing locally as well. Another advantage is that you
can create greater loads on the firewall than in the real (Internet)
world. So you you can indeed test the robustness of the firewall better.
But as a lot of my clients are located everywhere in the world, it would
make the testing a bit more expensive :-)) - and I hate flying :-))
Another issue is the greater control you have when testing locally. You
can have feedback from the firewall immediately and react to that. In the
end it turns out to be much more efficient, more thorough and cheaper.
Gr. Arjan
--
Eat hard
Sleep hard
Wear glasses if you need them
Follow-Ups:
References:
|
|
