Protocol validation

Rate limits count packets. Protocol validation and the detection engines look at what is inside them, which is how Prism catches a flood that stays under every ceiling you set. All of it is configured per rule, in the same dialog you use to open the port.

Protocol validation (L7)

The switch labelled Protocol validation (L7) writes l7_validation. The panel describes it as: "Checks that traffic actually speaks this service's protocol and drops what doesn't."

It matters because the rate limits structurally cannot see the traffic it catches. Once a connection is established the packet ceilings treat it as vouched, so a flood riding open connections passes under them. The panel says so next to the switch: "Catches a flood hiding inside connections that are already open, which the rate limits above cannot see. Turn off if a real client or mod gets dropped."

It is off by default on a rule you add by hand

The default is deliberate rather than an oversight. A protocol validator drops anything that does not speak the service's protocol, which includes an unusual client, an older build, or a mod that speaks the protocol loosely. Switching that on underneath a server that is already running would cut those players off without warning, so it is left for you to turn on knowingly.

Turn it on when you are in a position to watch the result: after a change, with someone able to test a connection, and not in the middle of an attack.

Services that have no validator

Not every service ships one. When the service on the rule has none, the switch renders dim and says so: "This service has no protocol validator. No effect on this one." Services that do ship one are marked · L7 in the Service picker, so you can see which is which before you commit to a rule.

The three engine switches

Most of Prism's detection engines run on every allowed port with no setting at all. Three can be switched off for one rule, and they are the three most likely to misjudge a legitimate but unusual client.

How the switches map onto disabled_engines

A rule stores its engine settings as disabled_engines, a bitmask recording which engines are switched off. The switches show the opposite: a switch that is on means the engine is running and its bit is clear.

• A new rule carries disabled_engines of 0, meaning nothing is disabled and every engine that applies is running.
• Turning TCP fingerprint off sets bit 1<<0, and turning it back on clears that bit.
• Turning two off sets both their bits, and each is independent of the others.

The rules table on the Firewall tab shows one chip per engine switched off, written with the engine's own name, for example tcp_fingerprint off. A rule with no chip has nothing disabled.

Switching an engine off after a false positive

You would turn one of these off for exactly one reason: a legitimate client is being dropped and you have identified which engine is doing it. The panel states the case for each.

TCP fingerprint. "Turn off if a real client behind an unusual NAT, VPN or tunnel is being blocked." What you give up: forged SYNs on that port are no longer rejected on the shape of the sending stack, so spoofed connection attempts that a fingerprint check would have caught now reach your rate limits instead.

Signature (zero-day). "Turn off for a service whose legitimate payloads are unusual or highly variable." What you give up: the ability to block an attack pattern that nobody has written a rule for yet. That is the engine that adapts to something new mid-attack, so switching it off leaves that port covered only by the checks that already know what to look for.

UDP first-packet challenge. "Turn off if real users sharing one address (CGNAT, office or campus NAT) drop out during an attack." What you give up: the cheapest defence against spoofed single-shot UDP floods, which never retransmit and so never pass the challenge. Expect a UDP game port to absorb more junk with this off.

How to do it without guessing

1. Confirm the engine before touching it

   Work through When players cannot connect first. The Address lookup on the Attacks tab tells you why a specific address was dropped, which is what identifies the engine. Turning switches off on a hunch leaves protection off for nothing.

2. Change one switch

   Open the rule, turn off the single engine that matches, and press Save changes. Changing two at once means you will not know which one mattered.

3. Retest with the affected client

   Give your server about 30 seconds to pick up the change, then have the affected player try again.

4. Put it back if it made no difference

   If the client still fails, turn the engine back on before trying the next one. An engine left off is protection you are not getting, in exchange for nothing.

A dim switch still holds its value

A switch shown as dim is not cleared. The rule keeps whatever that setting was last saved as, and saving the rule writes it back unchanged.

The practical case: a rule with Protocol validation (L7) on, moved to a service that has no validator, still carries l7_validation as on. Nothing is lost, and if you move the rule back to a service that does validate, it is live again immediately. The same applies to the engine bits when you switch a rule between TCP and UDP.

So a dim switch means "not in play for this rule as it stands", not "off". If you want a setting genuinely off, set it while the rule is on a service and protocol where the switch is live.

Related