3 ms·

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 pac

by cesarb 10y ago

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.

falcolas 10y ago
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?
- cesarb 10y ago
  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
jeremyjh 10y ago
That is the obvious answer, do you have any scripts you could share?
manojlds 10y ago
But the data is not static.
- abofh 10y ago
  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).
  - jamiesonbecker 10y ago
    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.
    - TheDong 10y ago
      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

by cesarb 10y ago

falcolas 10y ago

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?

cesarb 10y ago
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

jeremyjh 10y ago

That is the obvious answer, do you have any scripts you could share?

manojlds 10y ago

But the data is not static.

abofh 10y ago
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).
- jamiesonbecker 10y ago
  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.
  - TheDong 10y ago
    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