Tráfego de rede de entrada e saída alto

Question

Ao longo do último dia, uma das instâncias teve uma grande quantidade de largura de banda consumida. Isso significa que quase excedemos nossa permissão (aproximadamente a mesma quantidade de entrada e saída).

Olhando os logs, a única coisa que consigo ver são muitos e muitos erros de 400 172 no nginx access.log com a mesma string de texto.

Alterei o nginx para uma porta diferente, implementei o fail2ban, mas como o tráfego está vindo de IPs diferentes, isso não está funcionando. Eu também tenho o nosso provedor de VPS para mudar o IP do nosso VPS.

O Fail2ban está atualmente descartando todas as conexões para a porta 80, o que não é o ideal, pois gostaríamos de usar essa porta.

Existe alguma coisa que podemos fazer para melhorar a situação? Se deixarmos cair tráfego suspeito, isso ainda conta para nossa mesada?

Mais informações

Eu consegui obter mais detalhes alterando o nível de log de erros do nginx.

O único erro que parece estar ocorrendo é que o cleint enviou uma solicitação inválida ao ler a linha de solicitação do cliente.

O domínio é novo e não foi usado antes (é um novo subdomínio em um dos domínios existentes de longo prazo).

Verificarei se está usando o mesmo caminho.

Existe também alguma razão pela qual o seu crescente tráfego de outboubd é apenas porque os pacotes de entrada estão sendo bloqueados?

    

Answer 1

Em geral, qualquer tráfego que chegue até você ou que chegue ao gateway (quando enviado pelo host) conta contra o limite de largura de banda. Isso é verdadeiro mesmo se a atividade for insubstancial ou consistir apenas em tráfego bloqueado pelo firewall do host.

Eliminar o tráfego malicioso o mais rapidamente possível é o ideal. No entanto, parece que você pode ter um problema envolvendo um plano de hospedagem que tenha grande largura de banda, mas pequenas cotas de transferência. Você está enfrentando um problema fundamental com esses planos, se esse for o caso.

O que você faz daqui depende de como é o tráfego. Se forem apenas alguns hosts, considere o bloqueio desses hosts usando o firewall do provedor de VPS, se eles disponibilizarem essa opção. Se for um robô do mecanismo de pesquisa, adicione um robots.txt que os proíbe de rastrear qualquer caminho que esteja gerando os erros.

172 nos seus registros não é parte do código de erro - essas linhas significam apenas que o servidor retornou o código de erro 400 Bad Request e a página de erro que ele retornou tinha 172 bytes de comprimento.

Como é o erro 400, provavelmente não é um mecanismo de pesquisa (a menos que você esteja executando um estranho aplicativo CGI), mas sem saber qual foi a string de consulta (incluindo o método), é difícil dizer o que está acontecendo. Mas tente abordá-lo com base no que parece que o "atacante" está tentando fazer.

É improvável que o bloqueio das solicitações no nginx mude muito.

Em vez disso, você pode considerar o bloqueio dessas solicitações na camada de rede, deixando de ofender o tráfego; Isso significa que o originador do tráfego acabará com um monte de conexões abertas. Se a velocidade não mudar, as probabilidades são razoavelmente boas, é malicioso. Você pode considerar enviar uma reclamação de abuso para o ISP de origem se tudo for proveniente da mesma rede e parecer uma inundação em vez de um processo automatizado tentando fazer alguma coisa. Pode ser tão simples quanto alguém ter tido seu nome de domínio antes de você.

    

Answer 2

Sem saber sobre o seu provedor de hospedagem, não posso dar uma resposta definitiva sobre se as solicitações negadas contam para o seu subsídio, mas, em geral, se ele atingir sua instância do servidor, isso geralmente é contado.

O uso do fail2ban é definitivamente recomendado nessa circunstância. Garantir que você está descartando os pacotes de entrada e não negá-los significa que você não deve ver nenhum aumento no tráfego de saída na forma de pacotes ICMP 'Conexão recusada'.

Existe algum padrão nas solicitações recebidas? Eles são todos de um bloco específico do CIDR ou são solicitações de um URL específico? Isso é uma URL legítima em seu website ou uma string aleatória?

• Se for o mesmo URL toda vez, sugiro bloquear essas solicitações no Nginx, se você ainda não tiver feito isso.

• Se for um bloco CIDR de origem específico que seja razoavelmente pequeno, você pode simplesmente descartar todas as conexões desses endereços.

Parece que você está sendo DDoS. Este artigo do Server Fault fornece excelentes conselhos: Estou sob DDoS. O que posso fazer?