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
* 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
* 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
* Provide a short period of time (3 days) after notification and before
disconnect to give an opportunity to fix the issue without service
interruption
* 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
This would make me happy.
What would make me angry is if they:
* Simply turn the connection off with little or no notice
* Provide no notification of what happened or why
* Offer no evidence of why they turned the connection off to help debug
* Force the customer to call customer service to ask for a retest or
reconnect
* Have the reconnect take multiple hours/days once approved
If done right, such a treaty here in the US and elsewhere thing would be a
major win for the Internet.
Beckman
Hi!
A major reason ISPs are hesitant to take deliberate measures against such systems is that they are afraid that disconnecting users and making them spend time and money cleaning up their systems will only drive them into the hands of competitors. And the support process itself is expensive, probably wiping out the profit from that user. But with such high coverage of the market users may not have permissive alternatives.
This will be an interesting phenomenon to watch. If it is successful perhaps it could work here too."
-------I couldn't find the story in English in a version that did not link to my original post, I waited a few days to see if anyone else picks it up, as I don't want yet another self-promotion fight. No one I found in under 2 minutes on Google did, so this second-hand link should do.
http://blogs.pcmag.com/securitywatch/2009/09/dutch_isps_sign_anti-botnet_tr.php
This is rather old news btw, the convernant was signed < 14 Aug.
The ISP's that signed are :
Alice, Het Net, InterNLnet, KPN, Luna NL, Concepts ICT, Online, Solcon, Tele2, Telfort, UPC, Xenosite, XS4ALL en Ziggo
This is certainly not 98% of the NL marked as they claim. But who cares its a nice initiative.
Bye,
Raymond.
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
Exactly correct. The number one priority, which trumps all others,
is making the abuse stop. Yes, there are many other things that can
and should be done, but that's the first one.
Let me also point out that there's a problem with offering simple, automated
removal (as was suggested in the message that you replied to): resident
malware on abuse-sourcing zombies will very quickly be reprogrammed to
avail itself of that mechanism (on a per-ISP basis if necessary, if
this becomes widespread). So there should be no automated removal process:
the intervention of humans should be required, doubly so as in most cases
the putative/former owner of the infected system is unaware of any of this.
---Rsk
* Provide a short period of time (3 days) after notification and before
disconnect to give an opportunity to fix the issue without service
interruptionUh... 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.
Yeah, after a few people privately emailed me regarding the same, the
short period of time should be thrown out, for the good of the rest of the
'net.
The "short period" was initially intended for infections that were not
active or immediately impacting, but were detected to be infected
none-the-less. Assuming active "bad behavior" immediate disconnect is
prudent and wise.
As our ability to remotely detect virus and trojans improves, I suspect
such an ISP-provided service would as well.
* 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 blockedEither 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.
Agreed. Another emailer mentioned that it's not always simple to
determine if the abuse is resolved or not, nor is it easy to explain this
to a non-technical customer in a way that makes them happy with their
service being cut off. However it is ignorance and lack of maintenance
that makes viruses and botnets so prevelant that it may just be time to
bite the bullet and force users to learn how to maintain their machines.
* Force the customer to call customer service to ask for a retest or
reconnectI don't really see a problem with this, so long as customer service is
responsive to such a call.
I like self-service. If it is 3am and staff is not available, making the
process automated would be ideal. If the staff is 24/7, agreed.
Beckman
because this works so well with:
1) cars
2) home-security
3) personal security wandering around cities/towns
I note that I'm not particularly against any of the proposal, just the
'people need a drivers license to get on the interwebz'... it's been
tried many times before, always without success.
I would also point out that Qwest does this walled-garden approach for
their customers (have been for at least 5 years now? DonS@qwest could
clarify) and they've seen success with it. Aliant in .ca also has some
fairly aggressive anti-malware works installed. There are places
where this sort of thing works well, planned and engineered properly.
I think Qwest, at least, made some of their reasoning and design/goals
publicly available for a time as well.
-Chris
Christopher Morrow wrote:
I would also point out that Qwest does this walled-garden approach for
their customers (have been for at least 5 years now? DonS@qwest could
clarify) and they've seen success with it. Aliant in .ca also has some
fairly aggressive anti-malware works installed. There are places
where this sort of thing works well, planned and engineered properly.
I think Qwest, at least, made some of their reasoning and design/goals
publicly available for a time as well.
I think Jonathan Curtis did something similar at Bell, but I only spoke with him about it for a couple of second two years ago, as Rio was rather distracting. So am unsure.
Apparently, marketing departments like the idea of being able to send customers that need to pay them to a walled garden. It also saves on tech support costs. Security being the main winner isn't the main supporter of the idea at some places.
Gadi.
Exactly correct. The number one priority, which trumps all others,
is making the abuse stop. Yes, there are many other things that can
and should be done, but that's the first one.
Stopping the abuse is fine, but cutting service to the point that a family
using VOIP only for their phone service can't call 911 and several children
burn to death could bring all sorts of undesirable regulation let alone the
bad press and legal expenses.
Barton F Bruce wrote:
Stopping the abuse is fine, but cutting service to the point that a family
using VOIP only for their phone service can't call 911 and several children
burn to death could bring all sorts of undesirable regulation let alone the
bad press and legal expenses.
While a legitimate concern it's also a red herring, as it's a technical problem looking for a technical solution.
Gadi.
> Exactly correct. The number one priority, which trumps all others,
> is making the abuse stop. Yes, there are many other things that
can
> and should be done, but that's the first one.Stopping the abuse is fine, but cutting service to the point that a
family
using VOIP only for their phone service can't call 911 and several
children
burn to death could bring all sorts of undesirable regulation let
alone the
bad press and legal expenses.
As far as the Ducth situation with one of the largest providers (KPN) goes this is solved by using a seperate VLAN for VOIP traffic. Only the data VLAN is being "blocked" or actually policy routed towards a walled garden in which users are able to clean themselves up.
First, this is fear-mongering. By this argument, we should do nothing,
ever, because we cannot know that seconds after taking whatever action
we take, Something Terrible could happen.
Second, a compromised system no longer belongs to its putative user(s):
it's not under their control. It's thus a huge reach to presume that
it will, whether "we" take any action or not, do what the people who
used to own it (and likely think they still do) expect it to. In
other words, just as likely as the scenario you outline, is the scenario
where the VOIP call doesn't go through because the new owner of the
system would prefer that it spend its cycles and bandwidth sending spam.
---Rsk
From: Christopher Morrow [mailto:morrowc.lists@gmail.com]
Sent: Sunday, October 04, 2009 4:04 PM
To: Peter Beckman
Cc: NANOG
Subject: Re: Dutch ISPs to collaborate and take responsibility for botted
clients
> service being cut off. However it is ignorance and lack of maintenance
> that makes viruses and botnets so prevelant that it may just be time to
> bite the bullet and force users to learn how to maintain their
machines.
because this works so well with:
1) cars
2) home-security
3) personal security wandering around cities/townsI note that I'm not particularly against any of the proposal, just the
'people need a drivers license to get on the interwebz'... it's been
tried many times before, always without success.
I'm trying to understand your analogy, but it's hidden in the sarcasm.
Your assertion is that education (and you've decided to include licensing,
for some reason) of drivers and the rest is ineffective? You're not
opposed to user education, you just believe it's useless because it will
only reduce, not eliminate, badness?
Lee
Gadi Evron wrote:
Apparently, marketing departments like the idea of being able to send customers that need to pay them to a walled garden. It also saves on tech support costs. Security being the main winner isn't the main supporter of the idea at some places.
I would love to do this both for non-pays and security incidents. I'd like to do something similar to let customers update their provisioning information for static IP changes so cable source verify doesn't freak out. Unfortunately I haven't been able to find any open source tools to do this. I can't even think of commercial ones off the top of my head.
It's a relatively simple concept. Some measure of integration into the DHCP provisioning system(s) would be needed to properly route the customer's traffic to the walled garden and only to the walled garden. Once the problem is resolved the walled garden fixes the DHCP so the customer can once again pull a public IP and possibly flushes ARP caches if your access medium makes that a problem to be dealt with.
I would think that the walled garden portion could be handled well-enough with Squid and some custom web programming to perform tasks to reverse the provisioning issues. I'm sure people have written internal solutions for SPs before but I haven't found anyone that has made that into an OSS project and put it on the Web. I'd love to make this a project but there is little financial gain to my small SP so if it costs much money it won't get management support.
Justin
Justin Shore wrote:
Gadi Evron wrote:
Apparently, marketing departments like the idea of being able to send
customers that need to pay them to a walled garden. It also saves on
tech support costs. Security being the main winner isn't the main
supporter of the idea at some places.I would love to do this both for non-pays and security incidents. I'd
like to do something similar to let customers update their
provisioning information for static IP changes so cable source verify
doesn't freak out. Unfortunately I haven't been able to find any open
source tools to do this. I can't even think of commercial ones off
the top of my head.It's a relatively simple concept. Some measure of integration into
the DHCP provisioning system(s) would be needed to properly route the
customer's traffic to the walled garden and only to the walled garden.
Once the problem is resolved the walled garden fixes the DHCP so the
customer can once again pull a public IP and possibly flushes ARP
caches if your access medium makes that a problem to be dealt with.I would think that the walled garden portion could be handled
well-enough with Squid and some custom web programming to perform
tasks to reverse the provisioning issues. I'm sure people have
written internal solutions for SPs before but I haven't found anyone
that has made that into an OSS project and put it on the Web. I'd
love to make this a project but there is little financial gain to my
small SP so if it costs much money it won't get management support.Justin
There is all sorts of kit that will do this for you, Ellacoya, Redback
etc. They all have APIs and all work well. The customer keeps their
public IP address, but you can then make it belong to another virtual
router instance, or you can apply certain firewall/ACL/policy rules to it.
For example, my Ellacoyas will, for a walled customer, deny traffic to
anything but the walled garden hosts and will then route any port 80
traffic to my proxy server that re-directs it all to a walled garden web
server. Then soon as they hand over their payment details and we take
payment, a request is sent to the Ellacoya to remove the restrictions.
Lovaly.
Perhaps someone has said this but a potential implementation problem
in the US are anti-trust regulations. Sure, they may come around to
seeing it your way since the intent is so good but then again "we all
decided to get together and blacklist customers who..." is not a great
elevator pitch to an attorney-general no matter how good the intent.
Obviously there are ways around that (e.g., it's ok to do credit
checks) but one has to be up-front and get approval.
I'm just sayin':
a) consult with legal counsel before doing anything in "collusion"
with competitors.
b) this is probably not for smaller ISPs until the legal way is
cleared by those with plenty of money for lawyering and lobbying.
(I did say "IN THE USA", right?)
Perhaps someone has said this but a potential implementation problem
in the US are anti-trust regulations. Sure, they may come around to
seeing it your way since the intent is so good but then again "we all
decided to get together and blacklist customers who..." is not a great
elevator pitch to an attorney-general no matter how good the intent.
That's not what is being discussed from my understanding.
abusers and data necessary to help in tracking DDOS.
I don't believe that any ISP is expected to necessarily take any
particular action determined by the group with respect to the
list of names they are given.
I do think that it is reasonable to have an agreement among
an industry organization or collaboration which states that
ISPs which determine that abuse is being sourced from one of
their customers (either through their own processes or by
notification from another participant) should be expected to
take the necessary steps to mitigate that abuse from exiting
said ISPs autonomous system.
Obviously there are ways around that (e.g., it's ok to do credit
checks) but one has to be up-front and get approval.
I don't think that's true. I think that as long as your privacy policy
and terms of service state that you will share certain information
with other operators regarding abuse complaints and (possibly)
abusive activities, you are free to share that information.
Having a coalition rule that says any member must refuse to
service any party on the list would be an anti-trust violation.
Having a list, alone, without any rules about how the list is used,
is not an anti-trust violation.
Just like agreeing ahead of time on the price of gas amongst
multiple competitors is an anti-trust violation, posting the price
of gas at your service stations is not. Modifying your price to
match the price across the street also is not.
I'm just sayin':
a) consult with legal counsel before doing anything in "collusion"
with competitors.
Definitely.
b) this is probably not for smaller ISPs until the legal way is
cleared by those with plenty of money for lawyering and lobbying.
I'm not so sure that is true, but, they should seek good legal counsel
about whatever they plan to do regardless of size.
Owen
In a way, this is kind of like stores keeping a list of bad check
writers. The whole information sharing thing can get more than a
little touchy from a legal perspective.
Then again, an independant database could also be viewed as a sort of
internet credit agency. Stuff in a name, get a score back and certain
flags and make your judgement based on that.
"I'm sorry, I can't give you an email account. Your internet-karma
rating came back below our minimum levels."
-Wayne
Do you currently drop them in to a VRF to get them to the Internet?
If so, do that, but a different VRF for the walled garden.
Gadi Evron wrote:
Barton F Bruce wrote:
Stopping the abuse is fine, but cutting service to the point that a family
using VOIP only for their phone service can't call 911 and several children
burn to death could bring all sorts of undesirable regulation let alone the
bad press and legal expenses.While a legitimate concern it's also a red herring, as it's a technical problem looking for a technical solution.
Gadi.
I think the need for someone being able to call 911 from their VoIP outweighs your right to claim that they should be disconnected from the Internet.
Besides, if that provider wants to help out, he might setup a captive portal or something with information regarding tools to clean their computer.