How to change AWS EC2 Security Group of an existing Instance

By Semir H.


If you find this tutorial useful, please consider making a donation to support future work like this:

Thank you :)

Scenario:

You have a few pre-made Security Groups and one of your Instances needs to change from one to another.

Solution:

AWS EC2 does not have a way to easily switch these. You basically have to clone the Instance into an AMI and then deploy a new Instance out of that AMI, taking care to associate the new Instance with the desired Security Group at the time of creation.
You can delete the AMI and the associated Snapshot, if you desire so.

Process:

Create a Security Group with your desired port settings.

Clone your Instance by right clicking on it and choosing to create an Image (EBS AMI). It is best if the original Instance is turned off so that no data is lost.

After a bit of time your new AMI should be visible in the AMIs section. Please make sure you’re in the correct Region.

Right-click on your new AMI and pick “Launch Instance”.

Use the “Request Instance Wizard” to select settings you wish but please make sure you select the correct Security Group during this process.
You may also take this opportunity to change your Key Pair.

Finish the wizard and launch the Instance.

You should now see that the new Instance has the new Security Group associated with it.
Log into your new Instance and confirm that no data is missing.

Cleanup:

Once you are sure no data is missing and that you will not need your original Instance or the resulting AMI then you can delete both.
Also delete the Snapshot that was made during the cloning process.

AWS EC2 Security Group (Firewall) Design and Creation

By Semir H.

This quick tutorial will show you how to open up some common ports on the AWS EC2 Firewalls, otherwise known as Security Groups. Please note that you should think about the Security Group design before you create Amazon Web Services (AWS) EC2 Instances. Once created and associated with a Security Group, there is no easy way (but there is a way) to associate an Instance with a different Security Group. I’ll show you how you can do it in another tutorial.

Let’s say we want to open TCP port 22 for SSH access to a Linux machine, ports 80 (HTTP) and 443 (HTTPS) for web access and port 10000 for Webmin. We want the HTTP/S ports to be open to anyone on the Internet but we want to restrict access over SSH and Webmin ports to a certain IP. The IP we will restrict it to will be 1.2.3.4 (obviously made up).


If you find this tutorial useful, please consider making a donation to support future work like this:

Thank you :)

Procedure:

Log into your Amazon Web Service (AWS) Management Console.

Navigate to Security Groups in the NETWORKING & SECURITY section.

Click on the “Create Security Group” button.

Give it a Name and a Description. Leave the VPC option as “No VPC”. Click on “Yes, Create”. Example:

Select the newly created Security Group and click on the Inbound tab at the bottom of the page to create new rules.

HTTP(S) and SSH can be pre-selected from the “Create a new rule” drop-down box. Webmin port will be the custom option.

Finally, click on “Apply Rule Changes”.

To put in a single IP as the Source you need to put the netmask as /32.
So our fake 1.2.3.4 address will be entered as 1.2.3.4/32

As you add the rules they will appear to the right of the rule creation area. You will see a message saying “Your changes have not been applied yet” until you apply them. To apply them just hit the “Apply Rule Changes” button.

Here’s what our finished example looks like:

Replace a lost Key Pair an existing AWS EC2 Instance uses

By Semir H.

This tutorial will show you how to use a new Key Pair with an existing Linux instance.

If you find this tutorial useful, please consider making a donation to support future work like this:

Thank you :)

Problem:

You have an existing EBS (root device) based Instance with data on it that needs to be saved. The original Key Pair has been lost so you can’t log into the Linux Instance. You need to get to the data on the virtual machine.

Solution:

We’ll clone the running Instance and re-deploy it but with a new Key Pair. We can either use a pre-made Pair or create a Pair while we’re re-deploying. My example uses Ubuntu but should apply to other flavours as well.

Creating an Image:

Log into your Amazon Web Services (AWS) Management Console, go to Amazon EC2, pick the Region where the Instance in question is running and click on the Instances link. Right click on the Instance in question and select “Create Image (EBS AMI)” from the resulting menu.

Give it a Image Name and a Description and click on “Create This Image” button. Example:

The process will now begin.  Close the notification window.

Once the AMI is created (won’t take long) you should see it in the "Images" - "AMIs" part of your Amazon EC2 AWS Management Console. Please make sure you are still in the correct Region. Example:

Creating new Instance out of the new AMI:

Go to Images AMIs, locate your recently created AMI, right-click on it and select “Launch Instance” from the resulting menu.

Follow the prompts to finish creating the Instance (see my previous post) but make sure you select the correct Key Pair (one you create earlier, not the lost one) in the “Create Key Pair” section. Example:

All other settings should be the same as for the original Instance.
After a little bit of time your new Instance should be up and running.
Here’s an example below. Please note the different Key Pairs.

You can now connect to it, using your new private key, and confirm that all your data is still there.
Once you confirm no data is missing you can stop the old Instance and eventuality terminate it (after making absolutely sure you will never need anything from it).

Cleaning Up:

You can now de-register the AMI (unless you want to use later again).

You should also go to EBS - Snapshots and delete the Snapshot of the disk that was created when the AMI was made (unless you intend to use it for something in the future).

Securing Websites with Pound (reverse HTTP proxy & SSL wrapper)

This is a short article on how to use Pound as a Reverse SSL Proxy.

Problem/Requirement:

You have a few websites in your DMZ or even on the LAN. You want them to be accessible from to the outside (Internet). Some of these websites are web based applications. You also have 1 external IP.
You want to serve all these websites from the one external IP and you want most of them to be secured via SSL (HTTPS).
On top of that you have different web servers serving the pages (e.g. Apache, IIS).

The diagram below depicts a typical inefficient web server setup (click on image to see larger version):

Requirements Summary:

• Use just one external IP.
• Use one SSL certificate (for websites under the same domain/sub domains).
  
• Secure websites REGARDLESS of the web server technology used to serve those websites.
• Have the ability to pick which websites get SSL encryption based on the source of the request (e.g. if from Internet then use SSL, if from corporate LAN then do not encrypt).

Solution:

Use a free application called Pound.

What is Pound?

Pound is a reverse HTTP proxy, load balancer, and SSL wrapper. It proxies client HTTPS requests to HTTP backend servers, distributes the requests among several servers while keeping sessions, supports HTTP/1.1 requests even if the backend server(s) are HTTP/1.0, and sanitizes requests.
It runs on Linux.
You can find more info @ http://www.apsis.ch/pound/

How Will it Work?

The diagram below shows where we want to be (click on image to see larger version):


Basically we want the Pound server to be the first point of contact from the outside. This way we reduce the number of "holes" we have to open in the firewall(s) and put another layer of security between the Internet and our web servers.
Pound meets all of our previously stated requirements:

• We can use just one External IP to server all our websites.
  
• Using a wildcard certificate (e.g. *.testdomain.test) we can encrypt all the web sites under the same domain/sub domains with just that one cert.
  
• Because we are doing the SSL encryption with Pound, it no longer matters what the other web servers inside your network use to serve pages. They can be Apache, IIS, Tomcat, etc. You can leave them ALL at the default port 80 (or 8080 for some). Pound can talk to them on pretty much any available port (even 443).
• We can make pound encrypt all requests that come from the Internet but NOT do so if the requests come from the LAN. Some companies choose to do that because it makes things faster. Not using SSL/HTTPS internaly can be done in two ways. One way is through Pound (so all the internal websites would point to the same internal Pound IP) and the other way is to not involve Pound at all. People wold just directly access the individual web servers. An advantage of going via Pound is that you can track access from one location and perhaps do custom redirects when needed (e.g. if a web server is down for maintenance you can have pound redirect to a notification page somewhere else).

Of course, there is one problem with using Pound for evertynig. It becomes a single point of failure. I suppose that can be remedied by using another Pound server to load balance or in another way (e.g. run as Virtual Machine - which works good. Let VMware worry about high availability, etc)

Next we will examine how some of the above is actually implemented:

Please Note:
This tutorial will not examine how the SSL certificates are acquired. The only thing you have to make sure is that they are Linux compatible. Pound runs on Linux. I usually use a self signed cert but if you generate one via a trusted CA then use the Apache/Linux instructions.

Let's assume you want to Encrypt web access for two of your internal web servers IF the requests are from the Internet. If they are from the LAN then do not encrypt.

Domain = testdomain.test
Internal Web Srv 1 = 192.168.7.5 (DMZ)
Internal Web Srv 2 = 192.168.0.10 (LAN)

The Pound server should always be put in the DMZ. Ideally all of your "exposed" servers should be but that is sometimes not an option.

Pound Server = 192.168.7.50 (DMZ)

First we define a HTTP (port 80) listening directive. Under that we put in our two web servers and since we want to encrypt them (if the requests is from the Internet and is on port 80 (HTTP) we will redirect to HTTPS:

ListenHTTP
Address 192.168.7.50
Port    80
xHTTP   2
Service
HeadRequire "Host: .*web1.testdomain.test.*" 
Redirect "https://web1.testdomain.test"
End
Service
HeadRequire "Host: .*web2.testdomain.test.*"
Redirect "https://web2.testdomain.test"
End
End

Next we define a HTTPS directive. This will be the one that will accept the redirects from above AND direct HTTPS requests (no redirect required in that case). This is also where we define which certificate to use and which back servers to contact.

ListenHTTPS
Address 192.168.7.50
Port    443
 Cert    "/path/to/cert.pem"
AddHeader "X-Forwarded-Proto: https"
HeadRemove "X-Forwarded-Proto"
Ciphers "ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL"
xHTTP   1

Service
HeadRequire "Host: .*web1.testdomain.test.*"
BackEnd
Address 192.168.7.5
Port 80
End
End

Service
HeadRequire "Host: .*web2.testdomain.test.*"
BackEnd
Address 192.168.0.10
Port 80
End
End
End

There is also a recommended "catch-all" deirective that goes to the end. This will be what Pound will serve if nothing above is matched. Example:

Service
BackEnd
Address 192.168.0.10
Port    80
End
Session
Type    BASIC
TTL     300
End
End

Access from the Internet:

Your external DNS will point web1 and web2 URLs to the same external IP. Your firewall (I use shorewall) will redirect traffic that comes on that IP over port 80 and 443 to the Pound server in the DMZ. Your internal DNS will point the above URLs to the DMZ IP of the Pound server (192.168.7.50).
So when the requests come from outside on HTTP they first hit the HTTP directive which just redirect to HTTPS. Internal DNS kicks in and the traffic is redirected back to Pound but this time over HTTPS (443). This is when the HTTPS directive kicks in. If you asked for web1 then request is directed internally to 192.168.7.5 over port 80 (HTTP). The answer is returned to the Pound server over port 80 (not encrypted) and then the traffic is encrypted to goioutside (from Pound to the Internet).
If the request from the outside is over HTTPS then the HTTPS directive is used straight away. Answers are returned to the Internet over HTTPS of course.

Access from the Inside:

The easy way is NOT to use pound if you don't want encryption.

If you want internal encryption then you just have to point the internal DNS to the Pound IP.

If you do not want encryption but still want to go through Pound then you need to give the Pound another internal IP (either another NIC or add an IP to the current NIC) and then create HTTP directives that forward traffic to the individual web servers. Of course, your Internal DNS will then have to point to that new Pound IP.
What happens if people have bookmarks that have HTTPS in them?
You can create HTTPS directives that redirect to HTTP. Effectivelly you do the opposite of what you did for the Internet traffic. Slightly more work but not the end of the world :)

Pound is capable of more complex setups than this and I may describe some of those in the future.