Bonjour,

J'ai actuellement un formulaire de connexion. Est ce que limiter le nombre d'erreurs par IP est une protection relativement efficace contre une attaque type brute force ?

Slt ,

Pour lutter contre les attaques par brute force , tu as plusieurs choses possible ,

le plus efficace , Niveau serveur ,

- ipchain / iptables
- mod_evasive d'apache 2

Ensuite , si tu n'as pas acces au niveau serveur , au niveau code , tu peux :

- mettre un délai entre chaque tentatives
- limiter effectivement le nombre d'essais par ip
- un ban de X minutes si trop de tentatives échoués
- vérifier que toutes les demandes de connexions proviennent bien de TON formulaire ( login , mdp )
- Forcer tes utilisateur à avoir un mot de passe solide !

Voilà , il doit y avoir d'autres pistes .. mais ce que j'ai cité ci-dessus est déjà pas mal contre les brute force.

Ch.

J'aimerais ajouter que tu peux faire ça avec les sessions, c'est
en général ce qui marche le mieux, tu peux faire ça avec une
base de données, en y stockant l'IP de l'attaquant, mais c'est
un peu plus lent...

Créer un formulaire dynamique, et faire en sorte que le nom des champs change à chaque tentative de connexion.
Exemple de se que je fais :

//-->Définition du fuseau horaire à utiliser.//
	    date_default_timezone_set("Europe/Paris");

	    //-->Création dynamique des noms des champs.//
	    $_SESSION['form_connexion'] = md5('connexion' . date('r')); #Création nom bouton  'Connexion' crypté et ajout de la date au format RFC 2822.
	    $_SESSION['form_login'] = md5('login' . date('r')); #Création du champ 'login' crypté et ajout de la date au format RFC 2822.
	    $_SESSION['form_pass'] = md5('pass' . date('r')); #Création du champ 'password' crypté et ajout de la date au format RFC 2822.

        //->Création du formulaire de connexion.//
        $form_connexion = 'Login :<input name="' . $_SESSION['form_login'] .
	        '" style="width: 80px" type="text" value="" /><br />
					 Pass :&nbsp;&nbsp;&nbsp;<input name="' . $_SESSION['form_pass'] .
	        '" style="width: 80px" type="password" value="" /><br />
					 <input name="' . $_SESSION['form_connexion'] .
	        '" type="submit" value="Connexion" /></div>';

Donc les noms des champs sont crypté ET change a chaque tentative de connexion (alors pour les forces brute bonne chance)
Et pour être vraiment tordu on pourrais aussi faire en sorte que login corresponde a password et inversement.

Dunbar, je peux te faire en quelques minutes un robot qui va sur la page d'accueuil, analyse la source et renvoi le formulaire complété. C'est plus long qu'un brute force conventionnel mais ca marche même avec ta protection.

Mais je prends note de vos astuces.

Dunbar, je peux te faire en quelques minutes un robot qui va sur la page d'accueuil, analyse la source et renvoi le formulaire complété. C'est plus long qu'un brute force conventionnel mais ca marche même avec ta protection.

Mais je prends note de vos astuces.

Ah oui va falloir m'expliquer ça, comment il fait ton robot pour connaitre le nom des mes champs ,le login et le pass du premier coup.
Parce que OK tu enregistre le code source.
Alors d'abord va dejà falloir connaitre le nom des champs, et même si par miracle tu y arrive quand tu va injecter ton code il ne sera de toute façon plus valable.
Parce que je pense que si tu étais aussi capable de faire une telle chose ta question n'aurais aucun pas lieu d'être.

genre en javascript dunbar, c'est facile.

genre en javascript dunbar, c'est facile.

Tu pourrai m'expliquer ça stp pour mon information
Pour rappel on voulais éviter une attaque par force brute uniquement.

parsing de ton formualire généré, peu importe la valeur de name, ca ne protège rien en soi.

ca ne protège rien en soi.

Si le nom ne correspond pas la connexion ne sera jamais valider.
Et de toute façon c'est pas une attaque par force brute ça, je me trompe

oh ok, et donc il faut qu'il remplisse le formulaire en moins de une seconde? ca pour sur c'est efficace, ni les bots ni les humains ne pourront bypasser cette sécurité.

Bon je recommence.

Je crée une SESSION.
Je génère les noms des champs en utilisant une signature MD5 + la date + H.M.S.
Une fois générer ces valeurs sont en SESSION.

Donc libre à l’utilisateur de prendre 5 minutes pour remplir le formulaire ces valeurs ne change qu’a chaque invocation de la page.

Donc pour l’utilisateur c’est invisible mais pour un boot lui qui va faire grand nombre d’essai, les valeurs change à chaque fois, donc pour que l’attaque fonctionne il lui faut trouver en une seule fois, les 3 noms de champs, le login, et le password, tu avoueras quand-même que c’est une protection relativement efficace.

vive les regexp suivie des appels curl avec les quels tu recuperes le cookie de session

Je vois quelques choses comme :

Tu appel la page de formulaire avec une fonction comme curl en recuperant le cookie de session.

Tu parse la page recupere les noms de chaque input

tu sais par exemple que le premier est le login , le second etc ... bref tu renseigne les valeur

et tu envois a l'url que tu as préalablement recuperer en prennant de réinjecter le cookie de connexion.

ceci juste avec PHP ^^ apres avec d'autre language hein

(meme si tout d'un coup les cookies de session j'ai un doute , mais je suis sur d'en avoir deja vu )

Bye Hawk

Non, la raison pour laquelle la technique est efficace (combinée avec un timeout à chaque échec pour l'IP incriminée), c'est que c'est beaucoup trop coûteux. De même qu'il est coûteux de passer par un proxy anonyme pour s'affranchir de l'IP. Quand on doit faire un essai, ça passe tout seul, quand on doit en faire des millions, ce n'est pas viable…

Bon je recommence.

Je crée une SESSION.
Je génère les noms des champs en utilisant une signature MD5 + la date + H.M.S.
Une fois générer ces valeurs sont en SESSION.

Donc libre à l’utilisateur de prendre 5 minutes pour remplir le formulaire ces valeurs ne change qu’a chaque invocation de la page.

Donc pour l’utilisateur c’est invisible mais pour un boot lui qui va faire grand nombre d’essai, les valeurs change à chaque fois, donc pour que l’attaque fonctionne il lui faut trouver en une seule fois, les 3 noms de champs, le login, et le password, tu avoueras quand-même que c’est une protection relativement efficace.

Meuh non ca ne change rien, l'absence d'information permettant l'identification du champ login par rapport au champ password ne change absolument rien, un bruteforce comme son nom l'indique c'est un truc brutal, bête et méchant, on teste tout un milliard de fois jusqu'a ce que ca passe, tout ce que tu fais c'est multiplié les proba par 3 vu que chaque combinaison doit etre testée sur chaque champ. En revanche la remarque de sekil est plus intéressante, le fait d'allonger par voie de timeout chaque tentative en erreur c'est bien, le seul soucis c'est que le bruteforce à alors un moyen de mettre ton serveur sur les genoux, le mieux est de repérer le nombre d'erreur et de faire des blacklist d'ip de 24h dans le firewall comme stopher disait au début du thread.