Background
During an attack, players can still move their characters locally, but cannot cast spells, interact, use actions, receive chat messages, or get disconnected.
This likely means that connections remain open while the world server is overloaded or blocked from processing and responding to game packets. The issue may involve network saturation, excessive connections, packet flooding, database pressure, or a stalled world update loop.
Goals
Reduce unauthorized and abusive connections.
Protect the world server from excessive connection and packet load.
Detect overload early and fail clearly instead of leaving players in a “connected but unusable” state.
Keep the implementation simple and compatible with the existing server.
Proposed Measures
1. Hide the World Server
I've noticed we just changed the fixed ip to play.octowow.st, but we may do more like:
Allow public connections only to a small proxy or gateway service.
Allow the world server to accept connections only from the gateway’s private IP address.
Keep login/web services separated from the world server where possible.
2. Add Basic Gateway Filtering
The gateway should perform lightweight checks before forwarding traffic:
Validate a short-lived login token or session ticket.
Limit new connections per source IP.
Limit concurrent sessions per IP and account.
Reject invalid packet sizes and invalid protocol states early.
Apply short handshake and idle timeouts.
This does not stop large bandwidth DDoS attacks, but it prevents many unauthorized, malformed, and low-effort automated connections from reaching worldserver.
3. Temporary IP Blocking
The gateway should temporarily block a source IP for 10 minutes when it repeatedly triggers rules such as:
Too many new connections in a short period.
Repeated invalid or expired tokens.
Invalid packet length or malformed packets.
Excessive packet rate.
Repeated failed handshakes.
Repeated violations may use a longer temporary block period. Thresholds should be conservative at first to avoid blocking legitimate players behind shared NAT networks.
This plan will not replace upstream DDoS protection for large volumetric attacks. However, it should significantly reduce the impact of connection floods, malformed traffic, unauthorized direct connections, and packet abuse.
The primary benefit is to protect worldserver resources, raise the attacker’s cost, and keep failures controlled and visible rather than allowing players to remain stuck in an unusable session.
Proposal: Simple Protection Plan for World Server
-
Mindpavilion
- Posts: 1
Re: Proposal: Simple Protection Plan for World Server
Solid suggestion, hope Octo’s team can gain some insight from thisRe: Proposal: Simple Protection Plan for World Server
I like the smart suggestions and want to add to that. I work in digital analytics, where we filter bot traffic two ways: rules and exclusions (IP, geo-location, ISP, browser size), or the inverse: identifying human behaviour. Someone toggling dark mode is almost certainly a person. Bots don't do that. So instead of identifying bots, you recognise humans and let them through.
That second approach maps onto this really well, and WoW has a much stronger "human" signal than any website does: logging in successfully with a real account.
In line with this philosophy (and a little Claude help):
1. Let only logged-in players reach the game server. On successful login, the auth server adds your IP to an allowlist for a few minutes. Anyone who hasn't authenticated can't open a connection. Recognise real gamers instead of chasing attackers.
2. A small "bouncer" server in front of the real one. It checks the basics before letting anything through: is this IP opening a suspicious number of connections at once, is this a valid game packet or garbage, did the connection actually finish logging in or is it just sitting there ? Anything that fails gets dropped, offenders get a timeout.
3. Per-account limits on expensive actions. Some actions we take in game are cheap to send but expensive to answer: /who, auction house searches, mail. A few ordinary accounts spamming those can stall the server with no attack traffic at all, and points 1 and 2 wouldn't catch it since those players are legitimately logged in. A cap per account per second might sort it.
None of this replaces the 10 GB/s upgrade of course.
LFG OctoWoW
That second approach maps onto this really well, and WoW has a much stronger "human" signal than any website does: logging in successfully with a real account.
In line with this philosophy (and a little Claude help):
1. Let only logged-in players reach the game server. On successful login, the auth server adds your IP to an allowlist for a few minutes. Anyone who hasn't authenticated can't open a connection. Recognise real gamers instead of chasing attackers.
2. A small "bouncer" server in front of the real one. It checks the basics before letting anything through: is this IP opening a suspicious number of connections at once, is this a valid game packet or garbage, did the connection actually finish logging in or is it just sitting there ? Anything that fails gets dropped, offenders get a timeout.
3. Per-account limits on expensive actions. Some actions we take in game are cheap to send but expensive to answer: /who, auction house searches, mail. A few ordinary accounts spamming those can stall the server with no attack traffic at all, and points 1 and 2 wouldn't catch it since those players are legitimately logged in. A cap per account per second might sort it.
None of this replaces the 10 GB/s upgrade of course.
LFG OctoWoW
-
Happyfeet82
- Posts: 1
Re: Proposal: Simple Protection Plan for World Server
"During an attack, players can still move their characters locally, but cannot cast spells, interact, use actions, receive chat messages, or get disconnected.
This likely means that connections remain open while the world server is overloaded or blocked from processing and responding to game packets. The issue may involve network saturation, excessive connections, packet flooding, database pressure, or a stalled world update loop."
See, this is where you are wrong.
You can move around, because moving around is done in client-side, to be fully lagless. Sometimes you might teleport on your client, but more often you'll see other people being teleported on your screen. That is the client-side position updating the server-side one, so things stay in sync.
When you lose connection, the client will still allow you to move around and trigger spell casts, since those do not require any response from the server. You just regularly push up your new location to the server, and it will only sparingly overwrite it. Triggering a spellcast also does not wait for the response from the server, to reduce the lag you see on your screen.
However once you trigger the spellcast, the client will wait for the server's response, to start showing the cast bar or to do the cast finishing and or magic FX animation (if it's instant spell).
But since you've disconnected, that response never happens, so you walk around on your screen, stuck in the spellcasting-start animation. You may be moving around freely on your screen, but your server-side position remains stationary.
This likely means that connections remain open while the world server is overloaded or blocked from processing and responding to game packets. The issue may involve network saturation, excessive connections, packet flooding, database pressure, or a stalled world update loop."
See, this is where you are wrong.
You can move around, because moving around is done in client-side, to be fully lagless. Sometimes you might teleport on your client, but more often you'll see other people being teleported on your screen. That is the client-side position updating the server-side one, so things stay in sync.
When you lose connection, the client will still allow you to move around and trigger spell casts, since those do not require any response from the server. You just regularly push up your new location to the server, and it will only sparingly overwrite it. Triggering a spellcast also does not wait for the response from the server, to reduce the lag you see on your screen.
However once you trigger the spellcast, the client will wait for the server's response, to start showing the cast bar or to do the cast finishing and or magic FX animation (if it's instant spell).
But since you've disconnected, that response never happens, so you walk around on your screen, stuck in the spellcasting-start animation. You may be moving around freely on your screen, but your server-side position remains stationary.