Slashdot Mirror
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."
I, for one, welcome our new spam overlords...
While I'm against the death penalty, I might be willing to consider it for spammers.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
I drankj a fifgth of wild turkey!!!!!1
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.
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.
Somebody finally solved the ????? = Profit equation. What's everyone getting so worked up about?
Everybody's a libertarian 'till their neighbour's becomes a crack house.
or virtual/private server company? And what would happen to the spammers? Account cancelled, so they'd just find another colo/host, or use one of many stolen credit cards to register another account with same host, under a different name. How is this any different?
body massage!
Article doesn't say.
Summary doesn't say.
Is William Gaine's returning to make an EC Comics revival?
I'm afraid taint.org might not be safe for work.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
They should require everyone that's sending mail to sign all mail with an extended validation certificate. The cost on this alone would probably cut down on the amount of spam. All outgoing mail from the cloud would have to pass through a filtering server that verifies keys on the outgoing mail.
Once they have the name of the instance, they also know who launched it -- after all, they are billing someone.
I like the suggestion to charge a large fee to the credit card they have on file, but what about simply banning the account in question?
Don't thank God, thank a doctor!
Charge $0.01 per message. Should put an end to spam pretty quickly.
Conformity is the jailer of freedom and enemy of growth. -JFK
The UK Honeynet Project spotted this a few days earlier :)
http://www.ukhoneynet.org/2008/06/30/it-had-to-happen
Achievem3nt5 that
Offer a spamfree block of IPs using their persistent IP offering, and let people put in a large deposit when getting an IP there. If they spam, confiscate the deposit. Use the interest on the deposit to offset the cost of triaging abuse complaints.
Although if mail is incidental to your business you can probably just host a relay offsite.
ok, your linux server becomes part of the botnet via some php exploit or some dumb asses winbox gets infected by malware and starts spamming... lets charge them $100 per incident... What kinda dumb ass idea is this? The spammers still get to fill mail boxes full of shit and innocent ppl end up paying for it.
Why do all the antispam nazi's solutions ignore the collateral damage to innocent by standers? "They should educate themselves" "they should switch providers" they scream. Black lists do nothing but break the system. I'd rather get all the spam than have important mail bounce. Just last week I had a mission critical email bounce because of some lame blacklist. This email not getting to its recipient would have basically ruined my life. Its a good thing I have the ability to send mail from more than once source.
Here is a wild idea... WILD.. Off the hook insanity....
Just block ALL of EC2 from being able to send out anything on port 25 and 587.
Problem solved. Last time I checked EC2 has a lot more interesting uses than running mail server software.
I think all the ideas of placing a deposit or putting an extra charge per message are against the EC2 model. The whole idea is to offer a high capability solution at a low entry price that scales easily.
Spammers and abusers tend to have distinctive patterns and this what Amazon should be paying attention to. Ie. some guy using a US credit card, logging to his instance from eastern Europe and sending a zillion emails messages the second day after sign up should raise some doubts. Manual inspection of suspicious traffic can be very costly but they can easily build a growing list of trusted customers who use the service for legitimate reasons and monitor suspicious traffic from new registrations.
If this would work, it would probably need to be combined with one of the other ideas above -- either requiring additional verification or posting a bond to remove the filters from instances created under a verified/bonded account. Some users will have legitimate reasons to send emails (some a few, some many) but many probably don't.
Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading
why not run an inward facing IDS- something like snort. It's easy enough to setup a script that automatically terminates accounts of people sending abuse, and to do it on the first instance of that abuse.
So long as it's not your stupid bank storing unencrypted info on tapes that went MIA. I guess the few million people that it has happened to this year, alone, would be annoyed, if not stupid.
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Ah, the PBL. That's where your argument falls to pieces.
From http://www.spamhaus.org/pbl/index.lasso :
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/ ) - please contact postmaster@whineyblacklisthater.org 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?
Um, yeah. I work for the isp in question. So, no, they didnt include my block in a list of ips that shouldnt be sending mail.
Since the offending ip was not listed in the data base when i checked the url I can only assume that I was a victim of a a misconfiguration on the other side.
I've installed, ran, and maintained exim. I've managed an exchange server for a minute. And I have my own pop3 and smtp server. I've sent mail by hand telneting to the smtp server. My experience with black lists is they have screwed me personally several times and they are almost always run by asshats with religious fever.
and how does the arguement fall apart? My legitimate mail didnt go thru. end of line.
Reduce, reuse, cycle