On this page
Traffic aimed at your server passes two separate filters before it reaches your operating system. Knowing which one does what tells you which problems you can fix yourself, and which vocabulary the rest of this section is written in.
The two layers
The network edge
The first layer sits on the network, upstream of the machine your server runs on. It removes traffic before that traffic ever arrives. You do not configure this layer and there is no control for it in the panel.
This is the layer that answers "how big an attack can you take". The network it runs on carries up to 17 Tbps of mitigation capacity, and that figure is the same whichever plan you are on, because it is the same network in front of every server here. It is not metered or divided per customer.
What it removed is not hidden from you. The Attacks tab folds edge removals into the same drop counters as the on-host filter, so you read one figure for what was dropped rather than two partial views split by layer.
Clouduxe Prism, on the host
The second layer runs on the machine itself and judges traffic packet by packet. This is the layer you configure. It decides which ports are reachable, how fast traffic is allowed to arrive on each of them, whether packets aimed at a port actually speak that service's protocol, and which individual source addresses are trusted or dropped outright.
Everything else in this section is about Prism.
What you control
There are three kinds of control, and they sit at different levels.
- One switch for the whole server. Protection for a server's IP reads Active or Paused. Paused means all traffic for that IP passes through unfiltered. See The Firewall tab.
- One rule per port. A rule opens a port or a port range for one protocol and carries every setting that applies to it: the rate ceilings, protocol validation, and which detection engines run.
- Source rules per address. An allow or deny entry for a single address, independent of any port rule.
Everything else Prism does runs on every allowed port with no setting attached to it. The Protection tab lists those always-on protections; it is a read-only list, not a set of switches.
Why raw capacity is not the answer
A flood aimed at a game port does not look unusual at the IP level. It uses the same protocol as your players, arrives on the same port, and carries packets of a plausible size. A filter that can only measure volume has two options against that traffic: pass it, or drop your players along with it.
Two things make a game server different from a website here.
- The limits are counted in packets, not bandwidth. Every ceiling in this section is packets per second. Small packets arriving quickly are the shape of attack a game server sees, and a bandwidth figure does not describe it.
- A ceiling on the port as a whole does not describe one player. Traffic that arrives as many established connections, each of them individually modest, can add up to far more than the port's aggregate cap was meant to allow. This is why a rule carries a second ceiling for a single connection. See Rate limits.
What separates a player from an attacker is knowing what the service's traffic is supposed to look like: which handshake a real client performs, and which packets are valid before that handshake completes. That is the job of protocol validation and the detection engines, and it is why a rule asks you which service runs on the port rather than only a port number.
The words this section uses
| Term | What it means |
|---|---|
| Rule | One row in the Inbound rules table. It covers one port or port range on one protocol, and carries that port's settings. |
| Port and protocol | Together they are a rule's identity. TCP 30120 and UDP 30120 are two separate rules, so a service needing both needs one of each. |
| Aggregate limit | The field Whole port, packets/sec (0 = unlimited), written as pps_limit. Counted across every source sending to the port. |
| Per-flow limit | The field Per connection, packets/sec (0 = service default), written as estab_flow_pps. Applies to one established connection, and only when an aggregate limit is also set. |
| Protocol validation | The switch Protocol validation (L7), written as l7_validation. Checks that traffic on the port speaks the service's protocol and drops what does not. |
| Engine | A named detection stage inside Prism. Most run on every allowed port with no setting. A few can be switched off for one rule when a legitimate client trips them, which is stored as disabled_engines. |
| Source rule | An allow or deny entry for one IPv4 address, added on the Source IPs tab rather than on a port rule. |
What "protected" means for one server
For a game server, protected means: the ports your players need are open and rate-bounded, traffic on them is checked against the protocol the service actually speaks, the detection engines run on every one of those ports, and individual addresses can be trusted or dropped by hand. It does not mean an unlimited amount of traffic can be absorbed, and it does not mean you can leave the ceilings unset. A rule with no limits on it still opens the port, and bounds nothing on it.
The one number you have to supply is the one only you know: what your server's traffic looks like when nothing is wrong.
Prism is doing considerably more than applying the limits you set. If you want the engineering behind it, where it runs and how it decides a packet belongs to a real player, read Inside the filter.
Related
The attack types it recognises.
Inside the filterWhere Prism runs, and how it tells a player from a flood.
The Firewall tabWhere all of this is managed, and what the switch at the top does.
Port rulesAdding a rule for each service your server runs.
Rate limitsThe two packet-rate ceilings and how they depend on each other.