Deploying an AWS Web Application Firewall

 2024-04-19
This topic outlines the process for deploying an Web Application Firewall (WAF) to protect LabKey instances from DDoS (Distributed Denial of Service) and other malicious attacks. The example in this topic uses AWS, but other firewall options can be configured similarly to protect your LabKey Server.

Overview

Public-facing LabKey instances are subject to "internet background radiation" by nefarious miscreants who seek to comprise systems to gain access to protected data. Typically motivated by financial extortion, these individuals use DDoS and bot networks to attack victims. Fortunately there are some easy and low cost tools to protect against many attacks. Deploying a Web Application Firewall (WAF) can protect against the OWASP top 10 vulnerabilities and many malicious bot networks.

Using the AWS WAF as an example, review their documentation here:

A tutorial is available here:

Requirements

  • LabKey Instance Deployed in AWS on EC2
  • Configured Elastic Load Balancer with target group routing to LabKey EC2 Instance
  • Required AWS Permissions to use CloudFormation, WAF, IAM Policies, S3, Lambda, etc.

Considerations

Many LabKey core APIs and user interfaces involve SQL, JavaScript, and other developer-oriented features. These types of activities are difficult to distinguish from malicious activities as the methods used to upload malicious code is indistinguishable from normal workflows.

For example, editing a SQL query and saving it within the Query Schema Browser APIs can look like a SQL injection attack to a WAF. However, LabKey Server's query engine ensures that any SQL used is safe.

As a second example, saving an HTML-based wiki page that contains JavaScript can look like a cross-site scripting (XSS) attack to a WAF. However, LabKey Server ensures that only trusted users in the Developer role are allowed to embed JavaScript in wikis.

To address possible false positives, clients have the following options:

  • Create an "Allow list" of specific IP addresses or IP Address ranges of users originating from within the clients network. (e.g. allow the Public NAT gateway of the client's network).
  • If this explicit listing is not feasible due to users coming from IP addresses from various internet locations, consider setting the XSS or SQL injection rules to count vs block. (See information below). While this may reduce the effectiveness of the WAF to protect against these specific attacks, clients still gain the benefit of other WAF features which block known malicious attacker source IP's.

Deployment

This example shows the details of deploying and configuring an AWS WAF.

Architecture

Deployment Steps

Follow the AWS Tutorial for detailed steps to deploy the WAF using the CloudFormation Template: High level steps:
  1. Deploy the WAF in the same region as your LabKey Instance.
  2. Configure the WAF to protect your Elastic Load Balancer.
  3. Optional: Configure IP Address "Allow lists".
  4. Login to AWS and go to the WAF Console.
  5. From the WAF Console, choose WebACL's.
  6. In the WebACL Conditions, choose IP Addresses.
  7. Locate the "Allow List" rule and edit it to include the IP addresses or address ranges you wish to allow.
  8. Test.

Optional: Configure WAF Rules Based on Usage Patterns

Edit the WebACL following the steps below to disable the "XSS Rule" as an example:

  1. Login to AWS and go to the WAF Console.
  2. From the WAF Console, choose WebACL's.
  3. Click the WAF Name in the WebACL's list. In the resulting dialog that opens, click the Rules tab to see the list of the ACL rules.
  4. Click the Edit web ACL button.
  5. For the XSS Rule, change the rule from "Block" to "Count".
  6. Click Update to save changes.
  7. Test.

Related Topics