Warden: How it works

When you use our Anti-DDoS solutions, it's important to understand listings and how they are used.

The section explains the purpose and use of whitelisting, greylisting, and blacklisting in Anti-DDoS solutions. Whitelisting allows only trusted IPs, greylisting temporarily blocks potential threats for verification, and blacklisting denies access to known malicious IPs.

These methods help manage and prevent DDoS attacks by filtering traffic based on its origin.

Traffic filtering techniques

Blacklisting

Blocks traffic from harmful or suspicious IP addresses or domains. Once blacklisted, their traffic is automatically denied to prevent attacks from known threats.

Greylisting

Greylisting is only used as a buffer during the authentication period. Warden allows you to connect, even though you are not whitelisted, requiring extra checks before allowing access. Warden will start limiting traffic in a greylist (and dropped) if you are in the middle of a DDoS attack, where traffic from unauthenticated IP addresses can be dropped as a safety measure.

Whitelisting

Creates a list of approved IP addresses or domains allowed to access the network or service. Whitelisted traffic is not rate limited.

How Warden works

Our system verifies the protocol type, determining if it is TCP or UDP. TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).

In Anti-DDoS strategies:

• TCP provides reliable, ordered, and error-checked delivery of streams of data between applications. It's essential for ensuring that traffic flows as intended without disruptions.

• UDP offers a simpler transmission model with no handshakes, suitable for time-sensitive communications like gaming or streaming, where speed is prioritized over reliability.

Using Transmission Control Protocol

1. First, Warden will check to see if the player IP address is blacklisted by you. If it is, then they are dropped and denied access to the network.

2. Based on your list of approved IP addresses, Warden will check to see if the player IP address is whitelisted. If it is, then the IP address is approved, and in turn the player is allowed access to the network.

3. If the player IP address is not whitelisted, then Warden verifies if the destination port is allowed. If it isn't, the packet is dropped.

4. If the destination port is valid, then the packet goes through rate-limiting. If the PPS is below the configured threshold, then the packet is allowed. Otherwise, it is dropped.

Using User Data Protocol

1. Warden will check to see if the player IP address is blacklisted. If it is, the player IP address is dropped and denied access to the network.

2. If the player's IP address is already whitelisted, Warden performs bytematching (if enabled in the Armor). There are 2 scenarios that can occur afterwards:

   1. If it passes bytematching, or in the absence of bytematching rules, the packet is allowed into the network.

   2. If the packet fails bytematching, then it is denied access into the network.

3. If the player's IP is not whitelisted, Warden verifies if the destination port is allowed. If it isn't, the packet is dropped.

4. If the destination port is valid, then Warden performs bytematching (if enabled in the Armor).

   1. If the packet fails bytematching, then it is denied access into the network.

   2. If it passes bytematching, and if the packet per second is below the configured threshold, then the packet is allowed to enter the network.

Known granularity limitation for natural expiration of IPs on lists

Warden was originally designed to handle billions of entries in its lists, and work with very long expiration duration values (e.g. in the order of 24 hours per item), since there was no mechanism to refresh the expiration through the POST /lists/{id} GLAD API call at the time.

In that historical context, as a database optimization measure (consider that an expiration can be multiple years in the future as well), the design decision was made for the Warden dataplane to process natural whitelist expiration on whole clock hours only.

This means that Warden rounds down the expires value passed via the POST /lists/{id} endpoint to the nearest full hour. Some examples:

• "expires": "2025-08-20T19:04:55Z" becomes "2025-08-20T19:00:00Z" in the Warden dataplane.

• "expires": "2025-08-20T20:55:31Z" becomes "2025-08-20T20:00:00Z" in the Warden dataplane.

When exact expiration times are required, as a workaround it is possible to issue a longer expiration (e.g. add +1h to your intended timestamp) and then at a time of your choosing make a second POST /lists/{id} call with an expires value in the past which will immediately revoke that item from the list and propagate to the Warden dataplane.

We are currently working on a migration to a different database backend that will not require this optimization measure, thereby enabling Warden to handle far more granular natural expiration of IPs on lists. It is expected to be brought live in the coming weeks.

Warden FAQs

What are the advantages of NOT using Warden's greylisting features at all, only allowing access from trusted IPs?

• Full service continuity while attacks are ongoing: New players can continue to connect to the game instance even while the server is under attack. When relying on greylisting, untrusted IPs will experience degraded service or may even have no service at all when the greylist-pps value is exceeded.

• Reduced operational overhead: You can skip thinking about how to interact with the blocklisting feature entirely, anything that is not trusted will be automatically dropped.

• Reduced exposure to low-and-slow attacks: You cannot receive packets from untrustworthy sources, significantly reducing the attack surface of your game and helping to defend against application layer attacks, such as those involving malformed packets. To avoid triggering greylisting, manage your PPS (Packets Per Second) and ensure it remains below the specified threshold.

• Easier troubleshooting: Debugging is much easier because a connection will either always work completely, or never work at all, there is no intermittency factor.

If that is the case, why would someone ever want to use Warden's greylisting feature?

• In some cases it's not possible to integrate with the authentication layer, then the game operator could instead choose to add IPs to the trusted list based on that IP's interactions with the server while in the greylist.

• Once your request reaches the GLAD API, updates propagate rapidly through Warden nodes worldwide. However, in some cases the user still tries to connect to the game instance before the IP address collected during authentication makes it onto Warden's trusted IPs list - a greylist would allow for the user to still complete their initial connection successfully.