Como a Fiasco Labs aponta em sua resposta , esse tipo de entradas de log é um centavo-a-dúzia. Mas como um administrador de sistemas com um histórico profundo de gerenciamento e proteção de servidores da Web baseados em LAMP, isso não é um ataque tanto como uma "detecção" de script do seu sistema por alguém em algum lugar. Essas sondagens / varreduras de um sistema são feitas para ver quais servidores (se houver) estão vulneráveis; não apenas seus servidores. Em geral, isso é o equivalente da "discagem de guerra" que era bastante comum nos anos 1980/90 de sistema de invasão via modem acústico; escaneie uma lista de sistemas, veja quais sistemas têm “falhas” e veja o que você pode fazer com essas supostas falhas.
Você deve estar em pânico com isso? De modo nenhum. Todo e qualquer servidor da Web na Internet está sendo constantemente investigado. Eu gerencio alguns servidores web Ubuntu Linux e tenho 100% de certeza se eu fosse checar meus logs agora, amanhã, um dia a partir de agora, etc… Eu veria entradas parecidas com o que você está vendo. Mas eu não estou perdendo o sono com isso. A realidade é que, se o seu sistema operacional principal for adequadamente corrigido e a estrutura que você está usando for corrigida e atualizada, você estará em boa forma.
Usar uma ferramenta como Fail2Ban não é uma má ideia, mas considero um pouco exagero Se você me perguntar. A razão é que mesmo com uma ferramenta como Fail2Ban ou mesmo ModSecurity , um bot inteligente ainda pode passar. É por isso que meu melhor conselho para qualquer administrador de sistemas é proteger seus servidores e ter uma maneira de recuperar facilmente de um comprometimento de sistemas.
Proteger seu servidor e seu código base
O que eu considero melhor prática de segurança é endurecer a configuração do servidor LAMP e garantir que o nosso código PHP seja sólido. Esta resposta no site Stack Exchange de segurança é um bom ponto de partida para entender o que significa "endurecimento", mas honestamente, se você não é um administrador de sistemas, muito disso pode estar acima da sua cabeça.
Portanto, eu recomendaria que, a menos que você esteja realmente à altura da tarefa de aprender como ser um administrador de sistemas Linux, talvez seja melhor usar algum provedor de hospedagem compartilhada em algum lugar. Dessa forma, seus administradores usam suas habilidades para se preocupar com essas coisas e você pode se concentrar na execução / codificação do site.
Dito isto, mesmo com uma configuração de hospedagem compartilhada, você não está fora do gancho. Mesmo se você estiver usando um framework PHP bem relacionado, você precisa estar atualizado sobre o patch do framework PHP praticamente sempre que uma atualização for lançada. E, no que diz respeito à sua base de código principal, você deve certificar-se de não cortar os cantos da prática básica de segurança em como codifica. Basicamente, você deve aprender a limpar toda e qualquer entrada que seu site receba e como configurar corretamente o site, para que, mesmo que ele falhe, isso não aconteça de maneira desastrosa.
Backups e recuperação de desastres
E em minha mente isso significa backups, backups, backups e mais backups. Você nunca pode controlar o comprometimento do servidor, mas a recuperação de dados / sistemas está sempre em seu controle. O que significa que você precisa ter algum tipo de “plano de recuperação de desastre” de pequena escala para restaurar seu site.
O que significa, certifique-se de fazer o backup de sua base de código principal, de modo que, se ela for comprometida, você poderá reimplantar código limpo com facilidade, sem muito esforço. Para esse fim, recomendo que você use uma ferramenta de gerenciamento de código-fonte, como git , para o acompanhamento de sua versão, bem como a configuração de um GitHub repositório para armazenamento remoto. Além disso, aprenda como usar o Capistrano com o PHP para implantar o código; Eu tenho uma resposta que aborda como fazer isso aqui .
Idem com seu banco de dados MySQL; dependendo do tamanho / escala, os backups estão disponíveis. Eu gosto de ter backups MySQL em sites de pequeno a médio porte executados a cada 3-4 horas. Dessa forma, o pior que pode acontecer se um site for hackeado é o banco de dados ter no máximo 3-4 horas de atraso; um banco de dados obsoleto no mesmo dia é melhor do que um banco de dados danificado, sem nenhum backup.