Layer 7 Protection Docs

Start here

Before you install

The agent disables any firewall or protection already running on that server when it installs: ufw, firewalld, an existing nftables/iptables setup, another anti-DDoS tool, whatever is there. We don't try to run alongside it.

This is deliberate, not an oversight. Two overlapping firewalls can silently conflict and leave gaps neither side catches on its own. Once Wiptor is installed on a server, you're relying on us for that server's protection. We won't risk a security gap for the sake of compatibility with something else. If you need to keep an existing setup, don't install the agent on that server yet.

Start here

Installation

One command, run as root on the server you want protected. No wizard, no config file to hand-edit first.

root@your-server

$curl -s https://wiptor.com/install.sh | sh -s YOUR_LICENSE_KEY

Works identically with wget -qO- https://wiptor.com/install.sh | sh -s YOUR_LICENSE_KEY if that's what's on the box.

1

Add your server in the dashboard

Name it, give us the IP, pick a type. You get a license key tied to that server's IP only, it won't activate anywhere else.

2

Run the install command

Detects the architecture, disables anything else already protecting that server, installs the agent as a systemd service.

3

Start protection from the dashboard

The general stack applies first, then anything specific to your server type. Status flips to Protected.

Protection

Defense in Depth

Three independent layers, each built separately, each covering what the one below it structurally can't. No single point that, if it misses something, the whole thing falls over.

01

Kernel layer

Runs at the network interface, before the firewall even sees the packet. eBPF/XDP on Linux, pf on FreeBSD. This is where the biggest, dumbest floods get dropped, cheaply, before they cost anything downstream.

02

Firewall layer

Real nftables rules in our own isolated table: connection limits, SYN cookie proxying, idle-connection reaping, port-scan detection. Stateful, per-IP, tuned by your sensitivity setting.

03

Intelligence layer, shared through Wiptor

Behavioral tracking and the Reputation Mesh live here: not static rules, memory over time. Your server doesn't talk to other customers' servers directly. It reports what it catches to Wiptor, and Wiptor uses that, aggregated across every protected server, to protect everyone else. A pattern flagged on your server can raise an IP's risk everywhere else; it never means your server is exposed to anyone else's.

your server → Wiptor → every other protected server. Never server-to-server.

Protection

General stack

The same six modules on every server, split into three technical layers: what actually runs at the network interface, what's a real firewall rule, and what's behavioral intelligence feeding the firewall.

ModuleLayerWhat it does

Kernel ShieldkernelDrops obvious flood traffic at the network interface, before it ever reaches the firewall (eBPF/XDP on Linux, pf on FreeBSD).

Connection flood protectionfirewallLimits new connections and concurrent connections per IP.

SYN Cookie ProxyfirewallSYN cookies / synproxy, absorbs handshake floods before they reach your service.

Slowloris KillerfirewallCloses connections held open without progress, even without the HTTP reverse proxy.

Behavioral Scan DetectorfirewallFlags and blocks IPs that probe multiple closed ports in a short time.

Handshake replay detectionintelRemembers handshake/login values already seen, blocks IPs that resend one instead of a fresh one. Needs memory over time, not a static rule.

Reputation MeshintelIPs that attacked other Wiptor-protected servers feed into your firewall automatically, repeat offenders auto-escalated over time. Free+ only.

What these modules become, technically

Every module compiles down to real nftables/eBPF constructs in our own isolated table, not a third-party ruleset. The exact rule set is generated per server from your sensitivity and ports, but the underlying technique is standard and inspectable:

SYN Cookie Proxy, conceptually

table inet wiptor { chain input { type filter hook input priority filter; policy accept; # SYN flood on a protected port: cookie-proxy the handshake tcp dport { 27015, 25565 } tcp flags syn \ synproxy mss 1460 wscale 7 sack-perm timestamp } }

Adaptive Connection Limiter, conceptually

# Medium sensitivity: 50 new conn/sec, 30 concurrent, per source IP tcp dport 25565 ct state new \ limit rate over 50/second drop tcp dport 25565 ct count over 30 drop

Slowloris Killer, conceptually

# Closes connections that stay half-open too long ct timeout tcp { protocol tcp; policy = { syn_sent: 5s, established: 60s } }

Illustrative syntax showing the real, standard technique behind each module, not a literal dump from a live server.

Protection

Proprietary scripts

On top of the general stack, a set of scripts we built ourselves, not adapted from a public ruleset. We don't publish exactly how they work, that's deliberate: the value is partly in the fact that it isn't documented anywhere an attacker can read.

What makes these proprietary isn't the code. It's the data behind it.

Every proprietary module here is built to learn from attack patterns collected across Wiptor-protected servers, and to keep sharpening as the network grows. That's a living dataset unique to Wiptor: refined constantly, specific to the servers we actually protect, not a static ruleset frozen at release.

Each module also runs as a purpose-built subsystem, written in C, at the layer where it actually belongs (kernel-level via eBPF/XDP where raw speed matters, our own isolated nftables table for the rest), not a config file bolted onto someone else's tool.

Built on our own attack data Not a downloadable ruleset Written in C, kernel-level where it counts Refined continuously, not frozen at release

A2S Query Guard PROPRIETARY

Built from zero for query-protocol abuse specifically, not a modified rate limiter someone else wrote. Reports what it sees into the same Intelligence layer as every other module, so a pattern caught here can shape a decision on a completely different server.

Handshake Validator PROPRIETARY

Several independent checks chained together, each one written in-house, no single point a crafted packet can slip through. What it checks and in what order is intentionally not something we lay out in public docs.

Auth Flood Limiter PROPRIETARY

A completely separate enforcement layer around your login path, engineered apart from the general connection stack so a login flood can never starve real players, or the other way around. We're keeping the specifics off this page on purpose.

Session Heartbeat Monitor PROPRIETARY

Runs for the entire lifetime of a session, not a one-time check at login, built to catch hijacking mid-session, something a static firewall rule structurally can't do. How it decides a session is compromised isn't something we spell out here.

TLS Fingerprint Engine PROPRIETARY

Computes both JA3 and JA4/JA4H (the current industry standard) from the real handshake, plus our own integrity check on top. Does what the client claims to be (via its User-Agent) actually match how its TLS stack behaves? Feeds straight into the Intelligence layer, and into the shared reputation network across every Wiptor-protected server.

Threat Signature Engine PROPRIETARY

Scores traffic against a threat model we build and retrain ourselves, cross-referenced against everything else the Intelligence layer is tracking, not a static blocklist someone else compiled. How it scores a client isn't published.

Network Risk Engine PROPRIETARY

Not a checkbox list of blocked countries. Every network and origin carries a risk score we compute ourselves from attacks actually seen across Wiptor-protected servers, and it shifts as that picture changes, tightening automatically around networks with a real history of abuse. The exact scoring stays internal.

We're specific about what a module protects against. We're deliberately vague about how, for the same reason a lock manufacturer doesn't publish the pin layout.

Protection

Type-specific modules

On top of the general stack, protocol-aware scripts depending on what you picked when adding the server.

Source engine (CS2/CS1.6, TF2, GMod, L4D2)

Query flood protection (A2S): rate-limits status/info query packets per IP.
Handshake validation: drops malformed connection packets before they reach the game process.

GTA5 / FiveM

FiveM handshake validation: drops malformed connection packets before they reach the game process.
Player connection rate limiting: limits new player connections per second.

Minecraft

Query/ping flood protection: rate-limits status ping packets per IP.
Handshake validation: drops malformed connection packets before they reach the server process.

Custom / other game

Unauthenticated connection timeout: closes connections that never complete login within a few seconds.
Login/auth packet flood protection: rate-limits login packets separately from gameplay traffic.
Authentication pool limits: caps concurrent "logging in" connections, separate from real player slots.
Session heartbeat: re-verifies logged-in sessions, drops hijacked ones.

Websites

TLS fingerprinting (JA3 & JA4): flags known attack tools by handshake signature, not just IP.
Bot allow/block lists: 500+ known bad bot/scanner signatures, never challenges Googlebot/Bingbot.
Country & ASN blocking: block or challenge by country or abusive hosting network.
Full HTTP protection (optional): real TLS-terminating reverse proxy, the same approach Cloudflare/Akamai use. Off by default. Unlocks:
Web attack firewall: blocks SQL injection, XSS, path traversal, command injection, Log4Shell-style probes.
Data leak detection: alerts if your site accidentally leaks a card number, API key, or token in a response.
Progressive tarpit: repeat offenders get delayed by an increasing amount instead of an instant block.
Honeypot paths: instant block on /wp-admin, /.git, /.env and similar.
Crawler verification: confirms a claimed Googlebot/Bingbot really is one, via reverse DNS.
Credential stuffing protection: blocks sources with repeated failed logins.
Per-page rate limiting & challenge page: rate-limits by URL, not just by connection.

Rust, ARK, Valheim, ARMA 3, Squad, Unturned, 7 Days to Die, Conan, DayZ, Project Zomboid, Satisfactory, V Rising, Generic VPS

No extra protocol-specific modules yet, honestly. The general stack above already covers these; type-specific scripts are prioritized by how many servers actually run each type.

Protection

Sensitivity & thresholds

Three presets control how aggressively the general stack's thresholds trigger. Real numbers, not a vague slider:

Sensitivity

New conn/sec per IP

Concurrent conn per IP

Best for

Low

100

60

High-traffic, low false-positive tolerance

Medium

50

30

Default for most servers

High

20

10

Small server, already under pressure

Sensitivity is per-asset, changeable any time from Rules. Monitor-only mode runs every module and logs what it would have blocked, without blocking anything, useful for a first look at real traffic before switching to Enforcing.

Firewall / WAF

Ports & purposes

You don't write firewall rules directly. You declare what a port is for and Wiptor applies the right protection. Every port has a purpose, an optional role, and a state.

Purposes

Game server Website / web server Database SSH / admin access Other

States

ProtectedWiptor applies rules for this purpose.

OpenAllowed through, optionally restricted to one source IP.

ClosedBlocked from the internet entirely.

Role is free text with contextual suggestions (Auth, Channel 1, RCON, Query...) depending on your server type, for splitting a game's sub-services out from the main port.

Firewall / WAF

Port profile library

1,548+

Ready-made port profiles across every game type we support plus the self-hosted software people actually run alongside a server, each with its real documented default port and protocol. Pick one in Firewall / WAF instead of looking the port up yourself. A sample, by category:

Games

ServicePortProtoPurpose / role

CS2 / CS1.627015udpGame · Game

Rust28015udpGame · Game

Rust RCON28016tcpGame · RCON

Minecraft Java25565tcpGame · Game (Java)

Minecraft Bedrock19132udpGame · Game (Bedrock)

ARK: Survival Evolved7777udpGame · Game

GTA5 / FiveM (txAdmin)40120tcpWeb · txAdmin panel

Databases & storage

ServicePortProtoPurpose / role

MySQL / MariaDB3306tcpDatabase

PostgreSQL5432tcpDatabase

Redis6379tcpDatabase

MongoDB27017tcpDatabase

Elasticsearch9200tcpDatabase

Panels, DevOps & networking

ServicePortProtoPurpose / role

Pterodactyl Panel8080tcpOther

Pterodactyl Wings8443tcpOther

Docker API2375tcpOther

Grafana3000tcpOther

WireGuard51820udpOther

SSH22tcpSSH / admin access

Every profile fills in port, protocol, purpose and role in one click. You still choose the state (Protected / Open / Closed) and any IP restriction yourself.

Network & account

Verify & security score

A real audit, not a preview: 20-30 checks against your actual configuration, run on demand from the Verify page.

Covers sensitivity and its thresholds, every general and type-specific module, license activation, declared IP vs. the IP that actually activated the license, agent heartbeat, whitelist/blacklist, and every declared port, including a hard flag for a database or SSH port left open to the internet with no IP restriction. Each issue gets a severity: Critical, High, Medium, or Low. A 0-100 score is computed from what's actually wrong, shown only once the full check sequence finishes. "Solve this for me" fixes the straightforward stuff automatically: raises sensitivity if it's Low, switches off Monitor-only, enables anything you'd left off.

Network & account

Shared reputation network

The actual differentiator, not just another flood filter.

An IP that attacks one Wiptor-protected server gets flagged and fed into every other Wiptor-protected server's firewall automatically, repeat offenders get auto-escalated over time. The network gets stronger as more servers join it. This module is Free+ only.

Network & account

Zero Trust, applied to Layer 7

Zero Trust means: nothing gets trusted just because it made it past the front door. Every connection gets checked, continuously, not once and then waved through. That's the same principle the general stack already runs on, we just haven't spelled it out until now.

No third party in the trust chain

No proxy, no DNS handoff. There's no external network sitting between your players or visitors and your server that has to be trusted too, unlike a proxy-based service.

Trust is revoked instantly, network-wide

The Reputation Mesh doesn't grant lasting trust just because an IP looked clean earlier. The moment it's caught misbehaving on any Wiptor-protected server, that's reflected everywhere, immediately.

Connections are re-checked, not just admitted once

Slowloris Killer and the Adaptive Connection Limiter keep watching a connection after it's already open. Getting past the handshake isn't the same as being trusted for the rest of the session.

What's next here

Hundreds of generic web-attack detection rules, in the style of the OWASP Core Rule Set (SQL injection, XSS, remote code execution and the rest of the well-known attack classes), layered on top of full HTTP protection for websites. PLANNED, not built yet, this is the direction the reverse-proxy mode is heading.

Network & account

Free vs Free+

Free

1 protected server
Every module except the reputation network
Full Verify, Firewall/WAF, Analytics, Incidents
No credit card, ever

Free+

Up to 3 protected servers
Everything in Free, plus the shared reputation network
Requirement: a small "Protected by wiptor.com" badge somewhere public, self-declared, no proof needed
Still free, still no credit card

Upgrade or downgrade any time from Account. Instant, no billing involved since everything is free right now.

More

What we're building next

Layer 7 protection with the same technical depth Cloudflare brings, aimed specifically at VPS and game servers. In progress, not live yet.

Behavioral detector → adaptive thresholds IN PROGRESS

Sensitivity today is three fixed presets. Next: thresholds that tune themselves from each server's real traffic instead of a static number.

Reputation confidence scoring PLANNED

Not just blocked/not blocked. A trust score per IP, shared across the network, so a borderline IP gets watched more closely instead of an all-or-nothing call.

Deeper protocol fingerprinting PLANNED

JA3/JA4 today cover TLS. Extending fingerprinting to more of the traffic hitting a game or generic TCP/UDP service, not just HTTPS.

FreeBSD support PLANNED

Same idea via pf and native synproxy instead of nftables/eBPF, for people running FreeBSD-based game hosting.

More

FAQ

Does traffic route through Wiptor's infrastructure?

No. The agent runs on your own server. Nothing proxies through us except license checks and reputation-network sync calls to our API. No DNS changes.

What does Wiptor NOT protect against?

Volumetric Layer 3/4 floods (hundreds of Gbps, UDP amplification, raw bandwidth saturation). That's your datacenter's job, it already happens before traffic reaches your server. Wiptor handles what gets past that: connection/SYN floods, slow-connection attacks, bot and protocol abuse.

Can I uninstall it?

Yes, any time, no lock-in. Since the agent disabled whatever firewall you had before, put one back in place before or right after uninstalling if you still need protection.

Is this really free?

Yes. No credit card at any point, Free+ only asks for a public badge, self-declared.