Amazon's EC2 Having Problems With Spam and Malware

jamie pointed out a story about the recent problems Amazon's EC2 service has been having with malware and spam. "EC2 space is now actively blocked by Outblaze, and has been listed by Spamhaus in their PBL list [...] However as Seth Breidbart noted in the comments, 'note that Amazon will terminate the instance. That means that the spammer just creates another instance, which gets a new IP address, and continues spamming.' True enough -- as described, instance termination simply isn't good enough."

Death Penalty

While I'm against the death penalty, I might be willing to consider it for spammers.

Re:Death Penalty

Now thats the REAL instance termination we need!

Not spam filters, SPAMMER filters!

Re:Death Penalty

Because oftentimes it isn't those companies' fault. Say you have an affiliate program, or you rely on a third-party affiliate program management firm to provide compensation for those who promote your products. You can have strict terms for those people that warn against using spamming tactics to promote their affiliate sales, and you can terminate the ones who get caught, but you can't ever guarantee compliance en masse.

Your suggestion is equivalent to throwing knife makers in prison because some of their customers misuse the product.

Re:Death Penalty

As someone who has been involved with both sides of an affiliate program myself, I tend not to agree with your assessment. The company I worked for did an amazingly good job of keeping spammers from promoting our products. We had people on this continuously. These aren't random folks, they're people who we are paying (i.e. have an ongoing legal business relationship with) to bring customers to us. You can damn well bet it's our responsibility to make sure they act appropriately: they're our employees (claims of "independent contractor" notwithstanding).

I think that a reasonable legal framework for applying pressure to companies that benefit from spammers is warranted. I would have been glad to work under such a framework myself. Really, there's no excuse.

Cheers.

Terms of Service

They have the credit card numbers of these people, no? Add a $1000 (or more) charge to the TOS each time someone gets caught spamming through them. That should make a pretty clear point.

Re:Terms of Service

And what if the credit card in question is stolen?

Re:Terms of Service

Then the owner will actually notice that his/her card is stolen, and finally go over the bill with a fine-toothed comb, disputing charges as they go.

Nothing is lost.

Re:Terms of Service

That's something of an extreme approach. Not exactly the sort of behaviour that would endear a company to its customers.

If your EC2 account got hacked (which may happen if its worth the effort), you would end up hacked, billed, and having quite possibly a hell of a fight to get your cash back.

Re:Terms of Service

Actually, both Visa and MasterCard hold banks to the same "Zero Fraud Guarantee" policy for Debit Cards as they do Credit Cards.

In fact, if you search Visa.com for their Consumer Credit Card and Consumer Debit Card pages, you'll see that the Zero Fraud Policy link on both takes you to the same page.

They require that banks put provisional funds back into your account within 5 days of the dispute being made. Most banks do this the same day. I bank at BoA and they do it within hours.

The policy extends to charges incurred as a side-effect of the fraud, like overdrafts.

It does not apply to pin-based transactions, but there are no pin-based transactions on the web anyhow.

This makes sense if you think about it and it has nothing to do with Congress. Many people are transitioning away from cash. I hardly EVER carry cash. I use my Debit card for everything. And Visa has a vested interest in seeing this continue. A HUGE interest.

Besides, there is no difference between "Banks and credit unions" and "credit card companies."

Visa doesn't give out credit. They don't even give out credit-cards. They just provide a clearinghouse network. On their end, a Debit Card transaction (non-pin-based) looks identical to a CC transaction.

Of course, none of this applies if your debit card doesn't carry a Visa or MC logo. But if that's the case, you're not using it online, anyway.

Re:Terms of Service

Then amazon needs to do a much better job of determining who their clients really are, and there are quite a few fairly reliable ways of doing so.

Nothing is perfect, but it can be made very hard.

Re:

Depends, if it is not reported stolen; tough luck for the card holder, if it is; tough luck for the credit card company.

Re:Terms of Service

Actually, tough luck to vendor who allowed the fraudulent transaction. The credit card companies themselves typically have very little (any?) responsibilities when it comes to fraudulent transactions. It's entirely up to the vendor to do the proper verification prior to billing a transaction, as far as I know.

The problem is that these small fraudulent transactions are typically more expensive to track down than they are to write off. If someone racks up a $1,000 bill on the ec2 cloud with a stolen card, the credit card company isn't out a dime, and the vendor (in this case Amazon) isn't likely to spend much time finding and prosecuting whoever is using the stolen card because it's expensive and time consuming to do so. Sure, maybe some ip addresses will be blocked and cards added to blacklists (temporarily?) but that doesn't stop the next guy from doing the same with a new stolen card.

Re:Terms of Service

What's interesting about the set up (where the merchants are responsible for the fraud, not the credit card companies) is that the card companies have very little incentive to prevent fraud. In fact, they frequently have a disincentive: They collect a $25+ per charge "chargeback fee" from the merchants, for fraudulent charges. It would be in credit card companies' interests if fraud increased! (Of course, not past the level where merchants are hurt too badly to stop accepting cards).

Re:Terms of Service

No kidding. I'd say you have to put up a bond if you want to be able send more than some small threshold of emails out per day (100?). If you're good, you are safe. Maybe you get your bond back after 6 months. If you misbehave, Amazon cuts you off and you just lost $5-$10k.

Terminate accounts not instances?

Why aren't Amazon terminating the accounts of offenders, and blacklisting whatever payment method they're using? It's a paid service, it's not like spammers can register for new accounts as much as they like, they're going to run out of credit card numbers (well, assuming their activities aren't more nefarious than mere spam).

It's not in Amazon's interests to have EC2 blacklisted.

Re:

I agree with parent. This should be a non-issue. Just shut the account off, (possibly with a fine, as suggested elsewhere), and disallow the account holder from creating another account.

Re:Terminate accounts not instances?

There's actually a solution to that, but it involves slowing the process down. Just don't activate the account once the information's entered. Instead, send a physical letter to the credit-card billing address. You can require a form to be signed and returned, or just include an activation code in the letter that has to be entered to turn the account on. That should make it infeasible to use 99% of stolen cards. It introduces a few days of delay between requesting the account and getting it, but IMO if you intend to use the account for any length of time a few days shouldn't be an issue and if you don't then you're likely exactly the kind of person this is intended to filter out.

Sheesh, seems like a match made in heaven

Previously, senders of large volumes of paid-for (by the sender) yet unwanted (by the receiver) emails had to corral their own clouds of distributed, low-cost computing resources (a.k.a botnets). Amazon provides similar capabilities for pennies an hour. Both Amazon's and the emailers' business models work, and questionable penetration of third parties' computers is no longer required.

Somebody finally solved the ????? = Profit equation. What's everyone getting so worked up about?

Re:Sheesh, seems like a match made in heaven

Amazon will fix this, as soon as they have an incentive to do so. IE, if enough blocklists start adding their IP's, customers will threaten to take their business elsewhere, as their legitimate emails are not going through.. then, and only then, will amazon act (and only if the cost benefit to fix are less than the development time, and income from spammers). Would you expect a corporation to do differently?

I'd RTFA but...

I'm afraid taint.org might not be safe for work.

Re:I'd RTFA but...

My thoughts exactly. Luckily, Brian Krebs at the Washington Post wrote about this in his Security Fix blog [washingtonpost.com].

Re:

The hoster terminates the client and won't sign him up again. Amazon could easily do he same but doesn't. Instead the only terminate the instance.

Re:So what is EC2?

The top hit from Google would have told you. It's Amazon's Elastic Compute Cloud [amazon.com].

Re:So what is EC2?

Wikipedia says it's the north eastern corner of the city of London, roughly. I don't get the article, either.

PBL is the wrong blacklist to whine about

Of course it gave me a reason. 554 Denied [SHPBL] - Denied by Spamhaus PBL along with a nice url. I'm not willing to give up any more details than that as I am not interested in posting any of the related ips.

Ah, the PBL. That's where your argument falls to pieces.

From http://www.spamhaus.org/pbl/index.lasso [spamhaus.org] :

PBL IP address ranges are added and maintained by each network participating in the PBL project, working in conjunction with the Spamhaus PBL team, to help apply their outbound email policies.

So, your ISP told Spamhaus that mail shouldn't be coming from the range your IP address is in. Not Spamhaus making a trite, petty and vindictive block for the fun of it. Not some blacklist deciding in error to block a whole /24 full of static addresses with REAL rDNS records for most of it because they found a couple of zombied machines with vaguely generic-looking PTRs in it. This is a case of the people you pay for connectivity telling Spamhaus that the rest of the world should not accept mail from your IP address or others near it until further notice - they're being good neighbours, and are to be applauded.

If you have a static address you can poke a hole in the PBL for it pretty easily - *you* can provide that further notice:

A feature of the PBL is the elimination of 'false positives' with a server-identifying and automatic removal mechanism for single IP addresses. This allows end users with static IP addresses within a larger dynamic pool, and legitimate mail server operators, to assert that in their opinion their IP addresses are a trustworthy source of email and to automatically remove (suppress) their IP addresses from the PBL database. Safeguards are built in to prevent abuse of this facility by spammers (and particularly by automated bots).

Do your research. The PBL is pretty damn useful, and you probably qualify for free use. If you have an unfiltered postmaster address on your domain (you do, don't you?) the smart thing would be to start blocking with it but make sure the rejection contains something like "Rejected: $IP_ADDRESS listed in Spamhaus PBL ( http://lookup-urlip_address/ [lookup-urlipaddress] ) - please contact [e-mail] for assistance if required" - you'll find that the "false-positives" for it are almost invariably from people who don't know what the PBL is and want to do their own thing, regardless of the practicalities the rest of the world has to face. Why should I or anyone else accept mail from somewhere your own ISP or their upstream provider has said I shouldn't?