Si está creando una API o un portal 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 sencillo 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 determinar algún tipo de límite de velocidad, debido a que 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 determinar un límite razonable es una buena idea.
Decididamente, su proveedor de nube además puede tener protección DDoS. Esto de forma general protegerá bien contra los ataques de Capa 3 y 4 dirigidos a su servidor. A pesar de esto, querrá asegurarse de que su servidor haga todo lo factible para evitar que los atacantes accedan a él.
Además tiene la opción de determinar el límite mucho más bajo para limitar las solicitudes en las API públicas. A modo de ejemplo, tal vez un determinado punto final requiera mucho procesamiento para responder a la solicitud. Es factible que desee limitar este punto final para que ninguna dirección IP pueda llevar a cabo 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 eso, 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. A pesar de esto, 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 alternativas para realizar la limitación de velocidad. Si está usando una API que necesita claves, le sugerimos 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. Además querrá agregar la memoria caché de Microsoft si aún no lo ha hecho. Después, deberá configurar IpRateLimiting desde el archivo JSON y después 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>();
Además en Startup.cs, deberá configurar el generador de aplicaciones para usar la limitación de velocidad de IP.
app.UseIpRateLimiting();
Tenga en cuenta que esto utiliza una limitación de velocidad en memoria, que es por instancia. Si está equilibrando la carga de su aplicación, deberá utilizar 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 próxima:
"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 distinto, querrá activar EnableEndpointRateLimiting, que es falso de forma predeterminada.
StackBlockedRequests hará que las solicitudes bloqueadas cuenten para el contador. Simplemente, 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 después no serán respondidas además.
RealIpHeader y ClientIdHeader se usan 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, caso contrario, el limitador de velocidad tratará a todos como la misma IP.
Después, hay tres listas blancas, una para IP, ID de cliente y puntos finales. Puede eliminarlos si no los necesita.
Después, 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 establecer 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 sugerimos revisando su documentación y viendo lo que es factible.
