BlogBang

Comment mettre en place une limite de connexion par ip avec Memcached

Par Korben | Nb visites : 165

twitededibox Comment recevoir des alertes systèmes via Twitter

Pour faire suite à l’affaire du vol de mots passe sur Twitter, et afin de limiter le nombre de tentatives de login erronées sur leur service web, l’équipe technique de Twitter a mis en place une stratégie plutôt intéressante pour limiter les requêtes à l’API.

On peut facilement bloquer des tentatives d’intrusion par bruteforce mais cela demande beaucoup de ressource serveur car il faut surveiller chaque tentative de log et l’écrire dans la base de données, ce qui est un peu chaud en terme de performance sur de gros sites comme Twitter. Du coup, la technique que Twitter a adopté se passe au niveau du gestionnaire de cache Memcached.

Avec Memcached, il est en effet possible de surveiller le nombre de requêtes par IP sur vos formulaires ou vos scripts et de bloquer celles-ci, si les hits sont trop rapprochés. (Donc dans une logique de bruteforce)

Tout se passe au niveau du compteur ratelimit de memcached qui s’incrèmente jusqu’à atteindre 10 par exemple…  Au dela de 10 tentatives, l’attaquant n’a plus accès au site. Pas con, le Jean-Pierre, hein ?

C’est un peu technique, il y a du code en python et un bout de perl en exemple et je n’ai malheureusement pas encore trouvé l’exemple qui me permettrait de brancher ça avec du PHP mais tout est là… Je me suis dit que ça en intéresserait certains.

+ d’infos ici

Publicité

Je vous recommande aussi la lecture des sujets suivants


Faites un lien vers cette news sur votre site



15 commentaires

  1. Siko Reply to this comment


    Suffit de mettre une varaible $_SESSION qui s’incrémente a chaque fois qu’un utilisateur remplis un mots de passe faux. Coupler avec une autre session qui enregistre le timestamp de la dérnière tentative pour limiter la fréquence et en ajoutant a cela les cookies. On arrive certes pas au même niveau que le script de twitter mais en 15 sec on peut faire chier plusieurs heure un hacker pas très doué. Si a chaque fois ils doit fermer et relancer son navigateur pour relancer les sessions.

    D’autant plus qu’on peut une fois la limite atteinte, cette fois ci ajouter a la bdd.

    Posté le 9 janvier 2009 à 20:39:17

  2. bb Reply to this comment


    ba ouais, mai si on sait faire un prog de brute force, on sait quand meme changer son ip nan ? c ptetre plus long mais cest faisable Dites moi si jme trompe

    Posté le 9 janvier 2009 à 20:47:04

  3. Siko Reply to this comment


    Oui mais en même temps rien n’est inviolable, cette méthodes prend a tout peter 10 min a mettre en place, et c’est toujours intéressant de sécuriser un peu plus son site même avec des truc futiles… de toutes façon un vraie hacker n’as pas besoin d’utiliser du bruteforce en général.. un « man in the middle » est plus dur a mettre en place et requiert plus de connaissance mais a mon avis 95% des sites ne sont pas protéger contre.

    Posté le 9 janvier 2009 à 20:49:57

  4. Ludo42 Reply to this comment


    @bb: Le brutforce c’est des milliers de requêtes, je pense pas que tu puisse trouver des milliers d’IP d’un petit claquement de doigt ;)
    Et puis ça serait super long.

    C’est un problème récurent, les pirates assomment souvent les serveurs de requêtes pour arriver à leurs fins. C’est pour ça que des IDS sont utilisés dans les gare, les aéroports etc… pour surveiller entre autre le nombre de requêtes par IP

    Posté le 9 janvier 2009 à 22:22:37

  5. Billyboylindien Reply to this comment


    @Siko: Un cookie ne sert pas trop dans le cas d’un bruteforce. Le gars script et ne fais pas ca avec son navigateur. Et s’il y a des cookies, il sont scriptées aussi ;)
    Donc la sessions c’est mort amha

    Posté le 9 janvier 2009 à 22:53:07

  6. Paganel Reply to this comment


    Ils sont gentils, chez Twitter, mais un brevet existe depuis déjà dix ans pour cette méthode, et qui n’a même pas besoin de connaitre l’IP !

    Cela étant, il fait peut-être partie de ceux qu’IBM a mis dans le domaine public, vu que ce brevet (US) a probablement été pris par précaution histoire de ne pas se faire chiper la méthode par un concurrent (il n’y a en effet pas de pognon à y gagner) n’y a mais ça n’interdit pas de rendre à César la paternité ce qui a été inventé par César :

    http://www.wikipatents.com/6587032.html

    Posté le 10 janvier 2009 à 07:28:02

  7. Armetiz Reply to this comment


    @Billyboylindien: La variable session n’est pas stocké dans un cookie sur le client, mais sur le serveur dans un fichier par défaut, et déportable vers un BDD suite à une conf d’apache (il me semble).

    Concernant la sécurité en général.. Rien n’est inviolable, tout n’est qu’une question de temps, et comme le temps c’est de l’argent. Une bonne sécurité revient à dire qu’il faut beaucoup de temps pour la violer :)

    Posté le 10 janvier 2009 à 12:13:36

  8. kane Reply to this comment


    @Armetiz: je dirais même plus, tu peux déporter la sauvegarde de la session en bdd avec juste une petite fonction PHP, voir la doc pour plus de détails ;D .

    Edit: http://a-pellegrini.developpez.com/tutoriels/php/session-db/

    Posté le 10 janvier 2009 à 12:46:36

  9. Myst Reply to this comment


    @Siko: Si ce que dit Armetiz est juste, l’optique d’amélioration des performances est perdu.
    Mais sinon, le module Memcache existe avec PHP et n’a pas l’air difficile à mettre en place.

    Posté le 10 janvier 2009 à 18:34:43

  10. coolmic Reply to this comment


    @Armetiz : certes, les données sont stockés sur le serveur, mais un cookie est tout de même stocker sur ton navigateur. Il contient l’id de la session, afin de pouvoir associer à tel visiteur le fichier de session correspondant!

    Posté le 11 janvier 2009 à 00:32:44

  11. coolmic Reply to this comment


    Moi aussi je pense que c’est la meilleur solution. Et ils sont pas obliger de stocker tous les ip, une file LRU devrait suffire.

    Posté le 11 janvier 2009 à 13:54:01

  12. petitchevalroux Reply to this comment


    hihi ! en plus si je dit pas de connerie je crois que memcache est en lru par defaut

    Posté le 11 janvier 2009 à 15:14:37

  13. Toto Reply to this comment


    Ne serait-il-pas possible de rajouter une pause d’une demi-seconde à la vérification du mot de passe coté serveur ?

    Ainsi, pour tester séquentiellement beaucoup de mot de passe, ça rallongerait considérablement le temps d’exécution de toutes les tentatives et pourrait limiter cette pratique, non ?

    Posté le 13 janvier 2009 à 20:04:49

  14. demarcq Reply to this comment


    Un module bien pratique pour apache qui fait bien le boulot : http://www.zdziarski.com/projects/mod_evasive/

    Posté le 13 janvier 2009 à 21:06:53

  15. Anonyme Reply to this comment


    @Siko: « Suffit de mettre une varaible $_SESSION qui s’incrémente a chaque fois qu’un utilisateur remplis un mots de passe faux »

    Mauvais, le bot login n’a qu’à supprimer le cookie entre chaque tentative …

    Posté le 2 octobre 2009 à 21:20:06