Protecting E-IAM Authentication Services with AWS WAF

By Scotty Miller, 1 July 2024

Country: Australia

The Customer

Akkodis has been responsible for the ongoing management and improvement of application workloads in AWS for a leading commercial operator in the lands industry since its inception.

The Challenge

The customer hosts a large set of integrated apps and services across multiple workloads in AWS. Akkodis has developed and maintains these apps and services to meet the customers compliance needs, including PCI DSS, ISMS ISO27001, Security and resilience ISO 22301, and more recently, the ASD Essential Eight.

Solutions are built in-line with the customer’s Business Continuity Plan, which follows ISO 22301 Security and resilience business continuity management systems requirements, Treasurers Instruction (TI) 825 – Risk Management and Security, and Public Sector Commissioner’s Circular 2015-03: Risk Management and Business Continuity Planning.

RTO/RPO for these apps is defined as follows:

• No Backup Restore: RTO < 4 hours with an RPO of < 10 minutes
• Backup Restore: RTO of < 16 hours with an RPO of < 24 hours

The E-IAM stack serving these apps uses identity provider nodes to handle user authentication, registration and password reset functionality. These nodes are hosted internally on Amazon EC2 instances, which are managed using EC2 autoscaling. Approximately 135k requests are ingested per day, through a public facing application load balancer.

It was identified that this solution had no application-level firewall or exploit detection mechanism in place to protect against common internet attack vectors. These attacks may go undetected and are harder to mitigate without such security measures in place.

The Solution

AWS WAF is a web application firewall that integrates natively with a number of AWS services. As part of a continuous improvement initiative to strengthen the client’s security posture, an AWS WAF WebACL was configured and implemented with these managed rule groups to monitor and handle web requests destined for EC2.

Architecture Diagram

The WAF is associated with the application load balancer, which forwards incoming requests to AWS WAF for inspection and filtering. Requests are evaluated against managed rule sets for common web exploit patterns. Any requests found to be malicious are blocked while valid requests are passed back to the ALB to forward to the EC2 ASG. All traffic is logged via Cloudwatch for future analysis, so that rules can be refined and new ones added.

AWS provide a set of managed rule groups, which contain predefined, ready-to-use rules that AWS define and maintain for you. These managed rule groups cover a variety of focus areas, from application type specific to bot control to fraud prevention. A number of these are available to AWS WAF customers at no extra cost.

WAF Configuration

The managed rule groups suitable for our use case are as follows:

• Core rule set (CRS) – AWSManagedRulesCommonRuleSet: Contains rules providing protection against a number of vulnerabilities, including some described in the OWASP Top 10.
• Admin protection – AWSManagedRulesAdminProtectionRuleSet: Contains rules that block external access to exposed administrative pages.
• Known bad inputs – AWSManagedRulesKnownBadInputsRuleSet: Contains rules that block known invalid request patterns associated with exploitations or vulnerability discovery.
• SQL database – AWSManagedRulesSQLiRuleSet: Contains rules that block request patterns associated with SQL database exploitation.
• Linux operating system – AWSManagedRulesLinuxRuleSet: Contains rules that block request patterns associated with the exploitation of vulnerabilities specific to Linux, including Linux-specific Local File Inclusion (LFI) attacks.
• Amazon IP reputation list – AWSManagedRulesAmazonIpReputationList: Contains rules that are based on Amazon internal threat intelligence, blocking IP addresses typically associated with bots or other threats.

An additional custom rule was needed to address a known false positive that triggers the CrossSiteScripting_BODY rule when the last string in a space-delimited name starts with “on”, resembling common Javascript event listener functions. This false positive was observed blocking SAML requests in our test environment, and was easily mitigated with a single rule using regex pattern matching to allow these requests.

Cost

Total cost for this implementation is minimal, at $5 per month for the single WebACL and an additional $1 per month for the custom rule to mitigate the CrossSiteScripting_BODY false positives. Total cost: $6 per month.

Deployment

The WAF implementation was added to the existing workload CloudFormation template, which resides in a CodeCommit repo for the solution in a dedicated AWS account.

The solution is deployed cross-account via Jenkins pipeline to staged environments as testing validation progresses. Access to these environments is granted via SSO with 365 integration, using IP restricted roles to provide permissions based on job function.

Once deployed, a set of CloudWatch alarms monitor EC2 instance health and connectivity between services, triggering autoscaling events and alerts when performance metric thresholds are exceeded.

The Outcome

With the WAF now implemented and actively managing requests, Akkodis continue to manage the solution for the customer. We’ve observed an approximate average of 662 blocked requests per day over the past month.

Blocked Requests by Attack Type

In that time, the most common rule triggered is the ExploitablePaths_URIPath from the Known bad inputs managed rule group.

Top 10 Managed Rule Labels

Lessons Learned

Spending time to test and evaluate rule sets prior to deployment is paramount. Deploying AWS WAF to production environments using count mode can allow you to safely observe the impact of a configuration without causing disruption to services. Regular monitoring and post deployment evaluations are important to establish a normal activity baseline, detect anomalies early, and keep configurations current.