Origin Firewall

Overview

Lumos Gate hides your origin server's IP address by routing all traffic through shield VPS servers. But if an attacker discovers your origin IP through other means -- historical DNS records, email headers, SSL/TLS certificate transparency logs, or server misconfigurations -- they can bypass the shield entirely and attack your origin server directly.

The solution is to configure your origin server's firewall to only accept incoming web traffic from your shield VPS IP addresses. This way, even if someone knows your origin IP, they cannot connect to it. All WAF protections (IP blacklist, rate limiting, bot protection) remain enforced because traffic can only reach your origin through the shield.

Why This Matters

Without origin firewall lockdown:

Attacker discovers origin IP (e.g., from old DNS records)
    |
    v
Attacker connects directly to origin IP on port 80/443
    |
    v
All Lumos protections bypassed (WAF, rate limit, bot protection)
    |
    v
Origin server exposed to direct attack

With origin firewall lockdown:

Attacker discovers origin IP
    |
    v
Attacker tries to connect directly to origin IP on port 80/443
    |
    v
Firewall blocks the connection (only shield VPS IPs allowed)
    |
    v
Origin server remains protected -- attacker must go through the shield

Important: Origin firewall lockdown is one of the most critical security steps in your Lumos Gate setup. Without it, an attacker who discovers your origin IP can bypass every protection you have configured in the dashboard.

How Attackers Find Origin IPs

Understanding how origin IPs leak helps you prevent exposure:

UFW Setup (Recommended)

UFW (Uncomplicated Firewall) is the simplest way to configure firewall rules on Ubuntu and Debian servers. It is pre-installed on most Ubuntu distributions.

Step 1: Ensure SSH Access

Warning: Before changing any firewall rules, make absolutely sure that SSH access is allowed. Locking yourself out of your own server is the most common firewall mistake. Always keep a second SSH session open while making firewall changes so you can undo mistakes.

# Allow SSH connections (do this FIRST, before any other rules)
sudo ufw allow 22/tcp

If you use a non-standard SSH port, allow that instead:

# If SSH runs on port 2222
sudo ufw allow 2222/tcp

Verify SSH is allowed before proceeding:

sudo ufw status

Step 2: Allow Traffic from Shield VPS

Allow HTTP and HTTPS traffic only from your shield VPS IP address. Find your shield VPS's public IP in Dashboard -> Servers.

# Replace SHIELD_VPS_IP with your actual shield VPS IP
sudo ufw allow from SHIELD_VPS_IP to any port 80 proto tcp
sudo ufw allow from SHIELD_VPS_IP to any port 443 proto tcp

Example with a real IP:

sudo ufw allow from 203.0.113.10 to any port 80 proto tcp
sudo ufw allow from 203.0.113.10 to any port 443 proto tcp

Step 3: Block All Other Web Traffic

Deny all other incoming connections on ports 80 and 443:

sudo ufw deny 80/tcp
sudo ufw deny 443/tcp

Step 4: Enable the Firewall

# Enable UFW (if not already enabled)
sudo ufw enable

# Verify the rules are correct
sudo ufw status verbose

Expected output:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    203.0.113.10
443/tcp                    ALLOW IN    203.0.113.10
80/tcp                     DENY IN     Anywhere
443/tcp                    DENY IN     Anywhere

Important: UFW processes rules in order from top to bottom. The ALLOW rule for the shield VPS IP is checked before the DENY rule, so traffic from the shield VPS passes through while everything else is blocked. If you add the DENY rules before the ALLOW rules, all traffic (including from the shield) will be blocked.

Complete UFW Script

Here is a complete script you can run on your origin server. Replace the placeholder values with your actual IPs:

#!/bin/bash
# Origin Firewall Setup for Lumos Gate
# Run this on your origin server

SHIELD_VPS_IP="203.0.113.10"  # Replace with your shield VPS public IP
SSH_PORT="22"                  # Change if using non-standard SSH port

# Reset UFW to clean state (optional -- removes ALL existing rules)
# sudo ufw --force reset

# Default policies
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow SSH (MUST be first)
sudo ufw allow ${SSH_PORT}/tcp

# Allow HTTP/HTTPS from shield VPS only
sudo ufw allow from ${SHIELD_VPS_IP} to any port 80 proto tcp
sudo ufw allow from ${SHIELD_VPS_IP} to any port 443 proto tcp

# Block all other HTTP/HTTPS
sudo ufw deny 80/tcp
sudo ufw deny 443/tcp

# Enable firewall
sudo ufw --force enable

# Show final rules
sudo ufw status numbered

Multiple Shield Servers

If your domain is assigned to multiple shield VPS servers for failover, add a rule for each one:

# Shield VPS 1 (primary)
sudo ufw allow from 203.0.113.10 to any port 80 proto tcp
sudo ufw allow from 203.0.113.10 to any port 443 proto tcp

# Shield VPS 2 (secondary)
sudo ufw allow from 203.0.113.20 to any port 80 proto tcp
sudo ufw allow from 203.0.113.20 to any port 443 proto tcp

# Shield VPS 3 (tertiary)
sudo ufw allow from 198.51.100.5 to any port 80 proto tcp
sudo ufw allow from 198.51.100.5 to any port 443 proto tcp

# Block everything else
sudo ufw deny 80/tcp
sudo ufw deny 443/tcp

Tip: When you add a new shield server in the Lumos dashboard, remember to add its IP to the origin firewall. Similarly, when you decommission a shield server, remove its firewall rule. See "Removing a Shield VPS" below.

With WireGuard

If you are using a WireGuard tunnel between your shield and origin servers, allow traffic from the WireGuard tunnel IP instead of the shield VPS's public IP:

# Allow from WireGuard tunnel IP (not the shield's public IP)
sudo ufw allow from 10.0.0.1 to any port 80 proto tcp
sudo ufw allow from 10.0.0.1 to any port 443 proto tcp

# Allow WireGuard UDP traffic (so the tunnel itself works)
sudo ufw allow 51820/udp

# Block all other web traffic
sudo ufw deny 80/tcp
sudo ufw deny 443/tcp

This is significantly more secure because:

• The WireGuard tunnel IP (10.0.0.1) is a private address that cannot be spoofed from the public internet. TCP/IP spoofing of private addresses is blocked by internet routers.
• Even if someone knows the shield VPS's public IP, they cannot send traffic that appears to come from the WireGuard tunnel IP.
• You do not even need to allow the shield VPS's public IP on ports 80/443 -- only the tunnel IP.

Multiple Shield Servers with WireGuard

For multiple shield servers with WireGuard:

# Shield VPS 1 via WireGuard
sudo ufw allow from 10.0.0.1 to any port 80 proto tcp
sudo ufw allow from 10.0.0.1 to any port 443 proto tcp

# Shield VPS 2 via WireGuard (different subnet)
sudo ufw allow from 10.0.1.1 to any port 80 proto tcp
sudo ufw allow from 10.0.1.1 to any port 443 proto tcp

# Allow WireGuard traffic from both shields
sudo ufw allow 51820/udp

# Block everything else
sudo ufw deny 80/tcp
sudo ufw deny 443/tcp

iptables Setup (Alternative)

If you prefer using iptables directly instead of UFW (for advanced configurations):

# Flush existing rules (CAREFUL -- this removes ALL rules)
# sudo iptables -F

# Allow established connections (so existing SSH sessions survive)
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow loopback traffic
sudo iptables -A INPUT -i lo -j ACCEPT

# Allow SSH
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow HTTP/HTTPS from shield VPS only
sudo iptables -A INPUT -p tcp -s 203.0.113.10 --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp -s 203.0.113.10 --dport 443 -j ACCEPT

# Allow WireGuard (if using WireGuard tunnel)
sudo iptables -A INPUT -p udp --dport 51820 -j ACCEPT

# Drop all other HTTP/HTTPS
sudo iptables -A INPUT -p tcp --dport 80 -j DROP
sudo iptables -A INPUT -p tcp --dport 443 -j DROP

Make the rules persistent across reboots:

# Debian/Ubuntu
sudo apt install iptables-persistent -y
sudo netfilter-persistent save

Verify the rules:

sudo iptables -L -n --line-numbers

Expected output:

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
3    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22
4    ACCEPT     tcp  --  203.0.113.10         0.0.0.0/0            tcp dpt:80
5    ACCEPT     tcp  --  203.0.113.10         0.0.0.0/0            tcp dpt:443
6    DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80
7    DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443

Verification

After configuring the firewall, verify that the lockdown is working correctly. This is a critical step -- do not skip it.

Test 1: Direct access should be blocked

From your local machine (or any machine that is not the shield VPS):

# This should time out or be refused
curl -v --connect-timeout 5 http://YOUR_ORIGIN_IP

# Expected output:
# * Trying YOUR_ORIGIN_IP:80...
# * Connection timed out after 5001 milliseconds
# curl: (28) Connection timed out after 5001 milliseconds

Test 2: Access through shield VPS should work

SSH into your shield VPS, then test:

# From the shield VPS (should return your website)
curl -v --connect-timeout 5 http://YOUR_ORIGIN_IP

# Expected: HTTP response with your website content

Test 3: Access through WireGuard should work (if using WireGuard)

From the shield VPS, test through the WireGuard tunnel:

# From the shield VPS through WireGuard
curl -v --connect-timeout 5 http://10.0.0.2

# Expected: HTTP response with your website content

Test 4: Access through Lumos should work

Test the full proxy chain by accessing your domain normally:

# From any machine, using your domain name
curl -v https://yourdomain.com

# Expected: HTTP response through the Lumos proxy chain

If the origin server is accessible directly from your local machine (Test 1 succeeds when it should fail), the firewall rules are not applied correctly. Review the rules and ensure the firewall is enabled.

Other Ports to Consider

While ports 80 and 443 are the most critical, consider your full attack surface:

Locking Down Database and Service Ports

# Block database ports from public access (allow only localhost)
sudo ufw deny 3306/tcp    # MySQL
sudo ufw deny 5432/tcp    # PostgreSQL
sudo ufw deny 6379/tcp    # Redis
sudo ufw deny 27017/tcp   # MongoDB

# Block common admin/alt-HTTP ports
sudo ufw deny 8080/tcp
sudo ufw deny 8443/tcp
sudo ufw deny 9090/tcp

Warning: Database ports should never be exposed to the public internet. If you need remote database access, use SSH tunneling (ssh -L 5432:localhost:5432 user@origin) or a VPN like WireGuard.

SSH Hardening

For maximum security, also restrict SSH access:

# Allow SSH only from your known IP
sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR_HOME_IP to any port 22 proto tcp

Additionally, configure SSH to use key-based authentication only:

# Edit SSH config
sudo nano /etc/ssh/sshd_config

# Set these values:
# PasswordAuthentication no
# PubkeyAuthentication yes
# PermitRootLogin prohibit-password

# Restart SSH (keep your existing session open while testing)
sudo systemctl restart sshd

Warning: Before disabling password authentication, make sure your SSH key is properly configured and you can log in with it. Test in a new terminal before closing your current session.

Best Practices

• Always allow SSH first. Before enabling any firewall, ensure SSH access is preserved. Test SSH in a separate terminal before closing your current session. If you lose SSH access and have a serial/KVM console from your provider, you can use that as a recovery path.

• Use WireGuard IPs when possible. WireGuard tunnel IPs are private addresses and cannot be spoofed from the public internet, making them more secure than allowing public IPs. This is the strongest firewall configuration available.

• Keep a list of shield VPS IPs. When you add or remove shield servers from Lumos, update the origin firewall rules accordingly. Consider keeping a checklist or script for this.

• Test after every change. After modifying firewall rules, verify both that the shield VPS can reach the origin AND that direct access is blocked. Test from multiple sources.

• Set default deny policy. Configure UFW to deny all incoming traffic by default (sudo ufw default deny incoming). This way, any port you forget to explicitly block is denied automatically.

• Monitor firewall logs. Blocked connection attempts can reveal that someone is probing your origin IP. This is a sign they may have discovered it:

# View UFW logs (blocked connections)
sudo tail -f /var/log/ufw.log

# Sample blocked entry:
# [UFW BLOCK] IN=eth0 OUT= SRC=198.51.100.99 DST=YOUR_IP ...

If you see frequent blocked connections on ports 80/443 from unknown IPs, your origin IP may be compromised. Consider migrating to a new origin IP and updating the domain configuration in Lumos.

• Consider fail2ban. Install fail2ban to automatically block IPs that make repeated failed SSH login attempts:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

Removing a Shield VPS

If you decommission a shield server from Lumos, remember to remove its firewall rule on the origin:

# Remove the allow rules for the decommissioned shield VPS
sudo ufw delete allow from 203.0.113.10 to any port 80 proto tcp
sudo ufw delete allow from 203.0.113.10 to any port 443 proto tcp

# Verify the rules were removed
sudo ufw status numbered

Warning: Leaving stale allow rules is a security risk. If someone else is assigned that IP address in the future (e.g., IP address recycling by a cloud provider), they would have access to your origin server's web ports. Always remove firewall rules for decommissioned servers promptly.

Disaster Recovery: Locked Out

If you accidentally lock yourself out of SSH:

1. Use your provider's console access -- Most VPS providers offer a web-based serial console or KVM that bypasses network firewalls.
2. Boot into rescue mode -- Most providers offer a rescue/recovery boot option that mounts your disk and lets you edit firewall rules.
3. From the console, disable UFW:

sudo ufw disable

4. Fix your rules and re-enable:

sudo ufw allow 22/tcp
sudo ufw enable

To prevent lockouts, always keep a second SSH session open when making firewall changes, and test SSH connectivity in a new window before closing the original.

Next Steps

• WireGuard Tunnel -- Set up an encrypted tunnel for the strongest origin protection
• WAF Overview -- Configure WAF rules that protect traffic at the proxy level
• Multiple Servers -- Manage firewall rules with multiple shield servers
• Failover -- Understand how failover works with origin firewall rules
• Domains -- Manage domain and origin configurations
• SSL/TLS -- Configure SSL certificates on your shield servers
• Servers -- View shield server IPs for firewall configuration
• VPS Providers -- Choose providers with console access for disaster recovery
• Troubleshooting -- General troubleshooting guide