Meu site usa o Discourse. Inicialmente, ele não era protegido pelo Cloudflare e sofreu um ataque DDoS.
Posteriormente, alterei o endereço IP e implementei o Cloudflare. No entanto, o site foi atacado novamente por DDoS, aparentemente devido a um vazamento do IP do servidor de origem.
Ao usar o Cloudflare CDN, como podemos evitar que o IP do servidor de origem seja vazado? Alguém tem algum método bom? Obrigado.
Não sei, mas o IP de todos os servidores online será vazado no mesmo momento em que for criado.
Você pode evitar muitos vazamentos fazendo o seguinte
HTTPS_PROXY e HTTP_PROXY para que o Discourse a utilize (defina-as na seção env do seu app.yml)NO_PROXY='127.0.0.1, localhost, \u003cinternal-network\u003e'Veja também Install discourse with internet access only via proxy, Configuration outbound proxy e Discourse Link previews through a proxy server? - #14 by supermathie
Além disso, quando você estiver atrás do CF, pode modificar o firewall no seu host Discourse para permitir apenas tráfego de entrada dos seus IPs do Cloudflare (e do host de onde você mesmo acessa)
Esta é a solução. Segurança por obscuridade não é segura. Então não importará se seu IP for de conhecimento comum.
Isso ou, alternativamente, uma abordagem mais simples seria usar o que é chamado de túnel do Cloudflare. Deve ser uma configuração única e, em seguida, você poderá fechar a maior parte do seu firewall para conexões de entrada.
Acredito que optei por isso há um tempo (sem a configuração de proxy que você mencionou). Não tenho certeza se isso se aplica a todos os firewalls (ou talvez a algo na minha configuração)
mas no meu caso com o ufw, vale a pena mencionar que o docker ignora o ufw por padrão, então você precisa garantir que as regras também se apliquem aos seus IPs internos do docker.
Já faz um tempo, mas posso investigar mais detalhes se você ainda precisar disso, no final desta semana.
E sim, os túneis do Cloudflare são incríveis! @itsbhanusharma
Você vai querer usar o firewall que seu provedor de VPS oferece. Usar um firewall baseado em host será muito menos eficaz no combate a um DDoS, pois o tráfego chega à sua pilha de rede.
Acho que a maioria dos grandes provedores oferece proteção DDOS por padrão? Isso não deveria ser suficiente? Adicionar IPs do CloudFlare manualmente através da interface parece ser um incômodo (meu script bash personalizado leva 2 segundos e busca automaticamente os IPs do CF, por exemplo).
Tenho que dizer que geralmente leio o oposto, ufw/fw local sobre o fw do provedor 
Editar; Eu entendo a lógica aqui, da perspectiva ddos isso é provavelmente mais eficaz e você está certo. Dito isso, se o IP principal estiver oculto corretamente desde o início, o ddos não deveria ser um problema, certo?
A maioria dos provedores tem uma API para isso hoje em dia?
Correto! Mas isso é um “se” bem grande…
Na verdade, errado. Só porque o IP não está oculto. Ataques DDoS não são um problema se um proxy reverso ou similar tiver ferramentas para impedi-los. E mesmo assim, quando há um ataque real, algo mais é necessário do que uma solução de nível básico. E se bots ou usuários escravos estiverem acessando portas fechadas ou portas com limite de IP, isso não é um grande problema. Eu chamaria isso de outra quinta-feira no mundo WordPress, mas o Discourse é outro mundo de tantas maneiras.
Por outro lado, não sou um especialista nisso.
Mas estou curioso… quanto tráfego é necessário para que um ataque DDoS seja bem-sucedido? Claro que depende dos recursos da configuração, mas por favor, me dê alguns números.
Depende da sua definição de oculto. Sim, todos os endereços IP são públicos. Mas então, qual dos 4 bilhões de endereços IP é o correto? Eu acho que, para esta discussão, o IP pode ser considerado oculto se não houver como determinar o(s) endereço(s) IP de um servidor que está servindo um fórum Discourse específico (então a função f(h) é indeterminada, onde a função f lhe dá o endereço IP real de um host)
Dado:
Mas concordo com você que “oculto” é um termo confuso e incorreto. “Desconhecido” é provavelmente melhor.
Isso depende do tipo de DDoS. Para um ataque de camada de aplicação, isso pode ser verdade, mas também difícil, pois exigiria algum tipo de limitação de taxa com inspeção de solicitação. Mas para um ataque de camada de rede (simplesmente inundação de tráfego por amplificação ou um ataque syn), isso pode não ser verdade. Além disso, o que você está basicamente dizendo é “não é um problema se você puder mitigá-lo”, o que é meio óbvio, mas também difícil e/ou caro.
Também depende do tipo de ataque. Um ataque de camada de aplicação precisaria ser adaptado ao Discourse, mas poderia, por exemplo, executar algumas consultas pesadas, como pesquisas, para sobrecarregar os servidores de aplicativos, enquanto um ataque de camada de rede pode ser mais genérico, consumir mais tráfego e simplesmente entupir o nginx ou a rede do VPS.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.