Re: Dutch ISPs to collaborate and take responsibility
Lee wrote: If an ISP is involved with tracking down DDOS participants or something, I can understand how they'd know a system was compromised. But any kind of blocking because the ISP sees 'anomalous' traffic seems .. premature at best. SANS newsbites has this bit: On Thursday, October 8, Comcast began testing a service that alerts its broadband subscribers with pop-ups if their computers appear to be infected with malware. Among the indicative behaviors that trigger alerts are spikes in overnight traffic, suggesting the machine has been compromised and is being used to send spam. When my son comes home from college, there's a huge spike in overnight traffic from my house. With all the people advocating immediate blocking of pwned systems in this thread, I'm wondering what their criteria is for deciding that the system is compromised & should be blocked. Lee Some info. here (from http://networkmanagement.comcast.net/ ): 5. Detection of Bots http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03 http://tools.ietf.org/html/draft-livingood-web-notification-00
RE: Dutch ISPs to collaborate and take responsibility
or when I initiate offsite backups. I've seen ISPs that react to just traffic bursts. It's not the way to go without more intelligent decision making on the content (i.e. SMTP, all SYNs, etc). Of course, content inspection is a whole 'nother hornet's nest :) - S -Original Message- From: Lee Sent: Friday, October 09, 2009 19:41 To: nanog@nanog.org Subject: Re: Dutch ISPs to collaborate and take responsibility On 10/9/09, Rich Kulawiec wrote: > On Wed, Oct 07, 2009 at 06:25:53AM -0700, Owen DeLong wrote: >> Additionally the problems of DDOS sourced from a collection of >> compromised hosts could be interfering with someone else's ability >> to make a successful VOIP call. > > Much more than that: they could be interfering with the underlying > infrastructure, or they could be attacking the VOIP destination, > or they could be making fake VOIP calls (see below), or they could > be doing ANYTHING. A compromised system is enemy territory, which is why: > >> This blocking should be as narrow as possible. > > Blocking should be total. A compromised system is as much > enemy-controlled as if it were physically located at the RBN. Trying > to figure out which of externally-visible behaviors A, B, C, etc. > it exhibits might be malicious and which might not be is a loss, If an ISP is involved with tracking down DDOS participants or something, I can understand how they'd know a system was compromised. But any kind of blocking because the ISP sees 'anomalous' traffic seems .. premature at best. SANS newsbites has this bit: On Thursday, October 8, Comcast began testing a service that alerts its broadband subscribers with pop-ups if their computers appear to be infected with malware. Among the indicative behaviors that trigger alerts are spikes in overnight traffic, suggesting the machine has been compromised and is being used to send spam. When my son comes home from college, there's a huge spike in overnight traffic from my house. With all the people advocating immediate blocking of pwned systems in this thread, I'm wondering what their criteria is for deciding that the system is compromised & should be blocked. Lee
Re: Dutch ISPs to collaborate and take responsibility
On 10/9/09, Rich Kulawiec wrote: > On Wed, Oct 07, 2009 at 06:25:53AM -0700, Owen DeLong wrote: >> Additionally the problems of DDOS sourced from a collection of >> compromised hosts could be interfering with someone else's ability >> to make a successful VOIP call. > > Much more than that: they could be interfering with the underlying > infrastructure, or they could be attacking the VOIP destination, > or they could be making fake VOIP calls (see below), or they could > be doing ANYTHING. A compromised system is enemy territory, which is why: > >> This blocking should be as narrow as possible. > > Blocking should be total. A compromised system is as much > enemy-controlled as if it were physically located at the RBN. Trying > to figure out which of externally-visible behaviors A, B, C, etc. > it exhibits might be malicious and which might not be is a loss, If an ISP is involved with tracking down DDOS participants or something, I can understand how they'd know a system was compromised. But any kind of blocking because the ISP sees 'anomalous' traffic seems .. premature at best. SANS newsbites has this bit: On Thursday, October 8, Comcast began testing a service that alerts its broadband subscribers with pop-ups if their computers appear to be infected with malware. Among the indicative behaviors that trigger alerts are spikes in overnight traffic, suggesting the machine has been compromised and is being used to send spam. When my son comes home from college, there's a huge spike in overnight traffic from my house. With all the people advocating immediate blocking of pwned systems in this thread, I'm wondering what their criteria is for deciding that the system is compromised & should be blocked. Lee
Re: Dutch ISPs to collaborate and take responsibility
On Wed, Oct 07, 2009 at 06:25:53AM -0700, Owen DeLong wrote: > Additionally the problems of DDOS sourced from a collection of > compromised hosts could be interfering with someone else's ability > to make a successful VOIP call. Much more than that: they could be interfering with the underlying infrastructure, or they could be attacking the VOIP destination, or they could be making fake VOIP calls (see below), or they could be doing ANYTHING. A compromised system is enemy territory, which is why: > This blocking should be as narrow as possible. Blocking should be total. A compromised system is as much enemy-controlled as if it were physically located at the RBN. Trying to figure out which of externally-visible behaviors A, B, C, etc. it exhibits might be malicious and which might not be is a loss, doubly so given that many of the attacks launched by such systems are of a distributed nature and thus are very difficult to infer solely by observation of one system. Moreover, there is no way to know, given a current observation of behavior A, whether or not behavior B will begin, when it will begin, or what it will be. For example, there's no way to know that a supposed VOIP call to 911 from that system is actually being made by a human being. It's certainly well within the capabilities of malware to place such a call -- and abuses of 911 in efforts to misdirect authorities are well-known. (See "swatting". And note that nothing stops a botnet equipped with appropriate s/w from launching a number of such calls in sequence, with what I think are predictable consequences.) The bottom line is that once a system is compromised, all bets are off. Nothing it does can be trusted by anyone: not its *former* owners, not the network operator, not anyone in receipt of its traffic. So the only logical course of action is to cut it off completely, as quickly as possible, and keep it that way until it's properly fixed. (Which of course involves booting from known-clean media, restoring apps from known-clean sources, scanning all user data, etc. Booting from known-infected media is an obvious and immediate fail.) ---Rsk
Re: Dutch ISPs to collaborate and take responsibility for botted clients
Gadi Evron wrote: [snip] This will be an interesting phenomenon to watch. If it is successful perhaps it could work here too." Comcast is launching a trial on Thursday of a new automated service that will warn broadband customers of possible virus infections, if the computers are behaving as if they have been compromised by malware. "ISPs have a helpful role to play in helping subscribers mitigate these kinds of security threats," she said. "The challenge is...when users get these notices, do they understand them? Do they trust that they are real? Do they follow through to the point where they clean up their computers?" http://news.cnet.com/8301-27080_3-10370996-245.html
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
Looks like ISP-to-customer notification of possible infection is starting on Comcast in the US now. http://news.cnet.com/8301-27080_3-10370996-245.html --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.com/ ---
Re: Dutch ISPs to collaborate and take responsibility
> From nanog-bounces+bonomi=mail.r-bonomi@nanog.org Wed Oct 7 06:18:24 > 2009 > Date: Wed, 07 Oct 2009 18:17:57 +0700 > From: Dave Temkin > To: Alexander Harrowell > Subject: Re: Dutch ISPs to collaborate and take responsibility > Cc: nanog@nanog.org > > Alexander Harrowell wrote: > > On Wednesday 07 October 2009 00:27:55 Joe Greco wrote: > > > > > >> Assuming that the existence of an infected PC in the mix translates to > >> some sort of inability to make a 911 call correctly is, however, simply > >> irresponsible, and at some point, is probably asking for trouble. > >> > >> ... JG > >> > > > > Also, someone mentioned that the FCC doesn't in fact mandate that PSTN > > terminals should be able to make emergency calls even if formally > > disconnected > > and asked about cellular. > > > > The opposite is true about GSM and its descendants; whether or not you're a > > valid roamer for the network you're talking to, have a prepaid balance, > > have > > paid your bill, you must be able to make emergency calls. Similarly, even > > if > > no SIM card is present, the device should register with the network as > > "limited service" - i.e. emergency only. > > > > > The FCC generally doesn't come into play when you're talking about ILEC > telephone service except at a very high level. In California, by PUC > regulation telephone companies are required to allow access to 911 so > long as there is copper in the facility and it was, at any time, active > with any sort of phone service. "Not exactly". They are required to do it only 'to the extent permitted by existing facilities'. To wit, if they need that wire pair to provide service (say, an additional line) to a paying customer, they _can_ physically disconnct the 'inactive account' premises, and hook up the new paying account to that pair. On occasion, telcos are known to re-use the pair, by just hooking the new customer onto it, _without_ pulling the bridge clips at the 'multiple' where the old custmer was connected. This leads to all sorts of messes. the 'non- customer' discovers dial-tone on the pair and starts using it. Calls are being made which the _real_ customer didn't make, which leads to real arguments with the billing department. Then, the customer picks up their phone, and instead of getting dial tone, discovers a conversation _in_progress_ on the line -- when _nobody_else_ at their place is on the phone. Strangely, the parties to that conversation refuse to identify themselves, and one of them is _really_ anxious to terminate that call, so you can use "your" line. I, personally, have been through this more than once, in older, high-density housing neighborhoods.
Re: Dutch ISPs to collaborate and take responsibility
> On Oct 6, 2009, at 4:27 PM, Joe Greco wrote: > >> Someone else pointed out that if the system in question has been > >> botted/owned/pwn3d/whatever > >> you want to call it, then, you can't guarantee it would make the 911 > >> call correctly anyway. > > > > I realize that many NANOG'ers don't actually use the technologies that > > we talk about, so I'm just going to correct this: > > > > You seem to be under the mistaken assumption that most people using > > VoIP > > do so using their computer. While it kind of started out that way > > years > > ago, it simply isn't so anymore. Most VoIP services can be > > configured to > > work with an analog telephony adapter, providing a POTS jack. Most > > VoIP > > services even provide one as part of the subscription, sometimes for a > > fee. > > I do use VOIP, bot computer and non-computer based. None the less, the > fact remains that should any of my systems become compromised, my > ability to make a VOIP phone call is in doubt regardless of what the > provider does. Well, /that's/ obviously not true. Cable providers are already using PacketCable NCS (read: "MGCP lightly modified") to provide completely reliable QoS for their own VoIP-to-the-cablemodem products; you are going to find it tough to impact the service level of such a device. For general VoIP, there's no particularly good reason that the VoIP traffic cannot be QoS'd / filtered to allow VoIP to continue to work while gardening the remaining traffic from the customer. That is completely under the provider's control. Since many of the CPE devices actually have a programmable hardware ethernet switch, it is even possible to do a lot of the work in hardware. > Additionally the problems of DDOS sourced from a collection of > compromised > hosts could be interfering with someone else's ability to make a > successful > VOIP call. I think the above addresses that. There are always risks, of course. The guy pruning tree branches down the street can knock down the cable line, for example. Of course, he probably takes out the phone lines as well... :-) > Abuse sources should be blocked from impacting the rest of the network. Sure. > This blocking should be as narrow as possible. Yes, that's my point. We should be able to narrowly block compromised hosts so that we don't screw up legitimate VoIP uses. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Dutch ISPs to collaborate and take responsibility
On Oct 6, 2009, at 4:27 PM, Joe Greco wrote: Someone else pointed out that if the system in question has been botted/owned/pwn3d/whatever you want to call it, then, you can't guarantee it would make the 911 call correctly anyway. I realize that many NANOG'ers don't actually use the technologies that we talk about, so I'm just going to correct this: You seem to be under the mistaken assumption that most people using VoIP do so using their computer. While it kind of started out that way years ago, it simply isn't so anymore. Most VoIP services can be configured to work with an analog telephony adapter, providing a POTS jack. Most VoIP services even provide one as part of the subscription, sometimes for a fee. I do use VOIP, bot computer and non-computer based. None the less, the fact remains that should any of my systems become compromised, my ability to make a VOIP phone call is in doubt regardless of what the provider does. Additionally the problems of DDOS sourced from a collection of compromised hosts could be interfering with someone else's ability to make a successful VOIP call. Abuse sources should be blocked from impacting the rest of the network. This blocking should be as narrow as possible. Owen
Re: Dutch ISPs to collaborate and take responsibility
Alexander Harrowell wrote: On Wednesday 07 October 2009 00:27:55 Joe Greco wrote: Assuming that the existence of an infected PC in the mix translates to some sort of inability to make a 911 call correctly is, however, simply irresponsible, and at some point, is probably asking for trouble. ... JG Also, someone mentioned that the FCC doesn't in fact mandate that PSTN terminals should be able to make emergency calls even if formally disconnected and asked about cellular. The opposite is true about GSM and its descendants; whether or not you're a valid roamer for the network you're talking to, have a prepaid balance, have paid your bill, you must be able to make emergency calls. Similarly, even if no SIM card is present, the device should register with the network as "limited service" - i.e. emergency only. The FCC generally doesn't come into play when you're talking about ILEC telephone service except at a very high level. In California, by PUC regulation telephone companies are required to allow access to 911 so long as there is copper in the facility and it was, at any time, active with any sort of phone service. Ref: http://ucan.org/telenforcers/files/SBC%20complaint%20PUC%20version.pdf Ref2: http://law.onecle.com/california/utilities/2883.html I believe this is also the case in numerous other states.
Re: Dutch ISPs to collaborate and take responsibility
On Wednesday 07 October 2009 00:27:55 Joe Greco wrote: > Assuming that the existence of an infected PC in the mix translates to > some sort of inability to make a 911 call correctly is, however, simply > irresponsible, and at some point, is probably asking for trouble. > > ... JG Also, someone mentioned that the FCC doesn't in fact mandate that PSTN terminals should be able to make emergency calls even if formally disconnected and asked about cellular. The opposite is true about GSM and its descendants; whether or not you're a valid roamer for the network you're talking to, have a prepaid balance, have paid your bill, you must be able to make emergency calls. Similarly, even if no SIM card is present, the device should register with the network as "limited service" - i.e. emergency only. signature.asc Description: This is a digitally signed message part.
Re: Dutch ISPs to collaborate and take responsibility
> Someone else pointed out that if the system in question has been > botted/owned/pwn3d/whatever > you want to call it, then, you can't guarantee it would make the 911 > call correctly anyway. I realize that many NANOG'ers don't actually use the technologies that we talk about, so I'm just going to correct this: You seem to be under the mistaken assumption that most people using VoIP do so using their computer. While it kind of started out that way years ago, it simply isn't so anymore. Most VoIP services can be configured to work with an analog telephony adapter, providing a POTS jack. Most VoIP services even provide one as part of the subscription, sometimes for a fee. There's also a growing number of phones that support Skype or generic VoIP, sometimes alongside a regular POTS line, sometimes not. It is perfectly possible to have an infected PC sitting right next to a nice VoIP-capable DECT cordless phone system, both hooked to the same NAT router. This is, of course, problematic, and would be a useful problem to contemplate how to cause one to break while keeping the other operational. Assuming that the existence of an infected PC in the mix translates to some sort of inability to make a 911 call correctly is, however, simply irresponsible, and at some point, is probably asking for trouble. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
RE: Dutch ISPs to collaborate and take responsibility for bottedclients
> > > -Original Message- > > From: Eugeniu Patrascu [mailto:eu...@imacandi.net] > > Sent: Tuesday, October 06, 2009 4:20 AM > > To: Gadi Evron > > Cc: NANOG > > Subject: Re: Dutch ISPs to collaborate and take responsibility for > bottedclients > . > > > > > 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. > > I believe the FCC requires even deactivated phones to be able to reach 911. > Can't confirm, fcc.gov is down. Authoritatively *NOT* true for hard-wire landlines in the U.S. Cellular may, and I believe _is_, be a different story.
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
Re: VOIP, 911, bots Shape their bandwidth down to the minimum required to make a 911 call, around 64Kbps, and capture their web accesses. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
The end problem is still users and really, these users will click on anything that has a bright and shiny button which says, Ok. Really, does setting up a portal help? Perhaps a "sandboxed" area which has some information on securing their machine and keeping it clean may be the way to go but how much more of a resource will it chew up? Best regards, Mark On 06-Oct-2009, at 11:56 PM, Owen DeLong wrote: On Oct 6, 2009, at 1:20 AM, Eugeniu Patrascu wrote: 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. I disagree... Distributed Denials of Service have gotten to the point where they can actually endanger lives. Think about this... In order to be able to make your 911 VOIP call, the VOIP provider has to be able to process your call. The system that is getting disconnected because it is an active source of abuse may be one of many participating in a DOS against someone elses 911 VOIP provider. Removing them from the internet could be saving more lives than it risks. Someone else pointed out that if the system in question has been botted/owned/pwn3d/whatever you want to call it, then, you can't guarantee it would make the 911 call correctly anyway. Owen
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
On Oct 6, 2009, at 1:20 AM, Eugeniu Patrascu wrote: 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. I disagree... Distributed Denials of Service have gotten to the point where they can actually endanger lives. Think about this... In order to be able to make your 911 VOIP call, the VOIP provider has to be able to process your call. The system that is getting disconnected because it is an active source of abuse may be one of many participating in a DOS against someone elses 911 VOIP provider. Removing them from the internet could be saving more lives than it risks. Someone else pointed out that if the system in question has been botted/owned/pwn3d/whatever you want to call it, then, you can't guarantee it would make the 911 call correctly anyway. Owen
RE: Dutch ISPs to collaborate and take responsibility for bottedclients
> -Original Message- > From: Eugeniu Patrascu [mailto:eu...@imacandi.net] > Sent: Tuesday, October 06, 2009 4:20 AM > To: Gadi Evron > Cc: NANOG > Subject: Re: Dutch ISPs to collaborate and take responsibility for bottedclients . > > > 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. I believe the FCC requires even deactivated phones to be able to reach 911. Can't confirm, fcc.gov is down. Don't know about CRTC. And I don't know how this could apply to an over-the-top VoIP service--how would an ISP know you're trying to call 911 on Skype? > Besides, if that provider wants to help out, he might setup a captive > portal or something with information regarding tools to clean their > computer. Many providers already do that. Lee
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
Eugeniu Patrascu wrote: 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. Again, I don't disagree, but I see it as a technical issue which is solvable. I don't see why this is THE issue. It's really just changing the subject of the discussion. Besides, if that provider wants to help out, he might setup a captive portal or something with information regarding tools to clean their computer. -- Gadi Evron, g...@linuxbox.org. Blog: http://gevron.livejournal.com/
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
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.
Re: Dutch ISPs to collaborate and take responsibility for botted clients
On 6/10/2009, at 3:04 AM, 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. 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. -- Nathan Ward
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
On Mon, Oct 05, 2009 at 03:55:02PM -0700, Owen DeLong wrote: > > On Oct 5, 2009, at 11:23 AM, Barry Shein wrote: > > > > >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. > > From my understanding, the intent is to share names of known > 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. 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 --- Wayne Bouchard w...@typo.org Network Dude http://www.typo.org/~web/
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
On Oct 5, 2009, at 11:23 AM, Barry Shein wrote: 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. From my understanding, the intent is to share names of known 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
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
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?) -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
Re: Dutch ISPs to collaborate and take responsibility for botted clients
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. -- Leigh
Re: Dutch ISPs to collaborate and take responsibility for botted clients
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
RE: Dutch ISPs to collaborate and take responsibility for botted clients
> -Original Message- > From: Christopher Morrow [mailto:morrowc.li...@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 > > On Sun, Oct 4, 2009 at 2:55 PM, Peter Beckman wrote: > > > 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/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'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
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
On Sun, Oct 04, 2009 at 08:07:00PM -0400, Barton F Bruce wrote: >> 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. 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
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
> > 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. -- Nils Kolstein SSCPlus
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
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.
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
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.
Re: Dutch ISPs to collaborate and take responsibility for botted clients
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? d...@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.
Re: Dutch ISPs to collaborate and take responsibility for botted clients
On Sun, Oct 4, 2009 at 2:55 PM, Peter Beckman wrote: > 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/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? d...@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
Re: Dutch ISPs to collaborate and take responsibility for botted clients
On Sun, 4 Oct 2009, Owen DeLong wrote: * 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. 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 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. 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 reconnect I 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 --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.com/ ---
Re: Dutch ISPs to collaborate and take responsibility for botted clients
On Sun, Oct 04, 2009 at 04:33:43AM -0700, Owen DeLong wrote: > 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. 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
Re: Dutch ISPs to collaborate and take responsibility for botted clients
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 smime.p7s Description: S/MIME cryptographic signature
Re: Dutch ISPs to collaborate and take responsibility for botted clients
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.
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
Hi! Sounds great but who cover the costs? If done right, such a treaty here in the US and elsewhere thing would be a major win for the Internet. The ISP's will pick up the costs. A cleaner customer base is also a win for them. First implementations wont be next week however but the start is beeing made. Bye, Raymond.
Re: Dutch ISPs to collaborate and take responsibility for bottedclients
Sounds great but who cover the costs? --Original Message-- From: Peter Beckman To: Gadi Evron Cc: NANOG Subject: Re: Dutch ISPs to collaborate and take responsibility for bottedclients Sent: Oct 3, 2009 7:18 PM 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 * 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 --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.com/ --- Sent from my BlackBerry device on the Rogers Wireless Network
Re: Dutch ISPs to collaborate and take responsibility for botted clients
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 * 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 --- Peter Beckman Internet Guy beck...@angryox.com http://www.angryox.com/ ---
