An introduction to Amazon EC2 credentials

When you assign an Identity and Access Management (IAM) role to an Amazon Elastic Compute Cloud (EC2) instance, the short-term credentials for the role are made available via a web service known as the Instance Metadata Service (IMDS). The IMDS provides an HTTP endpoint for retrieving instance metadata such as the instance IP address, AWS Region the instance is running in, the Amazon Machine Image used to launch the instance, and the access key, secret access key, and session token associated with the instance's IAM role. The AWS documentation describes how to retrieve instance role credentials from IMDS. If you've seen or used the http://169.254.169.254 or http://fd00:ec2::254 endpoints, then you've seen/used IMDS.

Retrieval of instance role credentials from IMDS is the mechanism by which the AWS CLI and SDKs learn the credentials belonging to the instance's IAM role without you having to configure anything on the instance. Quoting the IAM documentation:

The AWS SDKs, AWS CLI, and Tools for Windows PowerShell automatically get the credentials from the EC2 Instance Metadata Service (IMDS) and use them.

This is great! It means you can start using the AWS CLI, SDKs, or Tools for Windows PowerShell on an EC2 instance without having to configure any credentials.

However, like most nice things, IMDS can be exploited and used in unintended ways. This blog post will explain how EC2 credentials can be retrieved from IMDS, removed from the EC2 instance, and used outside of EC2. This post will also explain some ways to mitigate this activity.

Passwords suffer from an inherent risk: whoever possess the password inherits the privileges granted by that password. If the possessor is the intended person, then all is good. Otherwise, all is not so good because it means an unintended person has access to the system the password is guarding.

A colleague of mine recently quiped, "'The perimeter' in AWS is actually defined by Identity and Access Management (IAM)." After some reflection, I think my colleague is spot on.

There can be times when you're working on the AWS Cloud where you need to grant limited access to your account to a third-party. For example:

• A contractor or a specialist needs to perform some work on your behalf
• You're having AWS Professional Services or a partner from the Amazon Partner Network do some work in your account
• You're conducting a pilot with AWS and you want your friendly neighborhood Solutions Architect to review something

In each of these cases you likely want to grant the permissions the third-party needs but no more. In other words, no granting of AdministratorAccess policies because it's easy and just works. Instead, adherence to the principle of least privilege.

This post will describe two methods—IAM users and IAM roles—for proving limited access to third-parties.

In a previous post, I reviewed what a public subnet and Internet Gateway (IGW) are and that they allowed outbound and inbound connectivity to instances (ie, virtual machines) running in the AWS cloud.

If you're the least bit security conscious, your reaction might be, "No way! I can't have my instances sitting right on the Internet without any protection".

Fear not, reader. This post will explain the mechanisms that the Amazon Virtual Private Cloud (VPC) affords you to protect your instances.

Cisco Encrypted Traffic Analytics (ETA) sounds just a little bit like magic the first time you hear about it. Cisco is basically proposing that when you turn on ETA, your network can (magically!) detect malicious traffic (ie, malware, trojans, ransomware, etc) inside encrypted flows. Further, Cisco proposes that ETA can differentiate legitimate encrypted traffic from malicious encrypted traffic.

Uhmm, how?

The immediate mental model that springs to mind is that of a web proxy that intercepts HTTP traffic. In order to intercept TLS-encrypted HTTPS traffic, there's a complicated dance that has to happen around building a Certificate Authority, distributing the CA's public certificate to every device that will connect through the proxy and then actually configuring the endpoints and/or network to push the HTTPS traffic to the proxy. This is often referred to as "man-in-the-middle" (MiTM) because the proxy actually breaks into the encrypted session between the client and the server. In the end, the proxy has access to the clear-text communication.

Is ETA using a similar method and breaking into the encrypted session?

In this article, I'm going to use an analogy to describe how ETA does what it does. Afterwards, you should feel more comfortable about how ETA works and not be worried about any magic taking place in your network. ?

Whether it's Dropbox, LinkedIn, MySpace, PlayStation, or whatever the latest breach happens to be, it's almost inevitable that you will be caught up in one of these breaches and have your username, password and possibly other information exposed in a data dump. Here's how to respond when that happens.

There's a lot of information on the intertoobs about getting ssh-agent "working" in OS X and even more articles about when and how the stock behavior of ssh-agent changed (mostly with respect to how ssh-agent interacted with the Keychain).

This article doesn't cover or care about any of that.

This article is concerned with:

• Enabling ssh-agent in such a way that I can "ssh-add" in one terminal window and that same agent (and the loaded keys) is available in all of my other terminal windows.
• Enabling use of ssh-agent from MacPorts and/or Homebrew and not the older ssh-agent that OS X ships with in /usr/bin.
• To avoid having to put my keys in the Keychain (just a matter of preference).

I'm a big fan of Let's Encrypt (free, widely trusted SSL certificates) but not a big fan of most of the client software available for requesting and renewing certificates. Unlike a typical certificate authority, Let's Encrypt doesn't have a webui for requesting/renewing certs; everything is driven via an automated process that is run between a Let's Encrypt software client and the Let's Encrypt web service.

Since the protocols that Let's Encrypt uses are standards-based, there are many open source clients available. Being security conscious, I have a few concerns with most of the clients:

• Complication. Many of the clients are hundreds of lines long and unnecessarily complicated. This makes the code really hard to audit and since this code is playing with my crypto key material, I do want to audit it.
• Elevated privilege. At least one of the clients I saw required root permission. That's a non starter.

I wanted to jot down some quick notes relating to running a virtual Firepower sensor on ESXi and how to validate that all the settings are correct for getting traffic from the physical network down into the sensor.

Firepower is the name of Cisco's (formerly Sourcefire's) so-called Next-Gen IPS. The IPS comes in many form-factors, including beefy physical appliances, integrated into the ASA firewall, and as a discrete virtual machine.

Since the virtual machine (likely) does not sit in-line of the traffic that needs to be monitored, traffic needs to be fed into the VM via some method such as a SPAN port or a tap of some sort.