Securing My Blog: A Deep Dive into AWS WAF and Security Groups

A Little Blog with Big Security

As the proud owner of a modestly-sized blog – let’s just say it’s more of a cozy corner of the internet rather than a sprawling digital estate – ensuring its security is still top of the shelf. You might remember my previous post about the highly available architecture of my blog. Now, in this sequel, we dive into the nitty-gritty of the security controls safeguarding each asset, focusing on the AWS WAF implementation and the security groups for AWS instances.

The AWS WAF

Setting Up the First Line of Defense

The AWS Web Application Firewall (WAF) is like a shield for my web applications, filtering and monitoring the traffic between the app and the internet. Integrated with an Elastic Load Balancer (ALB), the WAF scrutinizes incoming requests based on a set of security rules – a mix of AWS-managed and custom rules crafted for my blog’s unique needs.

Why WAF Matters

1. Association with ALB: The WAF, linked to the ALB, filters traffic before it even reaches the EC2 instances. It’s like having a bouncer at the door, checking IDs before letting anyone in.
2. Web ACL: This is the rulebook. It determines what’s allowed and what’s blocked, defending against threats like SQL injection and cross-site scripting.
3. Rules Configuration: It’s a combination of AWS’s own managed rules and my custom rules, tailored to safeguard against specific threats.
4. Monitoring and Logging: Keeping an eye on the traffic patterns, identifying potential threats, and adjusting rules as needed.
5. Action on Match: The WAF either allows, blocks, or counts a request based on these rules, with the ‘count’ action serving as a great way to test new rules without disrupting traffic.

For setting up WAF I followed this well laid out guide from AWS.

Security Groups = Virtual Firewalls for Tailored Protection

In AWS, security groups act as virtual firewalls controlling the traffic to and from instances. They’re crucial for managing both inbound and outbound network traffic, with rules based on protocols, ports, and IP addresses. These groups are stateful, meaning changes to inbound rules automatically affect outbound rules. By default, they deny all inbound traffic and allow all outbound, but you can add rules to allow specific inbound traffic. Unlike Network Access Control Lists (NACLs) that operate at the subnet level, security groups provide instance-level security. Interestingly, they only have allow rules – if a type of traffic isn’t explicitly allowed, it’s automatically denied.

Strategic Defense Layers

You can view my full Security Group breakdown at this link.

Security groups in AWS act as strategic layers of defense, each tailored for specific components of my blog’s architecture:

EC2 Instance Security Group (SG-EC2): It’s for my WordPress site, allowing only HTTP and HTTPS traffic from the ELB security group and enabling outbound traffic to the internet.

Elastic Load Balancer Security Group (SG-ELB): This one’s for the ALB, allowing HTTP and HTTPS from anywhere and ensuring the ALB can forward traffic to the EC2 instances.

Relational Database Security Group (SG-RDS): Assigned to my RDS database instances, it only lets my EC2 instances access the database, keeping external threats at bay.

Elastic File System Security Group (SG-EFS): For the EFS File System, allowing the EC2 instances to access shared storage over NFS.

Challenges and Adjustments

The Real-World Balancing Act

Implementing AWS WAF wasn’t without its challenges. I initially opted for AWS-managed rule groups, including the Core Rule Set, which offered robust protection. However, I soon realized that these rules were a bit too tight. I couldn’t access my wp-admin dashboard anymore!

Making It Work

To resolve this, I had to create a new rule, prioritizing an exception for “/wp-admin” in the URI path. Even after gaining access, I found that I couldn’t update, publish, or upload media. So, another rule was born, making exceptions for these activities. It’s a delicate balance, but necessary.

Mitigating the Risks

MFA should always be enabled for user logins, but it just so happens that the MFA plugin (the only plugin I chose to use for now) compliments the “/wp-admin” URI path exception rule as a mitigating factor. On top of this, I have CloudWatch metrics enabled so I can monitor all admin dashboard requests.

You can view my custom rules here.

Takeaway

In the world of cloud computing, security is a moving target. It’s about finding the right balance between protecting your digital assets and ensuring they function as intended. My journey with AWS WAF and security groups is a testament to this delicate balance. It’s a continuous process of tweaking, monitoring, and adjusting, but the peace of mind it brings is worth every effort.

Remember, securing a blog is not just about setting up defenses; it’s about making them work for you.