Se você estiver criando uma API ou um portal público da web, você provavelmente está preocupado com o desempenho. A limitação de velocidade pode ajudar a prevenir o abuso de ataques DDoS básicos, e é bastante simples de configurar para aplicativos Blazor / ASP.NET Core.
Por que as solicitações de limite de taxa?
Existem muitas razões para qualificar os pedidos de limite. A maioria dos serviços provavelmente deve definir algum tipo de limite de velocidade, porque nenhum ser humano razoável vai realizar 100 solicitações por segundo por dez minutos consecutivos. Por padrão, seu aplicativo responderá a todas as solicitações, então determinar um limite razoável é uma boa ideia.
Decididamente, seu provedor de nuvem também pode ter proteção DDoS. Isso geralmente protegerá bem contra ataques de camuflagem. 3 e 4 direcionado para o seu servidor. Apesar disto, você vai querer ter certeza de que seu servidor faz tudo o que pode para impedir que invasores o acessem.
Além disso, você tem a opção de definir o limite muito mais baixo para limitar as solicitações em APIs públicas. Como um exemplo, talvez um determinado endpoint exija muito processamento para responder à solicitação. Você pode querer limitar este endpoint para que nenhum endereço IP possa realizar mais do que algumas solicitações a cada dois segundos, que limita o estresse em seu servidor / base de dados.
Definindo limite de velocidade no ASP.NET Core
O Blazor como uma estrutura é baseado no ASP.NET Core, que lida com todos os procedimentos internos para executar um servidor HTTP e responder às solicitações. Por isso, você precisará configurar a limitação de taxa para ASP.NET Core. As mesmas etapas se aplicam a qualquer pessoa que não use o Blazor.
Infelizmente, limite de velocidade não é um recurso padrão no ASP.NET Core. Apesar disto, existe um pacote NuGet muito popular, AspNetCoreRateLimit, isso faz o trabalho muito bem. Você pode instalá-lo clicando com o botão direito do mouse em seu projeto no Visual Studio e selecionando “Gerenciar pacotes NuGet …”:
Olhe para AspNetCoreRateLimit e instale-o.
Existem algumas alternativas para limitação de velocidade. Se você estiver usando uma API que precisa de chaves, sugerimos que você limite a taxa com base na chave API, cobrindo todos os casos. Para a maioria das pessoas, limitação de velocidade com base no endereço IP provavelmente é adequada, e é o valor padrão recomendado por AspNetCoreRateLimit.
Você precisará adicioná-lo como um serviço ao ASP.NET. Todos os serviços são configurados em Startup.cs, que os adiciona com o ConfigureServices(IServiceCollection services) Função.
Existem alguns serviços para configurar. A primeira função configura os serviços para carregar as configurações de seu arquivo de configuração. Você também desejará adicionar o cache da Microsoft, caso ainda não o tenha feito.. Depois de, você precisará configurar IpRateLimiting do arquivo JSON e, em seguida, adicionar o limitador de taxa.
// necessário para carregar a configuração de appsettings.json Serviços.AddOptions(); // necessário para armazenar contadores de limite de taxa e regras de IP Serviços.AddMemoryCache(); //carregar a configuração geral de appsettings.json Serviços.Configurar(Configuração.GetSection("IpRateLimiting")); // injetar contador e armazenamentos de regras Serviços.AddInMemoryRateLimiting(); // configuração (resolvedores, construtores de contra-chave) Serviços.AddSingleton<IRateLimitConfiguration, RateLimitConfiguration>();
Também em Startup.cs, você precisará configurar o construtor de aplicativos para usar limitação de taxa de IP.
app.UseIpRateLimiting();
Observe que isso usa uma limitação de velocidade de memória, o que é por exemplo. Se você estiver balanceando a carga de seu aplicativo, você precisará usar um armazenamento de memória distribuída como o Redis, do que este pacote também tem suporte para.
Configurações de limitação de velocidade
Depois de adicionado ao ASP.NET, você deveria ir para o seu appsettings.json arquivo de configuração para configurá-lo. A configuração se parece com a próxima:
"IpRateLimiting": {
"EnableEndpointRateLimiting": falso,
"StackBlockedRequests": verdade,
"RealIpHeader": "X-Real-IP",
"ClientIdHeader": "X-ClientId",
"HttpStatusCode": 429,
"IpWhitelist": [ "127.0.0.1", "::1/10", "192.168.0.0/24" ],
"EndpointWhitelist": [ "pegue:/api / licença", "*:/api / status" ],
"ClientWhitelist": [ "dev-id-1", "dev-id-2" ],
"Regras gerais": [
{
"Endpoint": "*",
"Período": "1s",
"Limite": 2
},
{
"Endpoint": "*",
"Período": "15m",
"Limite": 100
},
{
"Endpoint": "*",
"Período": "12h",
"Limite": 1000
},
{
"Endpoint": "*",
"Período": "7d",
"Limite": 10000
}
]
}
Em primeiro lugar, se você planeja limitar a taxa de certos endpoints de forma diferente, você vai querer habilitar EnableEndpointRateLimiting, que é falso por padrão.
StackBlockedRequests fará com que as solicitações bloqueadas contem para o contador. Simplesmente, com isso desativado, qualquer pessoa que fizer solicitações repetidamente receberá X respostas por período. Com ele ativado, as respostas máximas aumentarão muito rapidamente e não serão respondidas posteriormente.
RealIpHeader e ClientIdHeader são usados quando seu servidor está atrás de um proxy reverso, que é uma configuração comum. Uma vez que as solicitações sempre virão do servidor proxy, o proxy define um cabeçalho com as informações reais do usuário. Você precisará verificar o seu proxy e certificar-se de que este cabeçalho está configurado corretamente, caso contrário, o limitador de velocidade tratará todos como o mesmo IP.
Depois de, existem três listas brancas, um para IP, ID do cliente e endpoints. Você pode excluí-los se não precisar deles.
Depois de, você precisará configurar cada endpoint, bem como um período e um limite. Um curinga irá cobrir tudo e é a única coisa que funciona com EnableEndpointRateLimiting definido como falso. Sim, não é assim, você pode definir pontos de extremidade usando {HTTP_VERB}{PATH}, incluindo curingas, pelo que *:/api/values vai corresponder a todas as solicitações GET e POST para /api/values.
Você vai querer ter certeza de que seu ponto final corresponde a um arquivo e não um diretório. No meu caso, *:/download/*/* era um ponto final válido, mas *:/download/*/*/ Não foi., devido ao bar no final.
esta configuração padrão inclui uma lista branca ip para localhost, que você vai precisar comentar se você está fazendo testes. Mas, você deve ser capaz de testar sua configuração definindo o limite muito baixo, O que 5 por minuto, e fazer um monte de pedidos. você deve receber este erro, “Cota de chamadas da API ultrapassada”, o que significa que está funcionando corretamente.
Há muito mais que este pacote pode fazer, então, se você tiver necessidades mais específicas do que isso, nós sugerimos checando sua documentação e vendo o que é viável.
