At 11:41 AM 8/30/97 +0200, you wrote:
Arjon,
Thanks for your mail. You brought up a lot of good points (as usual). 8^)
>Frank,
>
>I do agree with you.
8^)
>But it is possible to minimize the hazard as
>identified by you.
You're right, it is possible to minimize the hazard. But so far,
I haven't seen a solution which is secure enough for me and is
less expensive (time, money, manpower) than doing it locally.
8< [snip]
>> 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.
If all IP addresses belong to the same entity, (ie - your company)
then nothing is really gained. One attacker may be monitoring one
IP address range, another might be monitoring another address range.
As the bad guys know who the good guys are, we have to assume that
they are monitoring our network traffic and take appropriate precautions.
If all of the IP addresses are at the same ISP, the process is even
easier for the attackers.
Even if attackers aren't set up at the ISPs your company is using,
they might have cracked the customer's local ISP and set up a sniffer.
The sniffer will probably be set to trigger on certain strings (password),
or signatures (test signature of common commercial & attacker security
scanners). They may also be using a scanner detector. The attackers
don't even need to have the results in real time. They just need to
check the results frequently enough to take advantage of the window
of vulnerability & take out the system before the vulnerabilities are
corrected.
>(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)
See above.
>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.
I disagree. If the attackers have taken out the ISP, they may have
uploaded scanner detectors and are using them (it would sure make
the sifting process easier).
>> 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.
Excellent point.
>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 :-))
It's slightly more expensive than doing it remotely, but the
customers should not be penny-wise & pound-foolish. They may
end up putting their company at risk in order to save $1-2K USD.
When we work for in a large company, we may not have very much say
in how things are run. We also have to be mindful of what the
customer wants.
If the decision to do remote testing is an internal management
decision, I would recommend escalating the issue and letting
them be aware that the quality of the work, which is being
performed by professionals such as yourself, is being put at
risk (as is the company's reputation if something goes wrong).
IMHO, it is simply not worth the risk.
If the choice is the customer's, then I would point out to the
customer, the risks of remote security testing. Let them see
the wisdom in spending the extra $1-2K USD to have quality work
performed which won't put their company at risk. I would definitely
try to make this point to the CFO. As the CFO's job is to manage
finances and protect the company's financial assets, they will
see the wisdom in spending the extra thousand or two to minimize
the risk to their company.
>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.
Good points.
>Gr. Arjan
>
>--
>Eat hard
>Sleep hard
>Wear glasses if you need them
Thanks again for the points you mentioned and the insight you provided.
Best Regards,
Frank
The opinions of the author of this mail may not necessarily be
representative of the opinions of Fortifed Networks, Inc.
Fortified Networks, Inc. - http://www.fortified.com/
Expert (vendor-neutral) Computer and Network Security Consulting
Phone: (317) 573-0800 Fax: (317) 573-0817
Follow-Ups:
References:
|
|
