I just called up my bank to tell them to 'block' it as a precaution (I will now have to give them a visit later today to get a new card). I encourage all other Linode customers to do the same, because it'll be easier to just spend half an hour doing this instead of spending hours upon hours disputing specific transactions.

Linode customer support keeps saying they have "no comment" on this issue (which I suppose does make sense -- I'm assuming they've been ordered by law enforcement persons to not share details), so as we're not being given much information to work with... just treat this as a worst-case scenario (all names, addresses, credit card numbers, etc. have been compromised). Do operate now with the assumption that all of this data has been compromised and may very well be public soon.

I live on the internet. Put my credit card out on many services. Over the last 5 to 8 years I've had my credit card numbers taken I believe 4 times.

Never had to dispute it once. These Credit Card companies and Banks have a stake in not allowing your account to be drained.

I think it would be a waste of time to go out and cancel our CC until hearing from Linode that yes, CC information was taken.

With that said - almost everyone seems to feel comfortable handing out their credit card to random taxi drivers, waiters, sales staff - with no idea whether a copy of their information is being taken down. Heck - if you give them the Credit Card, they even get your CCV as well.

I even wrote a blog post about it. I probably don't know what I'm talking about, but these were my thoughts at the time:

Wishlist – A Method to Pre-Approve and Track Credit Card Transactions

The issue:

A business using a credit card doing business with a relatively small number of vendors wanting to first avoid credit card fraud (stolen numbers) and secondly wanting to easily track down the offending business.

The idea:

The business would like to approve particular vendors to use the credit card with number 0000-0000-0000-0000 with each individual business pre-approved to run the transaction with a 5th set of identifiable numbers, so something like 0000-0000-0000-0000-0001.

If the credit card is used to make a fraudulent transaction, then ideally, they would have had to have used the 5th set of identifying numbers. This 5th set of identifiable numbers would then allow for easy tracking of the offending vendor, which would allow the business to either re-think doing business with them, or to serve as a starting point discuss security issues with the vendor’s credit card transaction processes.

Summary:

Basically, I believe there may be a need for a new or value added credit card type service. This transaction type would require a 5th set of numbers which have been assigned to pre-approved vendors. This 5 number set (ie. 0000-0000-0000-0000-0002) credit card transaction would most likely prevent theft right off (because the vendor is pre-approved and should provide their own private key (ie. CCV) to put through the transaction). Secondly, if and when the credit card number is stolen and used to make a fraudulent purchase, then, at least with the 5th number set a vendor can be identified and security policy with them can be re-evaluated.

http://www.redbridgenet.com/blogging/wishlist-a-method-to-pr...

My bank in Sweden requires MasterCard SecureCode for all online transactions on their debit cards. Stores that don't support it simply won't work with the card.

So, it's up to the bank how secure they want it to be. The technology is there.

My advice is different, though. I notice that I tend to get lucky in places where people can have very aggravating experiences. I'd say that if you've had problems before, then anticipate problems this time around too. If you haven't, then don't bother.

Also, great idea. But a pain, because most of my bills - cell, internet, insurance(s), etc all go through my credit cards. Is a gigantic pain to change the numbers.

Are you thinking of expired cards? That is different.

Unless the attacker dumped them all (semi) publicly, the more likely explanation is that the breakin caused people to check their accounts and a statistically normal percentage of them showed fraud from another origin. But anybody who sees it will be sure to get online and find others in a similar situation.

Everybody would be doing themselves a big favor if they stopped treating CC info as the #1 scary OMG data theft. The banks programmed you to care because congress made sure they're liable instead of you. Theoretically you might owe $50 due to fraud but practically you never pay a dime. Sure it's a bit of a pain in the ass to get resolved, but it's not worth stressing about until it happens.

I'd be way more concerned if my hoster lost my contact info, ip logs and identity challenge questions & answers.

I contacted Linode support and they've said in clear terms that they have no evidence that payment information of customers was accessed. I initially signed up for Linode because my friends spoke highly of the tech people working at Linode. Right now amidst all the commotions it's ryan's words (some anonymous dude who joined #linode/irc.oftc.net) vs. an established company's. I'm just going to now stop worrying and get back to my work.

On an interesting note, the big target who actually incurred identifiable damage was seclists.org: http://seclists.org/nmap-dev/2013/q2/3

Well that's a first. They were very evasive about it earlier.

With this lack of transparency, I feel like I had no choice but to block my card.

> In addition, we have found no evidence that payment information of any customer was accessed.

The question isn't transparency, but trustworthiness. Either Linode is telling the truth, and this anonymous IRC person with a pastebin is trolling everyone, or Linode is lying (or alternatively, Linode is incompetent and simply didn't detect the CC access). At the moment I'm going with Linode is telling the truth, because honestly, am I going to believe an anonymous person on IRC over a company I do business with?

Secondly, if they hold that data, it's possible one day someone will find a security breach and will access that data. The best solution is to never hold that data.

Since I don't trust most of the systems I use AND Linode has not denied it holds that data... I'm more inclined to believe in this anonymous IRC guy and err on the side of caution.

If Linode had come out and said "Look, we don't hold your CC number in our database" then I think there would be very little reason to be concerned. However...

Mine is not a CC or a debit card, it's a 'prepayed card' so liability is limited.

Still, I'm considering calling the lost/stolen line of the card.

   Thank you for contacting us. We have no evidence at this time that any payment information was compromised.

"We appreciate the response, and we can assure you that we have implemented all appropriate measures to provide the maximum amount of protection to our customers."

So I guess the answer would be, if you ended up hooking your PayPal account up to Linode in the way I described, yeah follow the same steps as other cards, otherwise it's not even possible to have a problem.

[1] http://forum.linode.com/viewtopic.php?f=20&t=9978

Waiting for their own lawyers would be a particularly weak excuse. This is a priority, and they are responsible from conveying that urgency to their lawyers.

/end nitpick

   1. (offline) Boot new and old VM servers from live CD
   2. old server: dd if=/dev/sda bs=8M | pbzip2 -c | netcat <newhost> <random high port>
   3. new server: netcat -l <same port> | pbzip2 -cd | dd of=/dev/sda bs=8M

Yeah, I mentioned that at the bottom of my post. Using ssh or some other inline encryption would be a good idea if it is a system you care about. If you have a site to site VPN tunnel between your systems, you can skip adding the encryption.

It wasn't there when windsurfer replied to you (I was reading the thread earlier), hence his question.

let SSH handle compression for you instead.

You don't want to leave out the compression or block size however, so add those back in. Most WAN links are low bandwidth enough that compression will not slow things down (this is usually true even on 1 GBE LAN links for pigz) and in my experience the speed-up is substantial.

pigz is much faster than using ssh compression as it is multicore. apt-get it or http://zlib.net/pigz/

In most cases, compression at the raw block level will result in HUGE size savings, especially since a lot of that may be free space. It might even make this transfer tenable.