Tenho muitas tentativas no meu servidor Web (pequeno, pessoal e absolutamente sem importância), e o apache e o fail2ban geralmente fazem seu trabalho corretamente. Mas há uma entrada de log que me preocupa:
xx.yy.www.zzz - - [9/Jul/2011:12:42:15 +0100] "GET http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP HTTP/1.1" 200 432 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12"
O problema é que a resposta não era um código 404, mas um 200. Tudo bem? Parece estranho para mim, mas meu conhecimento sobre esse campo (e muitos outros) é, para dizer o mínimo, limitado.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. A configuração padrão parece retornar uma página "Bem-vindo ao nginx" sem conteúdo significativo em nosso sistema ubuntu. Portanto, é uma resposta de 200, mas é uma página simples e abrangente - na verdade, não estamos proxyando a solicitação em outro lugar ou algo assim.Respostas:
Primeiro, na frente, não sei o que o suposto atacante está tentando realizar. Talvez haja um script PHP ou uma versão PHP vulnerável a algum ataque estranho de ID de sessão, não sei. Você provavelmente não precisa se preocupar com nada.
Seu servidor se comportou exatamente como o esperado. 200 é o código esperado nessa situação específica, devido à maneira como o Apache interpreta a URL que está sendo passada para ele.
Primeiro,
http://allrequestsallowed.comé tratado como o cabeçalho 'Host:' mais usual (observe que eu não acho que isso esteja especificado na RFC e outros servidores não possam interpretá-lo dessa maneira.Eu estava errado, isso está especificado na RFC 2616 na seção 5.1. 2. Embora os clientes raramente usem esse formulário, desculpe-me, preciso corrigir uma implementação de servidor HTTP que escrevi há algum tempo ...).Agora, presumivelmente, você não tem um site chamado 'allrequestsallowed.com'. Então, o que acontece quando o Apache obtém um
Host:cabeçalho (ou equivalente) para um nome de host que ele não reconhece? Ele escolhe o primeiro host virtual como padrão. Esse é um comportamento bem definido e documentado para o Apache. Portanto, seja qual for o seu primeiro host virtual (ou apenas a configuração principal do servidor, se não houver vhosts), não importa o nome.Agora, o restante da URL fornecida consiste em duas partes - o caminho
/, e um parâmetro GET (o?PHPSESSID...bit).Agora, o caminho
/deve estar presente em praticamente todos os servidores web disponíveis. Na maioria dos casos, ele é mapeado para algo comoindex.htmlou talvez umindex.phpscript, embora você possa substituir qualquer um disso, é claro.Se ele mapeia para um arquivo HTML estático, absolutamente nada de anormal acontece - o conteúdo do arquivo é retornado, e é isso, o parâmetro é simplesmente ignorado. (Supondo que você não tenha determinadas diretivas de configuração avançadas definidas e quase certamente não.)
Por outro lado, se for algum tipo de script, essa
PHPSESSIDvariável será passada para o script. Se o script realmente usar essa variável (nesse caso em particular, provavelmente somente os scripts PHP que usam o tratamento de sessões embutido no PHP), seu comportamento dependerá do conteúdo.Com toda a probabilidade, no entanto, mesmo se você
/mapear para um script PHP usando sessões, nada de notável acontecerá. O ID da sessão provavelmente não existirá de qualquer maneira e será ignorado ou o script mostrará um erro.No caso improvável de que o ID da sessão exista, bem, o invasor pode possivelmente seqüestrar a sessão de outra pessoa. Isso seria ruim, mas não é realmente uma brecha de segurança em si mesma - a brecha seria onde o invasor obteve as informações de ID da sessão (cheirar uma rede sem fio é um bom candidato se você não estiver usando HTTPS). Na verdade, eles não seriam capazes de fazer nada que o usuário cuja sessão foi originalmente não pudesse fazer.
Editar: Além disso, o '% 5C' dentro do SESSIONID é mapeado para um caractere de barra invertida. Este parece ser um teste para ataques de travessia de diretório nos hosts do Windows.
fonte
nginxoulighttpd, e depois de enviar os IPs / hosts de origem a uma empresa de análise cibernética, foi confirmado que havia tentativas de explorar falhas no servidor, entre outras coisas . Solicitações semelhantes à especificada pelo OP, hosts diferentes. Você está dizendo que eles devem ser totalmente desconsiderados? Porque se eles estiverem realmente preocupados, poderão bloquear o (s) host (s)iptables.Eu tenho todas essas solicitações permitidas conectadas em um ip que é usado como um registro para todos os nossos domínios de estacionamento.
Meu argumento é que esse nome de host é usado em combinação com o arquivo de host local do "atacante" apontando para o host de destino.
O servidor da Web atual em 31.44.184.250 é apenas para lidar com solicitações externas.
Minha opinião: totalmente inofensivo. Não veja nenhum valor agregado para isso, exceto as coisas que você pode fazer com qualquer outro nome de domínio falso no seu arquivo de host.
fonte