Re:EC2's most dangerous feature
by cesarb on Sunday October 09, 2016 @08:30AM
(#12670925)
What I've done for a previous company was to, as one of the very first things done within every EC2 instance, add an iptables owner match rule to only allow packets destined to 169.254.169.254 if they come from uid 0. Any information from that webservice that non-root users might need (for instance, the EC2 instance ID) is fetched on boot by a script running as root and left somewhere in the filesystem.
[ Parent
| on HN ]
This won't help with IAM roles, since the credentials provided in the metadata expire. Of course, a small tweak to the iptables entry would help there as well.
Mind posting your entry for us iptables impared folks?
I don't work there anymore, so I don't have access to the exact rule I used, but IIRC it was something like
iptables -t filter -I OUTPUT -d 169.254.169.254 -m owner \! --uid-owner 0 -j REJECT --reject-with icmp-admin-prohibited
But the data is not static.
Most of it is - your instance ID, network position, etc, will never change after boot (or 'start' if you stop it) - so caching it is just fine. There's very little that will change on a running instance except of course, the IAM credentials referred to in this article (as they expire within 90 minutes IIRC).
Re:EC2's most dangerous feature
by jamiesonbecker on Sunday October 09, 2016 @11:00AM
(#12671475)
The irony is that the attempt to make the instance creds secure by rotation actually prevent protecting them in this fashion. A local file, readable only by root, w/ embedded keys is actually far more secure than the current implementation.
It's easy to implement that yourself. Generate a pair of IAM keys and drop it on the filesystem or bake it in the ami or application or whatever.
What they have reduces the duration of a vulnerability so that if you know someone had access to your machine at some point in time, you cna figure out from there how long their keys would have lasted and scope down the timeframe to start digging with in cloudtrail