122 lines
No EOL
5.6 KiB
Markdown
122 lines
No EOL
5.6 KiB
Markdown
# 🛡️ 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. |