Digital Network recherche, pour le compte de l’une de ses filiales, un webmaster / développeur web,capable d’évoluer à moyen terme vers un poste de chef de projets et de manager.
Votre profil : passionné des langages web ( html, xml, js et css), vous avez également de bonnes notions de webdesign et une connaissance du langage php et des bases de données MySQL.
Pour plus d’informations cliquez sur le lien suivant : recherche webmaster
Je ne pensais pas que ça méritait un post, mais comme il ne semble pas possible de discuter avec ce charmant personnage, je me permets de publier l’explication complète de “la faille”. Comme la plupart d’entre vous le sait, le site www.digital-network.net contient de nombreux “private joke”, et ce depuis plus de 7 ans. Parmi ces blagues sympathiques, on peut citer : une page index “cachée” dans un répertoire “admin” qui simule une interface d’administration d’un gros extranet, des messages d’erreurs laissant penser que l’apprenti pirate a réussi à obtenir un shell sur son serveur, exploité une injection mysql ou encore une faille include.
Lors d’une discussion sur le site linuxfr, suite au post d’un contributeur qui était en désaccord avec moi sur un sujet, j’eu la bonne surprise de recevoir en copie le message suivant depuis le formulaire de contact du site vitrine du groupe :
J’en profite pour mettre une règle via iptables : iptables -A INPUT -s son_adresse_ip (qu’on ne citera pas ici) -j DROP -v : de son point de vue, le site (ainsi que tous les sites hébergés sur le meme serveur semblent “down”). Il se reconnecte quelques minutes après avec une autre ip, j’attends paisiblement qu’il clique sur “contact” puis je fais la même chose, une seconde règle histoire de voir quelle sera sa réaction.
Trouvant ce message un peu cru, je me permets de le lui faire remarquer dans le thread, ce à qui il répond alors fier de lui :
Erreur MySQL affichée en clair.
ON PEUT FAIRE DES INJECTIONS SQL ET SUPER FACILEMENT.
Ça me fait de mal de voir les tarifs que tu sembles pratiquer pour ton “expertise”. “
Pour le convaincre de son erreur, je décide de lui publier la réponse suivante qui démontre quelques points techniques, notamment que *l’affichage des erreurs” n’est pas actif : Dans un souci d’apaisement, je descends le ton d’un cran pour ne pas froisser son égo.
root@rdp13 /home/digitalnet/www # ls -altr /usr/local/Zend/etc/php.ini
-rw-r–r– 1 root root 27950 2009-02-28 20:48 /usr/local/Zend/etc/php.ini
root@rdp13 /home/digitalnet/www # cat /usr/local/Zend/etc/php.ini |grep display_error |grep -v “;”
display_errors = Off
root@rdp13 /home/digitalnet/www # cat qmail.php |grep mail |grep if
if(eregi( “^([-!#\$%&'*+./0-9=?A-Z^_`a-z{|}])+@([-!#\$%&'*+/0-9=?A-Z^_`a-z{|}]+\\.)+[a-zA-Z]{2,8}\$” ,$mail)!=0) {
root@rdp13 /home/digitalnet/www # tail -n 7 qmail.php
else
echo “plus rien non plus…”;
}
?>
Pour résumer, le diplay_error est à off depuis (au moins) la date affichée (depuis toujours en fait). Il ne peut donc pas y avoir de message d’erreur…
Le php.ini n’a jamais été modifié depuis. Le formulaire n’as pas de sql, c’est juste un formulaire d’envoi d’email qui forwarde sur sales@digital-network.net que je reçois en copie..
Pour chaque variable y’a un test à la con (exemple plus haut celui de l’email) qui dit en gros : si l’info envoyée ne correspond pas à ce qui est attendu, on envoie un code à la con via “echo”, choisi en fonction de la “technique” utilisée (en fonction de ce que tu aurais testé, t’aurais même eu droit à un access granted uid 0 bla bla…
De même la page www.digital-network.net/admin renvoyait une une interface (bidon c’était du html), genre “administration de l’extranet du groupe bla bla”… Voilà pour toute l’explication..
Cela dit, personnellement je n’y connais pas grand chose en SQL injection non plus (mais j’ai des collaborateurs qui connaissent), chacun son domaine. Et je suis le premier à dire qu’aucun système au monde n’est invulnérable, les notres ne font pas exception : le meilleur de la sécurité, ce sont des intrusions rares, rapidement détectées, compartimentées et traitées… Je pense qu’en terme de délais de réponse, c’était plutôt pas mal non ? 
Sans rancune. Bonne soirée.
Je crée donc rapidement une base de données vide sur le serveur, et reprends la requête affichée en erreur, puis la réactive dans le formulaire de contact. Je vide les règles de filtrages pour autoriser à nouveau son adresse ip (iptables -F), La connexion est valide mais il n’y a pas de table… Bon maintenant comment réactiver les erreurs sans redémarrer apache et perdre la “preuve” quil n’a jamais été arrêté… Facile on va pas faire ça, on va récupérer l’erreur et faire un echo de cette dernière pour qu’elle s’afiche…. Pour plus de véracité, je conserve les mêmes noms de variable dans la requête… va-t-il continuer ?
Attendant de voir sa réponse rien ne vient, mais les tests dans le formulaire s’enchaîne, puis sans lire mes autres réponses, il publie alors un journal à la gloire de sa “trouvaille” sauf que… tout est faux ! essentiellement parce qu’il est allé trop vite sans prendre le temps de lire le fil jusqu’au bout. Dommage.
1) La véracité de son explication repose sur le fait que durant une période de “correction” le site était down. C’est faux, bien entendu, et les logs apache sont là pour le montrer, mais le fait que les ips qu’il utilisait étaient blacklistées lui at fait penser que les sites étaient arrêtés..
2) Il n’y a pas de sql sur ce site, ou il n’y en a plus depuis au moins 7 ans. Pourquoi ? Parce que www.digital-network.net est désormais un site vitrine, il ne contient que du contenu statique. Le formulaire est simplement posté par email.
3) Le site reçoit des milliers d’attaques similaires par jour depuis des années, il n’a jamais été modifié.
Comment fonctionne la “supercherie” ? Simplement avec un if… pour chaque champ, si son contenu ne correspond pas à cette définition, une fausse erreur est affichée via la commande echo.
Ce système est utilisé non seulement sur les champs en première partie, puis une seconde fois directement au niveau du traitement du champs “email”. Pourquoi ? Parce que pour envoyer les emails on utilise pas la fonction mail de php mais un fichier qmail.php. Comme il appelle une commande système, un post qui pourrait bypasser le premier système de filtrage est susceptible de pouvoir exécuter du code sur le serveur via un caractère d’échappement utilisé en bash : c’est l’extrait cité plus haut.
J’ai failli oublié la capture de l’uptime apache fait durant l’écriture de ce même post, maintenant :
10 ans, cela fait une décénnie que Digital Network fourni des serveurs dédiés à ses clients. 10 ans que nous inventons de nouveaux produits, 10 ans que nous façonnons chaque serveur pour l’utilisation qui en sera faite par le client. De cette décennie d’expérience, nous avons retiré quelques règles que je vous fais partager. Ces règles de base, bien qu’elles puissent paraître simplistes vous permettront de bien choisir votre serveur dédié, et d’avoir un uptime moyen de plus de 500 jours sans trop de difficultés.
1) Connaître son projet : trop d’achat de serveurs dédiés ont lieu avant que le projet qu’il doit hébergé ait été correctement dimensionné. Il est important de bien connaître son projet mais également les technologies qui seront utilisées (php, python, perl, c, cgi, mysql, postgresql, oracle, websphere, dbase, apache…), l’espace physique occupé qui utilisera ces technologies et comment il sera concrètement utilisé : aura t’on besoin de beaucoup d’espace ? Hébergera t’on des gros fichiers, ou plutôt des petits, en quel nombre et dans quelle arborescence ? Quelle sera la taille physique de la base de données utilisée… une fois remplie ? Va t’on faire beaucoup de calcul brut ou bien va t’on plutot lire et écrire des données ? Va t’on traiter beaucoup de tâches en parallèle ou au contraire de grosses tâches les unes derrière les autres ? Une architecture multi-coeurs est elle préférable ou au contraire devont nous bâtir notre serveur sur un processeur puissant mais monocore ?. Les réponses à toutes ces questions permettront dans un premier temps de dimensionner correctement le hardware de votre serveur dédié, et, dans un second temps : de l’installer et de l’optimiser de manière adéquate.
Une fois obtenues les réponses à toutes ces questions, on pourra facilement évaluer le hardware nécessaire (processeur, ram), le type de disque dur (Enterprise Server, Velociraptor, SAS ou encore SSD ?), le type de raid à utiliser (RAID 1, RAID5, RAID 1+0, RAID 0+1 ou RAID6 ?). Dans tous les cas de figure : il faudra choisir du matériel certifié serveur et ayant un MTBF (temps moyen de bon fonctionnement) le plus élevé possible.
D’autres étapes pour choisir, optimiser et exploiter correctement son serveur dédié sont nécessaires. Pour la suite, le plus simple est de consulter le lien suivant : Bien choisir son serveur dédié
