Hacktivistas atingem sites governamentais em ataques DDoS ‘Slow HTTP’. CSIRT italiano divulgou recentes ataques DDoS contra sites governamentais cruciais no país nos últimos dois dias.
DDoS (negação de serviço distribuído) é um ataque que visa esgotar os recursos disponíveis de um servidor, tornando-o incapaz de responder a solicitações legítimas de usuários e tornando os sites que hospeda inacessíveis.
O Equipe de Resposta a Incidentes de Segurança de Computadores da Itália (CSIRT) divulgou que Hacktivistas pró-Rússia conhecidos como o grupo Killnet reivindicaram a responsabilidade pelos ataques e são o mesmo grupo que lançou ataques semelhantes contra portais romenos e o Aeroporto Bradley nos EUA.
Em resposta às notícias sobre os ataques DDoS contra a Itália, a Killnet publicou uma mensagem ao Telegram afirmando que outros ataques podem estar chegando no futuro.
“Nossa Legião realiza exercícios cibernéticos militares em seus países para melhorar suas habilidades. Tudo acontece de maneira semelhante às suas ações – os italianos e os espanhóis vão aprender a matar pessoas na Ucrânia. Nossa Legião está aprendendo a matar seus servidores!, ” um representante da Killnet postou em seu canal do Telegram.
“Você deve entender que isso é treinamento. Não faça muito barulho, estou cansado da quantidade de notícias sobre ataques ao Senado. Dou-lhe minha palavra de honra que nosso exército cibernético em breve terminará o treinamento em seu território , e partiremos para a ofensiva. Isso acontecerá de repente e muito rapidamente.“
O CSIR diz que relativamente aos recentes ataques DDOS ocorridos a partir de 11 de maio último contra sujeitos nacionais e internacionais, verificou-se que foram realizados com recurso a técnicas que diferem dos ataques DDOS mais comuns de tipo volumétrico, passando assim despercebido aos sistemas de protecção comumente usados no mercado contra esse tipo de ataque, pois ocorrem usando uma largura de banda limitada.
Essas técnicas de DDOS, definidas como um tipo de aplicação, visam saturar os recursos dos sistemas que fornecem os serviços, incluindo servidores web. Neste caso específico, foi constatado o uso da chamada técnica “Slow HTTP” que, via de regra, utiliza requisições HTTP GET para saturar as conexões disponíveis de um servidor web. Em particular, quando um cliente faz uma solicitação HTTP para um servidor web, o mesmo libera a conexão somente quando o cabeçalho da solicitação recebida estiver completo. Ao enviar inúmeras solicitações com velocidades de transmissão muito baixas, o invasor força o servidor web de destino a manter a conexão aberta, saturando os recursos dedicados pelo servidor à comunicação com clientes externos. Este tipo de ataque é mais eficaz no caso de utilizar requisições POST, pois também são utilizadas para enviar quantidades consideráveis de dados ao servidor web.
Operação
Um invasor tem a capacidade de abrir várias conexões com servidores web enviando uma sequência de solicitações GET/POST contendo dados fictícios até que o tempo limite definido seja atingido. Cada uma dessas solicitações aloca e ocupa um recurso do lado do servidor. Quando o limite máximo de recursos disponíveis é atingido (dependendo da tecnologia utilizada), o servidor não consegue mais responder ao tráfego legítimo, tornando o serviço indisponível. Este tipo de ataque permite saturar os recursos de um servidor web utilizando uma largura de banda reduzida. Isso gera as dificuldades de detecção mencionadas, considerando que os sistemas de detecção de intrusão (IDS) podem avaliar solicitações HTTP como legítimas.
Analisando uma solicitação HTTP GET de tráfego legítimo, podemos observar a presença de CRLF ( Carriage Return + Line Feed ), uma sequência de caracteres não imprimíveis que é utilizada para indicar o fim de uma linha. O servidor interpreta a presença do CRLF como o fim da comunicação com o cliente e, portanto, libera os recursos que havia dedicado a essa comunicação, disponibilizando-os para novas comunicações. O tráfego gerado pelo ataque cria uma sequência de solicitações HTTP GET que não contém o caractere CRLF. Em seguida, o servidor manterá a sessão ativa sem liberar os recursos até que o tempo limite seja atingido.
Identificação
Para determinar a natureza do ataque, é necessário inspecionar o tráfego HTTP registrado nos logs do servidor, identificando quaisquer elementos comuns entre as requisições reconhecidas como maliciosas. Dependendo da configuração em uso, você pode continuar usando o comando tcpdump (se o tráfego estiver criptografado, a captura de tráfego deverá ser descriptografada para visualizar os dados em texto não criptografado) ou os logs do servidor web.
Ações gerais de mitigação
Sem prejuízo da possibilidade de equipar-se com sistemas de proteção adequados contra ataques DDOS volumétricos, para proteger os seus sistemas de ataques de aplicação do tipo “HTTP lento”, é aconselhável aplicar as seguintes ações de mitigação:
- rejeitar conexões com métodos HTTP não suportados pela URL;
- limitar o cabeçalho e o corpo da mensagem a um comprimento mínimo razoável. Para URLs específicos, defina limites mais rígidos e apropriados para cada recurso que aceita um corpo de mensagem;
- defina um tempo limite de conexão absoluto, sempre que possível, usando estatísticas de conexão (por exemplo, um tempo limite ligeiramente maior que a duração média da conexão deve satisfazer a maioria dos clientes legítimos);
- use uma lista de pendências de conexões pendentes. Ele permite que o servidor mantenha conexões que não está pronto para aceitar, bloqueando assim um ataque HTTP lento maior, além de dar aos usuários legítimos a capacidade de serem atendidos sob alta carga. Se o seu servidor suporta um backlog, é recomendado que você o torne razoavelmente grande para que seu servidor web possa lidar com um ataque menor;
- defina a velocidade mínima dos dados de entrada e bloqueie as conexões que são mais lentas que a velocidade definida. Observe para ter cuidado para não definir o valor mínimo muito baixo para não bloquear conexões legítimas;
- ativar as ferramentas de proteção contra esse tipo de ataque disponíveis por meio de dispositivos de segurança como Web Application Firewall e Next Generation Firewall L7.
Ações de mitigação específicas do produto
A seguir estão as principais medidas a serem tomadas para prevenir e mitigar ataques HTTP lentos contra os principais servidores web atualmente em uso:
Apache
- usar as diretivas Limit e LimitExcept para descartar solicitações com métodos não suportados apenas pela URL não ajuda, porque o Apache espera que a solicitação inteira seja concluída antes de aplicar essas diretivas. Portanto, use esses parâmetros em conjunto com as diretivas LimitRequestFields, LimitRequestFieldSize, LimitRequestBody, LimitRequestLine, LimitXMLRequestBody conforme apropriado. Por exemplo, é improvável que o aplicativo da Web exija um cabeçalho de 8.190 bytes, tamanho de corpo ilimitado ou 100 cabeçalhos por solicitação, como a maioria das configurações padrão;
- defina valores para as diretivas TimeOut e KeepAliveTimeOut que sejam razoáveis (por exemplo, o valor padrão de 300 segundos para TimeOut é excessivo para a maioria das situações);
- aumente o valor padrão da diretiva ListenBackLog , útil quando o servidor não pode aceitar conexões com rapidez suficiente;
- aumente a diretiva MaxRequestWorkers para permitir que o servidor lide com o número máximo de conexões simultâneas;
- ajustar a diretiva AcceptFilter , que é suportada no FreeBSD e Linux, e habilitar otimizações específicas do SO para um socket de escuta baseado no tipo de protocolo (por exemplo, o filtro httpready Accept armazena em buffer todas as solicitações HTTP no nível do kernel );
- considere o uso de módulos como mod_reqtimeout para controlar aspectos como tempo limite e taxa mínima de dados para solicitações recebidas.
Nginx
- limite os métodos aceitos verificando a variável $ request_method ;
- definir no modo apropriado os parâmetros client_max_body_size, client_body_buffer_size, client_header_buffer_size, large_client_header_buffers ;
- defina os parâmetros client_body_timeout, client_header_timeout para valores razoavelmente baixos.
- considere usar HttpLimitReqModule e HttpLimitZoneModule para limitar o número de solicitações ou o número de conexões simultâneas para uma determinada sessão;
- configure worker_processes e worker_connections com base na contagem de CPU / núcleo, conteúdo e carga. A fórmula a ser usada é max_clients = worker_processes * worker_connections .
lighttpd
- limitar os métodos de solicitação usando o campo $ HTTP [“request-method”] no arquivo de configuração do módulo principal (disponível a partir da versão 1.4.19);
- use o parâmetro server.max_request-size para limitar o tamanho de toda a solicitação, incluindo cabeçalhos;
- defina o parâmetro server.max-read-idle para um valor mínimo razoável para que o servidor feche conexões lentas.
IIS
- limitar os atributos da solicitação através do uso do elemento <RequestLimits>, em particular os atributos maxAllowedContentLength, maxQueryString e maxUrl ;
- defina o elemento <headerLimits> para configurar o tipo e tamanho do cabeçalho que seu servidor web pode aceitar;
- Otimize os atributos connectionTimeout, headerWaitTimeout e minBytesPerSecond dos elementos <limits> e <WebLimits> para minimizar o impacto de ataques HTTP lentos.
Outros produtos
No caso de utilização de produtos específicos, é aconselhável consultar a documentação emitida pelo respectivo fornecedor.
Fonte: BleepingComputer & CSIRT Itália & Qualys
Veja também:
- iPhones ainda que desligados podem executar Malwares
- Acrônimos de segurança cibernética – um glossário prático
- Air gapping (air gap attack)
- Fortinet lança novo conjunto de FortiGate Network Firewalls
- Ciberataque persistente a Costa Rica pode ser prenuncio de ataque global
- Como implementar Gestão de vulnerabilidades na empresa?
- Google, Microsoft e Apple querem implantar logins sem as credenciais
- Por que o ciber é a evolução da guerra?
- Alexa é “solução de escuta ativa” de vigilância
- Como proteger a sua privacidade?
- Educação é um dos três setores mais visados por cibercriminosos
- Ransomcloud: a última geração de ransomware tem como alvo a nuvem
Deixe sua opinião!