Mon site web utilise Discourse. Initialement, il n’était pas protégé par Cloudflare et a subi une attaque DDoS.
Plus tard, j’ai changé l’adresse IP et implémenté Cloudflare. Cependant, le site web a de nouveau été attaqué par DDoS, apparemment en raison d’une fuite de l’adresse IP du serveur d’origine.
Lors de l’utilisation de Cloudflare CDN, comment pouvons-nous empêcher la fuite de l’adresse IP du serveur d’origine ? Quelqu’un a-t-il de bonnes méthodes ? Merci.
Je ne sais pas, mais l’adresse IP de tous les serveurs en ligne sera divulguée au moment de sa création.
Vous pouvez éviter de nombreuses fuites en procédant comme suit :
HTTPS_PROXY et HTTP_PROXY pour que Discourse l’utilise (les définir dans la section env de votre app.yml)NO_PROXY='127.0.0.1, localhost, \u003cinternal-network\u003e'Voir aussi Install discourse with internet access only via proxy, Configuration outbound proxy et Discourse Link previews through a proxy server? - #14 by supermathie
De plus, lorsque vous êtes derrière CF, vous pouvez modifier le pare-feu de votre hôte Discourse pour n’autoriser que le trafic entrant provenant de vos adresses IP Cloudflare (et de l’hôte auquel vous accédez vous-même).
C’est la solution. La sécurité par obscurité n’est pas sécurisée. Alors peu importe si votre IP est de notoriété publique.
Ceci, ou alternativement, une approche plus simple serait d’utiliser ce qu’on appelle un tunnel Cloudflare. Il devrait s’agir d’une configuration unique, puis vous devriez être en mesure de fermer la plupart de votre pare-feu pour les connexions entrantes.
Je crois que j’ai opté pour cela il y a un moment (sans la configuration de proxy que vous avez mentionnée). Je ne suis pas sûr si cela s’applique à tous les pare-feux (ou peut-être à quelque chose dans ma configuration)
mais dans mon cas avec ufw, il convient de mentionner que docker contourne ufw par défaut, vous devez donc vous assurer d’appliquer les règles à vos adresses IP Docker internes également.
Cela fait un moment, mais je peux examiner les détails plus en détail si vous en avez toujours besoin, plus tard cette semaine.
Et oui, les tunnels Cloudflare sont incroyables ! @itsbhanusharma
Vous voudrez utiliser le pare-feu que votre fournisseur de VPS vous fournit. L’utilisation d’un pare-feu basé sur l’hôte sera beaucoup moins efficace pour lutter contre une attaque DDoS car le trafic atteint votre pile réseau.
Je pense que la plupart des grands fournisseurs offrent une protection DDOS par défaut ? Cela ne devrait-il pas suffire ? Ajouter manuellement les adresses IP de CloudFlare via l’interface semble être une corvée (mon script bash personnalisé prend 2 secondes et récupère automatiquement les adresses IP de CF, par exemple).
Je dois dire que je lis généralement le contraire, ufw/pare-feu local par rapport au pare-feu du fournisseur 
Edit ; Je comprends la logique ici, du point de vue ddos, c’est probablement plus efficace et vous avez raison. Cela dit, si l’adresse IP principale est correctement cachée dès le départ, le ddos ne devrait pas poser de problème, n’est-ce pas ?
La plupart des fournisseurs ont une API pour cela de nos jours ?
Correct ! Mais c’est un “si” assez important…
En réalité, c’est faux. Ce n’est pas parce que l’adresse IP n’est jamais cachée. Les attaques par déni de service distribué (DDoS) ne posent pas de problème si un proxy inverse ou similaire dispose d’outils pour les arrêter. Et même dans ce cas, lorsqu’il y a une véritable attaque, il faut plus qu’une solution d’entrée de gamme. Et si des bots ou des utilisateurs esclaves tentent d’accéder à des ports fermés ou à des ports limités par adresse IP, ce n’est pas un problème majeur. J’appellerais cela un autre jeudi dans le monde de WordPress, mais Discourse est un monde différent à bien des égards.
D’un autre côté, je ne suis pas un expert en la matière.
Mais je suis curieux… combien de trafic est nécessaire pour qu’une attaque DDoS réussisse ? Bien sûr, cela dépend des ressources de la configuration, mais donnez-moi quelques chiffres, s’il vous plaît.
Cela dépend de votre définition de caché. Oui, toutes les adresses IP sont publiques. Mais alors, laquelle des 4 milliards d’adresses IP est la bonne ? Je pense que, pour cette discussion, l’adresse IP peut être considérée comme cachée s’il n’y a aucun moyen de déterminer l’adresse IP (ou les adresses IP) d’un serveur qui héberge un forum Discourse spécifique (donc la fonction f(h) est indéterminée, où la fonction f vous donne la vraie adresse IP d’un hôte).
Étant donné :
Mais je suis d’accord avec vous sur le fait que « caché » est un terme déroutant et incorrect. « Inconnu » est probablement mieux.
Cela dépend du type de DDoS. Pour une attaque au niveau de l’application, cela pourrait être vrai, mais aussi difficile car cela nécessiterait une sorte de limitation de débit avec inspection des requêtes. Mais pour une attaque au niveau du réseau (simple inondation de trafic par amplification ou attaque syn), cela pourrait ne pas être le cas. De plus, ce que vous dites essentiellement, c’est « ce n’est pas un problème si vous pouvez l’atténuer », ce qui est assez évident, mais aussi difficile et/ou coûteux.
Cela dépend aussi du type d’attaque. Une attaque au niveau de l’application devrait être adaptée à Discourse, mais pourrait par exemple exécuter des requêtes lourdes comme des recherches pour submerger les serveurs d’applications, tandis qu’une attaque au niveau du réseau peut être plus générique, nécessiter plus de trafic et peut simplement saturer nginx ou le réseau du VPS.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.