# 🛡️ Wallarm Deployment Toolkit

This repository contains automated scripts to deploy the Wallarm Filtering Node in various environments. Whether you are using a virtual machine (NGINX Dynamic Module) or a containerized environment (Docker/Podman), these scripts ensure a "Bank-Grade" configuration.

**Repository:** `https://git.sechpoint.app/customer-engineering/wallarm`

---

## 🚦 Step 1: Network Pre-Check (Crucial)

Before attempting any installation, you **must** verify that the server has egress access to Wallarm's Cloud and the official NGINX repositories. Banks often block these by default.

1. **Navigate to the script:**

```bash
cd ~/wallarm/
```

2. **Run the audit:**

```bash
chmod +x network-pre-check.sh

sudo ./network-pre-check.sh
```

3. **Result:** If you see any **RED** "FAIL" messages, contact the network team to whitelist the listed IPs/Hostnames on Port 443. **Do not proceed until all checks are GREEN.**
---
## 🛠️ Step 2: Choose Your Deployment Method

Depending on your architecture, choose **one** of the following methods.
### Option A: Virtual Machine (Native NGINX Module)
*Best for: Maximum performance, high-traffic production, or existing NGINX servers.*
1. **Configure:** Open the install script and set your `TOKEN` and `USE_CASE` (in-line or out-of-band).
```bash
nano ~/wallarm/installation-vm/install.sh
```
2. **Run:**
```bash
chmod +x ~/wallarm/installation-vm/install.sh

sudo ~/wallarm/installation-vm/install.sh
```

### Option B: Containerized (Docker / Podman)

*Best for: Rapid PoC, testing, or environments where you don't want to modify the host OS packages.*
1. **Configure:** Open the install script and set your `TOKEN` and `UPSTREAM` IP.

```bash
nano ~/wallarm/installation-docker/install.sh
```

2. **Run:**
```bash
chmod +x ~/wallarm/installation-docker/install.sh

sudo ~/wallarm/installation-docker/install.sh
```

**Observation on scaling the Docker / Podman (Containerized) deployment**
You can run multiple instances by changing the `NODE_NAME` and `TRAFFIC_PORT`/`MONITOR_PORT` variables. This allows you to serve different backends on one host.

---
## ⚙️ Configuration Variables
Inside each `install.sh` script, you will find a **Configuration** section at the top. You must update these:

|**Variable**|**Description**|**Example**|
|---|---|---|
|`NODE_NAME`|A unique identifier for the instance (useful for containerized deployments).|`wallarm-prod-01`|
|`TRAFFIC_PORT`|The host port where the node listens for incoming application traffic.|`8000`|
|`MONITOR_PORT`|The host port used to expose Wallarm metrics (Prometheus/JSON format).|`9000`|
|`TOKEN`|The unique API Token generated in the Wallarm Console.|`vPHB+Ygn...`|
|`REGION`|The Wallarm Cloud location associated with your account (`EU` or `US`).|`US`|
|`UPSTREAM`|The internal IP or hostname of the application server being protected.|`10.0.0.14`|
|`USE_CASE`|(VM only) Sets the mode: `in-line` (active filtering) or `out-of-band` (monitoring).|`in-line`|

---
### Deployment Flow Overview

When you deploy the node using these variables, the traffic typically flows as follows:
1. **Incoming Traffic:** Hits the `TRAFFIC_PORT`.
2. **Filtering:** The node uses the `TOKEN` to sync security rules from the Wallarm Cloud (based on your `REGION`).
3. **Forwarding:** Valid traffic is sent to the `UPSTREAM` IP.
4. **Monitoring:** System health and security metrics are pulled via the `MONITOR_PORT`.
---
## 🧪 Post-Installation Test

Once the script finishes, verify the WAF is working by sending a "fake" attack:

```bash
# Replace localhost with your server IP if testing remotely

curl -I http://localhost/etc/passwd
```  

## 📊 Sizing & Performance Specs

For a standard deployment (Postanalytics + NGINX on one host), we recommend the following:
### Resource Allocation & Performance

| **Resource**        | **Primary Consumer**      | **Performance Note**                                                                                                                            |
| ------------------- | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **CPU** (2 Cores)   | **NGINX & Postanalytics** | One core typically handles the NGINX filtering, while the second manages `wstore` (local data analytics). This setup safely handles ~1,000 RPS. |
| **RAM** (4 GB)      | **`wstore` (Tarantool)**  | Wallarm uses an in-memory circular buffer for request analysis. At 4GB, you can store roughly 15–20 minutes of request metadata for analysis.   |
| **Storage** (50 GB) | **Log Buffering**         | Required for local attack logs and the postanalytics module. SSD is mandatory to prevent I/O wait times from slowing down request processing.   |

---

### Scaling Indicators

If you notice your traffic increasing beyond these specs, here is when you should consider upgrading:

- **High CPU Usage (>70%):** Usually indicates you have reached the RPS limit for your core count or are processing highly complex, nested payloads (like large JSON or Base64-encoded data).
    
- **Memory Pressure:** If you see `wstore` dropping data before the 15-minute mark, it means your traffic volume (data per minute) is exceeding the 4GB buffer.
    
- **Disk Latency:** If you see "I/O Wait" in your system monitoring, it will directly cause latency for your end users, as NGINX cannot clear its buffers fast enough.  

> [!TIP]

> **Performance Note:** One CPU core typically handles **500 RPS**. In a 2-core setup, one core is dedicated to NGINX (filtering) and one core to `wstore` (local analytics). For production spikes, we recommend 2x headroom.