Armetiz

Suite à l’acquisition d’un serveur dédié chez OVH pour en faire principalement un serveur LAMP. Nous avons cherché à configurer au mieux notre serveur.

Les questions que nous avons eu sont du type : « Où mettre mes scripts PHP ?« , « Comment gérer les partitions systèmes ?« , « Quelles sont les paquets à installer ?« , ou encore « Comment sécuriser son serveur, et quel niveau de paranoïa avoir ?« .

Dans un soucis de professionnalisme, nous avons souhaité confirmer nos connaissances en utilisant Google, des forums et même des livres (C’est pour dire !)

Plusieurs articles verront donc le jour pour répondre à ces questions et par la même occasion centraliser l’information. Voici le plan :

• Système d’exploitation : GNU/Linux Debian
• Apache
• MySQL
• PHP

Introduction aux bonnes pratiques LAMP.

Les raisons qui nous poussent à sécuriser notre serveur sont évidentes, et l’utilisation de normes aussi. De nombreuses personnes laissent à désirer la configuration de leur serveur en faisant confiance aux paramètres par défaut. Ce n’est pas forcement un tord car parfois, il vaut mieux ne rien faire que faire mal. Mais quitte à ne rien faire, prenez un serveur mutualisé ou demander nous
Un serveur en production que l’on n’a pas configuré, qui s’arrête sans raison ou qui ne fonctionne pas correctement peut s’avérer être un vrai calvaire pour l’administrateur qui s’en occupe.

On ne sait rien, on a tout à apprendre

Commencer par vous dire que vous ne savez rien et vérifier par étape vos connaissances.
On devient trop facilement un vieux grigou qui croit tout savoir et qui ne fait que des conneries.
Si l’on est venu à écrire cette article, c’est que nous avons commencé par nous dire « Bon, nous voulons un serveur LAMP, comment procéder ? Je ne suis plus sûr de… » Et c’est d’ailleurs grâce à ce genre de question que l’on apprend pleins de nouvelles choses. Car d’un lien hypertexte à un autre, on en apprend des choses.

Vraiment, ne soyez sûr de rien, vérifiez toujours à deux fois vos connaissances.

Utilisation de machine virtuelle

Pensez à avoir une machine virtuelle ayant le plus de caractéristiques communes avec votre serveur dédié.
Lorsque vous souhaitez ajouter un paquet ou faire une modification même la plus simple, effectué là sur votre machine virtuelle.

Optez pour les mêmes conditions d’accès au prompt.
Il est fort probable que vous utilisiez un accès SSH pour vous connecter sur le dédié, faite de même pour votre machine virtuelle. L’exemple qui donne raison à cette bonne pratique, c’est l’ajout d’une règle au firewall qui bloque l’accès SSH. Résultat vous n’avez plus aucun accès à votre serveur dédié et vous devrez dans de nombreux cas réinstaller le système.

Ne pas bruler la corde par les deux bouts

Commencez par le début, et profitez du temps que vous avez avant de mettre en production pour effectuer vos réglages. Car ce n’est pas une fois en production qu’il faudra faire de belles gaffes.
L’utilisation d’une VM – Virtual Machine – est ici mise en avant. Car en production, vous pourrez faire vos testes sur la VM sans risquer d’avoir des erreurs 404.
De plus, si vous avez installé en parallèle votre dédié et votre VM, vous aurez une configuration réellement identique l’une pour l’autre, ce qui vous permettra d’assurer encore plus au niveau de vos tests.

Être à jour

Vous pensez que je vais vous parlez de votre machine ? Et bien non, pas encore, cela viendra dans le chapitre approprié sur votre Système d’exploitation GNU/Linux
Le sujet de cette sous-partie, c’est vous. Nous avons commencé par dire que vous ne saviez rien. Vous devez donc vous tenir informé sur l’ensemble des logiciels de votre machine.
Je ne dit pas que vous devez suivre une formation pour administrateur système expérimenté.
Mais vous devez au moins faire l’effort de vous abonner à un flux RSS sur la sécurité de votre distribution, de ces nouveaux paquets, des failles sur PHP ou sur les applications hébergées.

Postscriptum

Les articles ne sont pas encore écrit, si vous souhaitez avoir des explications sur la configuration Linux, Apache, MySQL ou PHP. N’hésitez pas à le demander dans les commentaires.
C’est avant tout pour moi un moyen de mettre au clair mes idées, de savoir comment je vais configurer le serveur et surtout d’avoir un post-it amélioré.

Cet article fait suite à un petit raz le bol envers les développeurs et les concepteurs peu soucieux de la gestion des mots de passe.
Nous allons voir pourquoi il ne faut pas stocker les mots de passe en clair, les risques que cela peut engendrer et les alternatives du stockage en clair.

Stocker les mots de passe en clair

Avez-vous déjà eu ces mails désagréables vous confirmant votre inscription, ces mails qui vous font un rappel de login et de mot de passe ?

Rappel pour votre prochaine connexion :

• login: armetiz
• password: biloute

Mais comment diable ce fait-il que le site connaisse mon mot de passe et l’affiche en clair dans un email ?

• Premièrement, le mail arrivera dans ma boite au lettre, il sera consulter sans condition de sécurité particulière, malheureusement quelqu’un qui regardait mon écran à vu cette information tellement confidentiel : mon mot de passe.
• Deuxièmement, comme 95% des mails non publicitaire ne sont pas supprimés, cela signifie que si l’on subit un phising réussi, on offre à notre attaquant une vue complète de notre anatomie.
• Troisièmement, le mot de passe en clair a de forte chance d’avoir été stocké en base de donnée. Comment l’utilisateur peut-être sur de la sécurité de l’entreprise ? Un développeur stagiaire qui a accès à la base de donnée peut récupérer tout ce qu’il désire pour les ré-utiliser autrement.

Dans la catégorie poids lourd, on peut nommer Amazon.fr qui stocke les numéros de carte bleu ainsi que le cryptogramme ! Une fois inscrit, on peut revenir et commander un article sans même avoir sa CB sous les yeux.

Les risques de l’individu

Nous allons commencer par les risques des individus.
D’après les exemples ci-dessus, il peut se produire pas mal de scénario catastrophiques. Voici l’exemple imaginé d’Anna.

Anna travaillant dans une grande PME, a suivie une formation interne sur les bases de la sécurité informatique, la chose qu’elle a retenue : des mots de passe diversifiés et complexes en fonction du type de site. Après cette formation, elle a modifiée son mot de passe, et utilise désormais trois mots de passe complexes pour trois types de site

• Commerciaux.
• Non commerciaux.
• Professionnel – Accès VPN, Connexion système de fichier, etc…

Malheureusement, Anna a subit une attaque de phising Hotmail qu’elle utilise comme messagerie principal.
Cette attaque ayant été correctement orchestré, elle n’y a vue que du feu et ne s’est même pas rendue compte que son mot de passe non commercial venait de lui être volé.

Ses attaquants ont parcouru ses emails, ils sont tombés sur une confirmation d’inscription à un site de vente en ligne pour de la lingerie, rien de bien méchant, sauf que cet email contient le login de connexion, ainsi que le mot de passe affecté.
Ils ont aussi vu qu’une commande sur Amazon avait été passée.

Pas de bol pour Anna, les attaquants ont été voir sur Amazon si un des deux mots de passe fonctionnait, et c’est le cas, car elle a bien respectée la règle qu’on lui a apprise en formation, le mot de passe commercial utilisé pour la vente de lingerie est le même que pour Amazon.
Les attaquants ont commandés une télévision à 1000€, et ce n’est pas Anna qui sera livrée… Sachant qu’ils ont accès à la boite email, ils ont supprimés le bon de commande et elle ne sera rien avant que son banquier ne l’appel ou qu’elle consulte l’état de son compte.

Le calvaire de la pauvre Anna ne s’est pas arrêtée à un téléviseur, car quand on est acteur – pseudo – influant sur Internet, les choses vont vite. Et les attaquants se sont amusés avec l’identité numérique, les blogs qu’elle animait l’ont bannis, et la réputation qu’elle avait construit avec cœur s’est détériorées très rapidement.

Si l’on regarde l’expérience d’Anna, on se rend compte que le phising qu’elle a subit est sous sa responsabilité, car c’est son manque d’attention qui a mené à bien l’attaque.
Par contre, le fait que le mot de passe soit affiché en clair dans l’email est sous l’entière responsabilité du site web où s’est inscrit Anna.
Et si amazon avait ne serai-ce que demandé le cryptogramme de 3 chiffres avant de passer la commande, les 1000€ serai toujours sur son compte bancaire.

Les risques des hébergeurs / administrateur

« Moins on en sait, moins on cours de risque« . Si l’on part de ce principe, ceux qui conservent les mots de passe en clairs se heurtent à d’énormes risques légaux.

Nous allons continuer avec l’exemple d’Anna qui a été porté plainte, sachant que le débiteur des 1 000€ est Amazon, la banque se retournera contre cette enseigne qui devait s’assurer que la demande de la vente provenait bien d’Anna.
Comme nous ne pouvons pas être sur à 100% de l’identité de la personne connectée, ils ne doivent pas conserver les codes de carte bleu.

Anna qui n’a vraiment pas de chance, s’est fait usurpée son identité par un stagiaire de la boutique de vente de lingerie qui s’est amusé à récupérer les mots de passe et à tester l’accès à des forums en fonction de l’email et du mot de passe.
Le stagiaire est itinérant, mais pas la boutique, elle peut être accuser d’avoir utiliser des données confidentiels et d’une haute importance, car ces données peuvent ouvrir l’accès à d’autres données personnelles. Comment la boutique pourra justifier qu’elle n’a pas utiliser à des fins « personnels » le mot de passe d’Anna ?

Les alternatives du stockage en claire

Pour empêcher que d’autres personnes ne subissent l’expérience de la pauvre Anna, qui rappelons le, a usée de méthode d’utilisateur conscient de la sécurité informatique. Il existe des méthodes très simple à mettre en place.
Mais pour cela, il faut que les concepteurs, développeurs et même administrateur soit au courant de ces pratiques.

Lorsque l’on s’inscrit sur un site, on ne conserve qu’un Hash du mot de passe, et si un utilisateur redemande le mot de passe, on le ré-initialise avec un tout autre mot, libre à la personne de le changer par la suite.

Amazon a vraiment fait quelque chose de pas « secure ». A l’heure où l’on se bat pour que messieurs tout le monde ai droit à une sécurité informatique, si de grandes enseignes ne respectent pas les règles élémentaires, c’est mission impossible.

Car il faut le rappeler, la sécurité informatique tient du respect des règles par l’ensemble des acteurs de l’informatique.
Si les utilisateurs se forcent à utiliser des mots de passe complexe, et que les sites ne font rien pour en assurer leurs sécurités… Nous ne seront jamais tranquille.

PS : Si une loi obligeait tout les développeurs à avoir connaissance des règles de sécurité pour pouvoir exercer… Nous vivrions dans un monde sans pirate :p

Pour aller plus loin, voici une liste de livre traitant de la sécurité informatique, disponible sur Amazon bien sur