Accenture : AWS Security Primer

Accenture released an AWS Security Primer at re:Invent last week: http://www.accenture.com/microsite/aws-2014/Documents/PDF/Accenture_Security_Perspective_AWS_web_final_1103.pdf

Amazon RDS using private IP to connect to database - not the right approach

You should always connect to your Amazon RDS instance using the RDS endpoint in the AWS console. However, some IT folks chose to use the private IP address of the RDS instance.  It is easy for you to determine the private IP address of your RDS instance by using the host or dig commands as follows (Keep in mind this is not recommended but it shows how easy it is for IT personnel that don't want to use the RDS endpoint can do so):

[ec2-user@ip-10-0-0-50 ~]$ host postgres.cyve56loidht.us-west-2.rds.amazonaws.com
postgres.cyve56loidht.us-west-2.rds.amazonaws.com is an alias for ec2-54-201-99-99.us-west-2.compute.amazonaws.com.
ec2-54-201-75-58.us-west-2.compute.amazonaws.com has address 10.0.5.204
[ec2-user@ip-10-0-0-50 ~]$ ping 10.0.5.204
PING 10.0.5.204 (10.0.5.204) 56(84) bytes of data.
^C
--- 10.0.5.204 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9792ms

[ec2-user@ip-10-0-0-50 ~]$ dig postgres.cyve56loidht.us-west-2.rds.amazonaws.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.28.amzn1 <<>> postgres.cyve56loidht.us-west-2.rds.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25864
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;postgres.cyve56loidht.us-west-2.rds.amazonaws.com. IN A

;; ANSWER SECTION:
postgres.cyve56loidht.us-west-2.rds.amazonaws.com. 5 IN CNAME ec2-54-201-99-99.us-west-2.compute.amazonaws.com.
ec2-54-201-99-99.us-west-2.compute.amazonaws.com. 60 IN A 10.0.5.204

;; Query time: 19 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Fri Jun  6 12:28:44 2014
;; MSG SIZE  rcvd: 132

OpenSwan on AWS

A common use case for using a third party VPN solution such as OpenSwan is to connect two regions VPCs through the use of an IPSec VPN server.  

First, set up a VPC in both regions with, here is what I did:

Region 1 (US-West-2) - VPC 10.0.0.0/16 with private subnet 10.0.0.0/24

Region 2 (Australia)- VPC 172.0.0.0/16 with private subnet 172.0.0.0/24

==================================================================================================================

Configure the VPN server software for the EC2 instances - Region 1

==================================================================================================================

Step 1
------
sudo yum install openswan

Step 2
------
nano /etc/ipsec.conf

Step 3
------
sudo vi /etc/ipsec.d/vpc1-to-vpc2.conf

Step 4
------
conn vpc1-to-vpc2
 type=tunnel
 authby=secret
 left=%defaultroute
 leftid=<EIP1>
 leftnexthop=%defaultroute
 leftsubnet=<VPC1 CIDR>
 right=<EIP2>
 rightsubnet=<VPC2 CIDR>
 pfs=yes
 auto=start

Step 5
------
sudo vi /etc/ipsec.d/vpc1-to-vpc2.secrets

Step 6
------
<EIP1> <EIP2>: PSK "<TYPE A KEY HERE>"

==================================================================================================================

Configure the VPN server software for the EC2 instances - Region 2

==================================================================================================================

Step 7
------
sudo vi /etc/ipsec.d/vpc2-to-vpc1.conf

Step 8
------
conn vpc2-to-vpc1
 type=tunnel
 authby=secret
 left=%defaultroute
 leftid=<EIP2>
 leftnexthop=%defaultroute
 leftsubnet=<VPC2 CIDR>
 right=<EIP1>
 rightsubnet=<VPC1 CIDR>
 pfs=yes
 auto=start

Note the CIDR needs to include the block range. For example: 10.0.0.0/16

Step 9
------
sudo vi /etc/ipsec.d/vpc2-to-vpc1.secrets

Step 10
-------
<EIP2> <EIP1>: PSK "<TYPE THE SAME KEY FROM STEP 6 HERE>"

==================================================================================================================

Configuration in each region

==================================================================================================================

Step 11
-------
a-
sudo service ipsec start

b-
sudo chkconfig ipsec on

c-
sudo vi /etc/sysctl.conf

net.ipv4.ip_forward = 1

d-
sudo service network restart


==================================================================================================================

Test your connections

==================================================================================================================

Step 1 - Region 1
------
ping 172.0.0.50

Step 2 - Region 2

ping 10.0.0.50

AWS Elastic Beanstalk and NAT instance

An Elastic BeanStalk launched in a VPC with a private subnet requires a NAT. Each instance needs to be able to talk to the Internet in order to answer the waitcondition. Connectivity can be provide through a NAT instance but there does have to be access to the internet.

The following show a VPC configuration with a private VPC. It is the connectivity to the Elastic Beanstalk end point that is needed. As you can see it is outside the VPC.

http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo-vpc-basic.html

You can find more detailed instructions for creating and configuring a NAT instance here:

 http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html

EMR in a private subnet

When running EC2 instance or other AWS services in a private subnet, you need a NAT to access S3. 

You can not use a NAT when using EMR:

http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/emr-plan-vpc-subnet.html

Because access to and from the AWS cloud is a requirement of the cluster, you must connect an Internet gateway to the VPC subnet hosting the cluster. If your application has components you do not want connected to the Internet gateway you can launch those components in other subnets you create within your VPC. In addition, because of the need to access the AWS cloud, you cannot use Network Address Translation (NAT) when you are running Amazon EMR on a VPC.

EC2 instances in public subnet calling S3 in same region

Traffic to and from S3 and  EC2 (in a public subnet) doesn’t go over the public Internet  in the same region.The traffic goes to the “AWS edge” (Internet Gateway) in that region.  It is the “public Internet” in the sense that you need an Internet Gateway, and S3’s endpoints are Internet-facing. However, the traffic does not move beyond the AWS-controlled networks if you stay within the same region.  The EC2 Instances (or other AWS services)  traffic simply travels via the Internet Gateway to S3. Obviously, for EC2 instance in private subnets they traffic would need to go through a NAT instance.

VPC benefits over EC2 classic

Here are some of the reasons why you would use VPC instead of EC2 classic for your Oracle instances:

• Predictable internal IP ranges: You define the IP address range of your VPC as opposed to your IP address being part of the AWS region IP address range.
• Subnets : Logically group Amazon EC2 instances into a private or public subnets and assign them private IP addresses.
• Traffic Routing : Control the outbound/egress traffic from your Amazon EC2 instances (in addition to controlling the ingress traffic to them; EC2 Classic security groups are ingress only) and provide selective internet access to instances.
• Network ACLs : Additional layer of security to your Amazon EC2 instances in the form of network Access Control Lists (ACLs). These allow for deny rules instead of just allow rules that security groups have.
• VPN Connectivity : Connect your VPC to corporate data center and on-premise infrastructure with a VPN connection, so that you can use Amazon VPC as an extension of your existing data center network,
• DHCP options: DHCP option sets let you specify the domain name, DNS servers, NTP servers, etc. that new nodes will use when they’re launched within the VPC. This makes implementing custom DNS much easier. In EC2 you have to spin up a new node, modify DNS configuration, then restart networking services in order to gain the same effect. 
• Multiple IP's per MAC address: The Elastic Network Interfaces (ENI) is a virtual network interface that can include the following attributes :
  • a primary private IP address
  • one or more secondary private IP addresses
  • one Elastic IP address per private IP address
  • a MAC address
  • one or more security groups
  • a source/destination check flag
  • a description
• Multiple ENIs per instance: Attach multiple Elastic Network Interfaces (ENI) to each instance for multiple MAC addresses.
• Moving ENIs (MAC and IP addresses) between instances :  ENI's attributes follow the ENI as it is attached or detached from an instance and reattached to another instance.

EC2 instance public key invalid fix

I happened to do the same thing that is listed at this web page:  http://dltj.org/article/ec2-fix-authorized_keys/

The steps are on the web page. Here are the command:
1. aws ec2 create-volume --snapshot-id snap-YourVolumesSnapshot --size 10 -- availability-zone az-asdf-1a
Note: Assumes you have a current snapshot: aws ec2 create-snapshot --volume-id vol-beforevolumewasbad

 2. aws ec2 stop-instances --instance-id i-YourInstanceId

3. aws ec2 detach-volume --volume-id vol-badvolume

4. aws ec2 attach-volume --volume-id vol-goodvolume --instance-id i- YourInstanceId --device /dev/sda1

5. aws ec2 start-instances --instance-id i-YourInstanceId

AWS VPC public and private subnets

What is the difference between a private and public subnet? I asked myself this after I was looking for a field in the ec2-describe-subnets command, AWS console, and ElasticWolf, and could not find anything to indicated whether a subnet was private or public...

Public and private subnets are more or less the same thing.  The routing table will decide whether a subnet is public or private. A subnet with a default route to the Internet Gateway, and instances using Elastic IPs, is considered as public. If you remove the Internet Gateway, you now have a private subnet.
This means that instances in a private subnet are invisible to the outside world and don't have access to the outside world (i.e internet).  Therefore, instances in private subnets need to make use of a NAT instance. The NAT instance will basically accept all traffic coming from the private instances and send it out to the Internet Gateway. That would theoretically add some latency.

Back to my original question: So, if an IGW is associated with your subnet it is a public subnet.

AWS Bastion host as single point of attack?

Bastion host could open you up to a single point of attack?  It can, but here are two ways to secure your bastion host:

• AWS security WP recommends only allowing access through the corporate network(VPN access):
• http://awsmedia.s3.amazonaws.com/pdf/AWS_Security_Whitepaper.pdf (page 17)
• This video talks about separate security credentials for bastion host:
• http://www.youtube.com/watch?v=XhYX06RmMHc&list=PLhr1KZpdzukcPA0A7h3FKDcMfKNPytXVf&feature=player_detailpage#t=837s  (this could be a separate user name password or more likely another PEM/PPK private key file)

Having only one point of attack is way better then opening up more than one or all of your EC2 instances for port 22 (SSH..assuming Linux) to 0.0.0.0/0 CIDR block.

Using AMIs on premise

AMIs provide a great way to package your software deployment.  Once this pre-configured 'template' is created some IT folks may want to use it on premise.  The solution to that does this is:
http://www.eucalyptus.com
Details can be found here:
http://www.eucalyptus.com/eucalyptus-cloud/iaas/concepts
Before the AMI can be used on premise, it must be converted to an EMI:
AMI--->EMI before using on premise.

Eucalyptus has support for EC2 instances, EBS, S3, and IAM.  It also has API compatibility.  They just announced support for ELB, Auto Scaling, and CloudWatch.

They are an AWS partner:https://aws.amazon.com/solution-providers/isv/eucalyptus

Connecting to AWS EC2 using SSH and SFTP

As I mentioned in a previous blog, you can only use SFTP (can not use FTP) to connect to an EC2 instance.  The other thing you need to have correct is an entry in the SSH config file for your  private key (of the key pair value for the EC2 instance).   In the Unix/Mac world, this file is called config and it is located in the ~/.ssh directory.  The following entry needs to be added to this config file:

identityFile ~/tomlaszKeys/PemFileName.pem

Adding this entry will also allow you to connect via SSH without having to pass in the private key file location:

ssh ec2-user@ec2-23-23-237-99.compute-1.amazonaws.com

Instead of:

ssh ec2-user@ec2-23-23-237-99.compute-1.amazonaws.com

 -i ~/PemfileName.pem

AWS EC2 public key from private key

In some cases, you may only have a private key (pem file) and you need to create a new instance from an AMI which requires a public key.  In this case, you can use the following SSH command:

ssh-keygen -y -f /path/to/private-key > /path/to/public-key

||

You can use PuttyGen to create the public key from the private key