Se prémunir contre les tentatives de contournement du DNS à l'aide du jeton sécurisé « x-ch-no-bypass ».

Introduction

Ce guide explique comment protéger votre serveur d'origine contre les tentatives de contournement du DNS. La mise en œuvre de la x-ch-no-bypass L'en-tête n'est pas obligatoire pour les intégrations CrowdHandler, mais il ajoute un niveau de vérification au niveau de votre source et est donc recommandé.

À quels types d'intégration cet article s'applique-t-il ?

Qu'entend-on par « tentatives de contournement du DNS » ?

L'intégration de CrowdHandler à votre CDN rend difficile le contournement des contrôles de CrowdHandler. Cependant, un utilisateur déterminé qui parviendrait à obtenir des informations réseau sur votre infrastructure pourrait être en mesure de faire passer le trafic en contournant votre point de terminaison CDN, échappant ainsi à toutes les mesures de protection qu'il offre, y compris votre intégration de CrowdHandler.

Comment ça marche ?

Une fois configurée, votre intégration CrowdHandler ajoute un en-tête nommé x-ch-no-bypass à chaque requête transmise à votre application. Sa valeur correspond à votre jeton anti-contournement. Grâce à quelques lignes de code, votre application vérifie que les requêtes comportent l'en-tête avec la valeur attendue et rejette celles qui n'en disposent pas. Seules les requêtes ayant transité par CrowdHandler parviennent à votre application.

Appcelerator (DNS) avec Cloudflare ou Imperva en amont

Si votre DNS pointe vers Cloudflare ou Imperva et que ce service redirige le trafic vers CrowdHandler, configurez le domaine de manière à ce que Type de configuration vers Cloudflare ou Imperva dans le panneau de configuration de CrowdHandler. Dans ce mode, CrowdHandler n'ajoute pas sa propre x-ch-no-bypass en-tête. Au lieu de cela, l'en-tête que vous définissez dans Cloudflare ou Imperva est transmis tel quel à votre serveur d'origine.

La validation de cette valeur au niveau de votre serveur d'origine permet alors de vérifier qu'une requête est bien passée par votre service en amont et par CrowdHandler. Une requête qui parvient directement à CrowdHandler, en contournant Cloudflare ou Imperva, arrive à votre serveur d'origine sans en-tête et est rejetée.

Lorsque le type de configuration est défini sur « DNS direct », CrowdHandler ajoute son propre jeton et remplace tout en-tête portant le même nom qu’il reçoit.

Où puis-je trouver mon jeton ?

Appcelerator (DNS) : ouvrez la page des paramètres du domaine dans le panneau de configuration de CrowdHandler, puis développez la section « Options ». Le jeton se trouve dans le champ « No-Bypass Token ».

Si le type de configuration est « Cloudflare » ou « Imperva », ce champ affiche « Relayé depuis Cloudflare » ou « Relayé depuis Imperva ». Dans ce cas, il n'y a pas de jeton CrowdHandler. La valeur à valider est celle que vous avez configurée en amont.

Panneau d'options affichant le champ « No-Bypass Token »

Autres intégrations CDN (Akamai, Cloudflare, CloudFront) : le guide d'installation correspondant explique où configurer le jeton. Vous pouvez choisir librement la valeur à attribuer.

Exemples d'intégration

Vérification de la présence et de la valeur de la variable x-ch-no-bypass L'en-tête de requête est simple à utiliser dans la plupart des langages et des serveurs Web. Remplacez VALEUR DE VOTRE JETON avec votre jeton.

Apache

RewriteEngine On

# Block if the x-ch-no-bypass request header does not match
RewriteCond %{HTTP:x-ch-no-bypass} !^(YOURTOKENVALUE)$
RewriteRule ^ - [F]

Nginx

location / {

    if ($http_x_ch_no_bypass != "YOURTOKENVALUE") {
        return 403;
    }

    proxy_pass http://app:3000/;
}

Express.js

app.get('/', (req, res) => {
    if (req.header('x-ch-no-bypass') !== "YOURTOKENVALUE") {
        return res.status(403).send("Sorry! You can't see that.");
    }
    res.sendFile(__dirname + "/views/index.html");
});

PHP

function getRequestHeaders() {
    $headers = array();
    foreach ($_SERVER as $key => $value) {
        if (substr($key, 0, 5) <> 'HTTP_') {
            continue;
        }

        $header = str_replace(' ', '-', ucwords(str_replace('_', ' ', strtolower(substr($key, 5)))));
        $headers[$header] = $value;
    }
    return $headers;
}

$headers = getRequestHeaders();

if (($headers['X-Ch-No-Bypass'] ?? '') != "YOURTOKENVALUE") {
    header("HTTP/1.1 403 Forbidden");
    exit;
}

Python (Django)

from django.http import HttpResponseForbidden
from django.http import HttpResponse

def index(request):
    ch_bypass_key = request.META.get('HTTP_X_CH_NO_BYPASS')
    if ch_bypass_key != "YOURTOKENVALUE":
        return HttpResponseForbidden()
    return HttpResponse("Hello world!")

Ce que l'en-tête protège et ce qu'il ne protège pas

Le x-ch-no-bypass La vérification s'effectue au niveau de votre serveur d'origine ; elle ne s'applique donc qu'aux requêtes qui parviennent à celui-ci. Il en découle deux conséquences.

La file d'attente est toujours respectée. CrowdHandler vérifie chaque requête au niveau de la périphérie avant toute autre opération, y compris les requêtes portant sur du contenu mis en cache. Un visiteur ne peut pas contourner la file d'attente en trouvant une copie mise en cache.

Le contenu mis en cache ne fait pas l'objet d'une vérification auprès de la source. Si un chemin est configuré pour être mis en cache, la première requête le récupère depuis votre source, où l'en-tête est validée, et les requêtes suivantes sont servies à partir du cache du CDN sans repasser par votre source. Ainsi, une requête ayant contourné votre CDN pourrait recevoir une copie déjà mise en cache de ce chemin. C'est ainsi que fonctionne tout cache CDN ; il ne s'agit pas d'une particularité propre à CrowdHandler. Si une page doit être validée à chaque requête, désactivez la mise en cache pour celle-ci. Pour Appcelerator, cela se trouve dans la colonne « Cache Policy » ( Politique de mise en cache) sous « Advanced Behaviour Rules » (Règles de comportement avancées) ; par défaut, les nouveaux domaines ne mettent rien en cache.