Après un mois d’inactivité blogesque du à mon travail, je fais un petit saut pour vous raconter comment  empêcher d’autres webmasters de vous piquer votre bande passante. Le hotlinking c’est quoi ? Simple: Vous avez un site Internet et hébergez des images que vous avez créés ou trouvées pour illustrer vos propos. Google image passe faire un tour par là, et hop, l’ensemble de vos images, créations, captures d’écran, logos se retrouvent sur le moteur. Jusqu’ici tout va bien, sauf que si vous êtes convenablement positionné sur un mot clé, une ribambelle de bloggers fainéants vont utiliser votre image pour illustrer leur billet. Qu’ils utilisent votre image sans vous en avertir, c’est une chose, mais qu’en plus au lieu de l’héberger, ils la pompent directement depuis votre serveur, c’en est une autre. Le hotlinking c’est ca, le fait d’utiliser des images hébergées sur un autre site que celui où elles sont affichées (site internet, forum, etc).

Pour le coup, l’exemple de Google image n’est pas le plus probant, simplement parce qu’il suffit d’insérer le code suivant dans votre robots.txt afin de faire le ménage:

User-Agent: *
Allow: /

User-Agent: Googlebot-Image
Disallow: /

Par contre si vous avez un site à forte audience comme abrutis.com,  il suffit qu’1/10 des visiteurs hotlinkent* (* attention, néologisme douteux) les images « marrantes » sur leur blog pour mettre votre serveur sur les rotules, où pour faire quadrupler vos coûts en bande passante. Autre cas de figure, nous avons un site Internet dump-it.fr, qui permet à n’importe quel internaute d’héberger son image afin de la donner à ses proches par IM, Mail ou en mettant un lien sur un forum ou sur son site. Ceci dit, les liens que l’on fournit afin de donner l’image sont formatés de telle façon que l’image soit affichée à l’écran contenue dans une page HTML, permettant ainsi d’améliorer le référencement de dump-it.fr, mais également de le monétiser. Mettre de la pub dans des pages html, c’est possible, au sein d’une image c’est plus difficile :D. Toujours est-il que j’ai comparé les stats que nous resortait Analytics pour ce site et celles du serveur sur lequel il est hébergé. Analytics comptabilisait dans les 600 visiteurs unique par jour quand en me basant sur l’analyse des logs du serveur j’en resortait dans les 1100. Il y a donc un manque à gagner de 500 visiteurs qu’Analytics ne peut comptabiliser, car ces derniers sont ceux qui affichent des images hotlinkés (et donc pas de tracker JS pour Analytics). J’ai donc décidé d’enrayer ce fléau pour les raisons que j’ai déjà evoqué (Bande passante, référencement, monétisation).

Il vous suffit de créer un htaccess qui ne va autoriser l’accès à vos images qu’aux referers que vous aurez autorisé. Alors bien évidement, on ne peut pas considérer que c’est une solution fiable à 100% car tout le monde sait qu’un referer est fakable. Ceci dit je mise sur le fait qu’une personne préfèrera uploader l’image sur son site plutôt que de devoir faker le referer de son script pour afficher une image hostée sur dump-it.fr …


RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?dump-it.fr/.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://(www\.)?john-jean.com/.*$ [NC]
RewriteRule .*\.(gif|GIF|jpg|JPG|bmp|BMP|jpeg|JPEG)$ http://www.dump-it.fr/hotlink.jpe [R,NC]

Cette méthode permet donc de rediriger l’ensemble des personnes tentant d’accéder à vos images, et dont le referer n’est ni vide (2ème ligne), ni dump-it.fr ou john-jean.com (3eme et 4eme lignes) vers l’image hotlink.jpe (dernière ligne). Notez bien que hotlink.jpe n’est pas une coquille, simplement si je renvoyais vers un .jpg, cela bouclerait car ma règle RewriteRule .*\.(gif|jpg|jpeg|bmp)$ réécrit pour les .jpg.  Les navigateurs interprètent correctement les .jpe de toute facon.

L’intérêt de cette méthode est qu’elle permet d’afficher des images relativement cocasses aux personnes qui vous leechent* (Second néologisme douteux du billet). Je me suis pas mal amusé avec dump-it.fr à mettre toute sorte d’images et c’était amusant de voir ce que cela rendait chez les hotlinkers. Un site e-commerce a vu l’ensemble de ses images intégralement remplacées, un site d’humour avec un forum actif également, et bien d’autres. Pour le coup, ceux qui m’ont contacté ont été ajoutés à ma white list ;)

Si vous ne souhaitez pas vous amuser à changer les images de tous les sites qui vous volent (et vous spolient !), vous pouvez simplement rediriger vers une 403:

RewriteRule .*\.(gif|GIF|jpg|JPG|bmp|BMP|jpeg|JPEG)$ - [F]

Voilà, bon amusement et désolé si cet article a été relativement mal écrit, je me remet dans le bain ;)
PS: Pour le cas de dump-it, comme le site était mal organisé j’avais une arbo comme cela: /upload/images/miniatures/, donc je devais limiter l’accès à images (pour le hotlink), mais laisser miniatures ouvert car il sert à l’insertion des miniatures dans les bbcode forum. Si vous avez le même type de soucis, il suffit simplement de rajouter dans le dossier *miniatures*:

RewriteEngine off
allow from all


Bien, donc imaginons que vous avez développé www.example.com. Vous avez aussi historiquement une dizaine de sites, example1.com, example2.com, example3.com et ainsi de suite. Vous souhaitez pouvoir gérer les accès aux répertoires /admin/ par le biais d’un login unifié par Mysql; Comprendre: déployer le même htaccess partout qui permet de checker dans une db si tel utilisateur a accès à tel site ou pas.  Au delà du fait que vous allez avoir besoin de mod_auth_mysql, il vous faut un serveur Mysql dans lequel l’ensemble des htaccess iront taper pour savoir si les utilisateurs peuvent se loger ou non. Autre exemple, example.com prend de l’ampleur, les requêtes SQL sont déjà optimisées mais elles mettent cependant le serveur sur les rotules tellement il y a de visiteurs sur le site, même chose, besoin d’un serveur Mysql à distance (je n’entend pas troller ici sur l’affinage des requêtes, l’optimisation hardware, etc ;) ).

Donc, comment permettons nous à Mysql d’écouter à distance ? C’est en réalité assez simple, mais comme ce n’est pas si évident que cela de retrouver sur google comment faire dans une seul document, je fais ce billet qui tente de condenser l’information.

La première chose à faire est d’aller modifier votre /etc/mysql/my.cnf afin de commenter la ligne suivante:

bind-address           = 127.0.0.1 devient donc
#bind-address           = 127.0.0.1

Vous devez ensuite, comme d’habitude, redémarrer mysql:

[john@coincoin:~]# /etc/init.d/mysql restart
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.

Vous venez d’enlever l’écoute locale du serveur Mysql. Désormais, vous pouvez créer vos utilisateurs. Et c’est ici qu’il faut être vigilant, si je reprend l’exemple d’avant (example2.com, example3.com, etc), potentiellement nous avons besoin qu’un utilisateur Mysql soit crée afin d’accéder aux informations. Mais ce n’est pas parce que 10 serveurs peuvent avoir besoin de contacter notre serveur Mysql que cet utilisateur doit avoir les droits %. Il convient de gérer précisement les autorisations de chaque utilisateur. Même si la solution de facilité souvent employée par les webmasters est de mettre en droit « % » (le % est une wildcard qui permet à l’utilisateur Mysql de se connecter depuis n’importe où), en cas de faille de type Injection Mysql, c’est la porte ouverte à n’importe qui pour collecter les informations (alors que de devoir faire relai sur le serveur qui possède la faille est beaucoup plus rébarbatif).

Donc pour résumer, ce qu’il ne faut pas faire:

CREATE USER 'example'@'%' IDENTIFIED BY '****';
GRANT USAGE ON * . * TO 'example'@'%' IDENTIFIED BY '****' WITH MAX_QUERIES_PER_HOUR 0
MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
CREATE DATABASE IF NOT EXISTS `example` ;
GRANT ALL PRIVILEGES ON `example` . * TO 'example'@'%';

Là, vous créez un utilisateur qui peut se connecter de n’importe ou. Par contre si example.com est hébergé sur 80.80.80.80, voici ce qu’il convient mieux de faire:

CREATE USER 'example'@'88.80.80.80' IDENTIFIED BY '****';
GRANT USAGE ON * . * TO 'example'@'88.80.80.80' IDENTIFIED BY '****' WITH MAX_QUERIES_PER_HOUR
0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;
CREATE DATABASE IF NOT EXISTS `example` ;
GRANT ALL PRIVILEGES ON `example` . * TO 'example'@'88.80.80.80;

Dans le cas où vous hébergez un site sur le serveur Mysql directement, et que vous n’avez pas besoin de contacter à distance pour l’utilisateur Mysql, vous pouvez mettre directement localhost, autant être logique. Et si d’aventure, vous n’avez pas envie de granter les accès immédiatement:

CREATE USER 'example'@'localhost' IDENTIFIED BY '****';
GRANT USAGE ON * . * TO 'example'@'localhost' IDENTIFIED BY '****' WITH MAX_QUERIES_PER_HOUR 0
MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0 ;

Malgré tout cela, Ca ne marche pas ?!
Il n’est pas impossible que IPTABLES rejette les connexions entrantes, vous devez donc autoriser les serveurs distants à vous contacter, là encore c’est comme le % ou l’IP directement, il y a deux écoles. Soit c’est Open-bar:

/sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 3306 -j ACCEPT

Soit on met l’adresse IP du serveur qui peut venir taper sur le 3306:

/sbin/iptables -A INPUT -i eth0 -s 80.80.80.80 -p tcp --destination-port 3306 -j ACCEPT

N.B:  Rendre vos bases de données accessibles depuis l’extérieur n’est pas synonyme de faiblesse de sécurité si les choses sont bien faites. Pour résumer:

• On commente bind-adress dans /etc/mysql/my.cnf
• On crée les utilisateurs avec les droits NECESSAIRES, pas plus. Autrement dit, on autorise depuis l’adresse IP d’où ils contactent et jamais depuis partout (%). Si l’utilisateur est local, on ne l’authentifie que depuis localhost.
• On crée des règles iptables pour autoriser les serveurs qui ont le droit de rentrer, pas pour tout le monde (-s 80.80.80.80).

Bonnes bidouilles.

Bon j’avoue, j’ai un peu triché, derrière ce titre racoleur se trouve une erreur de configuration assez grossière, mais que l’on retrouve, sans exagérer dans 70% des cas. Le premier responsable de cette faille est, il me semble, le site http://www.commentcamarche.net/. Pourquoi ca ? Simplement parce qu’ils sortent premier sur la recherche « Création htaccess« .

Et comment nous proposent-ils de créer un htaccess ?
Je cite:

ErrorDocument 403 http://www.commentcamarche.net/accesrefuse.php3
AuthUserFile /repertoire/de/votre/fichier/.FichierDeMotDePasse
AuthGroupFile /dev/null
AuthName "Accès sécurisé au site CCM"
AuthType Basic
<LIMIT GET POST>
Require valid-user
</LIMIT>

Donc si l’on fait un tour rapide:

• La première ligne donne la page où l’on doit rediriger lors d’une 403 (Erreur d’auth ou deny from all par exemple)
• La seconde donne le chemin du fichier contenant les mots de passe
• La troisième le chemin du fichier de groupe
• La quatrième, c’est le wording du prompt login / pass
• La cinquième donne le mode d’authentification, dans ce cas auth basic (mod_auth_basic)
• Enfin, les trois dernières expliquent que pour exécuter les requêtes GET et POST, il faut être un utilisateur authentifié.

Tout cela est assez schématisé, mais l’idée est là. Donc si je tente d’accéder à la page protégée, j’effectuerais une requête de type:

GET http://www.example.com/admin/index.php HTTP/1.0

Et je vais donc atterir sur une 401 Authorization Required. Où se situe l’astuce ? Apache ne gère pas correctement les requêtes mal formée. Je m’explique, si à la place de faire un GET ou un POST, je fais un:

JOHN http://www.example.com/admin/index.php HTTP/1.0

Apache me renverra le contenu de la page présente derrière /admin/index.php (200). Lorsque je dis que 70% des sites sont faillibles, c’est tellement il est facile pour un webmaster paresseux de réaliser cette configuration. htaccess permet de modifier localement la configuration d’apache, du coup chaque webmaster peut créer sa propre faille en suivant les conseils d’un site généraliste comme commentcamarche. Deux coupables: le webmaster car il dépose une config qu’il ne comprend pas et Apache car il interprète les requêtes mal formée comme étant des GET. Grosso-modo, il est possible pour le premier venu d’aller se balader sur les backoffices en forgeant simplement sa requête à base de JOHN.

Comment patchons nous cette faille ?
Tout simplement en ôtant de notre htaccess la limit GET, POST. En effet, aucun intérêt de limiter à GET et POST le require valid-user si ce dernier est effectivement nécessaire. D’ailleurs dans les préconisations globales d’apache, ils recommandent de ne pas utiliser les limit lors de la création de htaccess. Je cite:

Access controls are normally effective for all access methods, and this is the usual desired behavior. In the general case, access control directives should not be placed within a <Limit> section.

The purpose of the <Limit> directive is to restrict the effect of the access controls to the nominated HTTP methods. For all other methods, the access restrictions that are enclosed in the <Limit> bracket will have no effect. The following example applies the access control only to the methods POST, PUT, and DELETE, leaving all other methods unprotected.