PluXml.org

Blog ou CMS à l'Xml

Vous n'êtes pas identifié(e).

#1 02/03/2016 16:54:14

Ring
Membre
Lieu : Bretagne
Inscription : 16/02/2016
Messages : 30

Prévention contre les attaques par Force Brute

Voilà une astuce qui m'a évité de créer un plugin trop compliqué pour moi, comprenant notamment la création d'une table IP Bannies.

Il suffit de rajouter un sleep() dans la fonction d'authentification. Ceci permet une pause trop longue dans le reset pour un robot opérant une attaque par Force Brute.

Donc dans le core/admin/auth.php, à la ligne 81 (PluXml 5.5) :

[== PHP ==]
# Authentification
if(!empty($_POST['login']) AND !empty($_POST['password'])) {

	[...]

	if($connected) {
		header('Location: '.htmlentities($redirect));
		exit;
	} else {
		$msg = L_ERR_WRONG_PASSWORD;
		$error = 'error';
	}
}

Rajouter le sleep(15) sachant que 15 représente une pause de 15 secondes après le message d'erreur pour représenter un nouveau login. S'il s'agit d'un humain, 15 secondes d'attente ce n'est pas très long. En revanche pour un robot, cela allonge gravement le temps nécessaire à l'attaque, au point de l'abandonner.
De plus, le fait de placer l'instruction APRES l'instruction d'erreur, permet de ne pas attendre ces 15 secondes lorsqu'on ne s'est pas trompé (écrasante majorité des cas)  :

[== PHP ==]
# Authentification
if(!empty($_POST['login']) AND !empty($_POST['password'])) {

	[...]

	if($connected) {
		header('Location: '.htmlentities($redirect));
		exit;
	} else {
		$msg = L_ERR_WRONG_PASSWORD;
		$error = 'error';
		sleep(15);
	}
}

Evidemment, je devrai rajouter cette instruction à chaque mise à jour du core. A moins que Stephane ne l'intègre dans la nouvelle version (avec possibilité de mettre le nb de secondes en variable modifiable).

Hors ligne

#2 02/03/2016 19:33:06

DjbWebmaster
Membre
Inscription : 13/07/2012
Messages : 298

Re : Prévention contre les attaques par Force Brute

Merci pour l'astuce   big_smile


Mon labo de templates/Plugins pour le CMS PluXml http://nextum.fr
Templates PluXml et Framework SASS Compass pour PluXml: http://libertea.fr
-----------------------------------------------------
Intégrateur HTML5 https://psd-html.fr
Coming soon http://psdtohtml5.fr
-----------------------------------------------------

Hors ligne

#3 02/03/2016 19:47:56

bazooka07
Membre
Lieu : Quelque part en Rhône-Alpes
Inscription : 06/02/2014
Messages : 768
Site Web

Re : Prévention contre les attaques par Force Brute

C'est une astuce pour un gentil robot qui ne fait qu'une attaque à la fois  big_smile

Je suis étonné qu'il n'y ait pas encore un captcha sur la page de d'authentification comme pour les commentaires.

J'ai un plugin captchaImage qui comble ce manque sur mon dépôt

A++

Hors ligne

#4 02/03/2016 20:02:49

DjbWebmaster
Membre
Inscription : 13/07/2012
Messages : 298

Re : Prévention contre les attaques par Force Brute

Bonsoir bazooka07,

Je ne connais pas ton plugin, mais le lien sur le post ne fonctionne pas

merci d'avance,


Mon labo de templates/Plugins pour le CMS PluXml http://nextum.fr
Templates PluXml et Framework SASS Compass pour PluXml: http://libertea.fr
-----------------------------------------------------
Intégrateur HTML5 https://psd-html.fr
Coming soon http://psdtohtml5.fr
-----------------------------------------------------

Hors ligne

#5 02/03/2016 20:12:38

Gzyg
Membre
Inscription : 25/09/2006
Messages : 837
Site Web

Re : Prévention contre les attaques par Force Brute

Hors ligne

#6 02/03/2016 20:23:42

Ring
Membre
Lieu : Bretagne
Inscription : 16/02/2016
Messages : 30

Re : Prévention contre les attaques par Force Brute

bazooka07 a écrit :

C'est une astuce pour un gentil robot qui ne fait qu'une attaque à la fois  big_smile

Ben oui mais j'ai eu cette idée en trouvant un script d'attaque par force brute de ce genre en php, sans doute pour les newbies et les "mauvais garçons" dont tu parles ailleurs !
Et puis mon blog ne va pas héberger les adresses et n° de tel de toute la cour d'Angleterre non plus...

bazooka07 a écrit :

Je suis étonné qu'il n'y ait pas encore un captcha sur la page de d'authentification comme pour les commentaires.

Je me suis fait la même remarque en découvrant PluXml. Mais je n'aime pas les captcha image et il est hors de question d'utiliser un captcha propriétaire externe.
Ceci dit, j'ai une bonne idée de captcha ludique et accessible mais je ne sais pas suffisamment programmer en php...

@Gzyg : merci mais tu penses bien que j'ai pillé ce site allègrement ! Merci à Bazooka au passage.

Dernière modification par Ring (02/03/2016 20:25:35)

Hors ligne

#7 02/03/2016 21:02:15

bazooka07
Membre
Lieu : Quelque part en Rhône-Alpes
Inscription : 06/02/2014
Messages : 768
Site Web

Re : Prévention contre les attaques par Force Brute

Ce captcha n'utilise aucun plugin propriétaire. On utilise la librairie GD de PHP pour générer une image de mauvaise qualité à partir d'une chaine de caractères. C'est difficile à décoder pour un robot mais encore accessible à un être humain.

Sinon il existe dans les entrailles de Pluxml un captcha basé uniquement sur des lettres qu'il serait facile de mettre en place.

Si tu as une bonne idée et claire d'un captcha ludique tu peux toujours expliquer. Cela ne devrait pas être difficile à coder en PHP.

Hors ligne

#8 13/03/2016 12:51:47

paSlabres
Membre
Inscription : 22/03/2015
Messages : 30

Re : Prévention contre les attaques par Force Brute

Bonjour,

le sujet m'intéresse. Je ne veux pas non plus de captcha propriétaire externe.
Les questions auxquelles des humains peuvent répondre mais pas des robots sourds et aveugles, ça marche ou pas dans les cas d'attaque par force brute ?

Quid des sites polyglottes ? Il faudrait des questions adaptées à chaque langue ?

Hors ligne

#9 13/03/2016 18:03:45

Ring
Membre
Lieu : Bretagne
Inscription : 16/02/2016
Messages : 30

Re : Prévention contre les attaques par Force Brute

J'ai effectué pas mal de recherches sur les captcha à questions. Quelques CMS les ont utilisés un moment puis les ont abandonnés suite à des défections de plus en plus nombreuses. 2 raisons à cela :
- du fait du caractère open source desdits CMS, la librairie initiale questions-réponses était connue et facile à programmer sur un robot,
- l'utilisateur pouvait rajouter ses propres questions-réponses à la librairie mais le faible nombre et la pauvreté imaginative de ces éléments rajoutés rendait aussi facile à contrer.

Attention, on parle bien ici d'attaque par Force brute et non de DDOS.

Hors ligne

#10 13/03/2016 20:12:12

Rubén
Membre
Lieu : Tolosa
Inscription : 11/05/2011
Messages : 108

Re : Prévention contre les attaques par Force Brute

On peut peut-être combiner plusieurs solutions :

  • 15 secondes entre deux essais

  • Une réponse à fournir

  • X essais toutes les Y minutes

Qu'en dites-vous ?


Traduction en occitan de : PluXml (5.4, 5.5, 5.6), plxMySearch, plxMyGoogleAnalytics, plxMyAllArchive, plxMyMailComment, plxMyautoMetaDescription, plxMyBreadcrumb, plxMyComRememberMe, plxMyBetterUrls, plxMyAkismet, plxMyPrivateStatic, plxMyCapchaImage, plxMyMultiLingue, plxMyRescueData, plxMyPager, plxMyContact.
lockArticle + aide, Tweentie, MyTeam, TinyEditor et plxMyShop

Hors ligne

#11 14/03/2016 10:19:38

Ring
Membre
Lieu : Bretagne
Inscription : 16/02/2016
Messages : 30

Re : Prévention contre les attaques par Force Brute

Si le(s) robot(s) possède(nt) le dictionnaire, une seule réponse fera mouche au 1er essai. Donc les tentatives de ralentissement n'y feront rien.

Je suis persuadé que la solution est dans la voie ouverte très (trop ?) simplement par Stephane :
- création d'un mot composé de X (aléatoire mais borné) lettres (aléatoire mais alpha minuscule seulement)
- puis choix d'une lettre (aléatoire) dans ce mot en signalant sa position après une petite transformation (rang 1="première", rang 2="deuxième", last="dernière"...).

Jusqu'à maintenant, à part une alerte durant l'été 2015 ou 2014 (je crois l'avoir lu dans le forum) et due certainement à une attaque "humaine" sur les commentaires ("félicitations pour cet article"...), le captcha propriétaire a réussi à tenir face aux attaques des robots jusque là. Il faut prendre en compte la faible diffusion de Pluxml, comparée au plus gros concurrent, et l'intérêt souvent non stratégique des contenus des utilisations, rendant le développement d'un hack insuffisamment rentable.

Pour le rendre encore plus sûr, peut-être qu'il suffirait de :
- étendre les bornes du nombre de lettres du mot aléatoire (5 à 9)
- étendre le champ des caractères choisis (maj, min, chiffres)
- choisir de 2 à plusieurs caractère(s) dans le mot généré (2 à 4)

Dans tous les cas, la méthode choisie devra obligatoirement être accessible et responsive sans l'apport superflu d'une méthode audio toujours faillible (c'est aussi une des raisons de mon éviction de la méthode image générée).

Hors ligne

#12 14/03/2016 10:28:24

cfdev
Membre
Lieu : Provence
Inscription : 22/07/2011
Messages : 273
Site Web

Re : Prévention contre les attaques par Force Brute

salut,
pour l'admin, il y a un plugin déja existant :

Auth - Version 1.0 (03/01/2012)
Méthode qui évite de casser le mot de passe par brute force
http://www.ecyseo.net/static5/telechargements


Vous voulez créer votre plugin pour pluXml? -> spxdatas est fait pour vous !
mcercle - Logiciel de gestion devis/factures/stock !

Hors ligne

#13 14/03/2016 22:53:14

Ring
Membre
Lieu : Bretagne
Inscription : 16/02/2016
Messages : 30

Re : Prévention contre les attaques par Force Brute

Merci cfdev, je ne le connaissais pas. Je vais voir de quoi il retourne.

Quel dommage que toutes ces ressources (plugin, thèmes) soient éparpillées un peu partout sans même un annuaire pour les recenser - bien qu'il serait meilleur que la communauté regroupe ses ressources sur le site officiel...

Edit : voici la discussion sur le plugin auth : http://forum.pluxml.org/viewtopic.php?id=3050

Dernière modification par Ring (14/03/2016 22:55:45)

Hors ligne

#14 15/03/2016 10:35:44

Rubén
Membre
Lieu : Tolosa
Inscription : 11/05/2011
Messages : 108

Re : Prévention contre les attaques par Force Brute

Il fonctionne avec la version actuelle de PluXml ?


Traduction en occitan de : PluXml (5.4, 5.5, 5.6), plxMySearch, plxMyGoogleAnalytics, plxMyAllArchive, plxMyMailComment, plxMyautoMetaDescription, plxMyBreadcrumb, plxMyComRememberMe, plxMyBetterUrls, plxMyAkismet, plxMyPrivateStatic, plxMyCapchaImage, plxMyMultiLingue, plxMyRescueData, plxMyPager, plxMyContact.
lockArticle + aide, Tweentie, MyTeam, TinyEditor et plxMyShop

Hors ligne

#15 15/03/2016 10:44:19

Ring
Membre
Lieu : Bretagne
Inscription : 16/02/2016
Messages : 30

Re : Prévention contre les attaques par Force Brute

Oui, elle fonctionne bien sur PLuXml 5.5 Beta 3.

Mais ce plugin est basé sur un cookie de session donc il est enfantin de contourner le comptage en effaçant le cookie à chaque tentative.
Ça peut venir en complément de la fonction sleep() proposée en haut de topic pour faire une barrière de plus.

Hors ligne

#16 15/03/2016 14:05:24

Rubén
Membre
Lieu : Tolosa
Inscription : 11/05/2011
Messages : 108

Re : Prévention contre les attaques par Force Brute

On peut carrément empêcher tout le monde de se connecter après 3 tentatives avec le mauvais mot de passe jusqu'à que quelqu'un efface par FTP le fichier le comptable.
Radical mais efficace ^^


Traduction en occitan de : PluXml (5.4, 5.5, 5.6), plxMySearch, plxMyGoogleAnalytics, plxMyAllArchive, plxMyMailComment, plxMyautoMetaDescription, plxMyBreadcrumb, plxMyComRememberMe, plxMyBetterUrls, plxMyAkismet, plxMyPrivateStatic, plxMyCapchaImage, plxMyMultiLingue, plxMyRescueData, plxMyPager, plxMyContact.
lockArticle + aide, Tweentie, MyTeam, TinyEditor et plxMyShop

Hors ligne

#17 15/03/2016 22:24:06

Ring
Membre
Lieu : Bretagne
Inscription : 16/02/2016
Messages : 30

Re : Prévention contre les attaques par Force Brute

Quelques explications dans un français compréhensible ?
Merci Rubén

Hors ligne

#18 16/03/2016 09:22:45

Rubén
Membre
Lieu : Tolosa
Inscription : 11/05/2011
Messages : 108

Re : Prévention contre les attaques par Force Brute

Je la refais.
Mettons on ait drois à trois tentatives, après trois mauvais mots de passe, personne ne peut plus s'identifier.
Pour débloquer la situation, il faut qu'un administrateur supprime le fichier txt où sont compté les tentatives (par FTP par exemple).
Ou sinon aller sur une URL du style www.monsite.com/core/debloquer.php?clef=28f6e29cf70ef8ca38894874f3e950c52457850b qui charge un script qui efface le fichier.
Où la clef serait la même que la clef perso pour le flux RSS privé.
Vous me suivez ?


Traduction en occitan de : PluXml (5.4, 5.5, 5.6), plxMySearch, plxMyGoogleAnalytics, plxMyAllArchive, plxMyMailComment, plxMyautoMetaDescription, plxMyBreadcrumb, plxMyComRememberMe, plxMyBetterUrls, plxMyAkismet, plxMyPrivateStatic, plxMyCapchaImage, plxMyMultiLingue, plxMyRescueData, plxMyPager, plxMyContact.
lockArticle + aide, Tweentie, MyTeam, TinyEditor et plxMyShop

Hors ligne

#19 16/03/2016 10:58:45

Ring
Membre
Lieu : Bretagne
Inscription : 16/02/2016
Messages : 30

Re : Prévention contre les attaques par Force Brute

Merci Rubén pour ton retour.
Alors, si j'ai bien compris, un robot fait 3 tentatives de connexions infructueuses - ou 3 robots, une seule - et le site bloque toute tentative de connexion nouvelle jusqu'à déblocage par l'admin ?
C'est faisable mais (car il y a toujours un mais et ici je me fais l'avocat du diable) si le site fait l'objet d'une attaque ciblée, à quel moment faudrait-il aller le débloquer, sous peine de refaire la manip en permanence ?
D'autre part, le fichier des login manqués devrait être détruit automatiquement de façon régulière. En effet, on ne peut pas considérer que 3 tentatives manquées durant les 6 derniers mois constitue une attaque.
Mais l'idée est bonne à condition, bien sûr, que le fichier du nombre de tentatives ne soit pas lié aux IP (ce que je craignais dans ton idée).

Hors ligne

#20 16/03/2016 11:25:22

bazooka07
Membre
Lieu : Quelque part en Rhône-Alpes
Inscription : 06/02/2014
Messages : 768
Site Web

Re : Prévention contre les attaques par Force Brute

Une alternative serait de bloquer le site un certain temps.
On note l'heure de blocage du site dans un fichier.
Et chaque visite suivante, on regarde si le site a été suffisamment bloqué pendant un certain temps, disons 1 à 2 heures.
Bien sûr on envoie un mail d'alerte à l'admin en début de blocage.

Hors ligne

#21 16/03/2016 11:54:45

Rubén
Membre
Lieu : Tolosa
Inscription : 11/05/2011
Messages : 108

Re : Prévention contre les attaques par Force Brute

On peut rassembler les idées !
Non je ne pensais pas lier les tentatives avec les adresses IP.
Tu as raison d'indiquer que 3 tentatives en 6 mois et 3 en une minute ce n'est pas pareil.
Il faudrait faire un tableau avec la date de la tentative et nettoyer de temps en temps.
On peut aussi bloquer le site un certain temps, ou accélérer les choses via la méthode dont je parlais.
Très bien aussi l'idée du courriel à l'admin.


Traduction en occitan de : PluXml (5.4, 5.5, 5.6), plxMySearch, plxMyGoogleAnalytics, plxMyAllArchive, plxMyMailComment, plxMyautoMetaDescription, plxMyBreadcrumb, plxMyComRememberMe, plxMyBetterUrls, plxMyAkismet, plxMyPrivateStatic, plxMyCapchaImage, plxMyMultiLingue, plxMyRescueData, plxMyPager, plxMyContact.
lockArticle + aide, Tweentie, MyTeam, TinyEditor et plxMyShop

Hors ligne

#22 16/03/2016 15:28:49

Ring
Membre
Lieu : Bretagne
Inscription : 16/02/2016
Messages : 30

Re : Prévention contre les attaques par Force Brute

Oui, l'idée du mail à l'admin est bonne.
On pourrait aussi neutraliser le blocage lorsque l'admin est connecté ou au moins lui lancer une alerte en ligne.

Donc, je récapépète :
* 1ère connexion manquée -> mise en mémoire du numéro de tentative + de la date/heure/min/sec de la tentative. Comparaison de l'heure avec N-2. Si la différence est inférieure à D (durée maxi entre 3 connexions ratées), alors blocage. Dans ce cas 1ère tentative, N-2 n'existant pas ou différence supérieur à D, pas de blocage.
* 2ème connexion manquée -> mise en mémoire du numéro de tentative + de la date/heure/min/sec de la tentative. Comparaison de l'heure avec N-2. Si la différence est inférieure à D (durée maxi entre 3 connexions ratées), alors blocage. Dans ce cas 2ème tentative, N-2 n'existant pas ou différence supérieur à D, pas de blocage.
* 3ème connexion manquée -> mise en mémoire du numéro de tentative + de la date/heure/min/sec de la tentative. Comparaison de l'heure avec N-2 (la 1ère connexion). Suppression des données N-3 devenues inutiles. Si la différence est inférieure à D (durée maxi entre 3 connexions ratées), alors blocage.
- Procédure de blocage : création d'un htaccess ? L'admin est-il connecté ? Oui = alerte, Non = Envoi d'un mail auto à l'admin. Mise en route d'un minuteur (ou cron ?) et comparaison régulière avec la date N-2. Dès que la différence est supérieure à D -> déblocage = nouveau htaccess. Possibilité de déblocage manuel par l'admin à tous moments.

En fait, le fichier ne garderait en permanence que les 3 derniers logs ratés (N° + Date/Heure).
Au départ j'avais une tout autre idée basée sur le concept du captcha. Mais ceci remplacerait carrément le captcha, ce qui serait meilleur.

Qu'en pensez-vous ?

Hors ligne

#23 16/03/2016 15:49:29

bazooka07
Membre
Lieu : Quelque part en Rhône-Alpes
Inscription : 06/02/2014
Messages : 768
Site Web

Re : Prévention contre les attaques par Force Brute

Non ! pas de .htaccess svp
Il n'y a pas que Apache, il y a aussi Nginx qui va mieux. C'est comme Windows ...

On crée un fichier de log dans le dossier de données et on consulte la dernière ligne. En n'oubliant pas de faire un logrotate suivant le temps ou la taille

Tout le monde ne saura pas régler un crontab sur un hébergement mutualisé. Il vaut mieux consulter le fichier de logs à chaque visiteur.

Hors ligne

Pied de page des forums

A propos Nous soutenir Contact Twitter Google+
Copyright © 2006-2017 PluXml.org, tous droits réservés