RedCloud — ban evasion protection for CS 1.6

RedCloud is a player identification module for Superban. It collects several independent markers, merges them into a profile, and keeps a history of changes.

If a player changes their SteamID, IP, or game client, RedCloud can still link the new connection to a known profile using whatever markers remain. It then scores the matches it finds and passes Superban information about a possible link to an active ban.

Features

Player profiles. RedID, CloudID, SteamID, IP, GameID, and KeyID are merged into a single profile with a history of values and connections.
RedID. A personal marker stored in the game client's settings and restored on future connections.
CloudID. An additional browser-side marker issued through the MOTD window. It is independent of SteamID and the game client's settings.
Evasion detection. RedCloud compares the current markers against profiles linked to active bans and reports any match to Superban.
Strong and weak markers. RedID, SteamID, and CloudID carry more weight. IP, GameID, and KeyID are considered less reliable and are checked under extra constraints.
Protection against coincidences. The system accounts for how many players share a weak marker and how current it is, so a shared IP or a common KeyID never becomes the sole reason for a punishment.
Trust levels. A profile grows from new to trusted based on session count, profile age, how recently it last connected, and its ban history.
Automatic thresholds. RedCloud can tune the trust-level requirements on its own, based on how active the project's players are.
Immunity for trusted players. A trusted profile protects a regular player from a mistaken punishment over a weak marker or a missing CloudID.
Trusted list. trusted.ini lets you manually grant a trusted level to a player by SteamID or IP.
Ban type suggestion. RedCloud analyzes a player's accumulated markers and can suggest Superban a suitable set of identifiers for a new ban.
Two protection modes. In normal mode RedCloud works purely as an identification system. Real-time mode adds extra checks and a reaction to a missing CloudID.
Integration with Superban. RedCloud never stores or applies bans on its own: it identifies the player, and Superban checks the ban list and makes the final call.

The web part and MOTD

CloudID needs RedCloud's web endpoint to work. You can host it yourself or use this site — the web part writes browser markers, checks that the database is reachable, and shows ban information in the MOTD window. redcloud_motd_url has to be set and start with http://.

Self-hosted MOTD

RedCloud's web part needs to be hosted somewhere — either your own hosting or this site. It issues the CloudID, refreshes browser markers, and shows ban information in the MOTD window. The data lives in the same MySQL database used by Superban and RedCloud.

Hosting requirements

PHP 8.2 or newer;
the PHP pdo_mysql and mbstring extensions;
MySQL or a compatible MariaDB version;
Apache or nginx;
the web server's access to Superban's database;
the ability to serve the endpoint over plain HTTP.

For MOTD, plain http:// is recommended. The old browsers embedded in CS 1.6 clients may not support modern TLS and could fail to open an HTTPS page.

Installing the web part

Unpack the superban-motd-core.zip archive on the web server, keeping the directory structure:

motd/
├── src/
└── standalone/
    ├── redcloud.php
    ├── config.php
    ├── check_template_motd.php
    ├── ban_template_motd.php
    ├── pic.swf
    └── lib/

Both the src and standalone folders are required. They must sit next to each other: standalone/lib/bootstrap.php pulls in the source code from src.

Point the site's (or a dedicated subdomain's) document root at the standalone folder. src must stay outside the public document root. The endpoint should then be reachable at:
```
http://motd.example.com/redcloud.php
```
Open standalone/config.php and set the connection to the same database the game plugins use:

dbHost: '127.0.0.1',
dbPort: 3306,
dbName: 'cs_16',
dbUser: 'superban',
dbPassword: 'password',

Check the table names:

superbanPrefix: 'amx_',
superbanTable: 'bans',
redcloudPrefix: 'redcloud_',

Set your own secret for the ban's browser marker:

banCookieSecret: 'long-random-string',

Set the endpoint address in the game server's redcloud.cfg:

redcloud_motd_url "http://motd.example.com/redcloud.php"

After changing the config, change the map or restart the game server.

Checking the web part

Open the health endpoint:

http://motd.example.com/redcloud.php?mode=health

With a correct database connection it will return:

ok

A db_error response means the web part cannot connect to MySQL. In that case check the database host, username, password, database name, and permissions.

After the game server starts, RedCloud's logs should show a confirmation that the web part is reachable:

[CloudAuth] web health OK

Securing the config

config.php contains the database password and must never be reachable through a browser.

For Apache, the package includes .htaccess files that block direct access to config.php and the lib folder. The server must have .htaccess processing enabled.

For nginx, add the restrictions manually:

location = /config.php {
    deny all;
    return 404;
}

location ^~ /lib/ {
    deny all;
    return 404;
}

After this, a request to config.php should return 403 or 404.

Customizing appearance

check_template_motd.php controls the page a player sees on a normal connect. You can put server rules, an image, or other information there.

ban_template_motd.php controls the ban information page: the player, the reason, the duration, the unban date, and the admin.

When editing the templates, don't remove the required variables from the <head> section:

<?php echo $cloudidHtml; ?>
<?php echo $cookiebanHtml; ?>
<?php echo $cookieFallbackHtml; ?>

They're used to write browser markers on clients that ignore the regular Set-Cookie header.