Comment évaluer les demandes de limite dans Blazor/ASP.NET Core –

Si vous créez une API ou un site Web public, vous vous inquiétez probablement des performances. La limitation du débit peut aider à prévenir les abus des attaques DDoS de base, et il est assez facile à configurer pour les applications Blazor/ASP.NET Core.

Pourquoi les demandes de limitation de débit ?

Il existe de nombreuses raisons de limiter les demandes de taux. La plupart des services devraient probablement fixer une sorte de limite de débit, car aucun être humain raisonnable ne fera 100 requêtes par seconde pendant dix minutes d’affilée. Par défaut, votre application va répondre à chaque demande, il est donc judicieux de définir une limite raisonnable.

Bien entendu, votre fournisseur de cloud peut également disposer d’une protection DDoS. Cela protégera généralement bien contre les attaques de couche 3 et 4 ciblant votre serveur. Cependant, vous voudrez toujours vous assurer que votre serveur fait tout son possible pour empêcher les attaquants d’y accéder.

Vous avez également la possibilité de définir la limite beaucoup plus bas pour limiter les demandes sur les API publiques. Par exemple, un certain point de terminaison peut nécessiter beaucoup de traitement pour répondre à la demande. Vous souhaiterez peut-être limiter ce point de terminaison afin qu’aucune adresse IP ne puisse effectuer plus de quelques requêtes toutes les deux secondes, limitant ainsi le stress sur votre serveur/base de données.

Configuration de la limitation de débit dans ASP.NET Core

Blazor en tant que framework repose sur ASP.NET Core, qui gère tous les éléments cachés pour exécuter un serveur HTTP et répondre aux demandes. Vous devrez donc configurer la limitation du débit pour ASP.NET Core. Les mêmes étapes s’appliqueront à toute personne n’utilisant pas Blazor.

La limitation du débit n’est malheureusement pas une fonctionnalité par défaut dans ASP.NET Core. Cependant, il existe un package NuGet très populaire, AspNetCoreRateLimit, qui fait très bien l’affaire. Vous pouvez l’installer en cliquant avec le bouton droit sur votre projet dans Visual Studio et en sélectionnant « Gérer les packages NuGet… » :

Rechercher AspNetCoreRateLimit et installez-le.

Il existe plusieurs façons de limiter le débit. Si vous utilisez une API qui a besoin de clés, nous vous recommandons de limiter le débit en fonction de la clé API, ce qui couvre tous les cas. Pour la plupart des gens, la limitation du débit basée sur l’adresse IP est probablement correcte et est la valeur par défaut recommandée par AspNetCoreRateLimit.

Vous devrez l’ajouter en tant que service à ASP.NET. Tous les services sont configurés dans Startup.cs, qui les ajoute avec le ConfigureServices(IServiceCollection services) une fonction.

Il y a pas mal de services à configurer. La première fonction configure les services pour charger les paramètres à partir de votre fichier de configuration. Vous voudrez également ajouter le cache mémoire de Microsoft si vous ne l’avez pas déjà fait. Ensuite, vous devrez configurer IpRateLimiting à partir du fichier JSON, puis ajouter le limiteur de débit.

            // needed to load configuration from appsettings.json 
            services.AddOptions();
 
            // needed to store rate limit counters and ip rules
            services.AddMemoryCache();
 
            //load general configuration from appsettings.json
            services.Configure(Configuration.GetSection("IpRateLimiting"));
 
            // inject counter and rules stores
            services.AddInMemoryRateLimiting();
 
            // configuration (resolvers, counter key builders)
            services.AddSingleton<IRateLimitConfiguration, RateLimitConfiguration>();

Aussi dans Startup.cs, vous devrez configurer le générateur d’applications pour utiliser la limitation du débit IP.

app.UseIpRateLimiting();

Gardez à l’esprit que cela utilise une limitation du débit en mémoire, qui est par instance. Si vous équilibrez la charge de votre application, vous devrez utiliser un magasin de mémoire distribuée comme Redis, que ce package prend également en charge.

Configuration de la limitation de débit

Une fois ajouté à ASP.NET, vous devrez vous diriger vers votre appsettings.json fichier de configuration pour le configurer. La configuration ressemble à ce qui suit :

"IpRateLimiting": {
    "EnableEndpointRateLimiting": false,
    "StackBlockedRequests": true,
    "RealIpHeader": "X-Real-IP",
    "ClientIdHeader": "X-ClientId",
    "HttpStatusCode": 429,
    "IpWhitelist": [ "127.0.0.1", "::1/10", "192.168.0.0/24" ],
    "EndpointWhitelist": [ "get:/api/license", "*:/api/status" ],
    "ClientWhitelist": [ "dev-id-1", "dev-id-2" ],
    "GeneralRules": [
      {
        "Endpoint": "*",
        "Period": "1s",
        "Limit": 2
      },
      {
        "Endpoint": "*",
        "Period": "15m",
        "Limit": 100
      },
      {
        "Endpoint": "*",
        "Period": "12h",
        "Limit": 1000
      },
      {
        "Endpoint": "*",
        "Period": "7d",
        "Limit": 10000
      }
    ]
  }

Tout d’abord, si vous prévoyez de limiter le taux de certains points de terminaison différemment, vous devrez activer EnableEndpointRateLimiting, qui est faux par défaut.

StackBlockedRequests fera compter toutes les demandes bloquées dans le compteur. Fondamentalement, avec cette option désactivée, toute personne faisant des demandes à plusieurs reprises recevra X réponses par période. Avec cette option, ils travailleront très rapidement sur les réponses maximales, puis ne recevront plus de réponse.

RealIpHeader et ClientIdHeader utilisés lorsque votre serveur est derrière un proxy inverse, ce qui est une configuration courante. Étant donné que les demandes proviendront toujours du serveur proxy, le proxy définit un en-tête avec les informations réelles de l’utilisateur. Vous devrez vérifier votre proxy et vous assurer que cet en-tête est correctement défini, sinon le limiteur de débit traitera tout le monde comme la même adresse IP.

Ensuite, il existe trois listes blanches, une pour les adresses IP, les ID client et les points de terminaison. Vous pouvez les supprimer si vous n’en avez pas besoin.

Ensuite, vous devrez configurer chaque point de terminaison, ainsi qu’une période et une limite. Un caractère générique couvrira tout et est la seule chose qui fonctionne avec EnableEndpointRateLimiting défini sur false. Si ce n’est pas le cas, vous pouvez définir des points de terminaison en utilisant {HTTP_VERB}{PATH}, y compris les caractères génériques, donc *:/api/values correspondra à toutes les requêtes GET et POST à /api/values.

Vous voudrez vous assurer que votre point de terminaison correspond à un fichier et non à un répertoire. Dans mon cas, *:/download/*/* était un critère d’évaluation valide, mais *:/download/*/*/ ne l’était pas, à cause de la barre oblique finale.

Cette configuration par défaut inclut une liste blanche d’adresses IP pour localhost, que vous devrez commenter si vous effectuez des tests. Mais, vous devriez pouvoir tester votre configuration en définissant une limite très basse, comme 5 par minute, et en faisant un tas de requêtes. Vous devriez obtenir cette erreur « Quota d’appels d’API dépassé », ce qui signifie qu’elle fonctionne correctement.

Il y a beaucoup plus que ce package peut faire, donc si vous avez des besoins plus spécifiques que cela, nous vous recommandons de consulter leur documentation et de voir ce qui est possible.