Re: Points on your Internet driver's license (was RE: Even you can
So you claim even the ISPs you ran yourself have never attempted to do any of these things?
the last access-side isp i had anything to do with running used uucp and shell and was just getting going on c-slip when i pushed off. (i assure that any rmail or rnews spam was grounds for suspension during my watch.) my last gig at a colo-side isp ended with me moving over to paix due to the board's discomfort over my policies toward certain colo-side customers (who have since improved, yay.)
If you didn't do them, why do you think other people should?
so you aren't going to google for "chemical polluter business model", huh?
On Sun, 13 Jun 2004, Paul Vixie wrote:
If you didn't do them, why do you think other people should?
so you aren't going to google for "chemical polluter business model", huh?
I hope you also google for Nonpoint Source Pollution. ISPs don't put the pollution in the water, ISPs are trying to clean up the water polluted by others. ISPs are spending a lot of money cleaning up problems created by other people.
On Sun, 13 Jun 2004, Paul Vixie wrote:
If you didn't do them, why do you think other people should?
so you aren't going to google for "chemical polluter business model", huh?
I hope you also google for Nonpoint Source Pollution.
ISPs don't put the pollution in the water, ISPs are trying to clean up the water polluted by others. ISPs are spending a lot of money cleaning up problems created by other people.
ISPs do put the pollution in the water. They own/run the pipes that carry the pollution into the ocean. Nobody cares about pollution inside the ISP's own network, we only care about the pollution they put into our water. They own, run, and manage the pipes that put the pollution where it can harm others. They have continuous control over the process and ultimately decide who does or does not put things into those pipes and influence the policies. I think there's a serious disconnect between how ISPs see this issue and how their customers do. I hold ISPs responsible for their customers behavior once they are aware of that behavior. It has been many years since "I just pass the traffic my customers tell me to pass" was an acceptable answer. In fact, ISPs that take that attitude are (properly) ostracized today. If an ISP knows or suspected or should know that their customer is putting pollution into the communal waters, they have an obligation to do whatever it takes to stop that pollution. If that's notifying the customer, disconnecting the customer, filtering, whatever, that's between the ISP and the customer. I'm willing to make all kinds of allowances for what is and is not possible. I don't expect a filter in minutes. I don't expect them to disconnect a customer because they couldn't reach them. However, I do expect them to track the issue with their customer until it's resolved. If they do not do so, I hold them responsible to the extent that I am able to do so. Again, as I said, this in no way diminishes the responsiblity of the customer, the author of the malware, the person who failed to install the patch, the person who misconfigured the firewall (or decided they really didn't need one). Responsibility does not have to sum to 100%, it's possible for any number of parties to be wholly responsible. It amazes me how quick ISPs are to blame others, as if this diminshes their responsibility. It does not. If I leave your car unlocked and someone steals your CDs, no amount of blame I place on the thief diminshes my responsibility. DS
davids@webmaster.com ("David Schwartz") writes:
ISPs don't put the pollution in the water, ISPs are trying to clean up the water polluted by others. ISPs are spending a lot of money cleaning up problems created by other people.
ISPs do put the pollution in the water. They own/run the pipes that carry the pollution into the ocean. Nobody cares about pollution inside the ISP's own network, we only care about the pollution they put into our water. They own, run, and manage
"and profit from"
the pipes that put the pollution where it can harm others. They have continuous control over the process and ultimately decide who does or does not put things into those pipes and influence the policies.
yea, verily. -- Paul Vixie
The real challenge here is that the "default" Internet service is wide-open Internet Protocol, w/o any safeties or controls. This made a lot of sense when the Internet was a few hundred sites, but is showing real scaling problems today (spam, major viruses, etc.) One could imagine changing the paradigm (never easy) so that the normal Internet service was proxied for common applications and NAT'ed for everything else... This wouldn't eliminate all the problems, but would dramatically cut down the incident rate. If a site wants wide-open access, just give it to them. If that turns out to cause operational problems (due to open mail proxies, spam origination, etc), then put 'em back behind the relays. /John
One could imagine changing the paradigm (never easy) so that the normal Internet service was proxied for common applications and NAT'ed for everything else... This wouldn't eliminate all the problems, but would dramatically cut down the incident rate.
If a site wants wide-open access, just give it to them. If that turns out to cause operational problems (due to open mail proxies, spam origination, etc), then put 'em back behind the relays.
guilty until proven innocent, eh? thanks mr ashcroft. randy
At 6:58 PM -0700 6/12/04, Randy Bush wrote:
One could imagine changing the paradigm (never easy) so that the normal Internet service was proxied for common applications and NAT'ed for everything else... This wouldn't eliminate all the problems, but would dramatically cut down the incident rate.
If a site wants wide-open access, just give it to them. If that turns out to cause operational problems (due to open mail proxies, spam origination, etc), then put 'em back behind the relays.
guilty until proven innocent, eh? thanks mr ashcroft.
Randy, are you objecting to the model for initial connectivity, or the throwing them back behind relays w/o a formal trial? /John
One could imagine changing the paradigm (never easy) so that the normal Internet service was proxied for common applications and NAT'ed for everything else... This wouldn't eliminate all the problems, but would dramatically cut down the incident rate.
If a site wants wide-open access, just give it to them. If that turns out to cause operational problems (due to open mail proxies, spam origination, etc), then put 'em back behind the relays.
guilty until proven innocent, eh? thanks mr ashcroft.
Randy, are you objecting to the model for initial connectivity, or the throwing them back behind relays w/o a formal trial?
the former, see previous post about the e2e internet if you can actually diagnose bad traffic, then you may have a right to act randy
On Sat, 12 Jun 2004, John Curran wrote:
One could imagine changing the paradigm (never easy) so that the normal Internet service was proxied for common applications and NAT'ed for everything else... This wouldn't eliminate all the problems, but would dramatically cut down the incident rate.
In the BBS days, how did most viruses get on computers? Have things really changed that much? Take a look how computers are being compromised. Its amazing just how many compromised computers have NAT, firewalls, proxies, etc. 1) pre-infected, i.e. already compromised before connecting to your network (laptops are dangerous) 2) self-infected, i.e. compromised because the user installed the software containing the virus 3) network-infected, i.e. compromised solely by being connected without any action by the user Some broadband providers have been selling service that includes a NAT/firewall on the connection for several years. What is the difference in infection rate of those users? Is it just wishfull thinking by some people that NAT/firewalls/proxies will solve the problem? Or do they have hard data to back them up? Preventing users from compromising their computers is a lot like preventing users from accessing porn or music. Basically anything the user wants could be potentially harmful, and the miscreants know that. So how do you make sure users can only access "safe" content?
Sean... Bigger and more important questions than "How do you make sure your users only access safe content?" are: 1. Should you? It is very hard for me to distinguish this from censorship in my mind. No, I'm not saying malware doesn't violate community standards of decency. However, so do obscene phone calls. TPC is not expected to block all obscene phone calls. They are expected to assist in the investigation and termination of repeated abuse. I think ISPs should be held to that same standard. Anything more treads a slippery slope. 2. Who defines "safe" content? Is porn safe? Is <freeapp> (with it's well known spyware and other adjuncts) safe? Is <peertopeer> safe, with it's well known tendency to support copyright infringement? Is the web safe, given the various malware activex components, javascript bugs in browsers, etc.? I like deciding for my self what risks I will take. I really don't want my ISP making those choices for me. Owen
On Sat, 12 Jun 2004, John Curran wrote:
The real challenge here is that the "default" Internet service is wide-open Internet Protocol, w/o any safeties or controls. This made a lot of sense when the Internet was a few hundred sites, but is showing real scaling problems today (spam, major viruses, etc.)
One could imagine changing the paradigm (never easy) so that the normal Internet service was proxied for common applications and NAT'ed for everything else... This wouldn't eliminate all the problems, but would dramatically cut down the incident rate.
This sounds like a fantastic idea, for instance: How much direct IP does joe-average Internet user really require? Do they require anything more than imap(s)/pop(s)/smtp(+tls) and dns/http/https ? I suppose they also need: 1) internet gaming 2) voip 3) kazaa/p2p-app(s)-of-choice 4) IM Actually I'm sure there are quite a few things they need, things which require either very smart NAT/Proxy devices or open access. The filtering of IP on the broad scale will hamper creativity and innovation. I'm fairly certain this was not what we want in the long term, is it?
If a site wants wide-open access, just give it to them. If that turns out to cause operational problems (due to open mail proxies, spam origination, etc), then put 'em back behind the relays.
We have methods of dealing with these abuse problems today, unfortanately as Paul Vixie often points out there are business reasons why these problems persist. Often the 'business' reason isn't the tin-foil-hat-brigade's reason so much as 'we can't afford to keep these abuse folks around since they don't make money for the company'. Downstream from the ISP, the individuals are not taking responsibility for their actions/in-actions with respect to 'security'. Vendors are not providing safe environments for their consumers either. I understand that shipping an OS with 100% of things enabled might 'foster innovation' or 'make things easier for the end user', however, so would well thought instructions for enabling (safely) these same features. 99% of computer users never ever need to share files, yet file sharing is enabled by defailt on some operating systems... This is a major vector for infection and abuse. Education and awareness are also lacking in the industry as a whole, well not the 'industry' so much as 'the culture' I think. "Why should anyone want to hack my machine? I'm not some big corporation with lots of 'secrets'." No, they want your machine for the simple fact it's connected to the global Internet and it's NOT their ip address so abuse of it won't harm 'them' :( -Chris
At 4:21 AM +0000 6/13/04, Christopher L. Morrow wrote:
We have methods of dealing with these abuse problems today, unfortanately as Paul Vixie often points out there are business reasons why these problems persist. Often the 'business' reason isn't the tin-foil-hat-brigade's reason so much as 'we can't afford to keep these abuse folks around since they don't make money for the company'.
I'll argue that we have don't effective methods of dealing with this today, and it's not the lack of abuse desk people as much as the philosophy of closing barn doors after the fact. The idea that we can leave everything wide open for automated exploit tools, and then clean up afterwards manually with labor-intensive efforts is fundamentally flawed. /John
On Sun, 13 Jun 2004, John Curran wrote:
At 4:21 AM +0000 6/13/04, Christopher L. Morrow wrote:
We have methods of dealing with these abuse problems today, unfortanately as Paul Vixie often points out there are business reasons why these problems persist. Often the 'business' reason isn't the tin-foil-hat-brigade's reason so much as 'we can't afford to keep these abuse folks around since they don't make money for the company'.
I'll argue that we have don't effective methods of dealing with this today, and it's not the lack of abuse desk people as much as the philosophy of closing barn doors after the fact. The idea that we can leave everything wide open for automated exploit tools, and then clean up afterwards manually with labor-intensive efforts is fundamentally flawed.
that was the last part of my post, initial installs and supportable (end user supportable) security really is the only way. (or that's my thoughts)
We have methods of dealing with these abuse problems today, unfortanately as Paul Vixie often points out there are business reasons why these problems persist. Often the 'business' reason isn't the tin-foil- hat-brigade's reason so much as 'we can't afford to keep these abuse folks around since they don't make money for the company'.
I'll argue that we have don't effective methods of dealing with this today, and it's not the lack of abuse desk people as much as the philosophy of closing barn doors after the fact. The idea that we can leave everything wide open for automated exploit tools, and then clean up afterwards manually with labor-intensive efforts is fundamentally flawed.
and i'd agree. the trouble, when this problem was first isolated, was that the costs and benefits were assymetric. the people who needed the added services (filtering, training, remote OS upgrades/audits/management, etc) were the ones least able/willing to pay extra for those services. the folks who didn't need them have always complained that they have to pay more to avoid getting them. now, though, there's an opportunity to do a marketing U-turn on this. cable and dsl providers in the USA can point to the national cybersecurity plan and say that to comply with it they have to put infected computers in cyberjail, with a fee of $N to get these machines audited, and if found clean, put back on the net, noting that N doubles every time this process is invoked, and that a deposit of $(0.5*N) is required as prepayment for the next incident, refundable after one year if there are no further incidents. then offer to remotely manage their host ("give me your root passwords, trust me!") for an annual fee of $(0.75*N). if the initial value of N were $500, you might be able to get the people who need this service to pay for it. it's worth a try? -- Paul Vixie
----- Original Message ----- From: "Paul Vixie" <vixie@vix.com> : : now, though, there's an opportunity to do a marketing U-turn on this. cable : and dsl providers in the USA can point to the national cybersecurity plan and : say that to comply with it they have to put infected computers in cyberjail, : with a fee of $N to get these machines audited, and if found clean, put back : on the net, noting that N doubles every time this process is invoked, and : that a deposit of $(0.5*N) is required as prepayment for the next incident, : refundable after one year if there are no further incidents. then offer to : remotely manage their host ("give me your root passwords, trust me!") for an : annual fee of $(0.75*N). if the initial value of N were $500, you might be : able to get the people who need this service to pay for it. it's worth a try? : -- : Paul Vixie : If I read Paul's post correctly, then I would have to agree that the costs of cleaning up the problem customers should be placed on the customer (miscreant) as opposed to the rest of us. This would be far more preferable than putting in place controls by the respective ISP that would limit my own use of my connection, on which I have spent considerable time, money and education to make sure it is secure and beyond that, compliant with the ISP Acceptable Use policies. Doug
On Sun, 13 Jun 2004, Doug White wrote:
----- Original Message ----- From: "Paul Vixie" <vixie@vix.com>
: remotely manage their host ("give me your root passwords, trust me!") for an : annual fee of $(0.75*N). if the initial value of N were $500, you might be : able to get the people who need this service to pay for it. it's worth a try? : -- : Paul Vixie :
If I read Paul's post correctly, then I would have to agree that the costs of cleaning up the problem customers should be placed on the customer (miscreant)
the 'customer' is most often NOT the 'miscreant', they are more often than not your mother/sister/brother/innocent-user#35 penalizing them is a touchy proposition. -Chris
the 'customer' is most often NOT the 'miscreant', they are more often than not your mother/sister/brother/innocent-user#35 penalizing them is a touchy proposition.
Well... I suggested that there should be a one-incident free policy at the beginning of this process. I'll stick to that. In that case, the customer that is my mother/sister/brother/innocent-user#35 gets an education and knows that they need to work to prevent this in the future. If they fail to do so, then they pay the cleanup costs. Seems perfectly reasonable to me. I have no problem with that model. Owen -- If it wasn't crypto-signed, it probably didn't come from me.
doug@clickdoug.com ("Doug White") writes:
If I read Paul's post correctly, then I would have to agree that the costs of cleaning up the problem customers should be placed on the customer (miscreant) as opposed to the rest of us.
and if you read the other post last night you'll see that this has to be fixed and that the money to fix it has to come from somewhere and that if making cable/dsl subscribers pay more if they need these services won't work, then making cable/dsl subscribes pay more if they don't need these services would have to remain the norm (it's already the norm.)
This would be far more preferable than putting in place controls by the respective ISP that would limit my own use of my connection, on which I have spent considerable time, money and education to make sure it is secure and beyond that, compliant with the ISP Acceptable Use policies.
i agree that making users like you describe pay more is senseless. but what really burns me is that you're made to pay more, but the cable/dsl company just pockets the money rather than allocating it toward filtering cleaning or otherwise dealing with the effluent dumped into the stream as a side effect of their operations. --- which brings us back to the chemical polluter business model, and sean. sean's been whining for a while about how it's not reasonable for large masses of pollution victims to boycott all output from his factory, since there's good mixed in with the bad. this all seems like throwing out the baby with the bathwater the way sean looks at things. so, let me be very clear about what i mean and what i want. what follows is a list of hits in my darkspace IDS from one of sean's networks, just for demonstration purposes. what i want is: 1. sean make some effort to discover these on his own rather than waiting to be told about them by victims. 2. sean believe me (and other qualified victims) when i report them. 3. verified reports result in immediate customer service suspension. 4. the customer be required to either attend training or pay a fine or both. 5. the customer's machine be audited before reconnection. 6. sean should ask the FCC to require this behaviour of his competitors also. 7. sean should stop whining about how i reject all traffic from his customers. note that the list below has ~600 entries and is just a /19 out of a larger /12. the listing for the /12 is Quite Large and would not be instructive. SELECT MIN(DATE(entered)) AS earliest, MAX(DATE(entered)) AS latest, srcaddr, COUNT(srcaddr) FROM trans WHERE srcaddr << '63.202.104.0/19' GROUP BY srcaddr ORDER BY srcaddr; earliest | latest | srcaddr | count ------------+------------+----------------+------- 2004-04-13 | 2004-04-13 | 63.202.96.65 | 1 2004-04-08 | 2004-04-08 | 63.202.96.67 | 1 2004-03-19 | 2004-03-19 | 63.202.96.69 | 1 2004-03-18 | 2004-03-18 | 63.202.98.234 | 1 2004-04-17 | 2004-04-17 | 63.202.104.9 | 1 2003-01-19 | 2003-01-19 | 63.202.104.10 | 1 2004-03-28 | 2004-03-28 | 63.202.104.14 | 1 2004-03-22 | 2004-03-22 | 63.202.104.24 | 1 2004-05-29 | 2004-05-29 | 63.202.104.28 | 1 2004-03-30 | 2004-03-30 | 63.202.104.32 | 1 2004-03-29 | 2004-03-29 | 63.202.104.37 | 1 2004-04-14 | 2004-04-14 | 63.202.104.46 | 1 2004-03-22 | 2004-03-22 | 63.202.104.48 | 1 2004-04-19 | 2004-04-19 | 63.202.104.50 | 1 2004-03-17 | 2004-03-17 | 63.202.104.51 | 1 2004-04-01 | 2004-04-01 | 63.202.104.52 | 1 2004-03-26 | 2004-03-26 | 63.202.104.59 | 1 2004-05-07 | 2004-05-07 | 63.202.104.60 | 1 2004-03-18 | 2004-03-18 | 63.202.104.68 | 1 2004-04-08 | 2004-04-08 | 63.202.104.70 | 1 2004-01-01 | 2004-03-24 | 63.202.104.77 | 2 2003-10-28 | 2003-10-28 | 63.202.104.80 | 1 2004-03-20 | 2004-03-20 | 63.202.104.82 | 2 2004-03-26 | 2004-03-26 | 63.202.104.84 | 1 2004-04-04 | 2004-04-04 | 63.202.104.88 | 1 2004-04-03 | 2004-04-03 | 63.202.104.89 | 1 2003-01-12 | 2003-01-12 | 63.202.104.93 | 1 2003-04-14 | 2003-04-14 | 63.202.104.98 | 2 2004-03-17 | 2004-03-17 | 63.202.104.101 | 1 2004-04-03 | 2004-04-03 | 63.202.104.109 | 1 2004-02-12 | 2004-02-12 | 63.202.104.110 | 1 2004-04-20 | 2004-04-20 | 63.202.104.111 | 1 2004-03-29 | 2004-03-29 | 63.202.104.118 | 1 2004-04-08 | 2004-04-08 | 63.202.104.121 | 1 2003-10-01 | 2003-10-01 | 63.202.104.126 | 1 2004-03-17 | 2004-03-17 | 63.202.104.130 | 1 2004-05-04 | 2004-05-04 | 63.202.104.133 | 1 2004-05-05 | 2004-05-05 | 63.202.104.145 | 1 2003-10-05 | 2004-04-11 | 63.202.104.154 | 2 2004-03-20 | 2004-03-20 | 63.202.104.155 | 1 2004-04-12 | 2004-04-12 | 63.202.104.157 | 1 2004-05-28 | 2004-05-28 | 63.202.104.159 | 1 2003-08-25 | 2003-08-25 | 63.202.104.161 | 1 2004-05-05 | 2004-05-05 | 63.202.104.164 | 1 2004-04-18 | 2004-04-18 | 63.202.104.165 | 1 2004-04-21 | 2004-04-21 | 63.202.104.169 | 1 2004-05-05 | 2004-05-05 | 63.202.104.171 | 1 2003-12-02 | 2003-12-02 | 63.202.104.173 | 1 2004-03-30 | 2004-03-30 | 63.202.104.176 | 1 2004-03-21 | 2004-03-21 | 63.202.104.178 | 1 2004-04-02 | 2004-04-02 | 63.202.104.180 | 1 2004-04-10 | 2004-04-10 | 63.202.104.184 | 1 2003-10-03 | 2003-10-04 | 63.202.104.186 | 2 2003-08-29 | 2003-08-29 | 63.202.104.195 | 1 2003-09-06 | 2003-09-06 | 63.202.104.198 | 1 2003-12-10 | 2003-12-10 | 63.202.104.204 | 1 2003-10-09 | 2004-05-14 | 63.202.104.211 | 2 2003-12-07 | 2003-12-07 | 63.202.104.218 | 1 2004-03-18 | 2004-03-18 | 63.202.104.219 | 1 2003-09-28 | 2003-09-28 | 63.202.104.222 | 1 2003-10-12 | 2003-10-12 | 63.202.104.226 | 1 2004-04-17 | 2004-04-17 | 63.202.104.230 | 1 2004-04-11 | 2004-04-11 | 63.202.104.240 | 1 2004-04-21 | 2004-04-21 | 63.202.104.241 | 1 2004-04-13 | 2004-04-13 | 63.202.104.242 | 1 2004-04-18 | 2004-04-18 | 63.202.104.245 | 1 2004-03-29 | 2004-03-29 | 63.202.104.253 | 1 2004-05-30 | 2004-05-30 | 63.202.105.9 | 1 2004-03-28 | 2004-03-28 | 63.202.105.15 | 1 2004-04-26 | 2004-04-26 | 63.202.105.31 | 1 2004-03-25 | 2004-03-25 | 63.202.105.35 | 1 2003-11-30 | 2004-04-10 | 63.202.105.39 | 2 2004-04-22 | 2004-04-22 | 63.202.105.44 | 1 2004-04-19 | 2004-04-19 | 63.202.105.46 | 1 2004-04-11 | 2004-04-11 | 63.202.105.50 | 1 2004-05-13 | 2004-05-13 | 63.202.105.54 | 1 2003-10-31 | 2003-10-31 | 63.202.105.57 | 1 2003-08-26 | 2004-03-18 | 63.202.105.68 | 3 2003-09-29 | 2003-09-29 | 63.202.105.69 | 1 2003-09-09 | 2004-03-30 | 63.202.105.70 | 2 2004-03-21 | 2004-03-21 | 63.202.105.71 | 1 2003-09-19 | 2004-05-08 | 63.202.105.77 | 2 2003-11-19 | 2003-11-19 | 63.202.105.86 | 1 2004-05-13 | 2004-05-13 | 63.202.105.88 | 1 2004-04-14 | 2004-04-14 | 63.202.105.90 | 1 2004-05-12 | 2004-05-12 | 63.202.105.91 | 1 2004-04-17 | 2004-04-17 | 63.202.105.94 | 1 2004-05-12 | 2004-05-12 | 63.202.105.99 | 1 2003-12-16 | 2003-12-16 | 63.202.105.110 | 1 2003-12-13 | 2003-12-13 | 63.202.105.116 | 1 2004-03-26 | 2004-03-26 | 63.202.105.123 | 1 2003-12-31 | 2003-12-31 | 63.202.105.125 | 1 2004-05-09 | 2004-05-09 | 63.202.105.128 | 1 2004-03-29 | 2004-03-29 | 63.202.105.131 | 1 2004-05-11 | 2004-05-11 | 63.202.105.135 | 1 2004-03-20 | 2004-03-20 | 63.202.105.142 | 1 2004-05-07 | 2004-05-07 | 63.202.105.144 | 1 2003-01-17 | 2003-01-17 | 63.202.105.147 | 2 2003-11-12 | 2003-11-12 | 63.202.105.149 | 1 2004-05-12 | 2004-05-12 | 63.202.105.155 | 1 2004-04-15 | 2004-04-15 | 63.202.105.163 | 1 2004-03-21 | 2004-03-21 | 63.202.105.164 | 1 2003-05-02 | 2003-05-07 | 63.202.105.171 | 31 2004-05-09 | 2004-05-09 | 63.202.105.173 | 1 2004-05-15 | 2004-05-15 | 63.202.105.186 | 1 2004-03-18 | 2004-03-18 | 63.202.105.192 | 2 2004-05-11 | 2004-05-11 | 63.202.105.196 | 1 2004-04-23 | 2004-04-23 | 63.202.105.199 | 1 2004-03-31 | 2004-03-31 | 63.202.105.200 | 1 2004-04-27 | 2004-04-27 | 63.202.105.204 | 1 2003-11-22 | 2004-03-28 | 63.202.105.208 | 2 2004-04-26 | 2004-04-26 | 63.202.105.214 | 1 2004-03-19 | 2004-03-19 | 63.202.105.221 | 1 2004-03-20 | 2004-03-20 | 63.202.105.223 | 1 2004-04-21 | 2004-04-21 | 63.202.105.226 | 1 2004-04-28 | 2004-04-28 | 63.202.105.227 | 1 2004-05-28 | 2004-05-28 | 63.202.105.228 | 1 2003-07-16 | 2003-07-22 | 63.202.105.230 | 90 2004-04-12 | 2004-04-12 | 63.202.105.236 | 1 2003-10-05 | 2003-10-05 | 63.202.105.238 | 1 2003-03-30 | 2003-03-30 | 63.202.105.239 | 1 2003-09-03 | 2003-09-03 | 63.202.105.245 | 1 2004-05-14 | 2004-05-14 | 63.202.105.249 | 1 2004-03-25 | 2004-03-25 | 63.202.105.250 | 1 2003-11-25 | 2003-11-25 | 63.202.105.251 | 1 2004-04-06 | 2004-04-06 | 63.202.106.0 | 1 2004-04-02 | 2004-04-02 | 63.202.106.1 | 1 2004-04-26 | 2004-04-26 | 63.202.106.3 | 1 2003-10-28 | 2003-10-28 | 63.202.106.5 | 1 2003-05-28 | 2003-05-28 | 63.202.106.7 | 3 2004-04-11 | 2004-04-11 | 63.202.106.8 | 1 2004-04-01 | 2004-04-01 | 63.202.106.9 | 1 2004-03-25 | 2004-03-25 | 63.202.106.14 | 1 2004-03-21 | 2004-03-21 | 63.202.106.17 | 1 2004-05-07 | 2004-05-07 | 63.202.106.22 | 1 2003-05-18 | 2003-05-18 | 63.202.106.26 | 3 2004-04-21 | 2004-04-21 | 63.202.106.28 | 2 2004-05-07 | 2004-05-07 | 63.202.106.29 | 1 2004-03-31 | 2004-03-31 | 63.202.106.33 | 1 2004-04-19 | 2004-04-19 | 63.202.106.47 | 1 2004-04-22 | 2004-04-22 | 63.202.106.50 | 1 2004-04-17 | 2004-04-17 | 63.202.106.51 | 1 2004-05-14 | 2004-05-14 | 63.202.106.55 | 1 2003-04-18 | 2003-04-18 | 63.202.106.67 | 2 2004-04-24 | 2004-04-24 | 63.202.106.68 | 1 2004-04-30 | 2004-04-30 | 63.202.106.69 | 1 2004-03-20 | 2004-03-20 | 63.202.106.72 | 1 2003-12-04 | 2003-12-04 | 63.202.106.82 | 1 2004-04-25 | 2004-04-25 | 63.202.106.85 | 1 2003-05-18 | 2003-05-18 | 63.202.106.87 | 1 2004-05-13 | 2004-05-13 | 63.202.106.92 | 1 2004-05-28 | 2004-05-28 | 63.202.106.93 | 1 2004-04-01 | 2004-04-01 | 63.202.106.94 | 1 2004-04-11 | 2004-04-11 | 63.202.106.95 | 1 2004-04-22 | 2004-04-22 | 63.202.106.98 | 1 2004-04-10 | 2004-04-10 | 63.202.106.104 | 1 2004-05-12 | 2004-05-12 | 63.202.106.106 | 1 2003-07-15 | 2003-07-15 | 63.202.106.108 | 1 2004-05-13 | 2004-05-13 | 63.202.106.111 | 1 2004-05-27 | 2004-05-27 | 63.202.106.113 | 1 2003-11-14 | 2004-03-17 | 63.202.106.127 | 2 2004-04-21 | 2004-04-21 | 63.202.106.129 | 1 2004-04-12 | 2004-04-12 | 63.202.106.130 | 1 2004-04-16 | 2004-04-16 | 63.202.106.137 | 1 2004-04-20 | 2004-04-20 | 63.202.106.139 | 1 2004-02-18 | 2004-02-18 | 63.202.106.140 | 1 2004-03-25 | 2004-03-25 | 63.202.106.142 | 1 2003-11-21 | 2003-11-21 | 63.202.106.143 | 1 2004-05-10 | 2004-05-10 | 63.202.106.145 | 1 2003-12-01 | 2003-12-12 | 63.202.106.149 | 2 2004-03-27 | 2004-03-27 | 63.202.106.150 | 1 2003-09-01 | 2004-04-07 | 63.202.106.151 | 2 2003-09-27 | 2003-09-27 | 63.202.106.155 | 1 2004-04-30 | 2004-04-30 | 63.202.106.159 | 1 2004-03-27 | 2004-03-27 | 63.202.106.163 | 1 2004-04-04 | 2004-04-04 | 63.202.106.167 | 1 2004-04-14 | 2004-04-14 | 63.202.106.170 | 1 2004-03-21 | 2004-03-21 | 63.202.106.181 | 1 2003-04-30 | 2003-04-30 | 63.202.106.182 | 1 2004-05-02 | 2004-05-02 | 63.202.106.183 | 1 2003-08-28 | 2003-08-28 | 63.202.106.186 | 1 2003-10-14 | 2003-10-14 | 63.202.106.195 | 1 2004-03-26 | 2004-03-26 | 63.202.106.197 | 1 2004-03-26 | 2004-03-26 | 63.202.106.205 | 1 2004-05-02 | 2004-05-02 | 63.202.106.206 | 1 2004-03-31 | 2004-03-31 | 63.202.106.215 | 1 2004-03-28 | 2004-03-28 | 63.202.106.219 | 1 2004-03-25 | 2004-03-25 | 63.202.106.220 | 1 2004-04-16 | 2004-04-16 | 63.202.106.223 | 1 2003-10-14 | 2003-10-21 | 63.202.106.231 | 2 2004-04-27 | 2004-04-27 | 63.202.106.232 | 1 2004-04-08 | 2004-04-08 | 63.202.106.234 | 1 2004-03-24 | 2004-03-24 | 63.202.106.235 | 1 2004-04-23 | 2004-04-23 | 63.202.106.246 | 1 2004-04-27 | 2004-04-27 | 63.202.107.0 | 1 2004-01-04 | 2004-05-01 | 63.202.107.8 | 3 2003-12-09 | 2003-12-09 | 63.202.107.11 | 1 2003-01-10 | 2003-01-12 | 63.202.107.12 | 4 2004-04-14 | 2004-04-14 | 63.202.107.13 | 1 2004-03-19 | 2004-03-19 | 63.202.107.18 | 1 2004-05-10 | 2004-05-10 | 63.202.107.21 | 1 2004-04-04 | 2004-04-04 | 63.202.107.25 | 1 2004-04-11 | 2004-04-11 | 63.202.107.29 | 1 2004-04-16 | 2004-04-16 | 63.202.107.33 | 1 2004-02-14 | 2004-02-14 | 63.202.107.36 | 1 2003-12-20 | 2003-12-20 | 63.202.107.42 | 1 2004-04-09 | 2004-04-09 | 63.202.107.48 | 1 2004-03-17 | 2004-03-17 | 63.202.107.56 | 1 2004-03-23 | 2004-03-23 | 63.202.107.59 | 1 2004-04-10 | 2004-04-10 | 63.202.107.60 | 1 2004-03-21 | 2004-03-21 | 63.202.107.61 | 1 2003-09-11 | 2003-09-11 | 63.202.107.62 | 1 2004-03-24 | 2004-03-24 | 63.202.107.64 | 1 2004-04-14 | 2004-04-14 | 63.202.107.67 | 1 2003-05-12 | 2003-05-12 | 63.202.107.68 | 1 2004-04-14 | 2004-05-17 | 63.202.107.71 | 2 2004-05-03 | 2004-05-03 | 63.202.107.72 | 1 2004-05-02 | 2004-05-02 | 63.202.107.76 | 1 2004-03-21 | 2004-03-21 | 63.202.107.79 | 1 2004-03-22 | 2004-03-22 | 63.202.107.81 | 1 2003-11-29 | 2003-11-29 | 63.202.107.82 | 1 2004-03-08 | 2004-03-08 | 63.202.107.83 | 1 2003-11-21 | 2003-11-21 | 63.202.107.90 | 1 2003-11-19 | 2003-11-19 | 63.202.107.91 | 1 2004-03-31 | 2004-03-31 | 63.202.107.92 | 1 2004-04-04 | 2004-04-04 | 63.202.107.93 | 1 2004-04-28 | 2004-04-28 | 63.202.107.104 | 1 2004-05-07 | 2004-05-07 | 63.202.107.107 | 1 2004-04-09 | 2004-04-09 | 63.202.107.109 | 1 2004-05-07 | 2004-05-07 | 63.202.107.115 | 1 2004-05-27 | 2004-05-27 | 63.202.107.116 | 1 2004-03-18 | 2004-03-18 | 63.202.107.119 | 1 2004-05-08 | 2004-05-08 | 63.202.107.120 | 1 2004-05-03 | 2004-05-03 | 63.202.107.121 | 1 2004-04-03 | 2004-04-03 | 63.202.107.123 | 1 2004-03-21 | 2004-03-21 | 63.202.107.129 | 1 2004-04-02 | 2004-04-02 | 63.202.107.134 | 1 2003-12-02 | 2003-12-02 | 63.202.107.135 | 1 2003-09-07 | 2004-04-29 | 63.202.107.151 | 2 2003-05-12 | 2004-03-24 | 63.202.107.154 | 3 2004-04-21 | 2004-04-21 | 63.202.107.155 | 1 2004-04-22 | 2004-04-22 | 63.202.107.157 | 1 2004-03-26 | 2004-03-26 | 63.202.107.160 | 1 2004-05-09 | 2004-05-09 | 63.202.107.161 | 1 2004-04-09 | 2004-04-09 | 63.202.107.169 | 1 2004-03-23 | 2004-03-23 | 63.202.107.170 | 1 2004-04-01 | 2004-04-01 | 63.202.107.171 | 1 2004-04-21 | 2004-04-21 | 63.202.107.176 | 1 2004-05-01 | 2004-05-01 | 63.202.107.177 | 1 2004-05-11 | 2004-05-11 | 63.202.107.178 | 1 2004-04-29 | 2004-04-29 | 63.202.107.179 | 1 2003-09-21 | 2003-09-21 | 63.202.107.180 | 1 2004-04-10 | 2004-04-10 | 63.202.107.182 | 1 2004-04-01 | 2004-04-01 | 63.202.107.184 | 1 2004-04-29 | 2004-04-29 | 63.202.107.185 | 1 2004-03-31 | 2004-03-31 | 63.202.107.206 | 1 2004-04-28 | 2004-04-28 | 63.202.107.209 | 1 2003-02-14 | 2003-02-25 | 63.202.107.214 | 57 2003-05-21 | 2003-05-21 | 63.202.107.215 | 1 2004-03-31 | 2004-03-31 | 63.202.107.218 | 1 2004-04-24 | 2004-04-24 | 63.202.107.226 | 1 2004-03-30 | 2004-03-30 | 63.202.107.231 | 1 2004-03-28 | 2004-03-28 | 63.202.107.241 | 1 2003-09-09 | 2004-03-19 | 63.202.107.242 | 2 2004-04-17 | 2004-04-17 | 63.202.107.243 | 1 2004-04-19 | 2004-04-19 | 63.202.107.246 | 1 2003-10-01 | 2004-05-30 | 63.202.107.251 | 2 2004-05-28 | 2004-05-28 | 63.202.107.252 | 1 2004-05-07 | 2004-05-07 | 63.202.108.5 | 1 2004-03-21 | 2004-03-21 | 63.202.108.8 | 1 2004-05-06 | 2004-05-06 | 63.202.108.9 | 1 2004-05-07 | 2004-05-07 | 63.202.108.10 | 1 2004-04-21 | 2004-04-21 | 63.202.108.12 | 1 2003-12-24 | 2003-12-24 | 63.202.108.13 | 1 2004-03-22 | 2004-03-22 | 63.202.108.14 | 1 2004-04-27 | 2004-04-27 | 63.202.108.15 | 1 2004-05-31 | 2004-05-31 | 63.202.108.17 | 1 2004-03-26 | 2004-03-26 | 63.202.108.29 | 1 2004-03-19 | 2004-03-19 | 63.202.108.35 | 1 2004-04-07 | 2004-04-07 | 63.202.108.37 | 1 2002-12-11 | 2002-12-11 | 63.202.108.40 | 96 2004-03-24 | 2004-03-24 | 63.202.108.50 | 1 2003-09-05 | 2003-09-07 | 63.202.108.51 | 3 2004-04-29 | 2004-04-29 | 63.202.108.55 | 1 2003-01-19 | 2003-01-19 | 63.202.108.57 | 1 2003-10-02 | 2003-10-02 | 63.202.108.61 | 1 2003-10-15 | 2003-10-15 | 63.202.108.63 | 1 2003-09-15 | 2003-09-15 | 63.202.108.72 | 1 2003-10-17 | 2003-10-17 | 63.202.108.73 | 1 2004-03-22 | 2004-03-22 | 63.202.108.76 | 1 2003-11-07 | 2003-11-07 | 63.202.108.78 | 1 2004-03-31 | 2004-03-31 | 63.202.108.80 | 1 2004-04-26 | 2004-04-26 | 63.202.108.81 | 1 2004-04-03 | 2004-04-03 | 63.202.108.88 | 1 2003-08-29 | 2003-08-29 | 63.202.108.89 | 1 2004-04-16 | 2004-04-16 | 63.202.108.96 | 1 2004-04-24 | 2004-04-28 | 63.202.108.99 | 4 2004-04-04 | 2004-04-04 | 63.202.108.101 | 1 2004-03-17 | 2004-03-17 | 63.202.108.105 | 1 2004-03-19 | 2004-03-19 | 63.202.108.110 | 1 2004-02-14 | 2004-02-14 | 63.202.108.111 | 1 2004-04-17 | 2004-04-17 | 63.202.108.112 | 1 2004-03-17 | 2004-03-17 | 63.202.108.115 | 1 2004-05-14 | 2004-05-14 | 63.202.108.127 | 1 2004-03-17 | 2004-03-17 | 63.202.108.135 | 1 2004-03-24 | 2004-03-24 | 63.202.108.140 | 1 2004-04-16 | 2004-04-16 | 63.202.108.142 | 1 2003-09-01 | 2003-09-01 | 63.202.108.144 | 1 2004-03-17 | 2004-03-17 | 63.202.108.149 | 1 2003-03-14 | 2003-03-15 | 63.202.108.160 | 3 2004-03-28 | 2004-03-28 | 63.202.108.164 | 1 2004-03-26 | 2004-03-26 | 63.202.108.168 | 1 2004-04-17 | 2004-04-17 | 63.202.108.170 | 1 2004-03-20 | 2004-03-20 | 63.202.108.171 | 1 2004-03-19 | 2004-03-19 | 63.202.108.176 | 1 2004-05-07 | 2004-05-07 | 63.202.108.180 | 1 2004-03-27 | 2004-03-27 | 63.202.108.182 | 2 2004-03-27 | 2004-03-27 | 63.202.108.183 | 1 2003-02-14 | 2004-04-09 | 63.202.108.184 | 3 2004-05-09 | 2004-05-09 | 63.202.108.195 | 1 2004-03-24 | 2004-03-24 | 63.202.108.202 | 1 2004-04-12 | 2004-04-12 | 63.202.108.203 | 1 2004-03-24 | 2004-03-24 | 63.202.108.207 | 1 2004-04-18 | 2004-04-18 | 63.202.108.208 | 1 2004-03-23 | 2004-03-23 | 63.202.108.221 | 1 2004-05-10 | 2004-05-10 | 63.202.108.223 | 1 2003-03-15 | 2003-03-15 | 63.202.108.232 | 1 2004-05-07 | 2004-05-07 | 63.202.108.236 | 1 2004-03-24 | 2004-03-24 | 63.202.108.239 | 1 2004-03-13 | 2004-03-13 | 63.202.108.240 | 1 2004-04-02 | 2004-04-02 | 63.202.108.243 | 1 2004-03-27 | 2004-03-27 | 63.202.108.247 | 1 2004-03-29 | 2004-03-29 | 63.202.108.249 | 2 2004-04-07 | 2004-04-07 | 63.202.108.250 | 1 2004-04-13 | 2004-04-13 | 63.202.108.255 | 1 2004-04-09 | 2004-04-09 | 63.202.109.0 | 1 2004-03-26 | 2004-03-26 | 63.202.109.7 | 1 2003-09-09 | 2003-09-09 | 63.202.109.10 | 1 2004-04-14 | 2004-04-14 | 63.202.109.12 | 1 2004-05-28 | 2004-05-28 | 63.202.109.13 | 1 2004-04-10 | 2004-04-10 | 63.202.109.16 | 1 2004-03-18 | 2004-03-18 | 63.202.109.21 | 1 2004-05-05 | 2004-05-05 | 63.202.109.22 | 1 2004-05-06 | 2004-05-06 | 63.202.109.26 | 1 2004-03-30 | 2004-03-30 | 63.202.109.29 | 1 2004-05-11 | 2004-05-11 | 63.202.109.32 | 1 2003-05-05 | 2003-05-05 | 63.202.109.36 | 1 2004-04-07 | 2004-04-07 | 63.202.109.37 | 1 2004-05-12 | 2004-05-12 | 63.202.109.40 | 1 2004-03-29 | 2004-03-29 | 63.202.109.41 | 1 2004-04-09 | 2004-04-09 | 63.202.109.42 | 1 2004-04-14 | 2004-04-14 | 63.202.109.43 | 1 2004-03-27 | 2004-03-27 | 63.202.109.45 | 1 2004-05-29 | 2004-05-29 | 63.202.109.51 | 1 2003-01-19 | 2004-05-30 | 63.202.109.53 | 2 2004-04-26 | 2004-04-26 | 63.202.109.58 | 1 2004-03-20 | 2004-03-20 | 63.202.109.60 | 1 2004-04-18 | 2004-04-18 | 63.202.109.62 | 1 2004-04-25 | 2004-04-25 | 63.202.109.65 | 1 2004-04-19 | 2004-04-19 | 63.202.109.71 | 1 2004-03-31 | 2004-03-31 | 63.202.109.74 | 1 2004-03-25 | 2004-03-25 | 63.202.109.78 | 1 2004-05-13 | 2004-05-13 | 63.202.109.81 | 1 2003-10-10 | 2003-10-10 | 63.202.109.84 | 1 2004-04-11 | 2004-04-11 | 63.202.109.90 | 1 2004-05-08 | 2004-05-08 | 63.202.109.93 | 1 2003-09-22 | 2003-12-01 | 63.202.109.94 | 2 2004-04-13 | 2004-04-13 | 63.202.109.95 | 1 2003-10-25 | 2003-10-25 | 63.202.109.105 | 1 2004-05-11 | 2004-05-11 | 63.202.109.108 | 1 2003-01-18 | 2003-01-18 | 63.202.109.112 | 3 2004-05-27 | 2004-05-27 | 63.202.109.114 | 1 2004-04-07 | 2004-04-07 | 63.202.109.116 | 1 2004-03-21 | 2004-03-21 | 63.202.109.122 | 1 2004-05-10 | 2004-05-10 | 63.202.109.123 | 2 2003-04-23 | 2003-04-28 | 63.202.109.127 | 58 2003-10-05 | 2003-10-05 | 63.202.109.128 | 1 2003-05-18 | 2004-05-09 | 63.202.109.132 | 2 2004-04-02 | 2004-04-02 | 63.202.109.134 | 1 2004-04-24 | 2004-04-24 | 63.202.109.136 | 1 2004-04-03 | 2004-04-03 | 63.202.109.143 | 1 2004-04-03 | 2004-04-03 | 63.202.109.150 | 1 2004-05-11 | 2004-05-11 | 63.202.109.155 | 1 2004-04-15 | 2004-04-15 | 63.202.109.156 | 1 2004-04-14 | 2004-04-14 | 63.202.109.163 | 1 2004-03-30 | 2004-03-30 | 63.202.109.164 | 1 2004-04-03 | 2004-04-03 | 63.202.109.166 | 1 2004-03-21 | 2004-03-21 | 63.202.109.169 | 1 2003-09-20 | 2003-09-20 | 63.202.109.170 | 1 2003-10-06 | 2003-10-06 | 63.202.109.172 | 1 2003-12-08 | 2003-12-08 | 63.202.109.177 | 1 2004-03-26 | 2004-03-26 | 63.202.109.181 | 1 2004-04-12 | 2004-04-12 | 63.202.109.186 | 1 2004-05-06 | 2004-05-06 | 63.202.109.189 | 1 2003-09-16 | 2003-09-16 | 63.202.109.190 | 1 2004-03-21 | 2004-03-21 | 63.202.109.191 | 1 2004-04-16 | 2004-04-16 | 63.202.109.192 | 1 2004-04-26 | 2004-04-26 | 63.202.109.194 | 1 2004-04-12 | 2004-04-12 | 63.202.109.197 | 1 2004-02-13 | 2004-02-13 | 63.202.109.199 | 1 2004-04-03 | 2004-04-03 | 63.202.109.200 | 1 2004-04-19 | 2004-04-19 | 63.202.109.202 | 1 2004-05-04 | 2004-05-04 | 63.202.109.207 | 1 2004-03-17 | 2004-03-17 | 63.202.109.210 | 1 2003-08-23 | 2003-08-23 | 63.202.109.212 | 1 2004-04-03 | 2004-04-03 | 63.202.109.216 | 1 2003-08-26 | 2003-08-26 | 63.202.109.220 | 1 2004-03-29 | 2004-03-29 | 63.202.109.222 | 1 2004-05-27 | 2004-05-27 | 63.202.109.227 | 1 2003-12-24 | 2004-04-04 | 63.202.109.228 | 2 2003-11-18 | 2004-05-28 | 63.202.109.229 | 3 2004-04-16 | 2004-04-16 | 63.202.109.230 | 1 2004-05-11 | 2004-05-11 | 63.202.109.232 | 1 2004-05-28 | 2004-05-28 | 63.202.109.233 | 1 2003-09-04 | 2003-09-19 | 63.202.109.235 | 3 2003-10-07 | 2003-10-07 | 63.202.109.245 | 1 2004-04-25 | 2004-04-25 | 63.202.109.248 | 1 2004-04-25 | 2004-04-27 | 63.202.109.249 | 2 2004-03-28 | 2004-03-28 | 63.202.109.251 | 1 2004-04-07 | 2004-04-07 | 63.202.109.253 | 1 2004-04-11 | 2004-04-11 | 63.202.109.254 | 1 2004-04-27 | 2004-04-27 | 63.202.110.1 | 1 2004-05-11 | 2004-05-11 | 63.202.110.3 | 1 2003-12-17 | 2003-12-17 | 63.202.110.6 | 1 2004-03-28 | 2004-03-28 | 63.202.110.8 | 1 2004-05-28 | 2004-05-28 | 63.202.110.13 | 1 2004-05-27 | 2004-05-27 | 63.202.110.14 | 1 2004-05-29 | 2004-05-29 | 63.202.110.15 | 1 2004-05-03 | 2004-05-03 | 63.202.110.19 | 1 2004-04-10 | 2004-04-10 | 63.202.110.27 | 1 2003-04-29 | 2003-05-01 | 63.202.110.30 | 17 2004-03-20 | 2004-03-20 | 63.202.110.31 | 1 2003-11-07 | 2003-11-07 | 63.202.110.35 | 1 2004-03-24 | 2004-03-24 | 63.202.110.45 | 1 2004-03-23 | 2004-03-23 | 63.202.110.53 | 1 2004-05-31 | 2004-05-31 | 63.202.110.54 | 1 2004-04-03 | 2004-04-03 | 63.202.110.59 | 1 2004-04-28 | 2004-04-28 | 63.202.110.69 | 1 2003-05-14 | 2003-05-14 | 63.202.110.73 | 3 2004-04-22 | 2004-04-22 | 63.202.110.76 | 1 2004-04-03 | 2004-04-03 | 63.202.110.77 | 1 2004-03-17 | 2004-03-17 | 63.202.110.78 | 1 2004-03-23 | 2004-03-23 | 63.202.110.84 | 1 2004-02-06 | 2004-02-09 | 63.202.110.86 | 3 2004-04-23 | 2004-04-23 | 63.202.110.87 | 1 2004-04-24 | 2004-04-28 | 63.202.110.88 | 4 2003-10-19 | 2003-10-19 | 63.202.110.89 | 1 2004-04-18 | 2004-04-18 | 63.202.110.91 | 1 2003-12-03 | 2003-12-03 | 63.202.110.92 | 1 2003-09-09 | 2003-09-09 | 63.202.110.98 | 1 2004-04-25 | 2004-04-25 | 63.202.110.99 | 2 2004-04-02 | 2004-04-02 | 63.202.110.100 | 1 2004-04-15 | 2004-04-15 | 63.202.110.102 | 1 2004-04-10 | 2004-04-10 | 63.202.110.105 | 1 2003-03-12 | 2003-03-12 | 63.202.110.122 | 2 2004-04-07 | 2004-04-07 | 63.202.110.124 | 1 2004-05-29 | 2004-05-29 | 63.202.110.126 | 1 2004-04-21 | 2004-04-21 | 63.202.110.127 | 1 2004-03-19 | 2004-03-19 | 63.202.110.129 | 1 2004-04-14 | 2004-04-14 | 63.202.110.130 | 1 2004-03-22 | 2004-03-22 | 63.202.110.134 | 1 2004-04-25 | 2004-04-25 | 63.202.110.135 | 1 2004-03-24 | 2004-03-24 | 63.202.110.136 | 1 2004-05-15 | 2004-05-15 | 63.202.110.139 | 1 2004-04-14 | 2004-04-14 | 63.202.110.140 | 1 2004-04-23 | 2004-04-23 | 63.202.110.149 | 1 2004-05-13 | 2004-05-13 | 63.202.110.153 | 1 2004-04-08 | 2004-04-08 | 63.202.110.154 | 1 2004-05-28 | 2004-05-28 | 63.202.110.155 | 1 2004-05-28 | 2004-05-28 | 63.202.110.165 | 1 2004-04-28 | 2004-04-28 | 63.202.110.172 | 1 2004-04-02 | 2004-04-02 | 63.202.110.173 | 1 2004-05-07 | 2004-05-07 | 63.202.110.177 | 1 2004-04-19 | 2004-04-19 | 63.202.110.179 | 1 2004-05-15 | 2004-05-15 | 63.202.110.180 | 1 2004-05-06 | 2004-05-06 | 63.202.110.186 | 1 2004-04-10 | 2004-04-10 | 63.202.110.187 | 1 2003-09-23 | 2003-09-23 | 63.202.110.194 | 1 2004-03-25 | 2004-03-25 | 63.202.110.200 | 1 2003-10-29 | 2003-12-14 | 63.202.110.201 | 2 2003-01-14 | 2004-04-08 | 63.202.110.203 | 5 2004-05-31 | 2004-05-31 | 63.202.110.204 | 1 2004-04-27 | 2004-04-27 | 63.202.110.205 | 1 2004-04-06 | 2004-04-06 | 63.202.110.209 | 1 2004-05-27 | 2004-05-27 | 63.202.110.212 | 1 2003-05-30 | 2003-05-30 | 63.202.110.213 | 1 2004-05-28 | 2004-05-28 | 63.202.110.215 | 1 2004-05-02 | 2004-05-02 | 63.202.110.217 | 1 2004-03-21 | 2004-03-21 | 63.202.110.218 | 1 2004-05-11 | 2004-05-11 | 63.202.110.220 | 1 2003-09-21 | 2004-03-20 | 63.202.110.225 | 3 2004-03-29 | 2004-03-29 | 63.202.110.226 | 1 2004-03-27 | 2004-03-27 | 63.202.110.231 | 1 2004-03-09 | 2004-03-09 | 63.202.110.236 | 1 2004-04-20 | 2004-04-20 | 63.202.110.244 | 1 2004-04-10 | 2004-04-10 | 63.202.110.245 | 1 2004-04-20 | 2004-04-20 | 63.202.110.246 | 1 2004-04-15 | 2004-04-15 | 63.202.110.249 | 1 2004-04-18 | 2004-04-18 | 63.202.110.250 | 1 2003-12-09 | 2004-05-01 | 63.202.110.251 | 2 2003-08-20 | 2004-03-31 | 63.202.110.253 | 2 2003-05-21 | 2003-05-21 | 63.202.111.0 | 1 2003-01-15 | 2003-01-15 | 63.202.111.1 | 3 2004-04-18 | 2004-04-18 | 63.202.111.2 | 1 2004-03-18 | 2004-03-18 | 63.202.111.3 | 1 2003-03-31 | 2003-04-01 | 63.202.111.5 | 4 2004-04-07 | 2004-04-07 | 63.202.111.7 | 1 2004-04-29 | 2004-04-29 | 63.202.111.8 | 1 2004-04-02 | 2004-04-02 | 63.202.111.15 | 1 2004-03-25 | 2004-03-25 | 63.202.111.16 | 1 2003-11-09 | 2003-11-09 | 63.202.111.17 | 1 2004-05-01 | 2004-05-01 | 63.202.111.20 | 1 2003-04-20 | 2003-11-16 | 63.202.111.26 | 16 2003-12-06 | 2003-12-06 | 63.202.111.27 | 1 2004-03-17 | 2004-03-17 | 63.202.111.29 | 1 2003-12-12 | 2003-12-12 | 63.202.111.36 | 1 2003-07-15 | 2003-07-15 | 63.202.111.37 | 3 2004-03-30 | 2004-03-30 | 63.202.111.38 | 1 2004-05-05 | 2004-05-05 | 63.202.111.43 | 1 2004-05-09 | 2004-05-09 | 63.202.111.45 | 1 2004-04-08 | 2004-04-08 | 63.202.111.57 | 1 2004-04-08 | 2004-04-08 | 63.202.111.58 | 1 2004-04-13 | 2004-04-13 | 63.202.111.61 | 1 2003-08-30 | 2003-09-02 | 63.202.111.62 | 2 2003-12-10 | 2003-12-10 | 63.202.111.66 | 1 2004-04-24 | 2004-04-24 | 63.202.111.67 | 1 2004-04-05 | 2004-04-05 | 63.202.111.68 | 1 2004-03-27 | 2004-03-27 | 63.202.111.72 | 1 2004-03-26 | 2004-03-26 | 63.202.111.79 | 1 2003-09-23 | 2004-03-19 | 63.202.111.82 | 2 2004-04-06 | 2004-04-06 | 63.202.111.83 | 1 2004-03-18 | 2004-03-18 | 63.202.111.94 | 1 2003-09-08 | 2003-09-08 | 63.202.111.96 | 1 2004-03-28 | 2004-03-28 | 63.202.111.98 | 1 2004-04-14 | 2004-04-14 | 63.202.111.103 | 1 2004-04-10 | 2004-04-10 | 63.202.111.106 | 1 2004-03-25 | 2004-03-25 | 63.202.111.110 | 1 2004-03-17 | 2004-03-17 | 63.202.111.111 | 1 2004-04-16 | 2004-04-16 | 63.202.111.112 | 1 2003-12-03 | 2003-12-03 | 63.202.111.118 | 1 2004-04-21 | 2004-04-21 | 63.202.111.120 | 1 2004-04-06 | 2004-04-06 | 63.202.111.122 | 1 2004-03-25 | 2004-03-25 | 63.202.111.123 | 1 2004-05-28 | 2004-05-28 | 63.202.111.128 | 1 2004-03-31 | 2004-03-31 | 63.202.111.131 | 1 2004-05-10 | 2004-05-10 | 63.202.111.132 | 1 2004-05-13 | 2004-05-13 | 63.202.111.134 | 1 2004-03-25 | 2004-03-25 | 63.202.111.135 | 1 2004-03-19 | 2004-03-19 | 63.202.111.137 | 1 2004-03-28 | 2004-03-28 | 63.202.111.139 | 1 2004-03-17 | 2004-03-17 | 63.202.111.141 | 1 2004-05-04 | 2004-05-04 | 63.202.111.143 | 1 2004-04-26 | 2004-04-28 | 63.202.111.150 | 2 2003-05-28 | 2003-05-28 | 63.202.111.152 | 17 2004-04-15 | 2004-04-15 | 63.202.111.154 | 1 2004-02-27 | 2004-02-27 | 63.202.111.155 | 1 2004-05-03 | 2004-05-03 | 63.202.111.158 | 1 2004-05-10 | 2004-05-10 | 63.202.111.164 | 1 2004-05-08 | 2004-05-08 | 63.202.111.166 | 1 2003-11-08 | 2004-03-30 | 63.202.111.174 | 2 2004-05-29 | 2004-05-29 | 63.202.111.177 | 1 2004-05-14 | 2004-05-14 | 63.202.111.183 | 2 2004-04-29 | 2004-04-29 | 63.202.111.185 | 1 2004-04-27 | 2004-04-27 | 63.202.111.186 | 1 2004-02-29 | 2004-02-29 | 63.202.111.191 | 1 2004-04-20 | 2004-04-20 | 63.202.111.192 | 1 2003-10-12 | 2003-10-12 | 63.202.111.195 | 1 2004-03-17 | 2004-03-17 | 63.202.111.196 | 1 2004-05-26 | 2004-05-26 | 63.202.111.197 | 1 2004-05-07 | 2004-05-07 | 63.202.111.199 | 1 2004-05-28 | 2004-05-28 | 63.202.111.202 | 1 2004-04-15 | 2004-04-15 | 63.202.111.207 | 1 2004-04-06 | 2004-04-06 | 63.202.111.208 | 1 2004-03-19 | 2004-03-19 | 63.202.111.218 | 1 2004-05-15 | 2004-05-15 | 63.202.111.219 | 1 2004-03-31 | 2004-03-31 | 63.202.111.220 | 1 2004-04-08 | 2004-04-08 | 63.202.111.225 | 1 2004-03-22 | 2004-03-22 | 63.202.111.226 | 1 2003-11-04 | 2003-11-04 | 63.202.111.228 | 1 2003-05-12 | 2003-05-12 | 63.202.111.229 | 1 2004-05-13 | 2004-05-13 | 63.202.111.231 | 1 2004-05-01 | 2004-05-01 | 63.202.111.237 | 1 2004-01-01 | 2004-01-01 | 63.202.111.244 | 1 2004-04-21 | 2004-04-21 | 63.202.111.247 | 1 2004-04-27 | 2004-04-27 | 63.202.112.4 | 1 2004-04-26 | 2004-04-26 | 63.202.112.110 | 1 2004-03-30 | 2004-03-30 | 63.202.112.117 | 1 2004-05-06 | 2004-05-06 | 63.202.112.128 | 1 2003-12-21 | 2003-12-21 | 63.202.126.155 | 1 2003-02-12 | 2004-04-28 | 63.202.127.10 | 49 2004-05-27 | 2004-05-27 | 63.202.127.11 | 1 2002-12-11 | 2003-02-16 | 63.202.127.12 | 76 2002-12-11 | 2004-04-27 | 63.202.127.13 | 202 2002-12-13 | 2004-04-28 | 63.202.127.14 | 18 2003-09-04 | 2003-09-04 | 63.202.127.162 | 1 (595 rows) -- Paul Vixie
: now, though, there's an opportunity to do a marketing U-turn on this. cable : and dsl providers in the USA can point to the national cybersecurity plan and : say that to comply with it they have to put infected computers in cyberjail, : with a fee of $N to get these machines audited, and if found clean, put back : on the net, noting that N doubles every time this process is invoked, and : that a deposit of $(0.5*N) is required as prepayment for the next incident, : refundable after one year if there are no further incidents. then offer to : remotely manage their host ("give me your root passwords, trust me!") for an : annual fee of $(0.75*N). if the initial value of N were $500, you might be : able to get the people who need this service to pay for it. it's worth a try? : -- : Paul Vixie :
If I read Paul's post correctly, then I would have to agree that the costs of cleaning up the problem customers should be placed on the customer (miscreant) as opposed to the rest of us. This would be far more preferable than putting in place controls by the respective ISP that would limit my own use of my connection, on which I have spent considerable time, money and education to make sure it is secure and beyond that, compliant with the ISP Acceptable Use policies.
Yes, but then you have another problem. I get a virus - whoops, attached a laptop without thinking. I clean it up myself, cause I'm feeling so retarded for getting the virus that I damn well ain't sharing that with anyone. In the meantime, the ISP noticed the virus and put a block on. Do I have to pay them $500 to get it removed? Definitely cheaper to cancel service and go with someone else at that point. Rob Nelson ronelson@vt.edu
----- Original Message ----- From: "Paul Vixie" <vixie@vix.com>
now, though, there's an opportunity to do a marketing U-turn on this. cable and dsl providers in the USA can point to the national cybersecurity plan and say that to comply with it they have to put infected computers in cyberjail,
refundable after one year if there are no further incidents. then offer to remotely manage their host ("give me your root passwords, trust me!") for an annual fee of $(0.75*N). if the initial value of N were $500, you might be able to get the people who need this service to pay for it. it's worth a
Except that they don't HAVE to do this and so it's lying to customers and other ISP's will tell the customers the truth (that they don't have to pay these charges) and presto you are out of business. try? Paul, why don't you make this offer to all your relatives? Don't want the job? NEITHER DO WE!! (hoping the relatives comment will invoke the memories of exactly what is required to do this) We are ISP's, we got into this business because we know how to network not how to patch every OS on the planet. It's bad enough we have to filter email or customers go running off to another ISP but to provide security and deal with patching and then on top of that explain to parents how their 14 year old compromised their machine by running something she downloaded off the web so they really shouldn't sue us because someone got their CC and bank account numbers? Geo.
On Sun, 13 Jun 2004 18:19:39 EDT, Geoincidents <geoincidents@nls.net> said:
Paul, why don't you make this offer to all your relatives? Don't want the job? NEITHER DO WE!! (hoping the relatives comment will invoke the memories of exactly what is required to do this)
Out of curiosity, does *anybody* on this list actually possess a set of relatives such that they'd want to make that offer to *all* of them? ;) (If anybody actually answers affirmatively, everybody else keep an eye on them - it's obvious that their entire family has been taken over by Pod People or Stepford Wives or something of that ilk... ;)
geoincidents@nls.net ("Geoincidents") writes:
refundable after one year if there are no further incidents. then offer to remotely manage their host ("give me your root passwords, trust me!") for an annual fee of $(0.75*N). if the initial value of N were $500, you might be able to get the people who need this service to pay for it. it's worth a try?
Paul, why don't you make this offer to all your relatives? Don't want the job? NEITHER DO WE!! ... We are ISP's, we got into this business because we know how to network not how to patch every OS on the planet. ...
if you're not set up to offer this then don't. but sean's employer already has the trucks and the phonebanks, and they might be able to monetize a solution to this problem, and they should be encouraged to try it.
It's bad enough we have to filter email or customers go running off to another ISP but to provide security and deal with patching and then on top of that explain to parents how their 14 year old compromised their machine by running something she downloaded off the web so they really shouldn't sue us because someone got their CC and bank account numbers?
as an ISP who knows how to network, the only thing i request of you is that if your customer is spewing virus segments at me, you give me a way to prove that to you (that costs me less time and aggravation than blackholing you), and that once proven, you will revoke the account until you're sure that the infestation, and the process errors which led to it, are gone. (same as if they were spamming, or controlling a ddos botnet, or etc.) if you won't do that then you should not complain when folks blackhole your customers and otherwise treat you as a chemical polluter, like i treat sean's network. an isp has to take responsibility for the output from their network, and the ones who won't, are going to be treated by their victims as "bad internet neighborhoods". hopefully sean is ready to stop whining about that by this point in the thread. if not i can do another database extract for him. -- Paul Vixie
as an ISP who knows how to network, the only thing i request of you is
if your customer is spewing virus segments at me, you give me a way to
----- Original Message ----- From: "Paul Vixie" <vixie@vix.com> that prove
that to you (that costs me less time and aggravation than blackholing you), and that once proven, you will revoke the account until you're sure that the infestation, and the process errors which led to it, are gone. (same as if they were spamming, or controlling a ddos botnet, or etc.)
That's fine and we do deal with the problems in a reasonable amount of time, but we also prioritize them. If there are 5 bots on my network sending you a 2Mb flood, we'll shut them down or block the flood immediately, but if it's a single machine on a corporate network beind NAT and you are getting 4 port probes because it's infected with sasser, then we'll enter it into the support system and the customer will be contacted but the corp network will not be shut down until that contact has been made. Virus infections are a day to day occurance, not some critical emergency DOS condition and they should be handled with concern but not panic. Customers are the priority, not everyone else on the net. If you can't stand up to 4 port probes then you don't belong on todays internet. Now if you are talking about customers who remain infected for weeks, we won't allow that, once the contact has been made they've got to respond or we will shut them down. But the logs I saw posted here didn't appear to me to be the same customer, it just appeared to be a lot of probes over a long time meaning that the particular subnet is a very busy place with lots of worm bait. Virus infections on a subnet like that are to be expected. Trying to keep that subnet clean is like running around spinning plates on sticks. Geo. -George R.- NetLink Services, Inc.
GR> Date: Mon, 14 Jun 2004 21:47:49 -0400 GR> From: George Roettger GR> Customers are the priority, not everyone else on the net. Bad karma. At the risk of adding another analogy, look at the countries that refuse to join the global economy. Unless a network is ready to be self-sufficient, playing nice probably is a good idea. Did someone say "tragedy of the commons"? Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
Bad karma. At the risk of adding another analogy, look at the countries that refuse to join the global economy. Unless a network is ready to be self-sufficient, playing nice probably is a good idea.
I don't know if you've noticed, but the internet is based on an economy now, it's not a free resource provided by foundations and higher education. Without customers it shuts down. Just ask any of the ISP's who aren't around any more. Geo.
GR> Date: Mon, 14 Jun 2004 23:02:33 -0400 GR> From: George Roettger GR> I don't know if you've noticed, but the internet is based on GR> an economy now, it's not a free resource provided by GR> foundations and higher education. Without customers it shuts GR> down. I don't know if you've noticed, but it's easier to stem the flow of inbound crap/attacks when other providers cooperate. If you don't extend a helping hand to others, don't expect it from them. (It's easier to have customers when you can resolve issues, some of which *do* require help from other networks.) Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
I don't know if you've noticed, but it's easier to stem the flow of inbound crap/attacks when other providers cooperate. If you don't extend a helping hand to others, don't expect it from them. (It's easier to have customers when you can resolve issues, some of which *do* require help from other networks.)
Check any of the abuse databases you want and you won't find us there. All I'm saying is that you don't automatically shut down some business DSL account because one internal machine caught a bug. That's not abuse, that's normal day to day stuff that happens on the net. It does need to be resolved but it is not an emergency. Reserve yelling "FIRE!" for when there really is a fire. Geo.
GR> Date: Mon, 14 Jun 2004 21:47:49 -0400 GR> From: George Roettger GR> Virus infections are a day to day occurance, not some And being the status quo justifies something how? GR> critical emergency DOS condition and they should be handled GR> with concern but not panic. Customers are the priority, not GR> everyone else on the net. If you can't stand up to 4 port GR> probes then you don't belong on todays internet. Four port probes per day? It's been the better part of a decade since I saw that... and, back in those days, I actually _called_ many of the domestic networks that were attempting funny business. (You'd not believe how many network admins were on vacation...) Rather than waving my hands at vague concepts, I'll set forth a few hypothetical data points: * You have an infected machine that has absolutely no chance of harming anyone else. Should you care? ("Yes" reflects concern about the customer; "no" is the Internet-minded attitude.) At any rate, disconnection would be foolish. * That customer will infect one other system per month. It would be nice to stop that, but disconnection would be overly harsh. * I have an infected machine that pounds out attacks and exploits at high speeds, hurting thousands of systems hourly. Would you like it shut off? Probably. Do you not agree that this is grounds for disco/throttling/proxy -- at least temporarily? If you don't agree with me on the extremes, I think you're nuts. If you agree with me on the extremes, then we're arguing over where the boundaries should be. The problem is one of leverage: One compromised system can affect hundreds, thousands, or even tens of thousands of others. It's far easier to quell _one_ infected system at the source than it is for even two (let alone orders of magnitude higher) other people to deal with the fallout when they're hit. Is your { customer | time | whatever } more valuable than the aggregate of those who suffer? If you think so, that's arrogant even for NANOG. Yes, we've lost customers who refused to take care of their systems. We've also gained other customers and consulting clients who appreciate the "try to keep things clean" mentality. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
GR> Virus infections are a day to day occurance, not some
And being the status quo justifies something how?
No it doesn't justify it, it simply means it's not an emergency.
* You have an infected machine that has absolutely no chance of harming anyone else. Should you care? ("Yes" reflects concern about the customer; "no" is the Internet-minded attitude.) At any rate, disconnection would be foolish.
Yes of course you should care, but it should not be a high a priority as say a down situation.
* I have an infected machine that pounds out attacks and exploits at high speeds, hurting thousands of systems hourly. Would you like it shut off? Probably. Do you not agree that this is grounds for disco/throttling/proxy -- at least temporarily?
High priority because it can or is causing a down situation for someone.
If you don't agree with me on the extremes, I think you're nuts. If you agree with me on the extremes, then we're arguing over where the boundaries should be.
We aren't arguing over boundries, all I'm trying to say is that without customers the internet shuts down. So perhaps it's time to become a bit more customer oriented in our thinking of how to deal with the issues we face today. Automatically sand boxing business dsl customers is a bad idea. Do you want your backbone providers to do that to you because of a virus infection on your network? Geo.
On Sun, 13 Jun 2004, John Curran wrote:
I'll argue that we have don't effective methods of dealing with this today, and it's not the lack of abuse desk people as much as the philosophy of closing barn doors after the fact. The idea that we can leave everything wide open for automated exploit tools, and then clean up afterwards manually with labor-intensive efforts is fundamentally flawed.
Selling people barn doors and barn door audits is easier than figuring out how the rustlers are getting the horses. The problem is the horses aren't being rustled(?) through the barn doors. If they were, you would expect to see a difference between barns with doors and barns without doors. But in practice, we see people with and without firewalls with infected computers. Network level controls aren't as effective as some people hope at stopping many things. ISPs should stop porn, ISPs should stop music sharing, ISPs should stop viruses, ISPs should stop <insert here>. Yet somehow users manage to find a way around all of them. What are good predictors? There aren't any great ones, but there are some. Can we use them effectively? So what makes some users more likely or less likely to have infected computers? How do they become infected, but other users don't? What's different between the two groups?
Sean Donelan wrote:
Selling people barn doors and barn door audits is easier than figuring out how the rustlers are getting the horses. The problem is the horses aren't being rustled(?) through the barn doors. If they were, you would expect to see a difference between barns with doors and barns without doors. But in practice, we see people with and without firewalls with infected computers. Network level controls aren't as effective as some people hope at stopping many things. ISPs should stop porn, ISPs should stop music sharing, ISPs should stop viruses, ISPs should stop <insert here>. Yet somehow users manage to find a way around all of them. So what makes some users more likely or less likely to have infected computers? How do they become infected, but other users don't? What's different between the two groups? Skill, Desire and Luck - not always in that order.
I usually set out my stall on this one by making a the following assumptions - 1) any protective measure that relies on users having common sense will inevitably lead to astonishment at how uncommon common sense is (core rule) 2)Warning messages are now so common users don't read them, and web popup boxes even more so. By simple extension therefore, no warning message is of any value - users will read just enough to discover how to make it go away, and if the obvious way of doing so works, won't trouble themselves further. (case in point - "how did that porn dialler get there? I only visited a website or two. Yeah, there was some sort of popup box but I closed it") 3) not all machines will be vulnerable - either by skill, initial design, patching dilligence or obsolescence, some machines will be inherently protected against any given outbreak. Downside there is - said users will invariably decide they don't *need* to take protective measures because this one attack couldn't affect them (case in point - most linux users do not have AV software of any type, despite at least one being free and open source) 4) any scheme that relies on blocking users from what they want to do will be bypassed by at least some of those users; once some of the users know how to do it, the blackhats won't be far behind teaching their creations how to do it too, and the greyhats in writing little pretty gui tools to do it automagically - relying that users knowing how to bypass lockdowns being skilled enough to look after their own security therefore violates rule 1 5) anything that relies on convincing the users (or better yet their machine) that the action *is* what they want to do is onto a winner; see rule 3 and indeed rule 1 for details. so back to your list.
ISPs should stop porn, not going to work - prohibition just makes it harder to regulate stuff, even leaving aside the moral issues of trying to block online what can be bought in most newsagents.
ISPs should stop music sharing, why? users obviously want to do it, and in many places it is not a criminal act (copyright violations being civil not criminal in most countries) ISPs should of course co-operate with any lawful warrant or court order, and (for practical purposes) try to limit their own expenses in having to deal with copyright violations on websites and so forth but in the UK (Not sure about elsewhere) the real problem is commercial pirates selling dodgy copies from stalls or car boots, and that predates the web (and indeed the CD)
ISPs should stop viruses, Sure. I don't think that should be free though - plenty of services out there offer filtered, reactive web access to remove all those nasty worms, email viruses and so forth as fast as is possible. Doing that work *costs* and has little or nothing to do with the business of pushing bits down wires. Yey the free market....
ISPs should stop <insert here>. damn right. <insert here> has always bugged me :)
At 6:31 AM -0400 6/13/04, Sean Donelan wrote:
If they were, you would expect to see a difference between barns with doors and barns without doors. But in practice, we see people with and without firewalls with infected computers.
If you're asserting that having firewalls in the path doesn't have any impact on rate of infection, please provide a link to this data. Sure, I've even seen infected computers in rooms that don't (or should not have had) any connectivity, but that just means it is not a perfect world. Lot's of things make it through firewalls (email-based worms come to mind) but from what I've seen they are quite effective at protecting networks of otherwise helpless comes-out-of-the-box-wide-open PC's. /John
John Curran wrote:
If you're asserting that having firewalls in the path doesn't have any impact on rate of infection, please provide a link to this data. Actually, it doesn't - practical experience on a medium sized corporate network is that the firewall protects perfectly against TCP/IP worms - right up to the first time some senior management bozo plugs his laptop onto the network that his teen son was playing online games with all last night... and has no effect at all on email or website/browser 'sploits.
At 6:31 AM -0400 6/13/04, Sean Donelan wrote:
Network level controls aren't as effective as some people hope at stopping many things. ISPs should stop porn, ISPs should stop music sharing, ISPs should stop viruses, ISPs should stop <insert here>. Yet somehow users manage to find a way around all of them.
In a perfect world, ISPs shouldn't have to worry about content. There is no way to "know" whether the user wants a particular message and methods at guessing are always imperfect. Despite this, a lot of users would like their ISP to try to do their best to filter spam and viruses out of their mail stream, etc. It really should be an local issue but users ask, so the service appears. However, distinguish content from access. Typical users, particularly in broadband residential connections, have no desire to have anyone remotely access their machine. The same is true with most small business customers. Upon arrival of their first Internet connection, the systems do not magically recognize that end-to-end now could be any endpoint in the Internet and install appropriate filters. Why doesn't it make sense to change the default model so that such are in place under the user demonstrates some understanding of the situation by asking them to be removed? To add one more analogy to the mix, we blindly install on-ramps to the freeway to anyone who asks and certainly a few folks know what is in store once connected. However, the vast majority of ramps are connected to suburban driveways, skate board parks, and middle school playgrounds. It's amazing that we all act surprised when innocents get run over... /John
John Curran wrote:
Why doesn't it make sense to change the default model so that such are in place under the user demonstrates some understanding of the situation by asking them to be removed?
I'd just like to point out that people are going to ask to be removed so they can get their [IM client/IP phone software/webcam/filesharing client/gaming server/???] working, _not_ because all of a sudden they feel they have enough technical know-how to keep their computer from getting compromised. There is also the problem that filtered service will create an expectation that the ISP will magically stop everything, and of course hell will be sending out their invoices when (not if) something makes it through.
There is also the problem that filtered service will create an expectation that the ISP will magically stop everything, and of course hell will be sending out their invoices when (not if) something makes it through.
Yep, who is going to pay for little johnnies therapy if some porn slips thought your filters ? Not even your silly disclaimer that says "we offer this service but cannot be held responsible" will do. Service for fee always carries some expressed liability that no disclaimer gets you out of. -- James H. Edwards Routing and Security Administrator At the Santa Fe Office: Internet at Cyber Mesa jamesh@cybermesa.com noc@cybermesa.com
On Sun, Jun 13, 2004 at 04:21:03AM +0000, Christopher L. Morrow wrote:
We have methods of dealing with these abuse problems today, unfortanately as Paul Vixie often points out there are business reasons why these problems persist. Often the 'business' reason isn't the tin-foil-hat-brigade's reason so much as 'we can't afford to keep these abuse folks around since they don't make money for the company'.
One of the core skills required by an abuse desk person, and in particular an abuse team manager, is an ability to evangelise to higher management the business benefits of effective Acceptable Use Policy enforcement. For example, how many legitimate prospective customers does the following: Found 187 SBL listings for IPs under the responsibility of mci.com Listings in yellow are known spam gangs with ROKSO records http://www.spamhaus.org/sbl/listings.lasso Cause to decide not to even consider you as a supplier of bandwidth and/or hosting services? When one also factors into the equation the fact that spammers (of whatever type) tend historically to be bad payers, it is not unlikely that your apparent business related decision to provide safe haven to such folks is actually a cause of net revenue loss, not gain. -- Anthony Edwards * anthony.edwards@uk.easynet.net Abuse Team Manager * Easynet UK Abuse Team Easynet Ltd * DDI: 0161 227 0707 http://www.uk.easynet.net * Fax: 0845 333 4503
Christopher L. Morrow wrote:
On Sat, 12 Jun 2004, John Curran wrote:
The real challenge here is that the "default" Internet service is wide-open Internet Protocol, w/o any safeties or controls. This made a lot of sense when the Internet was a few hundred sites, but is showing real scaling problems today (spam, major viruses, etc.)
One could imagine changing the paradigm (never easy) so that the normal Internet service was proxied for common applications and NAT'ed for everything else... This wouldn't eliminate all the problems, but would dramatically cut down the incident rate.
This sounds like a fantastic idea, for instance: How much direct IP does joe-average Internet user really require? Do they require anything more than imap(s)/pop(s)/smtp(+tls) and dns/http/https ? I suppose they also need: 1) internet gaming 2) voip 3) kazaa/p2p-app(s)-of-choice 4) IM
Actually I'm sure there are quite a few things they need, things which require either very smart NAT/Proxy devices or open access. The filtering of IP on the broad scale will hamper creativity and innovation. I'm fairly certain this was not what we want in the long term, is it?
I acutally suggested something like this at the recent AusCERT 2004 conference... It's not such a bad idea.... The real question being "why are we giving mum's and dad's who sign up to the internet, and know nothing about either the Internet or computers, full unrestricted incoming and outgoing access...?" ... answer because the more bandwidth they use the more the ISP earns... so the ISPs don't care (in some cases) if the mum's and dad's get trojaned, because it's all money. My suggestion to the AusCERT delegates was to introduce a new default service which has very limited access, and if people ask for more, give them the access after they have read through various 'educational' pages.... Perhaps a simple online quiz at the end -just 3-5 questions with the answers being very clearly explained in the previous pages - just to show the people have actually read the pages, rather than skipped to the end and hit 'I accept'. I also suggested that if ISPs have the technology perhaps a simple IP pools method of allocating the users IP, where they could turn on and turn off access to certain protocols - eg: have a pool for P2P users, a pool for VOIP etc... / Mat
: Regulations could fix that. : : The US Postal Service has the Postal Inspection Service. They have : jurisdiction anywhere the mail goes. The post office didn't create : the Anthrax, they delivered the envelopes as addressed. : : Most railroads have railroad police with jurisdiction anywhere the : railroad tracks go. Some railroad police departments have : trans-national jurisdiction in multiple countries. :: My suggestion to the AusCERT delegates was to introduce a new default :: service which has very limited access, and if people ask for more, give :: them the access after they have read through various 'educational' :: pages.... Perhaps a simple online quiz at the end -just 3-5 questions :: with the answers being very clearly explained in the previous pages - :: just to show the people have actually read the pages, rather than :: skipped to the end and hit 'I accept'. ::: All other traffic will be blocked. This means that if you are ::: using any other internet-based applications, such as on-line gaming, ::: peer to peer file-sharing, etc., they will not work with Censorco. ::: These applications have been demonstrated to be unsafe, and, are not ::: accessible while still using the TrainingWheels(tm) service. If you ::: want to do this, you will need to contact your account representative, ::: pass a brief internet knowledge and security test, and sign the ::: appropriate waiver. We will then remove the TrainingWheels(tm) from ::: your internet service and you will receive a full, unfiltered, unsafe ::: connection to the internet. Four words why these regulatory/testing things won't work: It's a global network. It has been shown across many wars that global regulation isn't going to work... : Also the problem of off shoring spam probably should be taken into : consideration. No matter how good the plan is if a country is willing : not to enforce it there will be a problem. <ding, ding, ding> We have a winner! Someone please give sgorman1 a cigar for winning the NA vs. global network game in this round! scott
surfer@mauigateway.com (Scott Weeks) writes:
: Also the problem of off shoring spam probably should be taken into : consideration. No matter how good the plan is if a country is willing : not to enforce it there will be a problem.
<ding, ding, ding> We have a winner! Someone please give sgorman1 a cigar for winning the NA vs. global network game in this round!
so, we're back to the need to establish this by international treaty, again. for some reason we can require passengers to be fingerprinted if they didn't come from an approved airport, or let them through without checking their passport at all if they're from the same league of nations as "us", and make IMF money contingent on severing or establishing diplomatic ties with countries we dislike or like... but we balk at the idea of making it illegal for UUNET to connect their end of an E3 to a router if the other end touches down in a country who won't control their cybernauts. yes, that would mean a whole lot of homework for somebody, since you could multihop through middlemen at various ISO layers, repacketize, and so on. but even though it's still possible to ship all manner of contraband across every border in the world, it's HARDER TO DO if the country on at least one side of that border MAKES SOME KIND OF EFFORT AT STOPPING IT. if some country somewhere becomes a haven for spammers then the international community will have to isolate them (cybernetically) in their own defense. we can argue about anything else that pleases us, invent all the rules and new technology we want, but it will all come down to treaties between nations. unfortunately, my own nation is so interested in appeasing our spammers that they are unable to provide any leadership in this area. someone else should step up. -- Paul Vixie
On 14 Jun 2004, Paul Vixie wrote: : surfer@mauigateway.com (Scott Weeks) writes: : : > : Also the problem of off shoring spam probably should be taken into : > : consideration. No matter how good the plan is if a country is willing : > : not to enforce it there will be a problem. : > : > <ding, ding, ding> We have a winner! Someone please give sgorman1 a : > cigar for winning the NA vs. global network game in this round! : : so, we're back to the need to establish this by international treaty, again. I will not go on too much as these need to die off. I just want to point out the borderless beast we're riding and the need to make solutions for the whole beast, not just the front of it. scott : for some reason we can require passengers to be fingerprinted if they didn't : come from an approved airport, or let them through without checking their : passport at all if they're from the same league of nations as "us", and : make IMF money contingent on severing or establishing diplomatic ties with : countries we dislike or like... but we balk at the idea of making it illegal : for UUNET to connect their end of an E3 to a router if the other end touches : down in a country who won't control their cybernauts. : : yes, that would mean a whole lot of homework for somebody, since you could : multihop through middlemen at various ISO layers, repacketize, and so on. : but even though it's still possible to ship all manner of contraband across : every border in the world, it's HARDER TO DO if the country on at least one : side of that border MAKES SOME KIND OF EFFORT AT STOPPING IT. : : if some country somewhere becomes a haven for spammers then the international : community will have to isolate them (cybernetically) in their own defense. : : we can argue about anything else that pleases us, invent all the rules and : new technology we want, but it will all come down to treaties between nations. : : unfortunately, my own nation is so interested in appeasing our spammers that : they are unable to provide any leadership in this area. someone else should : step up. : -- : Paul Vixie :
I fully expect my ISP to turn me off if my site starts spewing abuse. However, until that happens, I expect my ISP to deliver any valid IP datagram destined for me, and, I expect to them to deliver any valid IP datagram I send out, at least to the next AS in the path to the destination. If they turn me off for spewing abuse, I expect them to immediately contact me and provide as much information as they have about the nature of the problem. I think expect that it is my responsibility to identify and correct the problem, notify my ISP, and wait a reasonable amount of time (possibly as much as 24-48 hours) for them to turn me back on. So far, this hasn't been a problem. Owen --On Saturday, June 12, 2004 9:54 PM -0400 John Curran <jcurran@istaff.org> wrote:
The real challenge here is that the "default" Internet service is wide-open Internet Protocol, w/o any safeties or controls. This made a lot of sense when the Internet was a few hundred sites, but is showing real scaling problems today (spam, major viruses, etc.)
One could imagine changing the paradigm (never easy) so that the normal Internet service was proxied for common applications and NAT'ed for everything else... This wouldn't eliminate all the problems, but would dramatically cut down the incident rate.
If a site wants wide-open access, just give it to them. If that turns out to cause operational problems (due to open mail proxies, spam origination, etc), then put 'em back behind the relays.
/John
-- If it wasn't crypto-signed, it probably didn't come from me.
participants (21)
-
Anthony Edwards -
Bob K -
Christopher L. Morrow -
Dan Hollis -
Dave Howe -
David Schwartz -
Doug White -
Edward B. Dreger -
Geoincidents -
George Roettger
-
James Edwards -
John Curran -
Matthew Sullivan -
Owen DeLong -
Paul Vixie -
Paul Vixie -
Randy Bush -
Rob Nelson -
Scott Weeks -
Sean Donelan -
Valdis.Kletnieks＠vt.edu