How to Configure Azure Virtual Server for a WAF to Use Appdome MOBILEBot Defense

Last updated April 24, 2024 by Appdome

Introduction

Web Application Firewalls (WAFs) play a crucial role in protecting web applications from a wide range of cyber threats. When combined with Appdome’s MOBILEBot™ Defense solution, businesses can achieve an unparalleled level of protection for their mobile applications. This article will guide you on configuring your Azure Virtual Server to connect to a WAF so it can work seamlessly with Appdome MOBILEBot Defense.

Before delving into the steps, let’s understand some of the terms used:

MTLS (Mutual Transport Layer Security): Mutual TLS (mTLS) is a method for mutual authentication in which both parties in a network connection validate the SSL certificates presented by each other against a trusted root Certificate Authority (CA) certificate.

Client Certificate: In cryptography, a client certificate is a type of digital certificate that is used by client systems to make authenticated requests to a remote server.

Safe Session: Represents sessions that are determined to be safe or not at risk of any threat.

At Risk Session: Represents sessions that are potentially under threat or have detected anomalies.

Header Payload: The data transferred in the header of HTTP requests or responses. Protecting this data ensures that it cannot be tampered with during transit.

Prerequisites for Using Azure Virtual Server with Appdome-Protected Apps

In order to use the Azure Virtual Server in conjunction with Appdome, you’ll need:

  • A configured and accessible Azure Virtual Linux Server
  • An Android or iOS app secured by Appdome MOBILEBot Defense
  • An Appdome MOBILEBot Defense License

How to Configure the WAF to Parse Safe Session and At Risk Session

When Appdome’s code is integrated into the Azure Virtual Server, it enhances the firewall’s capability to determine the validity of a session. To categorize sessions as “Safe Session” or “At Risk Session”, Appdome’s code analyzes specific headers within incoming requests: Timestamp, Nonce, and SignedMessage. The Timestamp header allows Appdome’s code to detect potential delay attacks by comparing the request’s timestamp with the server’s time. The Nonce, a unique random value, ensures the uniqueness of each request, protecting against replay attacks. The SignedMessage, typically an RSA-encrypted SHA256 hash of the timestamp, nonce, and a shared secret, ensures the integrity of the request.

Getting Started with Azure Virtual Server Setup and Configuration

Follow these steps to configure a Linux server on GCP and Azure, and launch a Docker container with open network settings.

Note: Make sure to replace placeholders such as YOUR_VM_NAME, your-docker-image, your-username, and your-vm-ip with your own custom values and preferences.

Setting up a Linux Server on Azure

  1. Create a Resource Group
    • In the Azure portal, navigate to Resource groups.
    • Create a new resource group to organize your resources.
      To learn more about managing Resource Groups on Azure, please read this article.
  2. Create a Virtual Machine (VM)
    • In the Azure portal, go to Create a resource -> Compute -> Virtual machine
    • Configure your VM instance, including selecting the Linux distribution you prefer (e.g., Ubuntu, CentOS).
      Note: Make sure to allow HTTP/HTTPS traffic when configuring the firewall rules.
  3. SSH into Your VM
    Use SSH to connect to your VM:

    ssh your-username@your-vm-ip
  4. Running a Docker Container on Azure
    Inside your VM, install Docker:

    sudo apt-get update

To learn more, see the installation instructions for Installing Docker Engine on Ubuntu

Configure Appdome’s Docker Image

Appdome’s Docker Image is a custom solution to secure apps built on the Appdome platform with the Anti-Bot service enabled. This service functions within a Docker container based on Nginx. To facilitate its operation, users must supply an SSL certificate, config files and keys, and designated environment variables.

Prerequisites: Familiarity with Docker and UNIX-based machines is beneficial.

How Does It Work?

Based on Nginx and Lua, the service employs the Lua module to decrypt the payload and validate the signature, then it proxies the request to the target route as specified in the config file.

The module can be used with either the built-in LRU cache or with Redis, but it is recommended to use the built-in LRU to reduce the overhead of making the calls to Redis and ease the setup. If working in a cluster, it is necessary to use Redis to share storage across multiple instances.

Setup

The following environment variables are required to set up the service.

Environment Variable Name Required Description
REDIS Optional Only provide AD_REDIS_HOST if you intend to use it.
LOG_LEVEL Optional The default setting is warn. Available options include: debug, info, notice, warn, error, crit, alert, emerg. All logs are output to the stdout.
RESOLVER Mandatory Provide the resolver DNS server to use for discovering upstream servers.
PASSTHROUGH Optional A key that logs only headers but does not validate them.
Note: For a Kubernetes server, the default DNS server IP is 192.168.0.10. For a pure Docker configuration, the default server IP is 127.0.0.11

Configs: Located in /home/configs, this folder contains JSON files. The name of the file is task_id, as built on Appdome and the content of the file is a JSON array of the mobile anti bot configuration as provided by Appdome.

Keys: Located in /home/keys, this folder contains private keys used to validate the headers sent by Appdome.After receiving the JSON file from the Appdome support team, you will need to add two fields: key, target and, optionally, heartbeat_validity. The first two are string fields, and the last is the heartbeat number in seconds.
The key will point to a key from the keys folder mentioned above to validate the headers. The target is the address to which the request will be forwarded, which should be resolvable by the resolver. The target can be an internal address provided that the resolver can find it.
Example:
“key”: “keys/task-id-1-host-1.pem”,
“target”: “http://jsonplaceholder.typicode.com/posts/1”

Optional: How to Configure SSL & mTLS

If you want the Appdome Docker Image to handle SSL and mTLS, additional configuration is required. This includes passing environment variables and mounting certificates to the service.
Environment Variable Name Description
SSL_ON In order to enable the reverse proxy to handle SSL connections, you need to mark the SSL_ON=true. Make sure to mount SSL certificates to the container under /etc/nginx/certs/{ssl.crt, key.key}.
MTLS_ON In order to enable the reverse proxy to handle mTLS, you need to set both SSL_ON and MTLS_ON=true.
Make sure to mount the CA certificate that will be used for the mTLS under /etc/nginx/certs/ca.crt.
FINGERPRINTS If MTLS_ON=true the certificate fingerprints can be passed to allow only specific certificates identified by a SHA1 fingerprint. The value format should include a string of comma-separated values with a space following each comma as follows: asd, zxc, qwe

How to run Appdome Docker Image

Connect to your VM, and run the following commands:

    • Pull the docker image from our public repository:
      docker pull public.ecr.aws/n2i7f1e2/appdome-waf:1.0.0
    • Run the docker image with the following command:
      docker run -p 443:443 -p 80:80 -d \
      -v "$(pwd)"/certs:/etc/nginx/certs \
      -v "$(pwd)"/keys:/home/keys \
      -v "$(pwd)"/configs:/home/configs \
      -e REDIS=<redis address> \
      -e PASSTHROUGH=false \
      -e RESOLVER=<resolver address> \
      -e SSL_ON=true \
      -e MTLS_ON=true \
      -e FINGERPRINTS=asd, zxc, qwe \
      -e LOG_LEVEL=debug \
      --restart unless-stopped \
      public.ecr.aws/n2i7f1e2/appdome-waf:1.0.0

At this point, you have a machine that will run the Appdome Docker Image. Make sure that your application traffic is routing correctly to the Appdome Docker Image and that the Appdome Docker Image is passing the traffic correctly to the target.

Conclusion

Integrating Azure Virtual Server with Appdome provides robust protection for mobile apps. By understanding and applying the configurations above, businesses can ensure that their mobile app traffic is both secure and optimized.

Related Articles:

Thank you!

Thanks for visiting Appdome! Our mission is to secure every app on the planet by making mobile app defense easy. We hope we’re living up to the mission with your project. If you don’t already have an account, you can sign up for free.

Appdome

Want a Demo?

Mobile Bot Defense

TomWe're here to help
We'll get back to you in 24 hours to schedule your demo.