Boa noite povo!
Vimos, no versículo anterior, a terceira parte da tradução de “Hashcash – A Denial of Service Counter-Measure”, continuamos hoje com a parte 4.
4 Hashcash Interativo
Com a forma interativa do hashcash, para uso em configurações interativas tais como o estabelecimento de conexões TCP, TLS, SSH, IPSEC, etc, um desafio é escolhido pelo servidor. O objetivo do hashcash interativo é defender os recursos do servidor de esgotamento prematuro, e prover uma degradação graciosa do serviço com alocação justa entre usuários em face a um ataque DoS onde um usuário tenta negar serviço a outros usuários consumindo tanto recurso do servidor quanto ele puder. No caso de protocolos de segurança tais como TLS, SSH e IPSEC com fases de estabelecimento de conexões caras computacionalmente envolvendo criptografia de chave pública, o recurso do servidor sendo defendido é o tempo de CPU disponível.
A função-custo do hashcash interativo é definida como segue:
4.1 Restrição Dinâmica
Com o hashcash interativo se torna possível ajustar dinamicamente o fator de trabalho requerido por um cliente baseado na carga de CPU do servidor. A abordagem também admite a possibilidade de que a resposta ao desafio do hashcash interativo seja usada apenas durante períodos de alta carga. Isso torna possível a introdução gradual de protocolos resistentes ao DoS sem interromper a compatibilidade retroativa com o software cliente antigo. Em períodos de alta carga os clientes que não usam hashcash não conseguiriam conectar, ou seriam colocados em uma pool de conexão limitada sujeitos a contramedidas para DoS antigas e menos efetivas como quedas aleatórias de conexão.
4.2 Cookies-hashcash
Com ataques de esgotamento do slot de conexão, como o ataque syn-flood [de inundação de sincronização], e o esgotamento direto do slot de conexão TCP, o recurso do servidor que está sendo consumido é o espaço disponível para o stack [pilha] TCP para armazenar o estado por conexão.
Nesse cenário pode ser desejável evitar manter o estado por conexão, até que o cliente tenha computado um token com a função-custo do hashcash interativo. Essa defesa é similar à defesa syn-cookie ao ataque syn-flood, mas aqui propomos a impor adicionalmente um custo de CPU na máquina de conexão para reservar um slot de conexão TCP.
Para evitar o armazenamento do desafio no estado da conexão (que consome espaço), o servidor pode optar por calcular uma MAC [autenticador de mensagem, na sigla em inglês] com chave das informações que, de outra forma, armazenaria e as enviaria ao cliente como parte do desafio, para ele poder verificar a autenticidade do desafio e o token quando o cliente os retorna. (Essa técnica geral – de enviar um registro que você armazenaria junto com uma MAC à entidade sobre a qual a informação se refere – é referido como certificado de chave simétrica.) Essa abordagem é análoga à técnica usada na syn-cookies, e Jules e Brainard propuseram uma abordagem relacionada, mas no nível do protocolo de aplicação, em seu artigo sobre quebra-cabeças de clientes.
Por exemplo, com a função MAC M com a chave K do servidor o desafio MAC poderia ser computado como:
O cliente deve mandar o m da MAC, e o desafio c e os parâmetros do desafio p com o token de resposta para que o servidor possa verificar o desafio e a resposta. O servidor deve também incluir na MAC os parâmetros da conexão, no mínimo o suficiente para identificar o slot de conexão e alguma medida de tempo ou aumento do contador t para que respostas antigas de desafio não possam ser coletadas e reutilizadas depois que os slots de conexão estiverem livres. O desafio e a MAC seriam enviados na mensagem de resposta TCP SYN-ACK e o cliente incluiria o token do hashcash interativo (resposta do desafio) na mensagem TCP ACK. Assim como com os syn-cookies, o servidor não precisaria manter nenhum estado por conexão antes de receber o TCP ACK.
Para compatibilidade com versões anteriores com pilhas TCP com reconhecimento de syn-cookies, uma pilha TCP com reconhecimento de cookie-hashcash apenas ativaria os cookies-hashcash quando detectasse que estivesse sujeito a um ataque de esgotamento de conexão TCP. Argumentos semelhantes como dados por Dan Bernstein em [5] pode ser usados para mostrar que a compatibilidade com versões anteriores é mantida, isso é, sob ataques syn-flood, os argumentos de Bernstein mostram como prover compatibilidade retroativa com implementações que não reconhecem syn-cookies; similarmente sob um ataque de esgotamento de conexão os cookies-hashcash são apenas ativados em um momento em que, caso contrário, o serviço não estaria disponível de qualquer forma para uma pilha TCP que não reconhece cookies-hashcash.
A medida em que o flood aumenta em gravidade, o algoritmo do cookie-hashcash aumentaria o tamanho da colisão necessária para estar na mensagem TCP ACK. O cliente com reconhecimento de cookie-hashcash ainda pode se conectar (embora cada vez mais devagar) com uma chance mais justa contra o atacante DoS, presumindo que o DoSer tenha recursos de CPU limitados. O atacante DoS vai efetivamente estar colocando seu CPU contra todos os outros clientes (que reconhecem os cookies-hashcash) também tentando conectar. Sem a defesa do cookie-hashcash o DoSer pode floodar [inundar] o servidor com estabelecimentos de conexão e pode mais facilmente amarrar todos seus slots concluindo n conexões por tempo limite de conexão inativa em que n é o tamanho da tabela de conexões, ou fazendo ping das conexões uma vez que o tempo limite de conexão inativa seja atingido para convencer o servidor de que elas estão vivas.
As conexões serão entregues aos usuários coletivamente na proporção aproximada de seus recursos de CPU, então a justiça é baseada nos recursos de CPU (presumindo-se que cada usuário estaria tentando abrir quantas conexões fossem possíveis), então o resultado será enviesado a favor dos clientes com processadores velozes já que eles podem computar mais tokens de resposta do desafio do hashcash interativo por segundo.
[5] Dan Bernstein. Syn cookies. Publicado em http://cr.yp.to/syncookies.html.Vista a quarta parte, no versículo seguinte a quinta. Abraços!
