[nono67]

Encore une fois merci pour tes explications et ton aide Cassiopée, tu es d'une réelle utilité publique

Désolé de ne pas t'avoir répondu avant mais j'étais en déplacement.

[cassiopee]

Encore merci Cassiopée pour ta précieuse aide

J'ai trouvé mon fichier "sudoers", il est bien dans etc/sudoers dans une release 3, est-il nécessaire de poster ce fichier ici ?

Non, ce n'est pas nécessaire puisque tu devras y ajouter des choses.

Dans quelle section de ma page phpinfo.php dois-je regarder pour trouver l'utilisateur d'apache ?

Si ce n'est pas là, c'est dans doute du côté des fonctions PHP :

print "User : ". posix_getpwuid(posix_geteuid())[name]."
\n";

Sinon, un simple "ls -al" dans le répertoire racine d'un site web devrait également te donner ces infos.

Dans quel fichier puis-je trouver les utilisateurs d'Apache ?

=> Fichiers de configuration d'Apache, lire la doc pour savoir où précisément.

A priori, tous les utilisateurs d'apache de mes sites web sont dans le même groupe "users".

Tant mieux.

Quelle serait le ligne de code à mettre dans le fichier sudoers afin d'autoriser le groupe "users" à ajouter des Ip à bannir dans iptables depuis un script php ?

Comme pour tout le reste : lis la documentation

Par exemple là :

https://www.digitalocean.com/communi...ntu-and-centos

ou encore là :

http://www.linuxtricks.fr/wiki/sudo-...-et-parametrer

J'ai trouvé cela dans le fichier sudoers (que faut-il faire avec le password ?) :

Je n'ai pas compris la question. Etant donné que tu utiliseras un script, il ne faut pas qu'il y ait
une demande interactive de mot de passe pour utiliser iptables, c'est donc la variante "sans mot de passe"
qu'il faut utiliser.

Sur ce site https://doc.ubuntu-fr.org/sudoers, il est dit :

Oui, c'est un avertissement normal. Dans le monde Unix, il y a une hiérarchie des comptes, des droits associés, etc.

Or le mécanisme de "sudo" permet d'outrepasser cette hiérarchie, il faut donc faire attention à ce que l'on autorise ou pas.

[nono67]

Encore merci Cassiopée pour ta précieuse aide

J'ai trouvé mon fichier "sudoers", il est bien dans etc/sudoers dans une release 3, est-il nécessaire de poster ce fichier ici ?

Dans quelle section de ma page phpinfo.php dois-je regarder pour trouver l'utilisateur d'apache ?

Dans quel fichier puis-je trouver les utilisateurs d'Apache ?

A priori, tous les utilisateurs d'apache de mes sites web sont dans le même groupe "users".

Quelle serait le ligne de code à mettre dans le fichier sudoers afin d'autoriser le groupe "users" à ajouter des Ip à bannir dans iptables depuis un script php ?

J'ai trouvé cela dans le fichier sudoers (que faut-il faire avec le password ?) :

## Allows people in group users to run all commands
# %users ALL=(ALL) ALL

## Same thing without a password
# %users ALL=(ALL) NOPASSWD: ALL

Sur ce site https://doc.ubuntu-fr.org/sudoers, il est dit :

Attention aux brèches de sécurité !
Faites extrêmement attention lorsque vous autorisez un utilisateur ou un groupe à exécuter une commande sans mot de passe. Ceci pourrait causer des brèches de sécurité si les commandes autorisées sont potentiellement dangereuses.

[cassiopee]

Si j'ai bien compris, le code php pour bannir/débannir une IP sera :

- Bannissement : $IP_ADDRESS (l'ip à bannir)
- Dé-bannissement = 1 hour (on peut bien sur faire varier comme l'on veut cette durée). Si j'ai bien pigé on a rien à faire de particulier, au bout d'une heure cette IP sera enlevée d'iptables, c'est bien cela ?

C'est tout à fait ça.

Si je dis pas de bêtise, chaque site web qui tourne sur mon serveur dédié à un utilisateur différent sous Apache,

ça déjà il faut le vérifier, il est possible que tous les sites fonctionnent avec l'utilisateur Apache.
Un script PHP avec "phpinfo();" devrait te donner cette info.

donc si je déploie cette technique de bannissement d'IP via un champ caché sur tous mes sites il faudra que j'autorise tous ces utilisateurs.

Dans l'absolu oui, maintenant creuse aussi l'idée d'autoriser non pas utilisateur par utilisateur mais d'autoriser
un groupe d'utilisateurs (groupe dont font partie tous tes utilisateurs de sites web, du genre "users", "wheel", etc.).

Si c'est possible, ça te ferait ne faire qu'une seule autorisation.

Y a-t-il un fichier "sudoers" sur une Release 3 ? Sinon quel sera le nom du fichier à modifier ?

Avec une Release 3 je n'en ai aucune idée n'ayant jamais eu cette distribution entre les mains.

Si ma mémoire est bonne, la Release 3 s'appuie sur une distribution CentOS donc :

https://www.centos.org/docs/5/html/5...root-sudo.html

Le fichier "/etc/sudoers" semble exister.

Ne reste plus qu'à paramétrer sudo :

http://www.linuxtricks.fr/wiki/sudo-...-et-parametrer

ou encore :

http://www.italic.fr/crontab-avec-su...e-sous-centos/

[nono67]

On peut par exemple autoriser l'utilisateur sous lequel tourne Apache à appeler iptables (fichier "sudoers" ou équivalent)
puis lancer un appel en PHP du genre :

exec ("sudo iptables -I INPUT 1 -s $IP_ADDRESS-j DROP");

où "$IP_ADDRESS" est une variable contenant l'adresse IP à bannir.

Si j'ai bien compris, le code php pour bannir/débannir une IP sera :

exec ("sudo iptables -I INPUT 1 -s $IP_ADDRESS -j DROP && { echo "iptables -D INPUT -s $IP_ADDRESS -j DROP" | at now + 1 hour; }");

- Bannissement : $IP_ADDRESS (l'ip à bannir)
- Dé-bannissement = 1 hour (on peut bien sur faire varier comme l'on veut cette durée). Si j'ai bien pigé on a rien à faire de particulier, au bout d'une heure cette IP sera enlevée d'iptables, c'est bien cela ?

Si je dis pas de bêtise, chaque site web qui tourne sur mon serveur dédié à un utilisateur différent sous Apache, donc si je déploie cette technique de bannissement d'IP via un champ caché sur tous mes sites il faudra que j'autorise tous ces utilisateurs.

Y a-t-il un fichier "sudoers" sur une Release 3 ? Sinon quel sera le nom du fichier à modifier ?

[cassiopee]

Héhé, merci Buddy

[buddy]

https://forum.ovh.com/showthread.php...l=1#post678857

[nono67]

Merci cassiopee.

Je crois effectivement qu'il faut bannir l'IP du robot pour être tranquille.

Si je dis pas de bêtise la commande iptables n'est executable que par l'user root, comment faire pour l'utiliser dans du code php ?

[cassiopee]

Merci pour toutes vos réponses.

J'ai constaté sur les 2 attaques que le robot n'utilisait qu'une seule IP différente à chaque fois, j'ai donc bannit manuellement ces 2 IP via iptables.

Oui, dans ce cas, c'est très simple et cela suffira sans doute à résoudre ton problème.

Cassiopée tu dit :

Dans la condition 3 si le champs caché est rempli il s'agit donc d'un robot, cassiopee peux-tu développer ton idée (avec tache cron) étape par étape de ce qu'il faut mettre en place comme script (du bannissement au dé-bannissement) car je ne vois pas trop comment faire techniquement

Cf le message n°22 plus haut.

Dans la ligne PHP qui appelle la commande "iptables", tu ajoutes (tout à droite, il faut bien scroller à droite pour le voir)
le bout de commande "at" nécessaire afin de débannir au bout de X temps, dans mon exemple, au bout de 1 heure
("now +1 hour" = heure actuelle +1 heure).

ça revient à dire "ajouter une règle pour bannir cette IP et dans une heure, retire cette règle", ce qui revient à débannir l'IP
dans une heure.

Bien entendu, on peut prévoir un délai plus long, en heures ou en jours, il suffit d'adapter les paramètres de la commande "at".

N'est-il pas plus simple de mettre en place, dans le cas d'un champs caché rempli, une redirection vers ma page erreur 404 ou de mettre une redirection vers une page extérieure à mon site ?

Pour ce qui est d'une redirection vers une page extérieure, tu y répondais un peu toi-même précédemment en évoquant
une éventuelle conséquence en terme de référencement par Google ou autre. Ne pas perdre de vue que si tu es pilonné
et que tu renvoies vers un autre site extérieur, cela revient à dire que tu fais en sorte que l'attaquant pilonne un autre site web

(et pour peu que les entêtes HTTP Referer soient alimentés, l'autre site web saura que ça vient en fait de chez toi ...)

Pour ce qui est de rediriger vers du 404, pourquoi pas mais :

1) ce genre de script ne vérifie généralement pas le statut de retour du serveur web visé donc il va continuer à te pilonner.
(j'en ai vu qui insistaient même avec un code d'erreur 403 ...)

2) si tu ne bannis pas par iptables, tu vas quand même garder de la charge pour ton serveur. Moindre sans doute que
lorsque tu envoyais un email mais malgré tout pas forcément négligeable. Disons que si les attaques sont très brèves
(genre 5-10 minutes), cela fera peut-être ramer le serveur pendant ce temps et si c'est une fois par jour, ça va, ça passe.
Si c'est plus long (30 minutes, 60 minutes) ou si c'est plus fréquent (1 fois par heure et non 1 fois par jour), ce serait sans doute
mieux de bannir par iptables.

3) Sans bannissement d'IP, il y aura toujours une belle pollution des fichiers de logs Apache des sites web concernés.
Outre la taille des fichiers de logs que cela peut générer, ça peut fausser des stats de visites, etc.

[buddy]

Pas besoin de redireger vers une autre page.

Tu peux, si la condition est validée (bot détecté) tu peux mettre


Echo "erreur dans le formulaire" ;
header("HTTP/1.0 404 Not Found");
Exit() ;

[nono67]

Merci pour toutes vos réponses.

J'ai constaté sur les 2 attaques que le robot n'utilisait qu'une seule IP différente à chaque fois, j'ai donc bannit manuellement ces 2 IP via iptables.

Cassiopée tu dit :

L'ordre chronologique est :

1) on reçoit les données saisies dans le formulaire HTML dans des variables ($_POST[] ou équivalent)
2) on purge les variables des caractères/séquences interdits (blocage des SQL injection et autres)
3) on vérifie si telle condition est remplie (champ caché non vide par exemple), si oui => bannissement de l'IP et fin du programme, on ne passe pas à l'étape 4
4) si tout va bien jusqu'ici (autres contrôles de saisie), alors seulement on envoie le mail.

Dans la condition 3 si le champs caché est rempli il s'agit donc d'un robot, cassiopee peux-tu développer ton idée (avec tache cron) étape par étape de ce qu'il faut mettre en place comme script (du bannissement au dé-bannissement) car je ne vois pas trop comment faire techniquement

N'est-il pas plus simple de mettre en place, dans le cas d'un champs caché rempli, une redirection vers ma page erreur 404 ou de mettre une redirection vers une page extérieure à mon site ?

[cassiopee]

Ce n'est pas un DOS mais juste des robots SPAM

C'est toi qui évoque "des centaines voir des miliers" d'adresses IP, ce n'est pas moi

Je n'ai encore jamais vu de robots de spam utiliser des milliers d'IP, c'est plutôt
pour du DDoS effectivement mais bon, admettons.

s'il y a des milliers d'IP il ne faut d'autant plus ne pas les bannir car
pour les bannir il faut vérifier s'il a validé le formulaire => Si oui alors on bannis l'IP => très bien mais le mail est parti et et le mal est fait.

Comment ça "le mail est parti" ? Le bannissement se fait bien évidemment *avant* l'envoi du mail
dans le code pas après sinon cela n'aurait plus aucun intérêt.

L'ordre chronologique est :

1) on reçoit les données saisies dans le formulaire HTML dans des variables ($_POST[] ou équivalent)
2) on purge les variables des caractères/séquences interdits (blocage des SQL injection et autres)
3) on vérifie si telle condition est remplie (champ caché non vide par exemple), si oui => bannissement de l'IP et fin du programme, on ne passe pas à l'étape 4
4) si tout va bien jusqu'ici (autres contrôles de saisie), alors seulement on envoie le mail.

et bannir des milliers d'IP ce n'est pas viable pour les ressources.

Déjà cela dépend de quel chiffre on parle précisément mais par exemple 2000 IP (ce qui serait déjà beaucoup
pour ce genre d'activités non DDoS), cela ne pose pas vraiment de problème dans une machine actuelle.

J'ai déjà eu des machines avec bien plus d'IP bloquées (+ de 10000) et ça fonctionnait parfaitement.
Evidemment, ce n'est qu'une situation temporaire, le temps de gérer l'attaque.

Et encore une fois, ne pas les bannir voudrait dire de laisser 2000 IP pilonner librement le serveur web de requêtes HTTP.
Même avec un script PHP ne faisant qu'un simple "exit();" , cela mettrait bien plus à genoux le serveur web
et donc le serveur dédié tout entier.

Ce serait bien plus consommateur de ressources qu'un blocage d'adresses IP au niveau d'iptables.
C'est d'ailleurs l'un des symptômes évoqués par Nono67 :

J'ai même un client qui était entrain de payer sa commande sur mon site et qui n'a pas pu la finaliser
parce que mon site était inaccessible à cause de ce robot de merde....

Et s'il n'y a que 200 ou 20 adresses IP attaquantes en jeu, le raisonnement est le même.

enfin on ne part pas sur des règles iptables sans filtrer un minimum. ce qui est posté dans les formulaires.

Mais l'un n'empêche pas l'autre. On peut à la fois bannir lorsque telle ou telle condition est remplie
et nettoyer par ailleurs les données saisies. Cf supra.

[boris44]

Ce n'est pas un DOS mais juste des robots SPAM

s'il y a des milliers d'IP il ne faut d'autant plus ne pas les bannir car
pour les bannir il faut vérifier s'il a validé le formulaire => Si oui alors on bannis l'IP => très bien mais le mail est parti et et le mal est fait.
et bannir des milliers d'IP ce n'est pas viable pour les ressources.

enfin on ne part pas sur des règles iptables sans filtrer un minimum. ce qui est posté dans les formulaires.

[cassiopee]

je ne pense pas que bannir l'ip soit une solution. car tu risques d'avoir besoin d'en bannir des centaines voir des miliers.

Dans ce contexte, s'il y a des centaines, voire des milliers d'IP différentes qui sollicitent le serveur, même si le script PHP gérant
le formulaire HTML fait rapidemment un "exit();", cela va quand même faire ramer le serveur dédié et noyer les
fichiers de logs sous un déluge d'appels stériles.

Mais depuis le début de ce thread on ne sait pas si on a affaire :

- à une seule IP attaquante ?
- à 10 IP attaquantes ?
- à 100 IP attaquantes ?
- à 10000 IP attaquantes ?

La réponse la plus adaptée dépend quand même pas mal de ce facteur.

[cassiopee]

Je ne connais pas très bien iptables est-ce possible depuis ma page php de bannir l'IP via iptables et de la rétablir dans XXX minutes (un peu comme fail2ban) ? Si oui, quel serait le code php pour bannir l'IP et la rétablir dans XXX minutes ?

Je ne comprends pas bien pourquoi tu voudrais un bannissement temporaire ?
Si tu re-autorises l'IP, le gars va revenir à la charge rapidement par ce biais.

A moins que tu n'aies des sites dans un domaine sensible (politique, sociétal, etc.), ce genre d'attaques
est plutôt ponctuel. Le gars va essayer pendant quelques jours/semaines et puis il ira voir ailleurs.

Donc il est important que les adresses IP bannies le soient pendant toute cette durée,
pas pour une heure ou deux seulement. (*)

Avec iptables je ne pense pas qu'il y ait moyen de le faire directement. Il faudra créer une tâche cron,
au moment du bannissement, qui aille supprimer le bannissement X temps après.

Si tu y tiens malgré tout, quelque chose dans ce genre :

iptables -I INPUT 1 -s $IP_ADDRESS -j DROP && { echo "iptables -D INPUT -s $IP_ADDRESS -j DROP" | at now + 1 hour; }

(*) bien entendu, une fois l'attaque passée, on libère les IP. Il ne s'agit pas de faire
un bannissement éternel, ce qui n'aurait aucun sens.

[boris44]

Bonjour,

je ne pense pas que bannir l'ip soit une solution. car tu risques d'avoir besoin d'en bannir des centaines voir des miliers.
La première chose à faire est de mettre en place un captcha.


Après tu peux ajouter un input de type hidden vide

"hidden" name="city" value="">
et dans le traitement
if( $_POST["city"] != "") {
   exit(1);
}

Si le robot détecte les type hidden et ne les remplis pas, tu met type="text" class="secure"
et tu le fais disparaitre en css

.secure{ display:none; }

Sinon ces robots ne gèrent pas le javascript.
Tu peux mettre un cookie en javascript
et lors du POST vérifier la présence de ce cookies

=> ne met pas ce code à coté de ton formulaire car si l'attaquant analyse tes sources il va comprendre très cite, tu le planques

et dans le traitement :

$cookie = substr( md5($_SERVER["REMOTE_ADDR"], 10, 17 );
if( $_COOKIE["contact"] != $cookie ) {
	exit(1);
}

// Traitement du POST

...

Bon courage
A+

[sich]

Aurais-tu un bout de code php de ce script ?

Est-ce que Fail2ban ne peut pas filtrer/bannir les IP en cas d'envoi massif d'emails ?

Non je n'ai pas de code sous la main (je code assez peu, je suis sysadmin à la base).
Mais en gros tu dois faire ça :
- Avoir un dossier spécifique sur ton site pour gérer le cache de ta fonction.
- Lors d'une tentative d'envoi de mail tu vérifies si il existe un fichier qui porte le nom de l'ip du gus qui essaie de poster.
- Si le fichier n'existe pas, tu le crées et tu y enregistres le timestamp, puis tu continues sur ta fonction d'envoi de mail. Tu crées un 2° fichier, du genre nbr_. Dans ce fichier tu mets 1.
- Si le fichier existe déjà, tu récupères la valeur du timestamp.
- Si le délais est trop court (à toi de le définir, mais au moins 1min) tu remets à jour ton timestamp, tu arrêtes ton script et tu renvoies une erreur. A côté de ça tu ouvres ton fichier nbr_, tu récupères la valeur et tu incrémentes ton compteur. A partir de 5 tu définies une action pour bannir l'ip concernée. Là vu que le parefeu se configure en root à toi de voir comment gérer ça.
- Si le délais est ok tu remets à jour la valeur timestamp dans ton fichier.

Pour le parefeu tu peux essayer de t'y coller avec fail2ban. Par exemple un fichier blocage dans lequel tu mets l'IP du méchant si il fait trop de tentatives. Sur fail2ban tu définis ton fichier comme source, tu mets un max retry à 1 et un findtime à 10min.
Par contre je ne sais pas comment va se comporter fail2ban si toi de ton côté tu ouvres / referme le fichier. Je ne sais pas si fail2ban sera capable de détecter la modification. Ou sinon peut être passer par syslog pour écrire dans ce fichier pour ne pas perturber fail2ban... A voir dans la pratique comment cela peux se gérer.

Mais normalement avec cela tu vas déjà empêcher l'envoi des mails, mais tu n'empêcheras pas la surcharge liée à l'appel de la page. Je ne sais pas quel "poids" fait cette page, mais tu peux tjrs vérifier au tout début du chargement du formulaire si tu as une entrée dans ton cache avec l'IP du visiteur + 1 timestamp inférieur à x minutes + un max retry à 5 ou plus... Et de là tu stop directement le chargement de ton script histoire de limiter au max l'impact sur ton serveur.

Voili, ça fait beaucoup de blabla mais côté code ça va pas faire très lourd (quelques if file exist, des fopen, fwrite, etc etc)...

[EDIT]
Penser à ajouter un script qui va vider ton dossier de cache toutes les nuits par exemple histoire de ne pas le laisser devenir trop gros.
[/EDIT]

[nono67]

Avec la technique du champ caché, lorsque tu détectes qu'il n'est pas vide, c'est là que :

1) tu le bannis instantanément via iptables, il est donc bloqué, il ne peut plus accéder à tes sites web, donc à tes formulaires HTML
et donc ne peux t'envoyer d'email ultérieurement.

Je ne connais pas très bien iptables est-ce possible depuis ma page php de bannir l'IP via iptables et de la rétablir dans XXX minutes (un peu comme fail2ban) ? Si oui, quel serait le code php pour bannir l'IP et la rétablir dans XXX minutes ?

[cassiopee]

Le but que je recherche est de le stopper (en bannissant son adresse IP) le plus rapidement possible, il m'a saturé mon serveur à deux reprises et cela en l'espace de quelques secondes (maxi 10 à 15 secondes). J'ai même un client qui était entrain de payer sa commande sur mon site et qui n'a pas pu la finaliser parce que mon site était inaccessible à cause de ce robot de merde....

Si je me contente de filtrer en php les champs de mes formulaires, il va continuer à essayer d'envoyer des emails en boucle et ça saturera quand même mon serveur.

Non, tu peux dire que s'il y a telle ou telle séquence de caractères dans un champ saisi, je bannis l'IP de l'émetteur.
(dès le premier envoi, donc il sera ensuite bloqué).

Il faut bien choisir la séquence, si elle est trop courte (du genre "select") tu risque de bannir à tort.
Si la séquence est trop longue, le pirate pourra changer facilement son code et passer outre.
Il faut trouver un juste milieu afin d'éviter les faux positifs.

Avec la technique du champ caché, lorsque tu détectes qu'il n'est pas vide, c'est là que :

1) tu le bannis instantanément via iptables, il est donc bloqué, il ne peut plus accéder à tes sites web, donc à tes formulaires HTML
et donc ne peux t'envoyer d'email ultérieurement.

2) tu arrêtes simplement le programme PHP donc aucun email n'est émis. Le pirate peut recommencer mais ça ne changera rien,
tout au plus, un peu (un tout petit peu) plus de charge pour ton serveur par rapport à l'option 1 mais c'est tout.

au choix.

Rien ne t'empêche de cumuler les deux techniques d'ailleurs (ceinture et bretelles )

Si je met en place dans mes formulaires une redirection vers une page affichant des pubs (comme le préconise cassiopee j'ai peur que Google assimile mon site et cette page (url) de pub, en terme de référencement ce serait pas top du tout !

C'était une plaisanterie

[buddy]

Si tu filtres et que tu affiches un message d'erreur, il arrêtera puisqu'il verra que çà ne sert à rien...

Sinon, tu ouvres tes logs apache et tu bannis l'ip à la main si c'est toujours la même.

[nono67]

Le but que je recherche est de le stopper (en bannissant son adresse IP) le plus rapidement possible, il m'a saturé mon serveur à deux reprises et cela en l'espace de quelques secondes (maxi 10 à 15 secondes). J'ai même un client qui était entrain de payer sa commande sur mon site et qui n'a pas pu la finaliser parce que mon site était inaccessible à cause de ce robot de merde....

Si je me contente de filtrer en php les champs de mes formulaires, il va continuer à essayer d'envoyer des emails en boucle et ça saturera quand même mon serveur.

Si je met en place dans mes formulaires une redirection vers une page affichant des pubs (comme le préconise cassiopee j'ai peur que Google assimile mon site et cette page (url) de pub, en terme de référencement ce serait pas top du tout !

Que faire ?

[buddy]

Merci pour tes conseils Buddy.

C'est vrai qu'on peut toujours mettre des vérifications dans le code php du type :

... mais quand tu as 30 champs dans un formulaire et qu'il faut vérifier pour chaque champs qu'il ne soit pas vide, qu'il existe, qu'il ne doit pas avoir de chiffre, qu'il ne peut pas avoir plus de 5 consonnes de suite (du style "mglkh"), qu'il ne doit y avoir de "select(" ou de "from(", etc... c'est un peu lourd à gérer, non

ce n'est pas si lourd, tu fais une fonction type qui vérifie tout et ensuite tu lui passes tes variables.

C'est la seule solution efficace à 99.99% du temps ... Tu n'auras aucune solution "simple" qui fait le tri sans aucun soucis. Tu n'es pas obligé de lister tous les champs non plus.
Tu peux limiter les champs noms et prénoms à 20 ou 30 caractères et ne véirifé par la suite que les champs texte "libre".

Si tes 30 formulaires sont proches, si tu fais bien le premier, avec un logiciel de merge, çà va vite.

[cassiopee]

Ton idée de champ HTML caché me plait

ça a l'avantage d'être très simple à mettre en oeuvre et indépendant d'autres choses
(quel serveur SMTP utilise-t'on ? Utilise-t'on ou pas fail2ban ? etc.)

Est-ce imparable contre ce type de robot ?

Dans l'absolu, rien n'est imparable mais d'expérience, oui, c'est très efficace.

L'utilises-tu dans tes formulaires ?

Oui, surtout si c'est un site "à risque".

Comment tu fait pour bannir l'IP via iptables ?

Euh ... ben tu l'appelles depuis ton code ?

Comme c'est pas mal lié à la gestion de la sécurité de ton serveur, le modus operandi exact peut varier grandement.

On peut par exemple autoriser l'utilisateur sous lequel tourne Apache à appeler iptables (fichier "sudoers" ou équivalent)
puis lancer un appel en PHP du genre :

exec ("sudo iptables -I INPUT 1 -s $IP_ADDRESS-j DROP");

où "$IP_ADDRESS" est une variable contenant l'adresse IP à bannir.

Mais bon, sinon tu peux te contenter d'arrêter le traitement du formulaire HTML, sans faire appel
à iptables pour bannir l'adresse IP. Le principal étant de supprimer l'envoi d'email.
Tu peux aussi faire une redirection vers une page affichant des pubs

Tu peux également stocker la ou les adresses IP dans un fichier dans "/tmp" par exemple, et là avoir
une règle fail2ban qui banni toute IP présente dans ce fichier.

etc.

Sinon avec fail2ban n'y a t-il pas une possibilité de vérifier le nombre d'envoi d'email d'un utilisateur (IP) et si > à 10 emails on bannit l'IP ?

Si mais la difficulté de cette approche est de pouvoir distinguer les cas légitimes des autres. Ne pas perdre de vue que fail2ban
met "un certain temps" à récolter des informations (de mémoire, je ne crois pas que l'on puisse descendre sous 1 minute).
Or si en une minute le spammeur a déjà envoyé 200 emails, ça sera moyennement efficace comme tactique.

Ca serait plus rapide que de déployer le champs caché dont tu parles sur tous les formulaires de tous mes sites

Bah ça dépend grandement de ton code.

Tout la partie "détection du contenu du champ" peut être mis dans une fonction PHP, laquelle peut être stockée
dans un fichier PHP de fonctions toutes faites que tu reprends dans chaque site.

Ensuite c'est seulement un appel à cette fonction qu'il faudra ajouter dans la partie "récupération des données de saisie",
qui normalement est centralisée aussi (notamment afin de pouvoir "nettoyer" tous les champs saisis sans exception).

[nono67]

Merci pour tes conseils Buddy.

C'est vrai qu'on peut toujours mettre des vérifications dans le code php du type :

if(isset($_POST['nom']) && !empty($_POST['nom'] && noChiffre($_POST['nom'])==TRUE && noConsonne($_POST['nom'])==TRUE && noSelect_From($_POST['nom'])==TRUE && etc....)
{
// envoi de l'email
}

... mais quand tu as 30 champs dans un formulaire et qu'il faut vérifier pour chaque champs qu'il ne soit pas vide, qu'il existe, qu'il ne doit pas avoir de chiffre, qu'il ne peut pas avoir plus de 5 consonnes de suite (du style "mglkh"), qu'il ne doit y avoir de "select(" ou de "from(", etc... c'est un peu lourd à gérer, non

[buddy]

Tu peux faire un filtre dans fail2ban qui vérifie le nombre d'appel à tes pages qui envoient les mails.


Pour compter le nombre d'email envoyés par un visiteur çà va être compliqué, car c'est ton serveur qui envoient les mails avec sa propre ip ..

ajouter un champ au formulaire et le traité en php se fait vite. (il suffit d'en créer un identique sur tous tes formulaires)

idem pour une fonction php qui vérifie les noms et prénom par exemple. Tu codes la fonction, tu vérifies qu'elle marche et tu la déploie partout ..

[nono67]

Une astuce très simple à mettre en oeuvre s'il s'agit d'un robot/script automatisé :

Ajouter un champ HTML caché (type=hidden) au formulaire avec un nom (name='...') très explicite,
du genre "url", "email", "nom", "name", "password", etc.

Ce champ de saisie n'apparait pas dans le formulaire visible par les visiteurs humains.
En revanche, un script/robot va le voir et essayer de le remplir.

A partir de là, dans le code principal du script appelé par le formulaire :

1) si le contenu de ce champ est vierge, on continue normalement le traitement.

2) si le contenu n'est pas vierge :

a) bannir l'adresse IP via iptables ou équivalent
b) ne pas aller plus loin dans le traitement, arrêter le script

Ton idée de champ HTML caché me plait Est-ce imparable contre ce type de robot ? L'utilises-tu dans tes formulaires ? Comment tu fait pour bannir l'IP via iptables ?

Sinon avec fail2ban n'y a t-il pas une possibilité de vérifier le nombre d'envoi d'email d'un utilisateur (IP) et si > à 10 emails on bannit l'IP ? Ca serait plus rapide que de déployer le champs caché dont tu parles sur tous les formulaires de tous mes sites

[cassiopee]

Une astuce très simple à mettre en oeuvre s'il s'agit d'un robot/script automatisé :

Ajouter un champ HTML caché (type=hidden) au formulaire avec un nom (name='...') très explicite,
du genre "url", "email", "nom", "name", "password", etc.

Ce champ de saisie n'apparait pas dans le formulaire visible par les visiteurs humains.
En revanche, un script/robot va le voir et essayer de le remplir.

A partir de là, dans le code principal du script appelé par le formulaire :

1) si le contenu de ce champ est vierge, on continue normalement le traitement.

2) si le contenu n'est pas vierge :

a) bannir l'adresse IP via iptables ou équivalent
b) ne pas aller plus loin dans le traitement, arrêter le script

[buddy]

Est-ce que tu me recommander un bon Captcha 'automatisable' ?

J'ai reçu aussi des centaines d'email avec simplement des chiffres dans les champs "nom" et "prenom" sans d'autres codes douteux, que faut-il fait dans ce cas là : vérifier chaque champs ?

Un nom ou un prénom ne peut pas contenir de chiffres... comment filtrez-vous toutes les données de vos formulaires avant d'autoriser l'envoie de l'email ?

Parfois je peux avoir des formulaires avec plus de 30 champs....

Dans la page php qui est appelé, il suffit de vérifier avec des fonctions php (ex : preg_match) que le champ "nom" ne contient par exemple par de chiffres. Tu peux aussi chercher les "select(" ou "from(". On n'écrit jamais naturellement ce genre de mots directement suivi d'une paranthèse dans une phrase "normale".

http://php.net/manual/fr/function.preg-match.php
et https://openclassrooms.com/courses/c...s-partie-2-2-2 (même si je préférai ce site avant, les informations/les exemples restent bons)

des formulaires à 30 champs ? il est forcément possible de vérifier leur contenu non ?

[nono67]

Il y'a une solution toute simple aussi qui limitera le problème (sans le résoudre) qui consiste à enregistrer dans un fichier txt (pas sql) l'adresse IP et la date de dernière tentative. Imposer 1min entre chaque envoie.

En cas de plus de 10 tentatives bloquer l'ip via le parefeu.

Aurais-tu un bout de code php de ce script ?

Est-ce que Fail2ban ne peut pas filtrer/bannir les IP en cas d'envoi massif d'emails ?

[Gaston_Phone]

@ sich, ta méthode est efficace.

J'en ai utilisé une semble il y a 8 ans pour éviter le pompage d'un de mes sites.

[sich]

Il y'a une solution toute simple aussi qui limitera le problème (sans le résoudre) qui consiste à enregistrer dans un fichier txt (pas sql) l'adresse IP et la date de dernière tentative. Imposer 1min entre chaque envoie.

En cas de plus de 10 tentatives bloquer l'ip via le parefeu.

Par contre pour le check il faut le faire via un fichier txt local, il vaudrait mieux éviter d'avoir une request sql à chaque tentative si il en fait des centaines à la minute...

[nono67]

Est-ce que tu me recommander un bon Captcha 'automatisable' ?

J'ai reçu aussi des centaines d'email avec simplement des chiffres dans les champs "nom" et "prenom" sans d'autres codes douteux, que faut-il fait dans ce cas là : vérifier chaque champs ?

Un nom ou un prénom ne peut pas contenir de chiffres... comment filtrez-vous toutes les données de vos formulaires avant d'autoriser l'envoie de l'email ?

Parfois je peux avoir des formulaires avec plus de 30 champs....

[Nowwhat]

...
Les robots ne contournent-ils pas les CAPTCHA ?

Il existe des Captcha 'automatisable', d'autres, c'est impossible. Il suffit de choisir un bon

[nono67]

Merci pour ta réponse.

Les robots ne contournent-ils pas les CAPTCHA ?

[buddy]

Bonjour,

"installer" un CAPTCHA.
renvoyer un message d'erreur (et donc ne pas envoyer le mail) si le coeur du message contient par exemple "sleep(" ou "from'" ou "select'".

et etc ...

[nono67]

Salut à tous,

J'ai un serveur dédié CentOS 6 64 bits Release 3 sur lequel j'ai mis mes sites web, un petit malin parcourt mes différents sites et cherchent mes formulaires (contact, demande de renseignements, etc...) et m'envoie des centaines d'emails via mes formulaires. Hier 1700 emails et aujourd'hui 800 emails reçu, ces emails sont envoyés en l'espace de quelques secondes.

Je trouve ce type de code dans les champs (nom, prénom, adresse, etc...) de mes formulaires :

${@print(md5(acunetix_wvs_security_test))}\ Uinovewl

If(now()=sysdate(),sleep(3),0)/*'xor(if(now()=sysdate(),sleep(3),0))or'"xor(if(no w()=sysdate(),sleep(3),0))or"*/ Diuaeiww

(select(0)from(select(sleep(3)))v)/*'+(select(0)from(select(sleep(3)))v)+'"+(select(0 )from(select(sleep(3)))v)+"*/ Diuaeiww

etc...

Comment stopper efficacement cet emmerdeur ?

J'avais pensé à fail2ban qui pourrait bloquer les adresses IP en fonction du nombre d'emails envoyés : si le nombre d'envoie d'emails est > à 50 emails par secondes on bloque cette adresse IP. Cela vous semble-t-il une bonne solution ? Sinon quelle autre solution préconisez-vous ?

Merci pour vos réponses et votre aide.

Bruno