Ethical DDoS drone network

Patrick W. Gilmore patrick at ianai.net
Mon Jan 5 11:53:49 UTC 2009


On Jan 5, 2009, at 3:39 AM, Gadi Evron wrote:
> On Sun, 4 Jan 2009, kris foster wrote:
>> On Jan 4, 2009, at 11:11 PM, Gadi Evron wrote:
>>
>>> On Mon, 5 Jan 2009, Patrick W. Gilmore wrote:
>>>> On Jan 5, 2009, at 1:33 AM, Roland Dobbins wrote:
>>>>> On Jan 5, 2009, at 2:08 PM, Patrick W. Gilmore wrote:
>>>> 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.
>>> Fine test it by simulation on you or the transit end of the pipes.  
>>> Do not transmit your test sh?t data across the `net.
>>
>> How do you propose a model is built for the simulation if you can't  
>> collect data from the real world?
>>
>> This is not "sh?t data". Performance testing across networks is  
>> very real and happening now. The more knowledge I have of a path  
>> the better decisions I can make about that path.

> I am sorry for joking, I was sure we were talking about DDoS testing?

I've been called by more one provider because I was "DDoS'ing" someone  
with traffic that someone requested.  Strange how the word "DDoS" has  
morphed over time.

But back to your original point, how can you tell it is shit data?   
DDoSes frequently use valid requests or even full connections.  If I  
send my web server port 80 SYNs, why would you complain?

Knowing whether the systems - internal _and_ external - can handle a  
certain load (and figuring out why not, then fixing it) is vital to  
many people / companies / applications.  Despite the rhetoric here, it  
is simply not possible to "test" that in a lab.  And I guarantee if  
you do not test it, there _will_ be unexpected problems when Bad Stuff  
happens.

As mentioned before, Reality Land is not clean and structured.

-- 
TTFN,
patrick





More information about the NANOG mailing list