Defending Your EC2 in AWS: Unleashing the Power of Security
Tags: aws, cloud, tutorial, security
Published: 2023-07-14 05:22:48

In the past few weeks, I was assigned with implementing SSL to an app hosted on an EC2 instance that it had its security group ports opened to the internet which is obviously a security issue, so by implementing a Load Balancer we could secure the instance and limit the traffic we want to reach the instance. At first I thought, this was gonna be a basic case of creating an Application Load Balancer(ALB) and its target group, Route53 domain and hosted zone and an AWS Certificate Manager(ACM) certificate. Putting it all together and that would be it.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wjx4dkeecm4lpyo359fw.png)

But this was not gonna be the case. The app was hosting WAMP Server and IIS simultaneously in the same instance, so there was two ports open serving the app 80 and 82, so when I deployed the ALB, at first I thought and that was what I knew until now, two listeners one for the port 80 HTTP and one for the port 443 HTTPS, a target group pointing to the instance performing a health check on the app. I also configured the listener for the HTTP 80 to redirect all trafic to 443.

So then I configured the ACM certificate, created the records in route 53, got it validated and then attached to the listener 443, and select the SSL/TLS policy on the ALB. I contacted the customer to perform a preliminary test on the night when user activity is at its minimal and in any error it would be easy to go back instead of pointing to the ALB, I would set it to point to the EC2 instance.

The test was going really well, all traffic was going straight to HTTPS and the website was displaying the HTTPS certificate, then the customer contacted me saying he was having trouble accesing the other functionality on port 82.

Then I realized my initial approach was no the right one. I set the records to point back to the EC2 instance and started investigating right away how could I solve this inconvenience.

At first I got a little miscarried, as I thought an ALB did not support listener to other ports than the 80 and the 443. So I started testing on a Network Load Balancer(NLB) as I show in the next image I created a test instance with port 80 and 82 open with a simple message.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7xd993qo2593ixautt7o.png)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kq1901384bov8ast7onk.png)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l1ivs4fmde4jbvv76vez.png)

Then, attached the instance to a target group and with that created a NLB with three listeners, TCP for 80 and 82 and 443 as shown in the image below.

After that, attached the ACM certificate and the policy to the NLB and tested connectivity, ensuring the ports remained accesible which proved to be possible as shown as in the image below. Both three listeners were working as expected. However, I encountered another difficulty. NLB cannot natively re-route traffic, so this approach was not viable either as the customer expected traffic redirected to the https version.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/flo3g5uw1rf6avc8gqaq.png)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/d45tz78b0b4ng29dq157.png)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yon933h8nvmtcsjam7mi.png)

I was about to give up all hope when I started asking some friends about what could I do besides some difficult implementations like reverse proxy inside the EC2 itself which is something I wanted to avoid to prevent application impact. And then I came accross a great collegue that taught me that ALB can in fact accept ports other than 80 HTTP and 443 HTTPS so the fact that the application was serving HTTP through a port like the 82 was irrelevant, ALB could still handle it as long is that kind of traffic, another story would be if it would be another kind of traffic, that would neccesarily mean an NLB implementation.

So I proceeded to create three listeners one for HTTP 80, one HTTPS 443 and one HTTPS 82, as this one was always have to be typed in the url like www.exampleurl.com:82, so re-routing that port to another port like 80 to 443 was going to be difficult for the customer, the only drawback from this was that the http version of the app on the port 82 showed a 403 error, which at the end with the customer was fine, he did not want that version served.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u4qfvij8h25h9oos2fmm.png)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6apzfkfw7mjst5jd7ak6.png)


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/t6uj5r4qos5ik1i6rpb1.png)

In conclusion, this an experience that has taught me a lot, I have gained a deeper understanding of the Load Balancing services and I was able to provide the customer with a great experience, and of course there so much to be improved here, the customer already has plans to migrate to LAMP to reduce costs on the EC2 instance, start using S3 as temporary storage for its app and subdomains to avoid further use of ports which will be corrected in the future so the ALB will redirect all traffic to use the SSL certificate.

Also this can be integrated with Web Application Firewall to monitor the application in real time and filter traffic and avoid common threats.

See you in the next post!

Happy architecting!