Ethical DDoS drone network
Patrick W. Gilmore
patrick at ianai.net
Mon Jan 5 07:04:03 UTC 2009
On Jan 5, 2009, at 1:33 AM, Roland Dobbins wrote:
> On Jan 5, 2009, at 2:08 PM, Patrick W. Gilmore wrote:
>
>> You want to 'attack' yourself, I do not see any problems. And I
>> see lots of possible benefits.
>
> This can be done internally using various traffic-generation and
> exploit-testing tools (plenty of open-source and commercial ones
> available). No need to build a 'botnet', literally - more of a
> distributed test-harness
>
> And it must be *kept* internal; using non-routable space is key,
> along with ensuring that application-layer effects like recursive
> DNS requests don't end up leaking and causing problems for others.
We disagree.
I can think of several instances where it _must_ be external. For
instance, as I said before, knowing which intermediate networks are
incapable of handling the additional load is useful information.
> But before any testing is done on production systems (during
> maintenance windows scheduled for this type of testing, naturally),
> it should all be done on airgapped labs, first, IMHO.
Without arguing that point (and there are lots of scenarios where that
is not at all necessary, IMHO), it does not change the fact that
external testing can be extremely useful after "air-gap" testing.
> And prior to any testing of this sort, it makes sense to review the
> architecture(s), configuration(s), et. al. of the elements to be
> tested in order to ensure they incorporate the relevant BCPs, and
> then implement those which haven't yet been deployed, and *then* test.
You live in a very structured world. Most people live in reality-land
where there are too many variables to control, and not only is it
impossible guarantee that everything involved is strict to BCP, but
the opposite is almost certainly true.
Remember, systems do not work in isolation, and when you touch other
networks, weird things happen.
> In general, I've found that folks tend to get excited about things
> like launching simulated attacks, setting up honeypots, and the
> like, because it's viewed as 'cool' and fun; the reality is that in
> most cases, analyzing and hardening the infrastructure and all
> participating nodes/elements/apps/services is a far wiser use of
> time and resources, even though it isn't nearly as entertaining.
Here we agree: Entertainment has (should have?) nothing to do with it.
--
TTFN,
patrick
More information about the NANOG
mailing list