Lidando com invasores de baixo nível?

Question

Eu tenho um pequeno site de jogos com 400 membros (~ 50 ativos) construído em torno de um banco de dados MySQL. Eu sou o único desenvolvedor, e sou um amador, então faço meu quinhão de erros.

Para ajudar a proteger a mim mesmo, o site e as contribuições de meus membros, eu configurei o servidor com uma mensagem de texto simples "nós experimentamos um erro" e enviamos por email automaticamente as informações de erro do PHP.

É claro que isso nunca funcionaria em um ambiente corporativo, muito pesado, mas meus membros estão compreendendo desde que desenvolvemos o site juntos e tenho relações pessoais com a maioria deles. Eles também são geralmente homens velhos tecnicamente não-sujos, o que significa que situações de falha de software seriam confusas para eles.

O site também usa o PDO, em todos os lugares.

/ histórico completo

Eu acordei esta manhã com 90 e-mails de erro. Incomum!

Todos foram acionados em uma janela de 2 minutos ... o mais incomum!

As mensagens de erro eram coisas como

PDOStatement::execute() expects parameter 1 to be array, string given

que, depois de analisar meu código, não é possível sem interferência externa.

Então eu vou pegar meus logs de tráfego e descobrir que o IP 219.117.193.20 de Tóquio está martelando meu site com pedidos como:

GET /search.php?type=basic%20AND%201%20=%201

o primeiro bit disso: GET /search.php?type=basic é válido e listado na navegação principal. Tudo o mais que ele (s) está anexando.

Parece um ataque Bobby Tables simples.

Então isso durou vários minutos e mais ou menos 100 chamadas, e depois parou.

A minha pergunta para você é:

Devo me preocupar em tentar tomar alguma ação contra esse IP?

ou isso é apenas o preço da visibilidade e muito freqüente para ser incomodado?

você proíbe o IP? a sub-rede? você contata o ISP?

Apenas o que os administradores profissionais de servidores fazem nesses tipos de situações, como eu imagino que isso deve acontecer extremamente com freqüência ...?

    

Answer 1

É o preço da fama. De vez em quando alguém vai tentar algo contra praticamente todos os sites (eu vejo uma varredura de versões vulneráveis do phpMyAdmin a cada dois dias, por exemplo). Como as máquinas envolvidas são quase exclusivamente máquinas zumbidas de usuários finais, "agir" contra elas é inútil (qualquer tipo de "contramedida ativa" é, obviamente, completamente errado, mas até mesmo tentar denunciar a máquina infectada ao proprietário é quase certamente fútil).

Certifique-se de que seu site é seguro e siga em frente com seu dia.

    

Answer 2

Como você também é o desenvolvedor, você pode considerar a codificação de um manipulador de erros apropriado para ignorar e / ou até mesmo acionar uma resposta / manipulação "tar pit".

    

Answer 3

A primeira coisa que você quer fazer é validar TODAS as entradas que você recebe e parametrizar completamente todas as consultas que você passar para o banco de dados. Desta forma, o ataque SQL Injection não será bem sucedido.

Como @womble disse que tentar banir o IP ou a sub-rede é inútil. As probabilidades são de que a pessoa que está executando o ataque nem sequer esteja nesse IP. Eles vão apenas mudar para outro zumbi e continuar assim.

Proteja tudo e seja feito. Os ataques falharão, eles ficarão entediados e seguirão em frente.

    

Answer 4

Você pode tentar protegê-lo usando uma chave do cliente gerada pelo selv. Distribua essa chave apenas para seus membros e atualize-a todo ano.

Desvantagem: Você provavelmente terá que explicar como instalar e usar essa chave em todos os navegadores da web ...

Uma abordagem mais simples pode ser uma proteção usando a proteção de senha do seu servidor .htdigest.