Vous avez un hébergement partagé et vous vous inquiétez de la sécurité? Voici ce que vous devez savoir

Hébergement partagé. C'est l'option bon marché, n'est-ce pas? Et pour une grande partie de la population, c'est tout ce dont ils auront besoin pour héberger leur site Web ou leur application Web. Et quand bien fait, l'hébergement partagé est évolutif, rapide et sécurisé.

Mais que se passe-t-il quand ce n'est pas bien fait?

Eh bien, c’est là que des problèmes de sécurité dangereux commencent à se faire jour. C’est le moment où votre site risque d’être altéré ou les données privées que vous possédez sont divulguées. Mais ne vous inquiétez pas. La grande majorité des hébergeurs ont des mesures de sécurité correctes. Il faut se méfier des hôtes passionnés de bonnes affaires.

Nous recommandons l'hébergement mutualisé d'InMotion Hosting avec stockage SSD.

Nous allons explorer les problèmes de sécurité liés à l'hébergement partagé. Mais d’abord, parlons de ce qui rend une plate-forme d’hébergement mutualisée sécurisée.

Ce qui fait un hôte Web sécurisé

Quelques considérations de sécurité exceptionnelles doivent être prises en ce qui concerne l'hébergement partagé..

• Chaque utilisateur du serveur doit être isolé des autres utilisateurs et ne doit pas pouvoir accéder aux fichiers d’autres utilisateurs ni les modifier..
• Une faille de sécurité dans la logique d'un site Web hébergé sur le serveur ne devrait pas avoir d'incidence sur les autres utilisateurs..
• Le serveur est régulièrement corrigé, mis à jour et surveillé pour résoudre les problèmes de sécurité architecturale..
• Chaque utilisateur doit avoir son propre accès isolé à la base de données et ne doit pas être autorisé à modifier les enregistrements stockés ni les autorisations de table des autres utilisateurs..

Encore une fois, la plupart des hébergeurs Web répondent à ces exigences pour leurs offres partagées. Mais si vous envisagez d’héberger plusieurs sites Web sur un serveur, ou si vous êtes curieux de voir comment votre société d’hébergement se range, ou pensez même à lancer votre propre société d’hébergement et êtes désireux de trouver un moyen de sécuriser vos utilisateurs, veuillez lire: sur.

Mais d'abord, un déni de responsabilité

Avant d'entrer dans le vif du sujet des attaques communes dressées contre l'hébergement mutualisé, je tiens simplement à préciser que cet article ne constituera pas (et ne devrait pas être lu comme) une liste exhaustive de problèmes de sécurité potentiels..

La sécurité est, en un mot, grande. Il y a beaucoup de façons de compromettre un site. Cela va double pour l'hébergement partagé. Les couvrir en un seul article n'a jamais été prévu.

Si vous êtes paranoïaque à propos de votre sécurité, procurez-vous un VPS ou un serveur dédié. Ce sont des environnements dans lesquels vous avez (pour la plupart) un contrôle absolu sur ce qui se passe. Si vous n’êtes pas sûr des différents types d’hébergement Web, consultez cet article Les différentes formes d’hébergement de sites Web expliquées [Technologie expliquée] Les différentes formes d’hébergement de sites Web expliquées [Technologie expliquée] En savoir plus sur mon collègue, James Bruce.

Je tiens également à souligner que ce message ne doit pas être interprété comme une attaque contre l'hébergement partagé. Il s’agit plutôt d’un regard purement académique sur les problèmes de sécurité liés à cette catégorie d’hébergement Web..

Répertoire Traversal

Commençons par les attaques de type "traversée de répertoires". Ce type d’attaque vous permet d’accéder aux fichiers et aux répertoires stockés en dehors de la racine Web..

En clair anglais? Eh bien, imaginons qu'Alice et Bob utilisent le même serveur pour héberger leurs sites Web. Les fichiers d'Alice sont stockés dans / var / www / alice, tandis que les documents de Bob se trouvent dans / var / www / bob. De plus, supposons qu'il existe un autre dossier sur le serveur (/ usr / crappyhosting / myfolder) contenant un fichier texte non chiffré (nous l'appellerons pwd.txt) contenant les noms d'utilisateur et les mots de passe du système..

Avec moi jusqu'à présent? Bien. Imaginons maintenant que le site Web de Bob propose des fichiers PDF générés localement et que le fichier local soit référencé dans l'URL. Quelque chose comme:

http://example.com/file?=report.pdf

Que se passerait-il si je remplaçais le 'report.pdf' par certains paramètres UNIX modifiant le répertoire?

http://example.com/file?=… / alice /

Si le serveur est configuré de manière incorrecte, cela vous permettra alors de voir la racine du document d'Alice. Intéressant, mais nous sommes beaucoup plus intéressés par ce fichier de passeports juteux. Mots de passe Accio!

http://example.com/file?=… /… /… /usr/crappyhosting/myfolder/pwd.txt

C'est vraiment aussi simple que ça. Mais comment traitons-nous? C'est facile.

Jamais entendu parler d’un utilitaire Linux peu connu appelé chroot? Vous avez probablement déjà deviné ce que ça fait. Il définit la racine Linux / UNIX sur un dossier arbitraire, empêchant les utilisateurs de le quitter. Effectivement, cela stoppe les attaques de traversée de répertoires.

Il est difficile de dire si votre hôte a mis cela en place sans enfreindre la loi. Après tout, pour le tester, vous accéderiez à des systèmes et à des fichiers auxquels vous n'êtes pas autorisé. Dans cet esprit, il serait peut-être judicieux de parler à votre hébergeur et de lui demander comment il isole ses utilisateurs les uns des autres..

Utilisez-vous votre propre serveur d'hébergement partagé et n'utilisez pas chroot pour protéger vos utilisateurs? Certes, chrooter vos environnements peut être difficile. Heureusement, il existe une multitude de plugins qui rendent cela facile. Regardez mod_chroot, en particulier.

Injection de commande

Revenons à Alice et Bob. Nous savons donc que l’application Web de Bob contient quelques… Ahem… Des problèmes de sécurité. L'un d'entre eux est la vulnérabilité d'injection de commande, qui vous permet d'exécuter des commandes système arbitraires. Guide de démarrage rapide avec la ligne de commande Linux Guide de démarrage rapide avec la ligne de commande Linux Vous pouvez faire beaucoup de choses étonnantes avec des commandes sous Linux. et ce n'est vraiment pas difficile à apprendre. Lire la suite .

Le site Web de Bob vous permet d'exécuter une requête whois sur un autre site Web, qui est ensuite affichée dans le navigateur. Il existe une zone de saisie HTML standard qui accepte un nom de domaine, puis exécute la commande système whois. Cette commande est exécutée en appelant la commande PHP system ().

Que se passerait-il si quelqu'un introduisait la valeur suivante?

example.com && cd… / alice / && rm index.html

Eh bien, décomposons-le. Certaines de ces choses pourraient vous être familières si vous avez lu notre «Guide de démarrage pour Linux» Guide de démarrage pour Linux Guide de démarrage pour Linux Un guide de démarrage pour débutants sous Linux! Vous avez probablement entendu parler de Linux, le système d’exploitation libre et à code source ouvert qui pousse Microsoft. En savoir plus e-book, que nous avons déjà publié en 2010, ou avons jeté un coup d'œil sur notre aide-mémoire Linux pour la ligne de commande.

Tout d'abord, il lancera une requête whois sur example.com. Ensuite, le répertoire de travail actuel deviendrait le répertoire racine d'Alice. Ensuite, le fichier intitulé "index.html" sera supprimé, ce qui constitue la page d'index de son site Web. Ce n'est pas bon. Non monsieur.

Alors, en tant qu'administrateurs système, comment pouvons-nous atténuer cela? Eh bien, pour revenir à l'exemple précédent, nous pouvons toujours mettre chaque utilisateur dans son propre environnement isolé, désinfecté et chrooté..

Nous pouvons également aborder cela à partir d'un niveau de langue. Il est possible (bien que cela puisse casser des choses) de supprimer globalement les déclarations de fonction des langues. Autrement dit, il est possible de supprimer des fonctionnalités des langues auxquelles les utilisateurs ont accès..

En regardant PHP en particulier, vous pouvez supprimer des fonctionnalités avec Runkit - la boîte à outils officielle de PHP pour modifier les fonctionnalités du langage. Il y a une mine de documentation là-bas. Lire dedans.

Vous pouvez également modifier le fichier de configuration de PHP (php.ini) pour désactiver les fonctions souvent mal utilisées par les pirates. Pour ce faire, ouvrez un terminal sur votre serveur et ouvrez votre fichier php.ini dans un éditeur de texte. J'aime utiliser VIM, mais NANO est également acceptable..

Recherchez la ligne commençant par disable_functions et ajoutez les définitions de fonction que vous souhaitez interdire. Dans ce cas, il s'agirait de exec, shell_exec et system, bien qu'il soit intéressant de noter qu'il existe d'autres fonctions intégrées exploitables par des pirates.

disable_functions = exec, shell_exec, system

Attaques linguistiques et interprètes

Alors, regardons PHP. C'est la langue qui alimente un nombre impressionnant de sites Web. Il comporte également un certain nombre d'idiosyncrasies et de comportements étranges. Comme ça.

PHP est généralement utilisé avec le serveur Web Apache. Pour la plupart, il est impossible de charger plusieurs versions de la langue avec cette configuration.

Pourquoi c'est un problème? Eh bien, imaginons que l’application Web de Bob ait été construite en 2002. C’est il ya très longtemps. C'est à l'époque où Michelle Branch était encore en tête du classement, Michael Jordan jouait encore pour les Wizards de Washington et PHP était une langue bien différente..

Mais le site de Bob fonctionne toujours! Il utilise tout un tas de fonctions PHP abandonnées et obsolètes, mais ça marche! Utiliser une version moderne de PHP aurait pour effet de casser le site Web de Bob et pourquoi Bob devrait-il réécrire son site Web pour répondre aux caprices de son hébergeur?

Cela devrait vous donner une idée du dilemme auquel font face certains hébergeurs. Ils doivent trouver un équilibre entre le maintien d'un service sûr et sûr sur le plan architectural, tout en veillant à ce que les clients payants soient satisfaits.

En conséquence, il n'est pas rare de voir des hôtes plus petits et indépendants utiliser les anciennes versions de l'interpréteur PHP (ou de tout autre langage).

Il n'est pas rare de voir des hôtes plus petits et indépendants utiliser les anciennes versions de PHP, exposant potentiellement les utilisateurs à des risques de sécurité..

Pourquoi est-ce une mauvaise chose? Premièrement, cela exposerait les utilisateurs à un certain nombre de risques pour la sécurité. Comme la plupart des principaux progiciels, PHP est constamment mis à jour pour traiter la multitude de vulnérabilités en matière de sécurité qui sont constamment découvertes (et divulguées)..

De plus, cela signifie que les utilisateurs ne peuvent pas utiliser les dernières fonctions linguistiques (et les meilleures). Cela signifie également que les fonctions qui ont été déconseillées pour une raison restent. Dans le cas du langage de programmation PHP, cela inclut les fonctions mysql_ qui sont utilisées pour interagir avec le système de base de données relationnelle MySQL et dl (), qui permet aux utilisateurs d'importer leurs propres extensions de langage..

En tant qu'utilisateur, vous devriez pouvoir voir quelle version d'un interpréteur s'exécute sur votre service. S'il est obsolète ou s'il contient un certain nombre de failles de sécurité, contactez votre hôte..

Qu'en est-il des administrateurs système? Vous avez quelques options ici. La première (et la plus prometteuse) consiste à utiliser Docker pour chacun de vos utilisateurs. Docker vous permet d'exécuter simultanément plusieurs environnements isolés, à la manière d'une machine virtuelle, sans avoir à exécuter un autre système d'exploitation. En conséquence, c'est rapide. Vraiment très vite.

En clair anglais? Vous pouvez exécuter le dernier et le meilleur interpréteur de pointe pour la majorité de vos utilisateurs, tandis que les clients utilisant d'anciennes applications utilisant des interpréteurs anciens et obsolètes pour le faire sans compromettre les autres utilisateurs..

Cela a aussi l’avantage d’être agnostique. PHP, Python, Ruby. Peu importe. C'est tout pareil.

Ne pas avoir de cauchemars.

Ce message était destiné à faire quelques choses. En premier lieu, il visait à attirer votre attention sur le nombre de problèmes de sécurité auxquels les sociétés d’hébergement Web doivent faire face afin d’assurer la sécurité de leurs clients et de leurs données..

Il visait également à vous montrer comment les sites hébergés sur le même serveur peuvent s’affecter. Voulez-vous mettre un frein à cela? Commencez à obéir à de bonnes normes de codage sécurisé. En particulier, commencez à désinfecter vos entrées à la fois sur le front-end et le back-end.

La nouvelle fonctionnalité de validation de formulaire HTML5 est un bon début. Nous en avons déjà parlé dans notre guide HTML5. Ensemble, nous pouvons rendre les sites Web plus sûrs en étant des programmeurs meilleurs et plus consciencieux..

Comme toujours, je suis prêt à écouter vos pensées. Laissez moi un commentaire ci-dessous.

Crédit photo: Tout le monde a besoin d'un pirate informatique (Alexandre Dulaunoy), autocollant sur la fenêtre du taxi (Cory Doctorow), salle des serveurs (Torkild Retvedt), livres et magazines Linux (library_mistress), PHP Elephant (Markus Tacker)

En savoir plus sur: la sécurité en ligne, l'hébergement Web.