Inside the filter

Most protection is a rate limit with a nice name. This page is about what Prism actually does with a packet, because the difference shows up on the one night your server is under a real attack.

Where it runs

Prism runs inside the kernel of the machine serving your game, attached at the earliest point a packet can be inspected, before the operating system has allocated a socket buffer, walked its firewall tables, or woken your game server up.

That position is the whole design, and three things follow from it.

Dropping is nearly free. A packet Prism rejects never reaches the network stack. Your server does not spend a context switch on it, your game does not see it, and the cost of refusing a flood stays close to flat as the flood grows. Filtering further up, in the host firewall or in the application, means the packet has already cost you most of what it was going to cost.

There is no scrubbing hop. Prism is not a proxy sitting between the internet and your server. Nothing is re-encapsulated, nothing is relayed through another city, and the filter is not a second place your traffic has to queue. Traffic that passes reaches your game the same way it would with no protection at all.

It sees the truth. Because it runs on the machine that terminates the connection, the filter reads the real source address and the real payload. A scrubbing service that relays traffic often gives your application a proxied source, which is exactly the information you need when a specific player is being flooded or a specific source is misbehaving.

Cheapest question first

Prism evaluates a packet in layers, and each layer only runs if the one before it did not already decide.

1. Layer 3, the address

   Is this address allowed to talk to this server at all, and is the packet structurally sane? Blocked sources and malformed traffic end here, at the lowest possible cost.

2. Layer 4, the transport

   Is this a real TCP or UDP conversation, or a packet pretending to be one? This is where spoofed and stateless floods are separated from traffic belonging to a connection that actually exists, and where the rate ceilings on your port rules apply.

3. Layer 7, the protocol

   Is this actually the protocol the port claims to serve? A packet aimed at a FiveM port is checked against how FiveM really behaves, not against a generic notion of UDP.

Ordering the work this way is why the filter holds up. The expensive question is only ever asked about traffic that already survived the cheap ones.

It knows your game

A rate limit cannot tell a player from a booter, because both send packets. A protocol validator can, because only one of them speaks the protocol correctly.

Prism ships validators written specifically for the services people actually run on it:

Each one understands how a genuine client opens a conversation on that service. That is why protection tuned for a game does not need to be as blunt as a plain packet cap, and why a flood that would sit comfortably under a rate limit still gets dropped when it does not speak the language.

Trust is earned, not assumed

The most useful thing Prism tracks is not how fast a source is sending. It is whether that source has behaved like a real client.

Sources accumulate a judgement over time. Completing a genuine protocol handshake counts in a source's favour. So does answering a challenge, and so does sending with the irregular timing of a human rather than the metronome of a script. Behaviour that only makes sense for an attack counts against it.

Two things follow that matter during an incident:

• A player who has already proved themselves is not thrown away when the server comes under pressure. The filter has a reason to keep them that a rate limit does not.
• An unknown source arriving mid-flood starts from nothing. It has to earn its way in at exactly the moment the bar is highest.

This is also why pausing protection during an attack is worse than it sounds. The filter's accumulated picture of who is real is part of what is holding your server up.

It learns during the attack

Signatures only catch attacks somebody has already seen. Real attacks against game servers are frequently just novel enough to miss.

Prism carries a zero-day engine that works without signatures. When traffic starts behaving like a coordinated attack, it derives the shape of that specific attack while it is happening and starts refusing traffic matching it, then relaxes when the pattern stops. Nothing has to be written, published, or pushed to you first.

Your server is not sharing a policy

Every server gets its own filtering state and its own rules. Your port rules, your rate ceilings, your allow and deny lists and your accumulated picture of which sources are real belong to your server alone. Another customer being attacked does not tighten anything on yours, and a rule you set does not leak outwards.

What you tune yourself

Everything on this page runs whether or not you touch it. What you set yourself is the shape of the policy: which ports are open, what rates they accept, and which validators run. Those are documented in full, with the real field names, in Port rules, Rate limits and Protocol validation.

To see what the filter actually did with a given source, the Attacks tab shows what was dropped and why.

Related