Número aumentado de 408 Tempos Limites de Solicitação para null em um servidor da web

Question

Nos meus registros de registro , tem havido uma progressão crescente destes:

  408 Request Timeout
      null: 694 Time(s)

No meu servidor da web.

Aqui estão alguns dos itens que parecem as solicitações de contribuição do log de /var/log/apache2/access.log :

ip - - date requestsfor"-"? httpcode bytes referrer useragent
75.149.117.146 - - [28/Jan/2013:17:49:47 -0500] "-" 408 0 "-" "-"
65.55.215.247 - - [28/Jan/2013:17:57:40 -0500] "-" 408 0 "-" "-"
205.157.206.75 - - [28/Jan/2013:18:00:21 -0500] "-" 408 0 "-" "-"

Exemplos de solicitação de acesso normal, claro, têm muito mais informações relevantes como esta:

ip - - date request-for httpcode bytes referrer useragent
66.251.23.171 - - [28/Jan/2013:17:45:41 -0500] "GET /images/al/al-mb0608tn.jpg HTTP/1.1" 200 4085 "http://example.com/brands.php?F=S&BrandCode=AL" "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)"

Veja uma amostra maior do meu log de acesso aqui (com alguns pedidos normais de get que 408 com o resto)

Eu fiz pesquisas reversas de IP nos ips e eles parecem vir de diversos locais nos EUA e no Canadá. Isso pode significar apenas que existe um proxy envolvido, suponho? Existe um grande bloco de:

96.42.74.117 - - [18/Feb/2013:02:55:58 -0500] "-" 408 0 "-" "-"

Isso se repete com frequência.

Eu hesito em tirar conclusões precipitadas de que isso é um ataque em oposição a uma falha, mas o número de sondas registradas tem aumentado constantemente na mesma época, p. logwatch também diz

 A total of 125 sites probed the server
    107.22.9.89
    108.132.76.100
    108.172.60.59
    108.226.133.142
    12.166.56.82
    12.54.94.24

.... e assim por diante, com uma lista de vários ips que usaram sondas detectadas contra o servidor. Há alguma sobreposição de ips listando como "sondando" o servidor e os ips que atingem o log de acesso com nulos, o que pode sugerir um ataque, mas como o servidor precisa atender a solicitações, será difícil dizer tempo limite de um ataque de tempo limite de solicitação do DOS, se é isso que está acontecendo aqui.

Como eu depuro este problema, ou se é um ataque, lide com este ataque?

    

Answer 1

De algumas pesquisas que fiz, estas são algumas possibilidades que levam à mensagem 408 . Você pode testar cada um para identificar o relevante para o seu caso.

1) Valor muito baixo do Apache TIMEOUT - o seu servidor web pode terminar a sessão antes que o cliente tenha a chance de enviar uma solicitação.

muitos códigos de erro 408 no log de acesso

2) browser predictive optimization - você pode facilmente testar isso com diferentes navegadores. Simplesmente use tail -f /var/log/apache2/access.log , enquanto estiver usando palavras-chave relevantes que abririam o seu site na primeira página de busca, passe o mouse sobre o link apontando para o seu site, verifique se a visualização do site aparece ..... tudo isso sem clicar no link que abre o seu site.

link

3) denial of service attack - ddos warms como slow loris podem abrir muitas conexões com o servidor sem enviar um único bye para amarrar todos os processos do Apache.

link

Uma citação acima do linke -

"O truque é abrir uma conexão com o servidor, mas não enviar um único byte. Abrir a conexão e aguardar quase não requer recursos do invasor, mas amarra permanentemente um processo do Apache para aguardar pacientemente por uma solicitação. Apache vai esperar até o tempo limite expirar e, em seguida, fechar a conexão.A partir do Apache 1.3.31, timeouts de linha de solicitação são registrados no log de acesso (com código de status 408). O Apache 2 não registra tais mensagens no log de erros, mas esforços estão em andamento para adicionar a mesma funcionalidade que está presente na ramificação 1.x. "

    

Answer 2

A maioria das respostas do servidor de código 408 parece ser devido a tempos limite do cliente em vez de olhar para frente. Estou excluindo a negação de serviço nos casos mencionados, meus servidores e as referências referenciadas porque o número de ocorrências é baixo. Eu tentei, mas não consegui reproduzir nenhum erro 408 através de look ahead no Safari, Chrome ou Firefox no OS X. Eu também não os vejo na maioria dos meses em um servidor local (não público) que eu esperaria se eles eram comportamentos normais do navegador. Pode ser navegadores olhando para o futuro abrindo conexões e nunca as usando para uma solicitação, mas não vejo esse comportamento com previlância suficiente para explicar o número de 408s nesses servidores públicos. Ao abrir uma conexão com uma solicitação vazia para obter a conexão iniciada, faz mais sentido, para uma perspectiva, pegar um recurso ou usar OPTIONS (que também vejo apenas em raras situações de cross site e spider).

Eu fiz uma pesquisa de host DNS em uma lista de 47 IPs que recebem 408 respostas sem um recurso, agente ou tamanhos de solicitação identificados no log de um servidor público pouco usado. Eu ignorei 67 IPs adicionais onde eles diferiam apenas pela última tupla e os representava com o primeiro em cada conjunto. Então, isso é 47 diferentes redes de clientes / ISPs. O TimeOut do Apache é o padrão de 60 segundos. Dos 47, 20 produziram nomes de máquinas. Destas máquinas 10 (50%) estavam na China continental, 5 nos EUA (25% e todas as OH, OK e NH) e 5 entre Brasil, Reino Unido, Itália e Taiwan (ROC). Eu também suspeito que uma boa proporção dos 27 IPs que não resultaram em um nome de máquina também está na China, mas não pode mostrar isso.

Dos 67 IPs ignorados já que seu bloco já estava representado, 63 eram spiders do Baidu: baiduspider - *. crawl.baidu.com (Se isso parecer excessivo, tenha em mente que agora ele é maior que o Yahoo ou Bing em termos de pesquisas por mês - perdendo apenas para o Google.

Se fosse um comportamento moderno do navegador, eu teria esperado uma proporção maior nos EUA. O servidor que eu registrei está na área da baía. Em vez disso, acho que isso é principalmente o congestionamento da rede, fazendo com que as conexões demorem muito para serem configuradas e permitindo que a solicitação completa seja enviada e recebida antes que a conexão seja descartada ou expirada pelo Apache. Em particular, o congestionamento extremo devido ao crescimento da demanda, largura de banda transfronteiriça inadequada e infraestrutura de firewall nacional na China. Também pode ser uma reconfiguração forjada deliberada, mas não há razão para esperar isso. O restante é de usuários domésticos com conexões ruins ou situações de equipamentos infelizes em outros lugares.

Acho que o problema é principalmente um problema de conectividade final do cliente, mas você pode querer ter uma página de erro 408 conciliadora e não gráfica. Apesar de julgar pelo tamanho 0 mostrado no log da resposta de saída, o Apache não está usando a página de erro.

    

Answer 3

No meu caso, o Apache estava sendo sobrecarregado. A resposta foi desativar o KeepAlive e aumentar o MaxClients no apache.conf.

    

Answer 4

Eu tive esse problema quando modifiquei minha configuração do Apache para o meu servidor FastCGI.

Aumentar o valor de -idle-timeout de 60 para 900 me deu algumas noites sem dormir, já que não consegui identificar os 408 erros nessa pequena alteração.

Ainda bem que eu consertei isso retornando isso para 60.