bloquer une liste d'ip dynamique apache2 ?

[Max72]

Oui redémarrer apache c'est pas top, c'est bien pour ça que je propose la commande reload et pas restart ...

Au temps pour moi, j'ai survolé trop vite.
En effet, en faisant quelques recherches je n'ai pas trouvé de problèmes récurrents avec le fait de reload la conf apache.

En fait je pense que je vais prendre ton approche Max72.
Mettre à jour avec un cron la BD, et plutôt que de bloquer bêtement tout le site (ce qui n'est pas le but), bloquer uniquement l'espace de jeu (via la connexion) avec une verif de l'IP via les IPs bloqué en BD.
Comme ça pas besoin de toucher à apache, on pourra même accéder au site (news, classement, règles...) mais pas le jeu donc moins de facilité pour des multicomptes. Ça fait un outil de plus contre la triche.

Perso je pense que c'est une bonne solution : en tant que joueur (même si j'utilisais TOR), le fait de tomber sur une 403 ne me donnerait pas envie de revenir..

Edit : Par contre si tu bloques la connexion avec la vérif de l'IP, moi je mettrai un message d'info à l'inscription disant que la connexion au jeu avec le navigateur TOR est impossible, histoire que le mec sache où il aille.

[niahoo]

Notez que je vote aussi pour quelque chose de moins bourrin que de modifier la conf apache dynamiquement

[Akira777]

Ola l'ami !

Je pense que dans ce cas précis le mieux et de passer par les iptables, une petite commande te permet d'ajouter une IP à bannir dans la conf et hop c'est au top
Et ce service est beaucoup moins contraignant à redémarrer.

Dans mon cas, je bannis les IP via mon serveur Plesk et Fail2Ban, et je peux via son API ajouter simplement une IP à bannir sans avoir à me soucier de redémarrer le service. Combiné à une page d'erreur 500 personnalisé c'est efficace !

[Xenos]

Je passe sous silence mon désaccord avec le principe de bloquer TOR, qui revient à bloquer un moyen (technique) au lieu de résoudre le problème sous-jacent

• D'accord avec Akira. Passer par la table SQL sera lourd (chaque test d'IP requiert le traitement par un worker Apache, puis le lancement du process PHP, puis la connexion à la BDD, qui a une limite de connexions simultanées généralement, puis l'exécution de la requête et enfin, le renvoie d'une réponse type 403). Sans compter le CRON (mais on le retrouvera surement dans le cas d'iptable si tu veux une MaJ automatique et régulière).


• Sinon, sans reload / restart, il n'y a apparemment que le htaccess d'utilisable (via un include si besoin). Au besoin, les plages d'IP peuvent réduire la taille de la liste.

• A noter: ce sera lourd de passer par les configs d'Apache, puisqu'il faudra lire N lignes de code pour savoir si 1 adresses IP est bloquée. Via un système arborescent (iptables s'en sert surement, mais je n'ai aucune preuve de cela), on lira toujours le même nombre de lignes (profondeur d'arbre) peu importe le nombre d'IP bloquées (nombre de feuilles). Bref, Apache sera forcément hyper-lourd, et pour le coup, Apache+PHP+BDD sera plus léger, mais iptables seul sera encore plus léger (et firewall seul sera top: l'hébergeur n'offrirait-il pas déjà une solution toute prête dans ses firewalls, pour bloquer TOR?).

[niahoo]

C'est vrai d'ailleurs, pourquoi bloquer TOR ? je sais que ce n'est pas le sujet mais si tu pouvais donner tes raisons, ça ferait un autre topic intéressant je pense.

[Argorate]

Ola l'ami !

Je pense que dans ce cas précis le mieux et de passer par les iptables, une petite commande te permet d'ajouter une IP à bannir dans la conf et hop c'est au top
Et ce service est beaucoup moins contraignant à redémarrer.

Dans mon cas, je bannis les IP via mon serveur Plesk et Fail2Ban, et je peux via son API ajouter simplement une IP à bannir sans avoir à me soucier de redémarrer le service. Combiné à une page d'erreur 500 personnalisé c'est efficace !

Je veux bien que tu me donnes la cmd lié à fail2ban pour gérer dynamiquement le ban d'une ip si tu l'as, svp.

niahoo : j'ai déjà donné ma raison. Chacun fait comme il veux, mais en l’occurrence pour la partie jeu, c'est typiquement un outils de multicompte en puissance. Alors oui, les innocents payent pour les tricheurs, mais je préfère qu'un jeu me permette pas d'utilisé tor, que d’être sur un jeu où je peux perdre parce qu'il y a des tricheurs en face. Certes cette limitation ne suffit pas en soit, mais c'est un outils de contrôle de plus sur la longue liste...

[@lucard]

J'avoue être noyer dans le jargon que vous utilisez ici, mais bref j'ai une petite question d'ordre technique à te poser Agorate (ou à un autre membre)

tu souhaites bloquer les ip dynamiques pour (surtout) bloquer la possibilité de faire du multi-compte.
Il me semble que certain FAI propose un service, parfois par défaut, d'adresse ip dynamique (de mémoire Alice changeait l'adresse IP à chaque reboot de la box.)

Pour ce cas là : un joueur se connecte à son "compte A", reboot (donc change d'adresse ip), et créer un "compte B" avec un autre navigateur (pas de cookies associé)...

Que se passe-t-il ?
Impossible de créer un compte B ? pourquoi ?
Impossible de se connecter au compte A par la suite ?

Voilà j'attends pas de réponse personnellement, mais c'est juste pour voir ce qu'il en résulterait... =)

[Argorate]

Je sais bien qu'il existe des tonnes de possibilité pour un joueur de tricher. Moi ce que j'espère quand je joue à un jeu, c'est que son(ses) créateur a passé du temps pour faire en sorte de réduire au maximum les possibilités de triche. Ça veux pas dire que ça sera parfait, ça veux dire que ça sera très très limité.
Je pense qu'en tant que créateur on a la responsabilité de faire tout ce qui est en notre pouvoir, et ces mots là ont un sens fort. C'est pas juste une expression. On doit user de tous outils de contrôle. De l'interprétation de comportement, jusqu'aux IPs. (et oui... si il n'y avait pas de tricheur, tout ce temps pourrait être utilisé a faire de meilleur jeu, mais c'est plutôt aux joueurs qui trichent qu'il faudrait l'expliquer).

[Xenos]

Moi j'expliquerai plutôt aux concepteurs que si un multi-compte permet d'avantager le joueur, alors le gameplay mérite d'être revu: quid d'une équipe de 10 joueurs qui agit comme un multi-compte (9 joueurs pushent le 10e, le groupe récoltant la gloire)?

Bon, après, je situe assez mal comment TOR peut être bloqué... Si je suis le principe, bloquer TOR, c'est bloquer toutes les machines qui font partie de ce réseau en oignon... Quid d'un utilisateur sur TOR qui quitte le réseau pour venir jouer? Son IP n'a pas changée, et il est bloqué parce que "bouh, TOR, c'est nul"?
Quid d'un multi-compte qui passe par un autre réseau que TOR?

Le moyen choisit (bloquer TOR) me semble inadapté au but (éviter le multi), tout comme le moyen technique (config Apache pour bloquer des IPs dynamiques) est inadapté à ce moyen choisit (bloquer TOR). On ouvre un autre topic pour le débat?

[Argorate]

Ton raisonnement est faux. Si un joueur programme 9 bot sur counter-strike qui head-shot à la frame prés où c'est possible, tu seras effectivement meilleur seul que la meilleure équipe du monde à 10.
Même chose pour un jeu par navigateur. Avoir 10 comptes sur ogame peut permettre d'arriver au même résultat (voir meilleur) qu'une alliance de 10 gars, mais la différence c'est qu'il n'y a aucun mérite à avoir coordonnée, coopérer 10 personnes avec des intérêts personnels propre et qui ont su se rassembler et s’unir pour être meilleur.
Bref, tu ne sembles regarder que le résultat, hors typiquement la triche permet d'arriver a des résultats, donc il faut surtout regarder comment on parviens à cela.

Pour TOR, bloquer le réseau n'est pas problématique puisque si le mec repasse par "internet" avec son ip "normal", il ne sera pas bloqué, donc il n'y a aucun aspect contraignant en réalité.

ouvre un débat si tu veux, mais on va vite retomber sur ce qui a déjà été dit dans le dernier^^