Wikini:TentativesDeVandalismeSurWikiNiPointNet

Nous n'avons rien à cacher et il peut être intéressant de lister ici toutes les tentatives de vandalisme opérées sur le site wikini.net. Par vandalisme, nous entendons une action volontaire pour souiller le wiki :

ajout de liens vers des sites sans rapport avec le sujet
effacement complet d'une ou plusieurs pages

Les actions suivantes ne sont pas considrées comme du vandalisme :

ajout de quelques caractères dans une page ; cette opération est observée de temps à autre sur wikini.net, il s'agit manifestement de tests d'utilisateurs incrédules : on lit d'ailleurs souvent le mot "test" à titre d'exemple
les contributions dans le BacASable et/ou ToutLeMondePeutEcrire
la création de page n'ayant rien à voir avec le sujet, souvent des tests des utilisateurs

Cette page peut permettre :

d'observer précisément le phénomène
de constater l'efficacité de la communauté à réagir
de lister les IP des vandales et, le cas échéant, de voir comment peut-on traiter le problème d'une IP-vandale persistante
- CharlesNepote : ce serait intéressant de centraliser aussi les attaques sur autres wikini ? Sur TentativesDeVandalismeDeWikini par exemple ? Comme on a pu le constater lors de l'ajout de "sites sympathiques" :-/ par un Russe.
- Attention, ya peut-être un souci légal à stocker les @IP dans une liste ? -- BenoitAudouard 20040501
- g0ki : Oui et encore, récupérer et blacklister les IP des vandales c'est bien mais que peut on bien en faire si ce ne sont pas des ips fixes ? Pour rappel en adsl standard les ips changent toute les 24h et même encore pire pour les 56k, c'est à chaque connexion. Le vrai moyen serait de faire comprendre à ces plaisantins que c'est bien souvent dans l'intérêts de la masse que de tel site sont développés. "Comment ça autant parler à une mule ?"

Liste des adresses éventuellement bloquées

Ces adresses sont bloquées à l'aide d'un fichier .htaccess à la racine du serveur.
Il conviendra de débloquer ces adresses au bout d'un certain temps.

2004-09-05 : 221.196.57.131 bloquée par CharlesNepote à la suite de SPAM à répétition dans diverses pages du site.
2004-09-05 : .nipr.mil bloquée par CharlesNepote à la suite de SPAM dans les références.

Cas litigieux

Le 06/06/2004, "ACBB564D.ipt.aol.com" a fait la promotion d'un wiki "au service de ceux qui passent leur bac de français ;-)". Il se trouve qu'un popup présente, à chaque ouverture du dit site, des publicités pour des sites parfois pornographiques. Dans le doute, j'ai donc supprimé ce site de la liste des SitesUtilisantWikiNi, jusqu'à une éventuelle explication de son auteur. -- CharlesNepote

Je peux m'expliquer, en effet, les publicité et pop up s'ouvrant au démarrage du site ne dépendent pas de nous mais de notre redirecteur d'adresse ulimit.com >> si vous voulez vérifier vous pouver acceder a notre site a cette adresse => http://vbouvier123.free.fr Je m'excuse pour le désagrément causé !!!
Merci de m'avoir fait remarqué cela. CurCulio?

PS : Utilisant un killer de Pop-Up je n'avait pas remarquer ce détail...
PS : C'est rassurant de voir que des gens controlent ce qui est écrit sur le wiki...

Il n'y a pas de problème. Je me doutais qu'il s'agissait d'un problème de ce genre là. -- CharlesNepote

Vandalisme des références

Parallèlement au vandalisme classique, il y a un petit malin qui s'amuse à spammer les références. J'ai bâni hier son IP (un jenesaispluquoi.mil) mais le voilà qui reviens de plus belle. Il s'agit manifestement d'un robot ou d'un couillon qui n'a que ça à faire puisqu'il revient à intervals très réguliers. Ce petit futé a naturellement du changer d'adresse. Il n'y a donc qu'un moyen d'arrêter sa progression, c'est de supprimer l'objet de sa visite : insérer des liens vers ses sites dans nos références. Je vois deux solutions :

contrôler par rapport à une liste à chaque ajout de référence (légèrement au détriment des performances de wikini)
réaliser une purge manuelle ou automatisée (par exemple 1 fois sur 4 requêtes comme la purge des pages)

-- CharlesNepote

Je suis le même vandalisme sur http://www.mirabellug.org. Je purge manuellement et assez régulièrement mais ca revient sans arret ... Si qqun peut me proposer un correctif
Fabien (void chez mirabellug poing org)

Il existe une solution simple si vous utilisez un serveur Apache. il suffit d'ajouter un .htaccess à la racine du site, contenant les références à exclure :
SetEnvIfNoCase Referer ".*(sex|hardcore|porn|pussy|xxx|webcam|ficken|fuck|boobs|babes|x\-pictures|macinstruct|incest|linuxwaves|secureroot|pervert).*" BadReferrer order deny,allow deny from env=BadReferrer
(Je documenterai mieux plus tard. Le code ci-dessus devrait suffire à ceux qui ont quelques connaissances.)
-- CharlesNepote

Merci cela m'a suffit largement. C'est en place depuis auojourd'hui. (Fabien)

Je n'arrive pas à le mettre en place : le serveur me renvoie une erreur :

Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, adm@ouvaton.net and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log.
(RemiDouai)

Bonjour, comme nous avons été attaqué par l'armée américaine (mdr) avec des sites gays et pornographique, nous avons mis en place la solution ci-dessus, cependant j'ai légèrement modifié le code pour que cela fonctionne sur notre serveur apache. Voici pour que vous ne deviez pas chercher trop longtemps
SetEnvIfNoCase Referer ".*(sex|hardcore|porn|pussy|xxx|webcam|ficken|fuck|gay|boobs|babes|x\-pictures|macinstruct|incest|linuxwaves|secureroot|perverted\-dreams|incestpornsites|spb).*" env=BadReferrer order deny,allow deny from env=BadReferrer
Attention, la ligne SetEnvIfNoCase doit contenir le grep et l'affectation de la variable env ...
(Philippe Devaud)
Ajout du mot interdit "perverted-dreams"
Ajout des mots interdits "spb" et "incestpornsites" (attaques provenant de 216.195.32.244)
--NicolasM

Sur alternC, j'ai utilisé pour la saloperie de spb (250 000 requetes en 1 semaine) :
setenvifnocase Referer ".*spb.ru" spam_ref=1 setenvifnocase Referer ".*un-autre-spameur.com" spam_ref=1 <FilesMatch "(.*)"> Order Allow,Deny Allow from all Deny from env=spam_ref
Si ca peux servir a ceux dont les exemples ne marchent pas chez eux...
--DaOuar

1) Il y'a un hic dans la méthode, car si je cherche par exemple "webcam" sur le wiki (ou la composante d'un des domaines banni), je ne peux pas aller sur les pages, car mon referer contient "RechercheTexte&phrase=webcam". Idem, si je crée une page WebCam, elle ne pourra lier sur aucune page, car considéré comme indésirable.
2) Je pense qu'une admin, permettant par exemple de cocher les referer indésirables, et qu'ils puissent être effacé après les avoir coché (un bouton "effacer ces referer indésirable" par exemple), serait l'idéal, avec pourquoi pas 3) une liste de referer bannis.
Avec le htaccess, c'est trop bourin a mon gout...
4) Sinon l"idée serait aussi de limiter l'affichage des referers aux inscrits seuls, comme ça plus d'interet de google rank.
Hop, j'ai fait ça assez dégueulassement sur notre wiki, après nettoyage avec avec phpmyadmin et une floppé de DELETE FROM `wikini_referrers` WHERE `referrer` LIKE '%site-xxx%'
Mon code pourri est chez DaOuar. Après reflexion, je pense que c'est le plus viable dans le temps, rendre inutile le spam plutot que vouloir le contrer.
--DaOuar (de retour, ponctuellement)

(Note : j'ai rajouté des chiffres dans ton texte) Bien vu DaOuar pour les problèmes soulevés en 1). On devrait pouvoir raffiner le .htacces pour avoir des choses du genre "webcam.com" plutôt que "webcam" mais ça complique un peu et ça rallonge la chaine... 4) pourrait être considéré comme une option mais je trouve ça un peu dommage car les rétroliens bilatéraux peuvent intéresser le webmestre : je renvois la balle au site qui me cite. Je suis plus sensible à la solution 2). Cela montre une fois de plus la nécessité de réaliser rapidement l'InterfaceDAdministrationWikiNi : j'ai récemment fait des propositions (cf. "Solution Technique III") : tous commentaires bienvenus. -- CharlesNepote

Est-ce que ca consomme tant de resources de faire ce test de mot clés dans le domaine au niveau de l'ajout de referer (donc en php) ? Il me semble que c'est trivial, un !preg_match n'est pas si complexe, non ? Déjà que wikini fait un test pour ne pas inclure les referer venant de son propre domaine... Et ça réglerais le problème que j'ai évoqué en 1) plus haut. --DaOuar

Et si on envisageait un banissement d'url ? En effet on constate que ce sont souvent les mêmes urls qui sont placées lors d'un spam. Lorsque le formatter trouve une url, il pourrait simplement vérifier qu'elle ne contient pas un masque avant de la transformer en lien. Si elle correspond au masque, il pourrait même afficher un message à la place, disant que cette url n'est pas autorisée. -- LordFarquaad

Ailleurs

Le listage du vandalisme semble être bien connu sur Wikipédia : http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Vandalisme_en_cours

De mon côté, après avoir laissé mon WiKi sans surveillance, j'ai perdu quelques pages. Quelques liens vers des sites porno avaient remplacé mes textes (que je n'ai d'ailleurs pas pu récupérer sans comprendre pourquoi ?). C'était aussi le fait d'une IP russe. -- MiKi

http://wiki.chongqed.org fait l'état des lieux des pratiques de spammer de Wiki et de Blog, pratique appellée chongqing (en référence à la ville de Chongqing en chine, qui semble être le lieu de vie d'un spammer des plus nuisibles). -- DavidDelon

2004-11-07 Nouvelle forme de vandalisme sur un Wiki (Wikini) , la création de nouvelles pages avec identification : voir http://tuxfamily.gradator.net/SsSs et http://tuxfamily.gradator.net/DerniersChangements, je crains que ce soit un robot, la protection basée sur l'identification vient donc de sauter. -- DavidDelon

Est-ce que tu peux nous résumer ce qui s'est passé par ce que les pages que tu donnes en référence ne permettent pas de voir le problème... -- CharlesNepote
- Oui, un administrateur a dû passer par là. Résumé : sur http://tuxfamily.gradator.net une vingtaine de page ont été créees, à intervalle tres rapproché, d'où le soupçon d'utilisation de robot, chaque page contenant du spam pour des sites, semble-t-il, Chinois. Première nouveauté donc, d'habitude, sur Wikini en tous cas, le spam massif intervient en modification de page, pas en création. Deuxième nouveauté : chaque page était associé à un propriétaire, SsSs?, donc il y a eu identification quelquepart, si cette identification s'est faite par un robot, on peut craindre une recrudescence de Spam sur les Wiki jusqu'ici protégés par cette barrière -- DavidDelon
  - On pouvait prévoir ces nouveautés sur la base de l'application qu'a développé EricVanDerVlist? pour http://websemantique.org : un robot (appelé PlomBier?) vient s'identifier sur le site, puis vient y écrire une ligne dans une page donnée à chaque fois qu'il y a de l'activité sur le canal IRC. Lorsqu'il faut créer une page, il le fait automatiquement. (cf. http://websemantique.org/DerniersChangements). D'après Eric, le robot a été écrit en python en quelques dizaines de lignes. On peut faire la même chose en Perl ou en PHP en presque aussi peu de lignes. En fait, la seul vraie barrière qui existe pour les chinois vis à vis de nous, c'est la barrière de la langue. Ton exemple montre avec d'autant plus d'acuité la nécessité d'un filtre sur la page du contenu (ie des liens publiés sur une page). -- CharlesNepote
    - A propos de sémantique, il serait possible de compléter la création d'un compte-identifiant par une énigme genre "quelle est la couleur du blanc (en 4 lettres) ?" -- JeanLuc?