Obtendo 408 erros em nossos logs sem solicitação ou agente de usuário


Respostas:


29

Por acaso, você está executando seus servidores Web na Amazon atrás de um Elastic Load Balancer?

Parece que eles geram muitas 408 respostas devido a seus exames de saúde .

Algumas das soluções desse tópico do fórum:

  • RequestReadTimeout header=0 body=0

    Isso desativa as 408 respostas se um pedido atingir o tempo limite.

  • Altere a verificação de integridade do ELB para uma porta diferente.
  • Desative o log para os endereços IP ELB com:

    SetEnvIf Remote_Addr "10\.0\.0\.5" exclude_from_log
    CustomLog logs/access_log common env=!exclude_from_log
    

E a partir desta postagem no blog :

  • Ajuste o tempo limite da solicitação para 60 ou mais.

2
No meu entendimento isso irá expô-lo ao ataque slowloris, ter um reqtimeout decente parece ser útil hoje em dia para qualquer pessoa usando apache
neofutur

Se você está atrás de um ELB, slowloris não é um problema.
Ladadadada

2
RequestReadTimeout header=0 body=0iria desativar pedido de leitura de tempo limite, todos juntos, eu não recomendo este
mikejonesey

@Ladadadada Acho que você ainda precisa de proteção lenta do loris, pois o http funciona como um proxy tcp, https se descarregado encaminhará solicitações http em vez de tcp, no entanto, não há filtros para conexões lentas, existe apenas um tempo limite para a resposta.
Mikejonesey

@Ladadadada você está errado, ELB ou ALB faz pouco ou nada para ajudar contra o slowloris e isso afetará a maioria dos servidores Web, veja minha pergunta e problema da AWS aqui: forums.aws.amazon.com/thread.jspa?threadID=269176
Cristiano Coelho

9

Algo está se conectando à porta e nunca mais enviando dados. HTTP 408 é um erro de "tempo limite". Há uma boa descrição aqui: http://www.checkupdown.com/status/E408.html


1
Embora esse link possa responder à pergunta, é melhor incluir aqui as partes essenciais da resposta e fornecer o link para referência. As respostas somente para links podem se tornar inválidas se a página vinculada for alterada.
kasperd

Tendo acabado de pesquisar uma lista de mais de 100 IPs que recebem 408s em seus pedidos vazios, é notável que a maioria é da China continental e eu suspeito que o problema esteja principalmente relacionado ao congestionamento. O congestionamento resultando em uma configuração de conexão bem-sucedida, mas o cabeçalho da solicitação não sendo enviado. A largura de banda entre fronteiras da China está muito sobrecarregada e as conexões não continentais que também chegavam vazias foram uma dispersão do Brasil, Europa e EUA rural, que plausivelmente têm problemas semelhantes ao chegar a um servidor da Costa Oeste dos EUA.
ClearCrescendo

8

Já existem algumas boas respostas aqui, mas eu gostaria de arriscar uma nota adicional que não foi especificamente abordada. Como muitos dos comentadores anteriores já mencionaram, 408 indica um tempo limite; e há uma variedade de circunstâncias nas quais ocorrem tempos limite em um servidor da web.

Com isso dito, 408 erros podem ser gerados em vários casos em que seu servidor está sendo verificado quanto a explorações. Os clientes nesses casos raramente apresentam um agente de usuário e frequentemente encerram conexões abruptamente, resultando em um desligamento abortivo dessa conexão que pode gerar um erro 408.

Por exemplo, digamos que sou um hacker covarde que está pesquisando na Internet computadores que ainda estão vulneráveis ​​à vulnerabilidade do POODLE. Como tal, escrevi um script que abre conexões para grandes blocos de endereços IP para encontrar servidores que aceitarão a versão 3 do SSL - posteriormente, usarei essa lista para verificar especificamente a exploração do POODLE. Tudo o que esse primeiro script faz é estabelecer uma conexão usando o openssl para verificar o SSLv3, assim:

openssl s_client -connect [IP]:443 -ssl3

Esse comando, em muitas configurações do Apache, resultará em uma mensagem 408 exatamente como você descreveu. Executar este comando em dois de meus próprios servidores resultou nessa entrada no log de acesso:

<remote IP address>  - - [04/Nov/2015:08:09:33 -0500] "-" 408 - "-" "-"

Eu queria deixar isso claro, mesmo em uma situação em que o OP não estava usando nenhuma forma de balanceamento de carga, os erros 408 podem ocorrer em várias circunstâncias - alguns maliciosos, outros indicando problemas no cliente e outros no servidor. (Observei no log fornecido pelo OP que um IP local era indicado como IP remoto, mas o OP não mencionou especificamente o uso de um balanceador de carga, portanto, não tinha certeza se o OP simplesmente usava um IP não roteável para os fins demonstração, como ele fez com o URL)

De qualquer forma, mesmo que meu post seja obviamente muito tarde para ajudar o OP, espero que ajude outras pessoas que chegam aqui procurando uma solução para todos esses malditos erros de tempo limite.


6

Há várias razões para um 408 Tempo limite. Mas vamos começar com a premissa de que está tudo bem, e em algum momento esses 408 começam a aparecer no seu log de acesso - ou seja, 408 0 "-" "-".

Como muitos apontam na rede, um 408 representa uma conexão feita, mas nenhuma solicitação é enviada na escala de tempo apropriada; portanto, o servidor descarta a conexão com um 408. Um indivíduo arrogante realmente respondeu a alguém pedindo ajuda sobre esse problema com - "Que parte do Timeout você não entende".

Eu acho que é uma resposta muito novata e demonstra uma total falta de entendimento de como alguns métodos de segurança funcionam com o software de servidor da web.

Então, de volta ao começo, por que estou vendo todos esses 408? Uma coisa que você terá em comum com o resto de nós gerenciando um servidor é a grande quantidade de ataques que você recebe diariamente. Agora, o que você faz sobre isso? Bem: você emprega os métodos de segurança escolhidos para lidar com eles, é isso que muda.

Vamos dar um exemplo muito fácil, soltar um endereço IP. Incluído em um arquivo iptabes (rules.v4), você tem "-A ufw-user-input -s 37.58.64.228 -j DROP". Então vem o 37.58.64.228, o firewall reconhece o IP e descarta a conexão. Em muitas configurações, você nem saberia que está batendo na porta.

Agora vamos dar um exemplo mais avançado: Abandone a conexão com base em alguns critérios. Incluído em um arquivo iptabes (rules.v4), você tem "-A INPUT -p tcp -m tcp --dport 80 -m string --string" cgi "--algo bm --to 1000 -j DROP". Isso é diferente porque nesta regra do iptable estamos dizendo, observe os primeiros 1000 bytes da string de solicitação e veja se você pode encontrar uma sub-string de "cgi" e se você encontrar essa sub-string, não vá além disso, basta largar a conexão.

Aqui, o método de segurança é bom, mas, no que diz respeito aos seus logs, é enganoso. O 408 0 "-" "-" gerado é o melhor que o apache pode fazer nessas circunstâncias. A conexão foi feita e a solicitação teve que ser aceita até certo ponto para aplicar a regra de comparação de cadeias que resulta em 408, porque sua regra atendeu aos critérios para a conexão ser descartada. Assim, nossos queridinhos novatos não poderiam estar mais errados se tentassem. Uma conexão foi estabelecida e uma solicitação foi recebida (você simplesmente não terá visibilidade dela nessas circunstâncias). Embora um 408 seja gerado, não é um 'Tempo limite'; seu servidor simplesmente interrompeu a conexão depois que a solicitação foi feita em associação com sua regra de firewall. Existem muitas outras regras que criariam a mesma situação. Don '

Idealmente, haveria outro código de erro gerado pelo Apache, por exemplo - '499', o que significaria 'Servidor leu sua solicitação e decidiu que simplesmente não poderia ser incomodado entretendo você - Sod Off HaHa'.

Com o mais recente software de servidor da web, você pode excluir praticamente ataques do DOS, e o novo gene de navegadores que incorporam recursos preditivos não causa esse problema, como alguns sugeriram.

Resumindo, o 408 é gerado porque o servidor não respondeu à solicitação; portanto, no que diz respeito ao cliente, a conexão expirou, quando, na realidade, o servidor leu a solicitação, mas interrompeu a conexão por outros motivos que não um tempo limite aguardando um pedido.


2
Mas PORQUE fez cair a conexão? Estamos vendo que se trata de logs do servidor, não de logs do cliente.
Erick Robertson

5

Tivemos esse problema e ficamos confusos por um bom tempo. A melhor solução que encontramos foi sugerida pela equipe ELB do suporte da AWS. Essencialmente, ele depende de garantir que as configurações de tempo limite do servidor httpd sejam todas maiores que a idle timeoutconfiguração ELB (o padrão é 60 segundos).

  • Verifique se o Timeoutvalor da diretiva apache é o dobro da idle timeoutconfiguração do seu ELB.
  • Ative o KeepAliverecurso, verifique se ele MaxKeepAliveRequestsé muito grande (0 para infinito ou muito alto, como 2000), e que KeepAliveTimeouté maior que o seu ELB idle timeout.

Descobrimos que a KeepAliveconfiguração (e configurações associadas) reduziu especificamente a quantidade de 408s para efetivamente 0 (vemos alguns, mas muito poucos).


Infelizmente, estou usando o Elastic Beanstalk. Eu não tenho essas opções disponíveis para mim.
Erick Robertson

3

Eu tive esse problema por trás do AWS Elastic Load Balancer. As verificações de integridade geraram uma quantidade terrível de 408 respostas no log.

A única solução que funcionou para mim era ter ocioso Timeout Load Balancer configuração menor do que o seu tempo limite de resposta do exame de saúde .


0

Um colega observou recentemente que, enquanto minha última postagem deu uma explicação válida de como um 408 poderia ter uma associação com uma medida de segurança, ele não ofereceu solução.

O registro de acesso canalizado é minha solução pessoal.

O seguinte deve funcionar de imediato na maioria das configurações do Ubuntu e com um mínimo de ajustes em outras configurações do Apache. Eu escolhi o PHP porque é o mais fácil de entender. Existem dois scripts: o primeiro impede que um 408 seja gravado no seu log de acesso. O segundo script envia todos os 408s para um arquivo de log separado. De qualquer forma, o resultado não é mais 408s no seu log de acesso. É sua escolha qual script implementar.

Use seu editor de texto favorito, eu uso o nano. Abra o arquivo em que você tem suas diretivas 'LogFormat' e 'CustomLog'. Comente os originais com o # habitual e adicione o seguinte. Você pode encontrar essas diretivas no arquivo abaixo.

sudo nano / etc / apache2 / sites-available / default

LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" AccessLogPipe

CustomLog "|/var/log/apache2/PipedAccessLog.php" AccessLogPipe env=!dontlog

NOTA: Não registro imagens no meu registro de acesso. No meu arquivo etc / apache2 / httpd.conf, incluo a linha

SetEnvIfNoCase Request_URI ".(gif)|(jpg)|(png)|(css)|(js)|(ico)$" dontlog

Se isso não lhe interessar, remova-o env=!dontlogda CustomLogdiretiva.

Agora crie um dos seguintes scripts PHP ( #!/usr/bin/phpé uma referência ao local do intérprete, verifique se o local está correto para o seu sistema - você pode fazer isso digitando no prompt $; whereis php- isso deve retornar algo como php: /usr/bin/php /usr/bin/X11/php /usr/share/man/man1/php.1.gz. pode ver #!/usr/bin/phpé o certo para a minha configuração).

sudo nano /var/log/apache2/PipedAccessLog.php

#!/usr/bin/php
<?php
  $file = '/var/log/apache2/access.log';
  $no408 = '"-" 408 0 "-" "-"';
  $stdin = fopen ('php://stdin', 'r');
  ob_implicit_flush (true);
  while ($line = fgets ($stdin)) {
    if($line != "") {
      if(stristr($line,$no408,true) == "") {
        file_put_contents($file, $line, FILE_APPEND | LOCK_EX);
      }
    }
  }
?>

sudo nano /var/log/apache2/PipedAccessLog.php

#!/usr/bin/php
<?php
  $file = '/var/log/apache2/access.log';
  $file408 = '/var/log/apache2/408.log';
  $no408 = '"-" 408 0 "-" "-"';
  $stdin = fopen ('php://stdin', 'r');
  ob_implicit_flush (true);
  while ($line = fgets ($stdin)) {
    if($line != "") {
      if(stristr($line,$no408,true) != "") {
        file_put_contents($file408, $line, FILE_APPEND | LOCK_EX);
      }
      else {
        file_put_contents($file, $line, FILE_APPEND | LOCK_EX);
      }
    }
  }
?>

Tendo salvo o PipedAccessLog.phpscript; verifique se o root possui propriedade executando o seguinte no prompt $.

sudo chown -R root:adm /var/log/apache2/PipedAccessLog.php

O PipedAccessLog.phpscript precisará de permissões de leitura / gravação e execução; portanto, execute o seguinte no prompt $.

sudo chmod 755 /var/log/apache2/PipedAccessLog.php

Finalmente, para que tudo funcione, você precisa reiniciar o serviço Apache. Execute o seguinte no prompt $.

sudo service apache2 restart

Se os logs do Apache estiverem em outro local, altere os caminhos para se adequar à sua configuração. Boa sorte.


6
Se os anos 40 estão acontecendo, precisamos descobrir o porquê e nos livrar deles. Simplesmente impedir que eles sejam registrados ou canalizá-los para outro arquivo é uma perda de tempo do servidor. Também serve para esconder apenas o problema. É como limpar o seu quarto empurrando tudo debaixo da cama.
Erick Robertson

-2

Eu descobri que 408 erros estão aumentando em número e frequência. O intervalo de endereços IP dos quais eles se originam também está aumentando (eles são registrados em seu próprio arquivo separado). Também existem padrões de log evidentes que exibem 408 consecutivos dos mesmos grupos de IP que não são devidos a tempos limites normais do servidor, pois o originador está tentando conexões com cerca de 2 ou 3 segundos de diferença em um padrão cíclico (não há espera por um tempo limite antes de outro tentativa de conexão) Eu vejo isso como simples tentativas de conexão no estilo DDOS. Na minha opinião, este é um tipo de mensagem de confirmação para o originador de que um servidor está online ... então eles retornam mais tarde com ferramentas diferentes ... Se você aumentar seu intervalo de tempo limite, está simplesmente dando a ele um time_allocation maior para executar seus programas de hackers dentro.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.