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

Publicité

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 lorsqu'il est 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 manifester. C'est à ce moment-là que votre site risque d'être endommagé ou que les données privées que vous détenez sont divulguées. Mais ne vous inquiétez pas. La grande majorité des hébergeurs Web ont des mesures de sécurité décentes. Ce ne sont que les hôtes qui volent la nuit au sous-sol dont vous devez vous méfier.

Nous recommandons Hébergement partagé 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 partagé sécurisée.

Ce qui fait un hébergeur Web sécurisé

Il y a quelques considérations de sécurité remarquables qui devraient être faites 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 ou modifier les fichiers des autres utilisateurs.
• Une vulnérabilité de sécurité dans la logique d'un site Web hébergé sur le serveur ne devrait pas pouvoir affecter 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 à la base de données isolée et ne doit pas être autorisé à modifier les enregistrements stockés ou 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 place, ou même penser à lancer votre propre société d'hébergement et vous avez hâte de savoir comment sécuriser vos utilisateurs, alors lisez s'il vous plaît sur.

Mais d'abord, un avertissement

Avant d'entrer dans le vif du sujet en examinant les attaques courantes destinées à l'hébergement mutualisé, je veux juste déclarer que ce billet ne sera pas (et ne doit pas être lu comme) une liste exhaustive des potentiels de sécurité problèmes.

La sécurité est, en un mot, grande. Il existe de nombreuses façons de compromettre un site. Cela va doubler pour l'hébergement mutualisé. Les couvrir dans 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 ce post Explication des différentes formes d'hébergement de sites Web [Explication de la technologie] Lire la suite de mon collègue, James Bruce.

Je dois é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.

Traversée d'annuaire

Commençons par les attaques de traversée de répertoire (souvent appelées «traversée de chemin»). Ce type d'attaque vous permet d'accéder à des fichiers et des répertoires qui sont stockés en dehors de la racine Web.

En anglais simple? 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) qui contient un fichier de texte en clair non chiffré (nous l'appellerons pwd.txt) contenant les noms d'utilisateur du système et mots de passe.

Jusqu'à présent avec moi? Bien. Imaginons maintenant que le site Web de Bob diffuse 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 qui changent le répertoire?

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

Si le serveur est mal configuré, cela vous permettra alors de voir la racine du document d'Alice. Intéressant, mais nous sommes beaucoup plus intéressés par ce dossier 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 y faire face? C'est facile.

Jamais entendu parler d'un utilitaire Linux peu connu appelé chroot? Vous avez probablement déjà deviné ce que cela fait. Il définit la racine Linux / UNIX dans un dossier arbitraire, ce qui empêche les utilisateurs de le quitter. En effet, il arrête les attaques de traversée de répertoire dans leurs pistes.

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é à accéder. Dans cet esprit, il serait peut-être judicieux de parler à votre hébergeur et de savoir comment ils isolent leurs utilisateurs les uns des autres.

Vous utilisez 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 facilitent la tâche. Jetez un œil à mod_chroot, en particulier.

Injection de commande

Revenons à Alice et Bob. Donc, nous savons que l’application Web de Bob contient quelques… Ahem… Problèmes de sécurité. L'un d'eux est la vulnérabilité d'injection de commandes, qui vous permet d'exécuter commandes système arbitraires Un guide rapide pour commencer avec la ligne de commande LinuxVous pouvez faire beaucoup de choses incroyables 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 s'affiche ensuite 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 saisissait la valeur suivante?

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

Eh bien, décomposons-le. Certains de ces éléments peuvent vous être familiers si vous avez lu notre «Guide de démarrage de Linux» Débuter avec Linux et UbuntuVous souhaitez passer à Linux... mais par où commencer? Votre PC est-il compatible? Vos applications préférées fonctionneront-elles? Voici tout ce que vous devez savoir pour commencer avec Linux. Lire la suite e-book, que nous avons déjà publié en 2010, ou qui ont jeté un œil à notre Aide-mémoire sur la ligne de commande Linux.

Tout d'abord, il exécutera une requête whois sur example.com. Ensuite, il changerait le répertoire de travail actuel en racine de document d'Alice. Ensuite, il supprimerait le fichier appelé «index.html» qui est la page d'index de son site Web. Ce n'est pas bon. Non monsieur.

Ainsi, en tant qu'administrateurs système, comment pouvons-nous atténuer cela? Eh bien, pour revenir à l'exemple précédent, nous pouvons toujours placer chaque utilisateur dans son propre environnement isolé, aseptisé 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 langages. Autrement dit, il est possible de supprimer des fonctionnalités des langues auxquelles les utilisateurs ont accès.

En ce qui concerne 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 existe une multitude de documentation. Lisez-le.

Vous pouvez également modifier le fichier de configuration de PHP (php.ini) pour désactiver les fonctions qui sont souvent utilisées abusivement 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 qui commence par disable_functions et ajoutez les définitions de fonction que vous souhaitez interdire. Dans ce cas, ce serait exec, shell_exec et system, bien qu'il soit intéressant de noter qu'il existe d'autres fonctions intégrées qui sont exploitables par les pirates.

disable_functions = exec, shell_exec, system

Attaques basées sur la langue et les interprètes

Voyons donc PHP. C'est le langage qui alimente un nombre surprenant de sites Web. Il s'accompagne également d'un certain nombre d'idiosyncrasies et de comportements étranges. Comme ça.

PHP est généralement utilisé en conjonction 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? Imaginons que l’application Web de Bob ait été initialement créée en 2002. C’est il y a longtemps. C'est à l'époque où Michelle Branch était toujours en tête des charts, Michael Jordan jouait toujours pour les Washington Wizards et PHP était un langage très différent.

Mais le site Web de Bob fonctionne toujours! Il utilise tout un tas de fonctions PHP abandonnées et obsolètes, mais cela fonctionne! L'utilisation d'une version moderne de PHP briserait efficacement 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 sont confrontés certains hébergeurs Web. Ils doivent trouver un équilibre entre le maintien d'un service architecturalement sûr et sécurisé, tout en restant en harmonie avec la satisfaction des clients payants.

Par conséquent, il n'est pas rare de voir des hôtes indépendants plus petits utiliser des versions plus anciennes de l'interpréteur PHP (ou n'importe quel langage, d'ailleurs).

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

Pourquoi est-ce une mauvaise chose? Eh bien, premièrement, cela exposerait les utilisateurs à un certain nombre de risques de sécurité. Comme la plupart des principaux logiciels, PHP est constamment mis à jour pour répondre à la pléthore de failles de sécurité qui sont constamment découvertes (et divulguées).

En outre, cela signifie que les utilisateurs ne peuvent pas utiliser les fonctions linguistiques les plus récentes (et les meilleures). Cela signifie également que les fonctions obsolètes pour une raison demeurent. Dans le cas du Langage de programmation PHP Apprenez à construire avec PHP: un cours intensifPHP est le langage que Facebook et Wikipedia utilisent pour répondre à des milliards de demandes quotidiennement; le langage de fait utilisé pour enseigner aux gens la programmation Web. C'est magnifiquement simple, mais brillamment puissant. Lire la suite , cela inclut les fonctions mysql_ ridiculement terribles (et récemment déconseillées) 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 leur propre langue extensions.

En tant qu'utilisateur, vous devriez pouvoir voir quelle version d'un interprète est en cours d'exécution sur votre service. S'il est obsolète ou 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 plusieurs environnements isolés simultanément, tout comme une machine virtuelle, sans avoir à exécuter un autre système d'exploitation. En conséquence, c'est rapide. Vraiment, très vite.

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

Cela présente également l'avantage d'être indépendant de la langue. PHP, Python, Ruby. Peu importe. C'est tout pareil.

N'ayez pas de cauchemars.

Ce message était destiné à faire deux ou trois choses. Tout d'abord, il s'agissait d'attirer votre attention sur le nombre de problèmes de sécurité auxquels les hébergeurs Web doivent faire face afin d'assurer la sécurité de leurs clients et de leurs données.

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

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

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

Crédit photo: Tout le monde a besoin d'un pirate (Alexandre Dulaunoy), Autocollant sur la fenêtre du taxi (Cory Doctorow), Salle des serveurs (Torkild Retvedt), Livres et magazines Linux (library_mistress), Éléphant PHP (Markus Tacker)