É possível veicular páginas específicas com base no endereço IP?

8

Fui alvo de um ataque de força bruta em dois sites WordPress que possuo. O invasor está usando o bom e velho XML-RPC para amplificar o ataque de senha de força bruta. Felizmente, temos senhas extremamente bem geradas, por isso duvido que ele chegue a algum lugar.

Acabei de usar o iptables para bloquear seus pedidos sempre que ele aparecer novamente (sempre do mesmo provedor de nuvem virtual), mas prefiro modificar o servidor para que, sempre que seu endereço IP solicite qualquer página, ele receba uma resposta dizendo a ele para ter uma vida. A maioria dos pedidos são POSTs, então, idealmente, gostaria de modificar o cabeçalho da resposta para incluir algo como "Melhor sorte na próxima vez!" ou algo igualmente satisfatório.

Isso é possível? Estou longe de ser um especialista no Apache, então não tenho certeza de quão difícil isso seria implementar. Mas mesmo que me leve horas, a satisfação será inestimável.

Para referência, estou executando o Ubuntu 16.04.2 LTS, com o Apache 2.4.18 hospedando o Wordpress 4.7.3.

apache-2.4 http-headers

— Aurelius
fonte

"sempre do mesmo provedor de nuvem virtual" OVH? Eu notei muitas crianças usando scripts, por algum motivo.

— hd.

Não, online.net ... eles ainda não responderam a nenhum dos meus relatórios de abuso. Além disso, na primeira vez que enviei uma solicitação de abuso, descobri que eles encaminhavam automaticamente a reclamação ao cliente. Daí como ele encontrou meu site pessoal. Bom trabalho, online.net ....

— Aurelius

25

Basta instalar o fail2ban com a prisão apropriada e pronto. Não se preocupe em dar uma resposta personalizada, pois é mais provável que isso nunca seja visto.

— EEAA
fonte

1

Com certeza. Mas isso é definitivamente algo que eu sempre quis fazer. Mesmo que ele nunca a veja, apenas a possibilidade me faz rir tanto que quase choro.

— Aurelius

14

Bem: 1) IMHO descobrir como exibir um insulto insignificante a um script kiddie é fora de tópico aqui. 2) Fazer isso ainda consumirá seus recursos apache, enquanto fail2ban / iptables bloqueia as solicitações upstream para que seu aplicativo nunca precise lidar com isso.

— EEAA 27/03

1

Ah, com certeza. Mas quero me divertir um pouco antes da proibição permanente. Quer seja mesquinho ou não, eu só quero rir, e isso é a pedido da pessoa que usa o servidor.

— Aurelius

4

@Aurelius, se você conhece o ip, e essa pessoa não o oculta, por que você não faz isso no próprio aplicativo, php neste caso. Basta verificar se é ip xx.xx.xx.xx e se é apenas matar o script com uma resposta, #die("blah blah");

— Miguel Miguel

Aceito como resposta, principalmente porque eu não sabia sobre fail2ban e, portanto, isso é realmente útil em geral. A resposta de Miguel acima, bem como a resposta de BlackWebWolf abaixo, são as duas coisas que vou analisar!

— Aurelius

5

Existe a possibilidade, e fizemos isso bastante, de reverter possíveis ataques. Use o iptables para redirecionar o provedor de nuvem (intervalo de endereços) para uma porta diferente - e a resposta ao invasor será útil, mesmo em cabeçalhos simples.

No Apache, você pode modificar os cabeçalhos por exemplo:

Header set GetOut "Better luck next time!"

— BlackWebWolf
fonte

Hehehe!! Agora é disso que estou falando. Boa ideia! Eu vou olhar para isso.

— Aurelius

5

essa estratégia provavelmente sairá pela resposta, porque permite que o invasor saiba o que está funcionando e o que não está, é muito melhor passar silenciosamente a solicitação para nada e não disparar nenhum sinalizador de alerta em seu software de ataque de bot. Idealmente, retornando o html da página solicitada, por exemplo. eles nunca sabem que você os pegou, nada acontece e seu site é mais seguro. Resista ao desejo de que eles saibam, isso é um ERRO, sempre. Isso simplesmente os ajuda a depurar o problema. No seu caso, basta mudar para faixas de IP mais dinâmicas, etc., dificultando muito a resolução do problema.

— Lizardx

1

Você está certo, não é recomendado - é até possivelmente perigoso. Estratégia com honeypot é sempre melhor, ainda pergunta era clara - como trolls um atacante :)

— BlackWebWolf

Eu realmente não me importo se for um erro - eu instalei o fail2ban e ele será banido de qualquer maneira. Duvido muito que ele realmente chegue a algum lugar; Até onde eu sei, os lançamentos recentes do WordPress realmente corrigiram esse bug de segurança? Sem mencionar, senhas forçadas brutais com mais de 20 caracteres ... sim, não acontecem na vida de nosso universo.

— Aurelius

blackwebwolf, é semelhante a alguém perguntando como implementar a extensão mysql_ obsoleta do php, enquanto tecnicamente é possível responder a essa pergunta, essa resposta está errada porque a resposta real significa fazer isso corretamente, nesse caso, por exemplo, usando mysqli_ ou xpdo. É apenas a noção, que muitos de nós também adotamos, de que responder de qualquer maneira como trolling é outra coisa senão um enorme negativo, deve ser corrigido, porque é um erro grave, e se alguém já sofreu por causa de Nesse erro, entenderíamos imediatamente por que a pergunta estava errada.

— Lizardx 28/03

3

Isso é muito fácil com o ModSecurity, que é um módulo WAF de terceiros para o Apache. Embora envolva aprender a sintaxe da linguagem de regras.

Você também pode usar o ModSecurity para simplesmente desconectar a conexão em vez de responder.

Dizendo isso, instalar o ModSecurity apenas para isso, quando, como outros sugeriram, é provável que as respostas sejam ignoradas, pode muito bem ser um exagero.

— Barry Pollard
fonte

2

Eu iria com fail2ban e soltar solicitações de locais de abuso conhecidos. E se você acha que o provedor de serviços do invasor não é o culpado, relate os ataques ao endereço de e-mail de abuso.

Se você deseja gastar tempo criando algo que desacelera o invasor, tente fazer um tarpit . Primeiro, é claro que você deve saber de onde vêm os ataques. Então você pode usar o apache para redirecionar a solicitação do ip (intervalo?) Para um script específico. Isso pode funcionar, embora eu mesmo não tenha tentado. Em seguida, basta implementar um script que, por exemplo, imprima um ponto (ou algo de / dev / null) a cada 15 segundos para manter a conexão do invasor aberta indefinidamente.

Como o invasor provavelmente está usando scripts para atacar o site, pode levar tempo para perceber que os ataques foram interrompidos, já que as conexões estão aparentemente ativas, não haverá tempo limite e a solicitação não será negada no local.

O problema é que você dedica tempo e recursos a algo que provavelmente não será tão útil quanto a preocupação mais importante: proteger seu login. É difícil atacar quando você não sabe onde atacar. Considere alguns dos seguintes:

restringir o acesso à página de login (apenas a intranet? intervalo de ip? vpn? outro?).
adicione reCaptcha ou outra pergunta de verificação para fazer login.
use autenticação multifator .
oculte sua página de login. Se possível, não o vincule a partir da página principal e não use / login ou outro local óbvio.

— Comunidade
fonte

Obrigado pela informação! Portanto, para esclarecer as coisas, A) os dois usuários capazes de efetuar login têm senhas longas geradas aleatoriamente. B) Há um tipo de captcha na página de login. C) Estou tentando fazer com que o .htaccess funcione para impedir o acesso a essa página. No entanto, parece que os padrões para .htaccess mudaram várias vezes - eu continuo vendo sintaxe diferente em todos os lugares e até agora o htaccess mal funciona.

— Aurelius

Além disso, relatei todos os ataques ao online.net sem nenhuma resposta.

— Aurelius

Algumas dicas úteis para htaccess: stackoverflow.com/questions/6441578/… (eu recomendo fortemente a autenticação Digest).

Olhando para os comentários nesta página, o resumo não parece uma ótima ideia? httpd.apache.org/docs/2.4/mod/mod_auth_digest.html

— Aurelius

1

Você me pegou lá. Sim, lembrei-me disso desde o momento em que usei a autenticação Digest e não tínhamos https em todos os lugares. A razão pela qual não usamos senhas htacces é que não é uma solução a longo prazo. Não há problema em usá-lo para ocultar algo uma semana antes da publicação, mas para o uso diário você não deseja outro nível de senhas. Nem é muito mais seguro. Quando existe um recurso que não aparece na Internet pública, estamos no caminho certo.