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

35

Estou recebendo muitas solicitações em nossos registros do Apache que se parecem com isso

www.example.com:80 10.240.1.8 - - [06/Mar/2013:00:39:19 +0000] "-" 408 0 "-" "-" -

Parece não haver solicitação nem agente do usuário. Alguém já viu isso antes?

    
por Glenn Slaven 06.03.2013 / 01:45

8 respostas

29

Você por acaso está executando seus servidores da Web na Amazon por trás de um Elastic Load Balancer?

Parece que eles geram um grande número de 408 respostas devido a suas verificações de saúde .

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

  • RequestReadTimeout header=0 body=0

    Isso desativa as 408 respostas se uma solicitação expirar.

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

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

E de esta postagem do blog :

  • Ajuste o tempo limite de sua solicitação para 60 ou mais.
por 06.03.2013 / 08:12
8

Algo está se conectando à porta e nunca enviando dados. HTTP 408 é um erro de "tempo limite". Há um bom artigo aqui: link

    
por 06.03.2013 / 01:48
6

Existem várias razões para um 408 Timeout. Mas vamos começar a partir de uma premissa de que tudo está bem, então, em algum momento, esses 408's 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 na verdade respondeu a alguém pedindo ajuda sobre este problema com - "Que parte do tempo limite você não entende".

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

Então, de volta ao começo, por que estou vendo todos esses 408? Uma coisa que você terá em comum com o restante de nós que gerencia um servidor é a grande quantidade de ataques que você recebe diariamente. Agora, o que você faz sobre isso? Bem: você emprega seus 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 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, Solte 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 --dportar 80 -m string --string" cgi "--algo bm - para 1000 -j DROP". Isto é diferente porque nesta regra de iptable estamos dizendo olhe para os primeiros 1000 bytes da string de requisição e veja se você pode encontrar uma sub-string de "cgi" e se você encontrar aquela sub-string então não vá Além disso, basta soltar a conexão.

Aqui, o método de segurança é bom, mas, no que diz respeito aos seus registros, é 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é um ponto para aplicar a regra de comparação de string que, em última análise, resulta em um 408 porque sua regra atendeu aos critérios para a conexão ser descartada. Então, nossos queridinhos novatos não poderiam estar mais errados se tentassem. Uma conexão foi feita e uma solicitação foi recebida (você simplesmente não terá visibilidade dela nessas circunstâncias). Embora um 408 seja gerado, ele não é um 'Timeout'; seu servidor simplesmente desconectou 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. Não aceite literalmente a explicação do código de erro do servidor 408 - 'Solicitação esgotada'.

O ideal seria que houvesse outro código de erro gerado pelo Apache, por exemplo - '499', que significaria 'servidor lia o seu pedido e decidiu que não poderia ser incomodado entretendo você - Sod Off HaHa'.

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

Em suma, o 408 é gerado porque o servidor não respondeu à solicitação, de modo que, no que diz respeito ao cliente, a conexão expirou, quando, na realidade, o servidor leu a solicitação, mas desconectou a conexão por outros motivos tempo limite aguardando uma solicitação.

    
por 22.11.2013 / 21:06
6

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á mencionados, 408 indica um tempo limite; e há uma grande variedade de circunstâncias em que os tempos limite ocorrem 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 do usuário e geralmente encerram as conexões abruptamente, resultando em um encerramento abortivo para essa conexão que pode gerar um erro 408.

Por exemplo, digamos que eu seja um hacker covarde que está examinando a internet em busca de computadores que ainda estão vulneráveis à vulnerabilidade 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 - mais tarde, usarei essa lista para verificar especificamente a exploração 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

Este comando irá, em muitas configurações do Apache, resultar em uma mensagem 408 exatamente como você descreveu. Executar este comando em dois dos 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 onde o OP não estava usando qualquer forma de balanceamento de carga, 408 erros podem ocorrer em uma variedade de circunstâncias - alguns maliciosos, alguns indicando problemas com o cliente, e alguns indicando problemas com o servidor. (Eu notei no log fornecido pelo OP que um IP local foi indicado como o IP remoto, mas OP não mencionou especificamente o uso de um balanceador de carga, então eu não tinha certeza se o OP tinha simplesmente usado um IP não roteável para os propósitos de demonstração, como ele fez com a URL)

De qualquer forma, mesmo que o meu post, obviamente, seja muito tarde no dia para ajudar o OP, esperamos que ele possa ajudar outras pessoas que chegam aqui procurando uma solução para todos esses erros de timeout.

    
por 04.11.2015 / 15:00
4

Tivemos esse problema e ficamos intrigados por um bom tempo. A melhor solução que surgiu foi sugerida pela equipe ELB de suporte da AWS. Basicamente, é necessário garantir que as configurações de tempo limite do seu servidor httpd sejam todas maiores do que a sua configuração de idle timeout do ELB (cujo padrão é 60 segundos).

  • Verifique se o valor da diretiva apache Timeout é o dobro da configuração idle timeout do seu ELB.
  • Ative o recurso KeepAlive , certifique-se de que MaxKeepAliveRequests seja muito grande (seja 0 para infinito ou muito alto, como 2000) e que KeepAliveTimeout seja maior que o% de coBde% do seu ELB.

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

    
por 30.05.2013 / 16:13
3

Eu tive esse problema por trás do AWS Elastic Load Balancer. Os exames de saúde geraram uma quantidade enorme de 408 respostas no registro.

A única solução que funcionou para mim foi ter a configuração Tempo ocioso do balanceador menor do que o Tempo limite de resposta da verificação de integridade .

    
por 31.07.2015 / 06:32
1

Um colega comentou recentemente que, embora meu último post tenha dado uma explicação válida de como um 408 poderia ter uma associação com uma medida de segurança, ele não ofereceu nenhuma solução.

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

O seguinte deve funcionar de forma imediata na maioria das configurações do Ubuntu, e com o 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 nano. Abra o arquivo onde você tem suas diretivas 'LogFormat' e 'CustomLog'. Comente os originais com o usual # e adicione o seguinte. Você pode encontrar essas diretivas no arquivo abaixo.

sudo nano / etc / apache2 / sites-disponíveis / padrão

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 log 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 for de seu interesse, remova o env=!dontlog da diretiva CustomLog .

Agora crie um dos seguintes scripts PHP ( #!/usr/bin/php é uma referência à localização do interpretador, 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 . Como você pode ver, o #!/usr/bin/php é o ideal para 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 script PipedAccessLog.php ; Certifique-se de que o root possua a propriedade executando o seguinte no prompt $.

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

O script PipedAccessLog.php 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 seus logs do Apache estiverem localizados em outro lugar, altere os caminhos para adequá-los à sua configuração. Boa sorte.

    
por 23.12.2013 / 22:05
-2

Eu descobri que 408 erros estão aumentando em número e frequência. O intervalo de endereços IP dos quais eles estão originando também está crescendo (eles são registrados em seu próprio arquivo separado). Também existem padrões de log evidentes exibindo 408s consecutivos dos mesmos grupos de IP que não são devidos a tempos limite normais do servidor, pois o originador está tentando conexões com intervalos de 2 ou 3 segundos em um padrão cíclico (não há espera por um tempo limite antes de outro tentativa de conexão) Eu vejo estas como simples tentativas de conexão estilo DDOS. Na minha opinião, estes são um tipo de mensagem de confirmação para o originador de que um servidor está on-line ... depois voltam mais tarde com ferramentas diferentes ... Se você aumentar seu intervalo de tempo limite, estará simplesmente dando a eles uma time_allocation maior seus programas hack dentro.

    
por 20.04.2015 / 03:54