Solutions · Gaming servers
Game server protection built around the players already connected
Game traffic is UDP, real-time and sensitive to delay. UMBREN filters attack traffic upstream and treats established player flows differently from new, unproven ones, so that stopping a flood does not mean dropping the players who were already in the match.
UDP game traffic
What makes a game server hard to protect
A game server is a small, steady stream of packets per player, on a port that anyone can send to. The same properties that make UDP right for games make it easy to attack.
No connection to lean on
UDP has no transport handshake. Telling a player from a flood takes flow tracking and a learned baseline, not a port number.
Delay is felt at once
Players notice added delay before any monitoring does. Filtering is done upstream, on a network built for it, and never in an application tier.
Servers use port ranges
One address often hosts several game instances. Register a single port or a port range. The allowance depends on your plan.
Sessions are long-lived
A player in a match is an established flow. Mitigation that treats every packet as new would interrupt the people it is meant to protect.
Flow Guard
Connected players are established flows, and are treated as such
Flow Guard tracks flows per source. With established-flow protection on, as it is by default, limits fall on how quickly a source opens new flows and how many it holds open. Flows that are already established are protected.
An attack that opens new flows at a high rate runs into the per-source limits. A player who joined before the attack began is not a new flow, and is not handled as one.
The defaults are a starting point. Set them from what your game actually does: how many flows a real client opens, and how long a connected client can be silent.
| Setting | What it does |
|---|---|
protect_established_flows | Protect flows that are already established while limits are applied to new ones. Boolean. Default true. |
max_new_flows_per_source_per_second | New flows one source may open per second. Integer. Default 50. |
max_concurrent_flows_per_source | Flows one source may hold open at once. Integer. Default 500. |
idle_timeout_seconds | How long a flow may stay idle before it is no longer treated as established. Integer. Default 180. |
Mitigation policy
A policy shaped by how your game sends packets
Game traffic is regular. Packet sizes fall in a known band and rates follow player counts. A policy that states those facts gives attack traffic less room to hide.
State the packet sizes
Packet Guard accepts a minimum and maximum packet size, and can drop fragments and malformed packets. Set the bounds your game actually uses.
Require anomalies to persist
Flood Guard acts on traffic that stays above the baseline multiple for a sustained period. Both the multiple and the period are yours to set.
Monitor through a busy period
Run a new policy in monitor mode across a release, an event or a weekend peak. Read what it would have done before you let it enforce anything.
Let rules expire
Automatically applied rules carry a time to live. An incident resolves only after traffic has stayed normal for the quiet period.
Choosing a protection region
A protected address adds a step to the path between player and server. Where that step is matters. At registration you set a preferred protection region: a specific region offered by a connected provider, or auto.
UMBREN does not publish latency figures. If the path decides whether protection is workable for your game, talk to us about your server and your players before you authorize activation.
Game-specific profiles
Today a game server is registered under the Gaming Infrastructure category and protected with the generic UDP or generic TCP profile, tuned through the policy settings above.
Protocol Guard profiles written for specific games are planned. They are not available today, and no date is given here.
Onboarding
From a registered server to a protected one
Nothing touches your server before you have proven it is yours, and nothing changes how players reach it until someone on your team approves the change.
Register the server
The origin address, UDP or TCP, the port or port range your instances use, and a preferred region.
Verify ownership
Run the verification agent on the server, or submit a manual verification request for review. An address typed into a form is not proof.
Stage and test
A protected address is reserved and your origin is configured behind it. Once your firewall accepts clean traffic from the delivery ranges, the staged path is tested. No player traffic moves yet.
Authorize activation and move players
When every activation gate holds, a member of your team approves the change. You then point players at the protected address.
Keep your game servers reachable
Create an account, register a game server and verify that it is yours. Protection is activated only after every check has passed and your team has authorized the change.