En fait un petit script qui se réveille toutes les heures pour prendre le
premier item d’une liste d’attente et l’envoyer c’est tellement simple à
faire que ça sera fait
il me semblait avoir compris que le pb si situait dans la simultanéité, pas
dans
la qtité…
Le Mer 31 janvier 2007 15:01, Guillaume B. a écrit :
Reste aussi, que là aussi, quelqu’un qui s’y prend bien, qui étale ses
contributions dans le temps, sera dûr voir impossible à repérer de
manière automatique.
… ou si c’est la mafia Russe, elle va utiliser les qques milliers
(millions ?) d’ordis zombis qu’elle “possede” sur Internet (((-:
Sans aller jusque là, si on parle bien d’un site de contribution
photo/vidéo (du type des dailymotion et autres youtube) les personnes qui
veulent diffuser du contenu à moindre frais en employant des robots ce
n’est pas de la science fiction, loin de
là.
En fait un petit script qui se réveille toutes les heures pour prendre le
premier item d’une liste d’attente et l’envoyer c’est tellement simple à
faire que ça sera fait, et assez rapidement (d’ailleurs ça existe déjà
pour les sites actuels et je suis convaincu qu’ils s’amusent les uns et
les autres à de joli batailles pour faire des vérifications/protections et
outrepasser ces même vérifications/protections).
Pas besoin de voir la mafia russe là derrière. Ca existe depuis les
premiers temps de la diffusion des mp3 par le réseau.
J’ai même croisé des gens qui dans le temps automatisaient des
upload/download de mp3 sur les comptes de free.fr en les renommant et en
espaçant par robot les téléchargement.
Pourtant je n’appartiens pas du tout à ce genre de communauté donc si j’ai
vu ça plusieurs fois c’est que ça ne doit pas être si rare que ça.
Dèsqu’il y a un espace de liberté, il y aura vite foule pour en profiter de
manière contestable. Autant le prévoir
le serveur soit surchargé en créant les thumbnails de toutes ces
galeries en même temps.
si tu calcules les thumbnails en direct et que tu vises une forte
charge ca ne tiendras pas. Il te faudra externaliser ce processus du
service web de manière à ne pas créer de goulot d’étranglement dans
les (trop peu nombreux) process rails dédié au web.
les solutions financièrement viable contre les DDOS ne sont pas
dans rails, trop lent, pas assez de concurrence dans les accès. Si tu
cherches à te prémunir efficacement il te faut un throttle
indépendant qui agit AVANT d’invoquer le serveur d’application sinon
c’est de toute facon la congestion assurée avec des moyens minimums.
Il faut savoir que les cas de soumissions robotisés se font de
toute facon en spoofant l’ip (les amateurs de spam de commentaire
dans movable type l’ont appris à leur dépend, le throttle ip est
insuffisant). Donc si tu veux te prémunir contre la soumission de
contenu par les robots c’est dans le process de soumission que réside
le salut. Les méthodes sont plus ou moins efficace/non ergonomique/
non accessible ca va du captcha à la soumission en deux étapes en
passant par les redirections obligatoires. Dans tout les cas la règle
est simple s’il est possible d’ajouter un contenu uniquement à partir
d’une unique requete bien formée (= avec tous les url/parametre/
cookies/referer/ip qui vont bien) tu es vulnérable à ce type d’attaque.
La conclusion c’est qu’il ne me semble pas qu’il y ait un rapport
avec une notion de connection limité à une ip par utilisateur dans ce
genre de problématique. Sécuriser la création de compte contre la
soumission automatique et limiter le nombre de soumission par compte
est une bonne solution de départ. Externaliser la création de
thumbnail dopera la charge supportable par serveur. Ensuite si veux
te prémunir contre un DDOS il te faudra des contremesures externe
mais ca c’est des problématiques d’hébergement pas de rails.
