Ethical DDoS drone network

Mon Jan 5 06:12:13 UTC 2009

On Sun, Jan 4, 2009 at 10:27 PM,  <bmanning at vacation.karoshi.com> wrote:
> On Sun, Jan 04, 2009 at 09:55:20PM -0600, Gadi Evron wrote:
>> A legal botnet is a distributed system you own.
>> A legal DDoS network doesn't exist. The question is set wrong, no?
>        kind of depends on what the model is.  a botnet for hire
>        to "red-team" my network might be just the ticket.

You probably don't have to entirely "own" the distributed system for
it to be legal.
You could just control it with proper authorization.

A  legal botnet is one whose deployment and operations doesn't break any laws
in any of the relevant jurisdictions.    The ways to achieve this are
legal considerations,
not technical considerations.

I'm  not thinking this list is really a good place to ask a question
about legality and get
an answer you can rely on.

You need to confer with your lawyers about how exactly your botnet can
or can't be
built and still be legal.  This may depend on what country your botnet
operates in,
where you are, where your nodes are,  etc.

But thoroughly control and restrain every possible factor that could ever
make your botnet illegal,  and the result should (imho) be legal...

This is not an exhaustive enumeration, but
 some  situations that often make illegal botnets illegal are:

(A) The botnet operator runs code on computers  without authorization,
or the botnet software exploits security vulnerabilities in victim computers to
install without permission
i.e.  operator gains  unauthorized access to a computer  to  deploy
botnet nodes,
or the software is a worm.

This problem is avoided if you take measures to guarantee you own every node,
or if you guarantee you have full permission for every computer you
will possibly run botnet
software on,  to the full extent of the botnet node's activities.

And you ensure botnet software used never automatically "spreads
itself"  like a worm.

This way, all access you gain to node PCs is authorized.

(B) Botnet node software conducts unauthorized activities after it is
installed on the host PC.
e.g. Theft of services.
 Perhaps an authorized user of the PC  did install the software, but
they installed it
for an entirely different purpose,  the botnet node is hidden
software, not noted in
the product brochure or other prominent information about the software.

This problem is avoided if you make sure the person giving permission
to install the
software is aware of the botnet node  and all its expected activities,
before a botnet
node can be brought up.

(C) Traffic generated by a botnet  could be illegal.
For example, traffic in excess of agreements you have in place, or in
violation of your ISP's
TOS, TOU, or AUP,  may be questionable.

Ethically: You need permission from owners of the source and
destination networks the botnet
generates traffic on, not just the source and destination computers.

For example, you have agreements for 10 gigs,  but your botnet test accidentally
sends 50 gigs  towards your remote site,  or one of the thousands of
nodes saturates a
shared link at its local site that belongs to someone else.

An attempt to simulate a DDoS against your own network could inadvertently turn
out to be a real DoS on someone else's network as well as yours, for example one
of your providers' networks.

This is best avoided by maintaining tight control over any distributed
stress testing, and
massively distributed stress testing should be quarantined by all
available means.

The destination of any testing must be a computer you have permission
to blow up.
And the amount of traffic generated by any botnet node on its LAN need
be acceptable.

Always retain rigid controls over any traffic generated,  and very
strong measures  to prevent an unauthorized third party  from ever
being able to make your nodes generate any traffic.

At a bare minimum,  strong PKI  (no MD5 or SHA-1) and digitally-signed
 timestamped  commands
for starting a test,  with some mechanism to prevent unauthorized
creation or replay of commands.

Plus multiple failsafe mechanisms to allow a test to be rapidly halted.

i.e.  all nodes ping a "control point"  once every 30 seconds.
if two pings are dropped, the node stops in its tracks.

So you can kill a runaway botnet by unplugging your control hosts.

-- 
-J