Dutch ISPs to collaborate and take responsibility for botted clients

Sun Oct 4 11:33:43 UTC 2009

On Oct 3, 2009, at 3:18 PM, Peter Beckman wrote:

> On Sat, 3 Oct 2009, Gadi Evron wrote:
>
>> The story is covered by PC mag:
>
> Thanks for the article Gadi.  Honestly, I wish both my personal ISP  
> and
> one of my business ISPs would do this.  Though I have the technical
> ability to monitor my outgoing connections for such things, it's not a
> trivial task and requires resources I've decided not to invest in,  
> namely
> a Linux PC running as my gateway with yet more software (OS,  
> monitoring
> tools, etc) I need to secure and keep updated.
>
> For me to be thrilled about my ISPs monitoring my connection for "bad
> behavior," the ISP should:
>
>    * Quickly notify the customer about the problem via email and phone
Agreed

>    * Offer the ability to view the evidence of the "bad behavior,"
>      accessible on the ISP network via the web so it can be viewed  
> whether
>      the connection is active or blocked, to help determine which  
> host(s)
>      is/are responsible
Agreed

>    * Clearly classify the type of "bad behavior" and offer both free  
> and
>      paid alternatives to potentially rectify the problem for those  
> less
>      technically inclined to self-solve the issue
Definitely.

>    * Provide a short period of time (3 days) after notification and  
> before
>      disconnect to give an opportunity to fix the issue without  
> service
>      interruption

Uh... Here I differ.  The rest of the internet should put up with the  
abuse
flowing out of your network for 3 days to avoid disruption to you? Why?
Sorry, if you have a customer who is sourcing malicious activity,  
whether
intentional or by accident, I believe the ISP should take whatever  
action
is necessary to stop the outflow of that malicious behavior as quickly
as possible while simultaneously making all reasonable effort to contact
the customer in question.

The ISP should take the minimum action necessary to stop the outflow,  
so,
if the traffic is sourced from a single host, that host could be  
filtered/blocked.
If the traffic can be classified more tightly (i.e. certain ports,  
etc., then that
classification should be used). This minimizes disruption to the  
customer,
but, still preserves the ISPs obligation to the rest of the internet.   
When you
connect to a community resource like the internet, you have an inherent
obligation not to source malicious activity. When you provide services
to downstream customers, you are not relieved of that responsibility
just because you accepted the malicious activity from them rather than
originating it yourself.

>    * Offer a simple, automated way to get the connection re-tested and
>      unblocked immediately (within 15 minutes) using a web service
>      accessible even if the connection is blocked
>
Either a web interface or even a telephonic process. It doesn't  
necessarily
need to be automated, but, it shouldn't be a 3 day wait for a technician
to get back to you. It should definitely be a pretty rapid process once
the abuse is resolved.

> This would make me happy.
>
> What would make me angry is if they:
>
>    * Simply turn the connection off with little or no notice
They should not turn the connection off unless it is absolutely  
necessary.
See above.
>    * Provide no notification of what happened or why
Absolutely agree here.
>    * Offer no evidence of why they turned the connection off to help  
> debug
Yep.
>    * Force the customer to call customer service to ask for a retest  
> or
>      reconnect
I don't really see a problem with this, so long as customer service is
responsive to such a call.
>    * Have the reconnect take multiple hours/days once approved
Agreed: the reconnect process should be very quick once the abuse is
resolved.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20091004/bdb1a337/attachment.bin>