Filters
What a stateful filter is, how it differs from a rule, and why applying one is recommended.
Two different things sit on your addresses, and the difference matters more than the names suggest.
| Object | What it does | Decides using |
|---|---|---|
| Rule | Allows or denies traffic matching a protocol, destination port and optional source | The packet in front of it |
| Filter | Validates traffic against what a specific protocol or game actually expects on that port | The packet and the state of the connection it belongs to |
A rule is a yes/no question about an address and a port. A filter is the part that can tell a real player's handshake from a spoofed one that looks identical packet-for-packet — which is why it has to be told which protocol is on the port. That is all a filter is: the answer to "what is supposed to be listening here?"
Both are managed under Protection → Firewall in the portal, or through the firewall API.
Filters attach to an address and a port
A filter is identified by its type and the port it is on — synproxy:25565 — and
that pair is the key the API takes when you remove it. Nothing about a filter is
global: the same type on two ports is two filters.
The catalogue is per address
Ask the network which filters are available for a given address rather than assuming a fixed list:
curl https://one.terabit.io/api/v1/firewall/ips/203.0.113.10/filters/available \
-H "Authorization: Bearer tbk_..."{
"data": [
{ "type": "synproxy", "name": "SYN Proxy", "category": "protocols" },
{ "type": "minecraft", "name": "Minecraft", "category": "games" }
]
}Two categories come back. Protocols are transport-level, of which SYN Proxy is the one most people meet — it answers TCP handshakes at the edge so a SYN flood never reaches your listener, and only a source that completes the handshake is passed through. Games are protocol-aware profiles for a specific title or game engine.
An address assigned to one of your services returns a shorter list than one
inside a prefix you announce, because service addresses already carry
default-protection filters that we manage rather than you. The same slug can
therefore be available on one of your addresses and not on another, and a type
that does not exist and a type that is not available here both come back 422.
Applying a filter disconnects everything on that port
A stateful filter has no knowledge of connections established before it existed. Everything currently connected through that port must reconnect through the filter — on a live game server, that means every player drops at once. Prefer a maintenance window, or apply the filter before the port is in use.
Removing a filter is not disruptive in the same way, but it does mean traffic on that port stops being validated.
Limits and ownership
Filters are capped per address (25 by default, and the live value travels in
meta.limits on every read). A filter that a firewall group manages is
read-only outside that group — the group is the source of truth and the next
reconcile would restore anything you removed by hand.
What filters are not
- They are not geo blocking. Blocking by country or ASN is a geo rule, portal only, and not exposed through the API.
- They are not what protects you by default. The always-on network filtering described in the overview applies with no filter configured at all; a filter is how you tell it something specific about your port, so it can more effectively mitigate attacks designed to bypass your application.