Cómo calificar las solicitudes de límite en Blazor / ASP.NET Core – CloudSavvy IT

Si está creando una API o un sitio web público, probablemente esté preocupado por el rendimiento. La limitación de velocidad puede ayudar a prevenir el abuso de los ataques DDoS básicos, y es bastante fácil de configurar para aplicaciones Blazor / ASP.NET Core.

¿Por qué las solicitudes de límite de tarifas?

Hay muchas razones para calificar las solicitudes de límite. La mayoría de los servicios probablemente deberían establecer algún tipo de límite de velocidad, porque ningún humano razonable va a realizar 100 solicitudes por segundo durante diez minutos seguidos. De forma predeterminada, su aplicación responderá a todas las solicitudes, por lo que establecer un límite razonable es una buena idea.

Por supuesto, su proveedor de nube también puede tener protección DDoS. Esto generalmente protegerá bien contra los ataques de Capa 3 y 4 dirigidos a su servidor. Sin embargo, querrá asegurarse de que su servidor haga todo lo posible para evitar que los atacantes accedan a él.

También tiene la opción de establecer el límite mucho más bajo para limitar las solicitudes en las API públicas. Por ejemplo, tal vez un determinado punto final requiera mucho procesamiento para responder a la solicitud. Es posible que desee limitar este punto final para que ninguna dirección IP pueda realizar más de unas pocas solicitudes cada dos segundos, lo que limita el estrés en su servidor / base de datos.

Configuración de la limitación de velocidad en ASP.NET Core

Blazor como marco se basa en ASP.NET Core, que maneja todas las cosas internas para ejecutar un servidor HTTP y responder a las solicitudes. Por lo tanto, deberá configurar la limitación de velocidad para ASP.NET Core. Los mismos pasos se aplicarán a cualquiera que no utilice Blazor.

Desafortunadamente, la limitación de velocidad no es una característica predeterminada en ASP.NET Core. Sin embargo, hay un paquete NuGet muy popular, AspNetCoreRateLimit, que hace el trabajo bastante bien. Puede instalarlo haciendo clic derecho en su proyecto en Visual Studio y seleccionando «Administrar paquetes NuGet …»:

Buscar AspNetCoreRateLimit e instalarlo.

Hay algunas formas de realizar la limitación de velocidad. Si está utilizando una API que necesita claves, le recomendamos que limite la tasa en función de la clave de API, que cubre todos los casos. Para la mayoría de las personas, la limitación de velocidad basada en la dirección IP probablemente esté bien, y es el valor predeterminado recomendado por AspNetCoreRateLimit.

Deberá agregarlo como un servicio a ASP.NET. Todos los servicios están configurados en Startup.cs, que los agrega con el ConfigureServices(IServiceCollection services) función.

Hay bastantes servicios para configurar. La primera función configura los servicios para cargar configuraciones desde su archivo de configuración. También querrá agregar la memoria caché de Microsoft si aún no lo ha hecho. Luego, deberá configurar IpRateLimiting desde el archivo JSON y luego agregar el limitador de velocidad.

            // 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>();

También en Startup.cs, deberá configurar el generador de aplicaciones para utilizar la limitación de velocidad de IP.

app.UseIpRateLimiting();

Tenga en cuenta que esto usa una limitación de velocidad en memoria, que es por instancia. Si está equilibrando la carga de su aplicación, deberá usar un almacén de memoria distribuida como Redis, que este paquete también tiene soporte para.

Configuración de la limitación de velocidad

Una vez que se agrega a ASP.NET, deberá dirigirse a su appsettings.json archivo de configuración para configurarlo. La configuración se parece a la siguiente:

"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
      }
    ]
  }

En primer lugar, si planea limitar la tasa de ciertos puntos finales de manera diferente, querrá activar EnableEndpointRateLimiting, que es falso de forma predeterminada.

StackBlockedRequests hará que las solicitudes bloqueadas cuenten para el contador. Básicamente, con esto desactivado, cualquier persona que realice solicitudes una y otra vez recibirá X respuestas por período. Con él activado, aumentarán las respuestas máximas muy rápidamente y luego no serán respondidas también.

RealIpHeader y ClientIdHeader se utilizan cuando su servidor está detrás de un proxy inverso, que es una configuración común. Dado que las solicitudes siempre vendrán del servidor proxy, el proxy establece un encabezado con la información real del usuario. Deberá verificar su proxy y asegurarse de que este encabezado esté configurado correctamente, de lo contrario, el limitador de velocidad tratará a todos como la misma IP.

Luego, hay tres listas blancas, una para IP, ID de cliente y puntos finales. Puede eliminarlos si no los necesita.

Luego, deberá configurar cada punto final, así como un período y un límite. Un comodín cubrirá todo y es lo único que funciona con EnableEndpointRateLimiting establecido en falso. Si no es así, puede definir puntos finales usando {HTTP_VERB}{PATH}, incluidos los comodines, por lo que *:/api/values coincidirá con todas las solicitudes GET y POST para /api/values.

Querrá asegurarse de que su punto final coincida con un archivo y no con un directorio. En mi caso, *:/download/*/* era un criterio de valoración válido, pero *:/download/*/*/ no lo era, debido a la barra al final.

Esta configuración predeterminada incluye una lista blanca de IP para localhost, que deberá comentar si está realizando pruebas. Pero, debería poder probar su configuración estableciendo el límite muy bajo, como 5 por minuto, y haciendo un montón de solicitudes. Debería aparecer este error, «Se superó la cuota de llamadas a la API», lo que significa que está funcionando correctamente.

Hay mucho más que este paquete puede hacer, por lo que si tiene necesidades más específicas que esta, le recomendamos revisando su documentación y viendo lo que es posible.

Deja un comentario

En esta web usamos cookies para personalizar tu experiencia de usuario.    Política de cookies
Privacidad