- Test - lists.nanog.org

Even you can be hacked
by Sean Donelan 12 Jun '04

12 Jun '04

Does the water company fix your toilet if it leaks water? Or do you call a plumber? Every consumer computer has a power switch. How to stop a virus, turn off the power switch and take your computer to a repair shop. http://www.globeandmail.com/servlet/story/RTGAM.20040609.wispp0609/BNStory/… A few months ago, Mike Bierstock, who runs a tiny property management business in Waterloo, Ont., found his office system had been compromised - either by a virus or hacker, he's not sure - and he was slapped with a terrific bill for the volume of traffic generated by his computer. His access provider forgave some of his initial bills, but did nothing to help him clean his system, so the problem continued. Ultimately the ISP killed his account, hitting him with a bill of $11,000. [...] Mr. Liber simply declared bankruptcy. "They knew about the worm way before any billing had accumulated," said Mr. Liber, now senior account executive with iTel Solutions Inc. "They also confirmed that while they knew that there was a worm and that they knew it was not our doing, they [say] the responsibility is ours. Yet only they could have stopped the worm and the massive amount of bandwidth that was flowing through because of this worm." Did your computer have a power switch? Did you turn it off? Or did you continue to let it run up the bill? Yes, even the complete computer novice can stop a computer room. Turn off your computer. If you don't know how to fix it, take it to a repair store. If you leave your lights on, the electric company will send you a bill. If you leave your faucets running, the water company will send you a bill. If you leave your computer infected, ???

29 61

New IANA IPv6 Allocations
by Doug Barton 11 Jun '04

11 Jun '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is to inform you that the IANA has allocated the following three (3) IPv6 /23 blocks to RIPE NCC, ARIN, and APNIC respectively: 2001:4000::/23 RIPE NCC Jun 04 2001:4200::/23 ARIN Jun 04 2001:4400::/23 APNIC Jun 04 In addition to the above allocations, it should be noted that ARIN has returned their most recently allocated IPv6 block, 2001:3C00::/23 to the IANA, which has marked that block and the one immediately following it "reserved" in anticipation of a possible future allocation to the RIPE NCC. IANA would like to formally thank ARIN for their willingness to operate in the best interests of the Internet community. For a full list of IANA IPv6 allocations please see: <http://www.iana.org/assignments/ipv6-tla-assignments> At their request, this message is being sent to the following communities: afnog(a)afnog.org apops(a)apops.net janog(a)janog.gr.jp nanog(a)merit.edu sanog(a)sanog.org Regards, Doug - -- Doug Barton General Manager, The Internet Assigned Numbers Authority -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAykOQwtDPyTesBYwRAmPrAJ9yz+QyWv8FvE9bA79N9O8H8MFb0ACeKlTE hrFfWUtIQLL4VixUtQ9psM0= =E2aq -----END PGP SIGNATURE-----

1 0

RE: Even you can be hacked
by Fisher, Shawn 11 Jun '04

11 Jun '04

Hmm, so your on earth? -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Mike Walter Sent: Friday, June 11, 2004 5:03 PM To: nanog Subject: RE: Even you can be hacked Now you are just getting silly, we know Flux Capacitors don't work on earth. Mike Walter -----Original Message----- From: Matthew McGehrin [mailto:mcgehrin@reverse.net] Sent: Friday, June 11, 2004 5:00 PM To: nanog Subject: was: Even you can be hacked Coupled with a Flux Capacitor for the ultimate in message delivery :) ----- Original Message ----- From: "Scott Stursa" <stursa(a)acns.fsu.edu> To: <nanog(a)merit.edu> Sent: Friday, June 11, 2004 4:44 PM Subject: Re: Even you can be hacked > Ah. A tunneling implementation. > You'll need a cold fusion generator to power that.

5 4

RE: Even you can be hacked
by David Schwartz 11 Jun '04

11 Jun '04

> > Of course, except in this case, the phone company can't > > easily tell the > > legitimate calls from the illegitimate ones and block only the > > illegitimate ones. Every analogy will break down, so don't expect to be > > able to convince people with analogies that seem so obviously right to > > you. Nothing is exactly accurate except the actual situation itself. > And how, exactly, did you expect the ISP to tell which packets you were > sending were legitimate and which were from the malware running on your > computer? Please enlighten me as to how I tell a customer's legitimate > outbound email from his system apart from the email from the same system > which is being sent not by him, but, by the malware that has infected his > system? In this case, the ISP informed the customer that there was illegitimate traffic. If it's your position that the ISP can't tell the difference, then the notification that we know happened would have been impossible. Presumably they even identified the particular customer responsible for the traffic, given that they notified him about it! Since it's obvious in this case that the customer would have preferred being disconnected to having to pay for the traffic, and the ISP could certainly have disconnected him, the question becomes, why didn't they? Especially since they knew the attack traffic was creating other innocent victims. My guess is that they *were* filtering it (probably by port) and never delivered the attack traffic to its destination anyway. They probably still billed the customer because they bill for traffic over the customer's line, regardless of whether it hits their emergency or bogon filters. > > And, again, almost every contract has some insurance elements to it. > > There will be unusual cases where it's actually possible for the utility > > to lose money if something unusual happens. My main point is that the > > understanding that seems so obviously right to you may not seem so > > obviously right to your customers. > No sane ISP will insure a usage-based customer against traffic sent by > that customer's infected machines AFTER he has informed the customer > of the problem. No sane ISP will allow attack traffic to continue to hit the Internet after they know it's coming from one of their customers regardless of what the customer does or does not do. So why should the customer pay for "Internet traffic" that their ISP likely did not (and certainly should not have) actually sent or delivered? > > As for all the people who talk about turning off their DSL > > access when > > they're away from home, they're missing the point. Obviously a person > > could do that. We could shut off our electricity when we leave home. We > > could have our telephone service temporarily disabled when we go on > > vacation too. A person could do all of these things. My point is that > > it's also perfectly reasonable for a person not to do these things. > > Because in general an ISP has more ability to control these > > things and it > > makes very little sense for a home user to insure an ISP, it makes more > > sense for the ISP to insure the user. > I still don't understand why you insist that my ISP has (or should have) > more control over what traffic my systems deliver to my internet > connection > than I do. This simply isn't the case, and I would be very unhappy if > it were to become the case. For the classes of service I'm talking about, like home DSL, they do. They choose which ports to block and they have a responsibility to monitor their customers for machines that are causing problems for others. In this case, they actually did that and detected the problem -- good for them. But they then decided that instead of remedying the problem, they'd bill their customer for it. Maybe they blocked the attack traffic, maybe not. If so, why charge for traffic you won't deliver? If not, then that's serious negligence, no? > > In any unfortunate situation, you can find a hundred things > > that anyone > > could have done differently that would have avoided the situation. But > > that is not how you establish responsibility, financial or moral. You > > look at people who failed to use reasonable prudence. > And you don't think that a person who is informed that their system is > infected and chooses not to fix it has failed the reasonable prudence > test? You think an ISP that knows that their customer is sending attack traffic but neither blocks the traffic nor shuts off the customer has failed the reasonable prudence test? And who should be more subject to a reasonable prudence test for Internet practices, a home DSL customer who may not know very much about computers, or an ISP that specializes in Internet access that has monitoring equipment a trained staff 24/7? Your customers expect you to deal with this stuff. You may or may not find their expectations reasonable, but dammit, you had better know what they are! > > And, of course, the ISP always (or very nearly always) > > insures the user > > against the costs of inbound attack traffic that exceeds his line rate. > > The more demands you make of your customers, the more you decrease the > > value of your very own product. > Right, but, that's not what happened in this case. No, this is much worse. This is a case where an ISP allowed an attack to continue, probably creating more innocent victims. > > The arguments that seem so obviously right to you may be greeted by > > amusement and the analogies you think work will be found unconvincing. > > This is because this argument is largely about other people's > > expectations. > Yep... and generally, no matter what, if you find a large enough group of > people you will find a certain percentage that will give up their lives > before they give up their unrealistic expectations. I don't think they're so unrealistic. It takes a level of expertise to keep a system safe and secure on the Internet, and the costs of obtaining that level are so high that you would lose half your customers if you insisted on imposing those costs on them. This is why home DSL is so heavily filtered. > However, that doesn't change the fact that a user who has an > infected system > sending traffic on his usage-based line may have a resonable > expectation not > to pay for it before his ISP informs him of the problem. However, any > expectation not to pay for it _AFTER_ the ISP has informed him of the > problem > is unrealistic, unreasonable, and, completely fails "reasonable prudence". Why? Because the ISP has no responsibility to stop attack traffic from its own customers after it has detected it?! (By adding filters, shutting off customers, repeatedly pestering them, or *whatever* it takes.) If you really believe that, you'll set inter-ISP cooperation back many years. DS

1 0

RE: Even you can be hacked
by Mike Walter 11 Jun '04

11 Jun '04

That is true, but only if they are placed in DeLorean because they filled with drugs. Mike -----Original Message----- From: John Neiberger [mailto:John.Neiberger@efirstbank.com] Sent: Friday, June 11, 2004 5:10 PM To: nanog(a)merit.edu Subject: RE: Even you can be hacked >>> mwalter(a)3z.net 6/11/04 3:02:42 PM >>> > >Now you are just getting silly, we know Flux Capacitors don't work on >earth. Sure they do, at least the ones made since 1985. I believe I remember a DeLorean that used one. John --

1 0

[OT] common list sense (Re: Even you can be hacked)
by Dickson, Brian 11 Jun '04

11 Jun '04

Paul Jamka [PJ] wrote: On Thu, 10 Jun 2004, Laurence F. Sheldon, Jr. [LFSJ] wrote: LFSJ> I'm on the list folks, if you send it to the list I'll get it. I don't need a copy to the list and Cc:'s until the end of time. PJ> Then set a Reply-To. Pretty simple. In case no one else bothered to point this out: Not everyone who *posts* to NANOG *reads* nanog via email. For example, I read it via the web archive. For those like us, any presumption about replies to the list being read by us, would be incorrect. And since no one necessarily knows the current subscription status of everyone else, it actually makes sense to copy both the sender and the list. As Randy [Bush, of course] points out, if you don't like duplicate mail, you are free to use some kind of filter. (Please don't bother replying. I am just attempting to get in the last blow before the equine perishes.) Brian

1 0

RE: Even you can be hacked
by John Neiberger 11 Jun '04

11 Jun '04

>>> mwalter(a)3z.net 6/11/04 3:02:42 PM >>> > >Now you are just getting silly, we know Flux Capacitors don't work on >earth. Sure they do, at least the ones made since 1985. I believe I remember a DeLorean that used one. John --

1 0

RE: Even you can be hacked
by Mike Walter 11 Jun '04

11 Jun '04

Now you are just getting silly, we know Flux Capacitors don't work on earth. Mike Walter -----Original Message----- From: Matthew McGehrin [mailto:mcgehrin@reverse.net] Sent: Friday, June 11, 2004 5:00 PM To: nanog Subject: was: Even you can be hacked Coupled with a Flux Capacitor for the ultimate in message delivery :) ----- Original Message ----- From: "Scott Stursa" <stursa(a)acns.fsu.edu> To: <nanog(a)merit.edu> Sent: Friday, June 11, 2004 4:44 PM Subject: Re: Even you can be hacked > Ah. A tunneling implementation. > You'll need a cold fusion generator to power that.

1 0

AV/FW Adoption Sudies
by Dennis Dayman 11 Jun '04

11 Jun '04

Does anyone know of any studies on user adoption of security s/w (AV and FW products), including how often people update and how regularly? -Dennis

8 19

RE: MD5 BGP performance on a VXR?
by Newell, Tony 11 Jun '04

11 Jun '04

Ben, My first question would be how big is your prefix list per BGP session? What is really going to task this router with 25 sessions is the BGP Scanner and BGP Router processes. To my knowledge MD5 is just for authenticating the session. I could be wrong. Tony Newell Technical Lead RTSG-BB IP Networking -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Ben Buxton Sent: Friday, June 11, 2004 5:49 AM To: nanog(a)merit.edu Subject: MD5 BGP performance on a VXR? Has anyone done any concrete testing on how well a 7206VXR with an NPE-300 can handle BGP MD5? The box in question has about 25 sessions and is pushing 150Mbps, with a 75% cpu load. I'm curious to know if it's the MD5 taking all the CPU. Thanks, Ben ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113

3 2