HN Explorer

Using temporary IPs in the cloud considered harmful

32 points by maconic ↗ HN
Here's an amusing hobby: 1. Start Amazon EC2 instances (or any other cloud service) 2. Use something like honeyd to listen on all ports 3. Wait for random activity associated with the previous owner of the EC2 instance to start flowing in.

I stumbled across this by accident after getting flooded by connections from apps.facebook.com which seems to be trying to interact with a Facebook app that was previously hosted on an IP which I'm now using. Presumably the previous owner of an EC2 instance had a DNS name that resolved to this IP and didn't see the risks of doing so. Remember: the Amazon public IPs are temporary and will be reassigned once the EC2 instance stops or dies.

For the sake of your users' privacy and security, use Elastic IPs. Even if the instance dies, the Elastic IP still belongs to you and won't be accidentally be reassigned to someone else. When you start up a new instance you can have the Elastic IP assigned to the new instance using ec2-associate-address.

22 comments

[ 4.2 ms ] story [ 54.3 ms ] thread
wooster
I still get requests to my dedicated server at Softlayer for the Facebook app which used it before me. I've had the server since mid-2008. Really, this seems like a problem on Facebook's side.

The bigger problem is trying to run a mail server on EC2. You can't, really, as a lot of providers are still doing (stupid) IP based filtering.

qjz
I've been permanently blocking all connections from any AWS/EC2 netblock I identify after an initial exploit attempt. I much prefer temporary blocks triggered by bad behaviour, but the constant onslaught from AWS finally got to be too much. In the last several months, blocking AWS has done more good than harm. I don't seem to be blocking any legitimate traffic or users, just badly behaved startups and downright malicious crackers. It was a tough compromise, but so far it doesn't seem stupid.
holdenk
How have you measured if its done more good than harm if your doing a complete block?
qjz
That's a fair question. Issues with misguided draconian measures tend to be revealed fairly quickly, but I also gradually rolled the policy out to several servers so I could make comparisons. With the AWS block in place, I'm sacrificing a lot less bandwidth to the startup crawler du jour (there appear to be a lot of Google wannabes in the AWS space) and there's a huge reduction in exploit attempts/pentesting against all services. It's true that the vast majority of blocks are for DNS requests, without which the domain can't be resolved, so post-block logging won't reveal the desired target host & service. Nonetheless, it's like I applied a pesticide and there is a noticeable reduction in pests. If the pesticide itself proves to be harmful, I'll adjust the amount/formulation or stop using it altogether.
patio11
Right.

Email has essentially converged on a patchwork ad-hoc net-wide implementation of a few of the proposals lampooned in the famous Slashdot copy/paste thing. Small businesses who are serious about getting their mail delivered pay what amounts to a delivery tax. The difference is it is not actually a tax, it is just a per-piece rate paid to a mailing service that keeps up with all the SPF records, feedback loops, blacklist monitoring, etc for us. However, considered from the perspective of the firm, it is essentially a tax, and it means that people paying a penny or two per email end up trustworthy. Everyone else is left in the email wild west, where they either have massive amounts of physical and reputational capital (Amazon et al) and get their mail accepted for free, or they're almost certainly trying to spam you (statistically speaking).

This is strongly related to strong centralization of email. I just had my 20,000th email submitted yesterday. Of those 20k, over 12k belong to just 10 domains. Even that overstates the diversity of spam squashing strategies, since most of the domains eventually use the same RBLs, etc.

viraptor
> "Everyone else is left in the email wild west"

In my experience some anti-spam organisations seem to want to keep that area wild. Or they just don't see the standard problems from their high horses. I get most of my servers listed as dynamic at least twice a year just because the ISP happens to provide residential dynamic DSL in the same netblock. And I can't change the rDNS of course, because the ISP doesn't allow it for people with ranges smaller than /28. Good luck explaining the situation to sorbs or people who block based on sorbs' dynamic list unconditionally.

sailormoon
Yeah that sucks. But you have to admit their reasoning is pretty sound.

The minimum "credible" IP suitable for duty as an email server is probably a cheap VPS somewhere.

mschy
I've had /23s and /22s listed as dynamic incorrectly, and anti-spam organizations wouldn't take them off even when they were either SWIPd through to my company, or were in my ASN.

Getting off the lists is an enormous pain in the ass. They make absurd demands, like changing the rDNS on every single IP in the block to contain the word static.... as though breaking rDNS is a good idea.

sailormoon
Argh. Well that's pretty indefensible. There must be some reason, though - you probably had the bad luck to take over a block that had previously been blacklisted.

That "static" thing is just stupid. God I wish ISPs would just standardise on putting "dyn" into the rDNS of their dynamic IPs though. That would solve so many problems.

mschy
you probably had the bad luck to take over a block that had previously been blacklisted.

That's exactly what happened. It was apparently dial-up space many years ago.

I say many, because the space in question has been under my control since 2005, and it's STILL on the dynamic ip list, despite a roughly annual attempt to get de-listed.

sailormoon
Everyone else is left in the email wild west, where they either have massive amounts of physical and reputational capital (Amazon et al) and get their mail accepted for free, or they're almost certainly trying to spam you (statistically speaking).

Hm. I've been involved with the mail servers of a few small businesses and I don't think it's as bad as you're implying. SPF isn't hard to set up, the RBL systems seem to work pretty well, and if you're sending from a stable IP/domain with a few years on the clock and no history of abuse, your mail will usually get through.

I view those for-pay mailing companies as being necessary only if you're sending out something a little spam-like but not spam, like opt-in mailing lists or marketing material or something that might otherwise look a lot like spam. But for regular mail I don't think it's at all necessary.

wooster
"your mail will usually get through"

Not in my experience. I have been on both sides: sending mail, and implementing IP based filtering. It's a clusterfuck.

brettnak
Am I the only one who get's frustrated by 'considered harmful' titles? Sorry for being off topic.

EDIT: I'll give you that it's not as bad as the whole (win|fail|this) thing that's becoming popular.

cperciva
frustrated by 'considered harmful'

Yeah, this is a clear case of "... for fun and profit".

cmelbye
I personally found the submission very informative and useful. I mean, "considered harmful" sounds a little weird, but doesn't really affect the content of the submission.
tptacek
You should make a web site with examples or a report of the kinds of traffic you get. I'd do it, and get a zillion hits on it and probably some press attention, but it's your idea.

You have a really good point.

prodigal_erik
For the sake of your users' privacy and security, use TLS (or IPSec) and a certificate that identifies your server. Anything sent in the clear is vulnerable to eavesdropping and tampering, whether or not the destination IPv4 address appears to be under your control.
eli
That's not always practical if you're interacting with another service like Facebook that won't know to check.