Forem: ECV PH Tech Team

AWS Network Challenge 1: Deploy Web App to EC2 / Two-Tier VPC Architecture

Raphael Jambalos — Sat, 25 May 2024 03:19:16 +0000

About the Challenge

I manage the Service Delivery Team at eCloudValley Philippines, and one of the first things I teach them is to understand how AWS networks work. As cloud developers, we deploy our applications in Lambda and connect them with databases and other components inside our AWS VPC (virtual network in AWS). Because of this, it becomes imperative for them to know more about how VPCs work. They need to know how to navigate network issues they will encounter.

In this challenge, we would deploy an application to 2 servers inside a virtual network in AWS. The network will have two tiers: private and public. Our result will be:

Before we begin, here are a few helpful hints:

This is a series of challenges that get progressively harder. It also meant to state what to do and what you should have learned. This is NOT a step-by-step guide on how to do the challenges.
I have added links to AWS documentation to help you get started with the challenges.
I have added guide questions to test your knowledge. It's easy to follow documentation to make this all work. But what we are striving for is a true understanding of how these components work together for a secure, reliable, and working network.

[A] Basic VPC Skeleton

Let's build the backbones of our VPC network. You'll be creating:

VPC (how)
2 Private Subnets (deployed in separate Availability Zones, how
2 Public Subnets (deployed in separate Availability Zones)
1 Internet Gateway (connected to the VPC we just created)
1 NACL for both subnets (with a rule that allows all traffic)
1 Route Table (for Private Subnets, how)
1 Route Table (for Public Subnets)

In this exercise, you must be able to answer the following guide questions:

What makes a subnet private? What makes it public?
What is an IPv4 CIDR block? What is the difference between /16, /20 and /24?
Why do we deploy subnets in different availability zones?

Architecture Diagram for Exercise A:

[B] Setting up the instances

With the VPC backbone in place, let's add more network components:

NAT Gateway (deployed in Public Subnet)
Set up for you to deploy an EC2 instance
EC2 instance (deployed in Public Subnet) - Getting Started - Best Practices
EC2 instance (deployed in Private Subnet)
Security Group that allows all traffic from port 22
Associate the security group to both EC2 instances
Private Route Table connected to NAT Gateway

Here are a few guide questions to answer:

DEMO: Be able to enter the CLI of the EC2 instance in the public subnet via SSH. Once inside, access the CLI of the EC2 instance in the private subnet.
Why do we need a NAT Gateway? How does it operate?
What is the difference between a NAT Gateway and an Internet Gateway?
What is the difference between a security group and an NACL?
Can a computer from the internet access the EC2 instance inside the private subnet? Why or why not?
What is the difference between a NAT gateway and a NAT instance? When would you use a NAT instance? NAT gateway?
What happens if you don't assign a public IP Address to an EC2 instance?

Architecture Diagram for Exercise B:

What we achieved

We created our private network in the Cloud! We also created two EC2 instances, one in the private subnet and another in the public subnet.

[C] Setting up NGINX and load balancing

We're getting close:

EC2 instance (deployed in Private Subnet 1)
EC2 instance (deployed in Private Subnet 2)
Install Nginx on both. Modify /usr/share/nginx/html/index.html to add "this is server one" for the 1st EC2 and "this is server two" for the second one.
Create an application load balancer
Create a listener to receive HTTP traffic
Create a target group that includes both EC2 instances as instance targets

Here are a few guide questions to answer:

DEMO: Once the resources have been created, get the URL from the application load balancer and put it in your browser. It should alternate displaying "this is server one" and "this is server two". This proves that the ALB is alternating sending traffic between the first and second EC2 instances.
What is the difference between a NAT Gateway and an Application Load Balancer?
Why put the EC2 instances in separate private subnets?
Why put the EC2 instances in the private subnet instead of being exposed directly?
Why add an application load balancer?

Architecture Diagram for Exercise C:

The result looks like this:

What we achieved

With Activity A-C, you have deployed your first VPC and have successfully deployed a simple app using a two-tier architecture. That’s honestly very close to how we deploy secure applications on the modern web.

There is one thing though. The application you accessed looked like something like this when typed in the browser:

http://jamby-alb-1962899873.ap-southeast-2.elb.amazonaws.com/

Two things come to mind when I see this:

First, the website is deployed on HTTP, not HTTPS, which leaves our end users insecure. As your end user browses your website, the data you send and receive goes across the internet unencrypted. The internet is made of thousands (or maybe millions) of routers connecting everyone in one big interconnected web. From your end user’s Macbook to your EC2 instance, there may be as many as 100 routers in between. if you leave your traffic as HTTP, any one of those 100 routers can see whatever you are sending between one another.

Second, as an e-commerce, I’d like to have a decent website name that my end users can easily remember. Something like:

jambyiscool.ecvphdevs.com

In exercise D, we will do just that.

Resources:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html

[D] Securing setup with HTTPS

Let's take it a step further.

Buy a domain in GoDaddy and associate it with Route 53 (if you haven't). If you have access to an existing Domain Name, no need to do this step.
Create a public certificate with AWS Certificate Manager. You may have to create DNS records in your domain manager.
Associate the certificate with the ALB created earlier
Create a route 53 record for "jambyiscool.yourdomain.com" and point it to the load balancer you just created. If your domain manager is not Route 53, feel free to create the record in your domain manager.

Architecture Diagram for Exercise D:

Here is the end result:

What's next?

Congratulations on completing this exercise! You know have a full view on how VPC works, and have deployed your first application on a best practice version of a private network in AWS.

On the next challenge, we will be doing VPC peering, EC2 auto scaling, VPC endpoints and CI/CD. Stay tuned!

Interested about joining ECV Philippines?

Send us your CV via email to ph.hr@ecloudvalley.com:

Photo by Nastya Dulhiier on Unsplash

How to Hack (and secure) Serverless Applications

Raphael Jambalos — Thu, 28 Mar 2024 06:49:00 +0000

At eCloudValley Philippines, we prefer developing web backends as serverless applications. We just push the code to AWS and they worry about the infrastructure. We don't have to think about provisioning, patching, scaling and securing it. That's all AWS. In terms of security, since even us don't have access to the infrastructure, we don't have to worry about it. We pay AWS to worry about that for us. But what we do have access to is the code. And that's one major attack vector we have to secure. And in ECVPH, we take that very seriously.

In this article, we will take a deeper look at how Serverless workloads get hacked, and what you can do about it.

Here are the 6 common types of attacks on Serverless applications

[1] Denial of Service

You'd think Serverless applications don't get DDoS attacks. Yes, they can scale fast. But the network components attached to them don't often scale at the same rate as them. We've seen Lambda functions use an RDS database, or is connected to an API that is deployed on a traditional EC2 setup. Your lambda functions will scale to meet the traffic, but they will rain down traffic into these weaker downstream dependencies.

That's why it's often a good idea to do event-driven architecture. Instead of directly writing into the database or directly calling the legacy system, the Lambda function queues

It's not only infrastructure that can cause denial of service. Sometimes, there are vulnerabilities in your packages that can cause this. For example, this Python package for etherium can cause resource exhaustion when a specific payload is added to it. With just a few requests, the package causes a malfunction that causes it to hog all the CPU and RAM of the device. This exhausts the resources of the server, causing it to go down.

To learn more about how to survive a DDoS attack, check out my blog post about how we survived a 2M requests per min attack.

[2] Denial of Wallet

But suppose that somehow your entire setup is serverless. You're using AWS Lambda for your compute, DynamoDB for your backend, and S3 for all your files. The attacker can just keep attacking you and AWS will be able to keep your website up. But since these services are pay-per-use, you'd just end up racking up higher AWS charges. And so long as they can sustain their attack, they can bankrupt your company to the ground.

To protect against both DoS and DoW attacks, it is best to put into place some kind of rate limiting. AWS WAF does this by allowing you to limit request per second for each IP address. This makes these attacks harder, but not impossible, especially if they have thousands of IP addresses on their disposal.

[3] Remote Code Execution

While the most common attacks are volumetric in nature, some just need a few API calls and they've compromised your system. The most common of which is remote code execution. It is when hackers are able to manipulate the payload so that they can execute custom code in your application.

Probably the most insecure code in Python is this snippet below. It allows you to evaluate a string and execute it as a Python code.

request_body = '2 ** 2'
response = eval(request_body)
return response

Imagine the possibilities. When you are using this code, an attacker can just modify the request body to a more sinister one.

request_body = 'run_sql("drop database")'
response = eval(request_body)
return response

Much of the programming world does not use this code anymore. But vulnerabilities found in old packages (that you may still be using) may leave you exposed to this vulnerability. Here's an example from an outdated version of Astropy.

[4] Malicious Packages

The dawn of open-source software has allowed developers to share code much freely. It has accelerated development since we no longer have to write code from the ground up. We can just compose libraries together to make our application. But that openness also comes at a price.

There are malicious libraries out there that exist to mimic legitimate software. Once added to your project, these libraries open backdoors for hackers to remotely execute code on your server. Like this "python package"

Malicious code don't exclusively come from packages. It can also come from Lambda layers. An inconvenience with Lambda is that when there are libraries with OS-specific dependencies, it is more difficult to upload them to Lambda. You have to compile the library using an OS that is similar to Lambda's OS. An example of this is psycopg2 (an internal library required to make Postgresql work in Python).

The most convenient way to fix this is just to use a Lambda Layer that somebody else already created. Like this Github page of Keith. While he looks generally reputable, nothing is stopping Keith from inserting malicious code to any one of his public Lambda layers. And once you use the code inside the Lambda layer, he may be able to remotely run code in your lambda. A better fix is to build the lambda layer yourself, even if it takes awhile. In Python, Pip added the --platform command where you can specific the platform when you install your library.

[5] API is too open

The easiest way to hack an API is when it is open to the public.

What we do is we often pair it with Cognito. The user logs in to the frontend, and Cognito issues a set of tokens that the backend will use to ensure that the user is who he says he is. The token expires every hour and needs to be renewed. During each renewal, we can validate if the session is still valid.

But how about APIs that are only used by other APIs? They shouldn't be open to the public in the first place. They should, at the minimum, be secured by an expiring API token that only the authorized system has access to. An even better approach is to determine these APIs and ensure they can only be accessed privately, inside the network.

[6] Privilege Escalation

ECS tasks and Lambda functions rely on IAM Roles to access AWS services. Those who leave this role with an admin privilege can leave their account open to hacking.

If there is a remote code execution vulnerability, hackers can use that to discover the IAM role inside the Lambda / ECS task. Then, they can use this role to create an IAM user with elevated privileges, which they can use to gain access to your AWS accounts.

But more often than not, this vulnerability is an inside job. For example, we have given the developer limited rights to our AWS account. They can only push code to their CodeCommit repository. But the execution role of the Lambda function is set to Administrator Access. The developer can change the code that is pushed to the CI/CD to include instructions to create an IAM user for him with elevated permissions.

Another form of privilege escalation is modifying the CloudFormation code that comes with the serverless application. Malicious developers can directly add instructions to create an elevated user there.

How about you? What are other ways to "hack" into serverless applications?

Let us know in the comments!

Also check out my other blog post on security best practices we learned the hard way.

Photo by Max Bender on Unsplash