|
| |
Choix technologiques et sécurité
Nous allons rapidement vous présenté les choix technologiques que nous avons fait pour KeoPanel, ainsi que la manière dont la sacurité est mise en oeuvre.
- OS - Linux Debian : nous avons opté pour la distribution Debian, dans sa branche Stable (actuellement Sarge). Debian est une distribution particulièrement bien adaptée à l'exploitation de serveur, son système de paquages (apt-get) est redoutablement efficace, et surtout . . . il intègre une gestion des dépendances quasi sans faille. De plus, il s'agit d'une distribution tres commune, que pratiquement tous les prestataires de locations de dédiés propose par défaut.
- Paquets .deb par apt-get : nous avons décidé pour la version 2 de nous appuyer sur les paquets proposés directement par Debian, branche Stable. Il y a plusieurs raisons à ce choix.
- Ne passent en version stable, QUE des services ayant déjà fait leur preuves en production, et ayant fait leurs preuves dans les branches unstable et testing. Ce modèle implique toutefois que vous ne disposiez pas forecément des toutes dernières versions des services qui seront installés . . . il y a parfois plusieurs mois de "retard". Mais vous avez de solides garanties quand à la stabilité et la sécurité de votre système, ce qui nous parait nettement plus important dans un contexte d'exploitation publique d'un serveur, que du fait de disposer systématique des toutes versions des services.
- Si vous décider d'installer des paquages non installés par défaut avec KeoPanel, vous pourrez le faire en utilisant apt-get, sans risque que des services qui pourraient entrer en concurance avec KeoPanel ne soit aussi installés.
- Des patchs de sécurités rapidement mis en ligne grâce à une communauté tres active et réactive.
- KeoPanel lui-même est distribué sous forme d'un paquet de type .deb installable par apt-get. De cette manière l'installtion et les mises à jours sont tres simples et suivent une procédure commune et normalisée.
- Apache version 2 : bien que la branche 1.3 de Apache soit encore communement utilisée en production, la branche 2 propose des fonctionnalités intéressantes, et s'est révelée parfaitement stable et fonctionelle sur nos platerforme de test (hébergement mutualisé, avec plus de 10.000 comptes, en modèle multi-serveur !)
- PHP en CGI via suPHP : bien que les performances brutes soit tres légeremement moins bonne avac un PHP executé en CGI plutot qu'en module Apache, il apporte plusieurs avantages.
- possibilité d'associer un UID/GID spécifique à chaque compte client. Celà permet grace à une politique de gestion des droits soigneusement appliquée, d'assurer un niveau de sécurité supplémentaire. Nous détaillons celà dans le section "Sécurité".
- grâce au fait que les scripts PHP de chaque compte s'executerons avec des droits UID/GID propre, il est tres simple d'identifier l'origine d'un scripts problématique. Par exemple un scripts qui provoque un bouclage ou qui est victime d'un DoS, sera visible dans un simple - top - et caractériqué par son UID/GID qui permettrons de faire le lien avec le compte client dont il est issu.
- permet d'associer un fichier php.ini à chaque client. Il est ainsi possible d'appliquer une politique extrêmement souple et parfaitement adaptée aux besoins de chaque client.
- Safe Mode Off : contrairement à une idée reçue, le Safe Mode On n'est pas indispensable à l'execution de PHP dans un contexte sécurisé. Il existe d'autres possibilité de sécurisation, permettant une beaucoup plus grande souplesse. Le fait que le PHP de KeoPanel s'execute en Safe Mode Off, garanti une compatibilité maximale avec la plupart des scripts. Nous détaillons l'approche sécuritaire dans la section "Sécurité".
Politique sécuritaire
Nous allons rapidement évoqué la manière dont la politique sécuritaire est implémentée dans KeoPanel. Avant d'enter dans les considérations techniques, nous tenons à évoquer certaines choses :
- nous vous imposons une politique sécuritaire, cette imposition ne devrait toutefois pas vous poser de problème, puisque nous mettons également à votre dispositions les éléments nécessaires à la modification de la politique par défaut. Toutefois si vous décider de la modifier, faite le en parfaite connaissance de cause !
- la politique proposée par défaut est une politique qui fait ses preuves depuis plusieurs années et sur de nombreux serveurs d'hébergement mutualisés.
Entrons maintenant dans les considérations techniques :
- Safe Mode Off : contrairement à une idée recue, la Safe Mode On de PHP n'est pas un gage de sécurisation absolue de PHP. Il s'agit le plus souvent de la solution de facilité, mais qui malheureusement n'offre pas une grande souplesse et pose régulièrement des problème de compatibilité avec certains scripts PHP. Pour ces raisons, nous avons fait le choix d'un fonctionnement en Safe Mode Off et de l'application des éléments de sécurité manuel. Voici brièvement ces élements :
- restriction open_basedir : cette restriction à pour but d'empêcher l'accès aux fichiers et dossiers qui sont en dehors du dossier du compte client. Cette méthode ne s'appuye pas sur les droits d'accès UID/GID du système de fichiers, c'est un système de contrôle propre à PHP.
- droits UID/GID : chaque utilisateurs dispose d'un UID propre, ses fichiers et dossiers héritent de ces même droits. Les processus qui traitent les fichiers du compte, héritent eux aussi de ce UID spécifique. Dans le contexte exclusif de l'exécution de scripts PHP, cette disposition n'est pas indispensable, en effet les restriction open_basedir assurent une contôle suffisant. Toutefois, ces restriction UID/GID font office de filet de secour, dans l'éventualité où les restrictions open_basedir pourrait être contournées (quelques failles PHP dans le passé on démontré que celà était possible). Dans le cadre de l'execution de scripts CGI, ces restrictions prennent toute leur importance . . .
- séparation physique des dossiers de sessions : les sessions de chaque compte client sont placées dans un dossier spécifique. De cette manière le vol de sessions devient tres improbable. Dans l'absolu, chaque utilisateur ayant ses propres UID, dont les fichiers sessions héritent aussi, le fait de regrouper toutes les sessions dans un dossier unique n'est pas supposé poser de problème, mais là aussi le passé nous a démontrer le contraire . . . (failles PHP).
- séparation physique des dossiers d'upload : comme pour le point précédent, une séparation nette des dossiers d'upload a été mise en place. Nous préferons ne pas nous appuyer uniquement sur les restrictions UID des fichiers en cours d'upload pour assuré leur sécurité. Cette disposition est d'autant plus nécessaire, que le dossier d'upload doit être inclu dans l'open_basedir des comptes clients. SI nous n'avions pas inclu ce dossier dans l'open_basedir, l'utilisation des fonctions de manipulation de fichiers standard aurait été impossible pour la gestion des fichiers uploadés, seul l'utilisation de la fonction move_uploaded_file serait permise. Ce qui n'est pas sans posé de nombreux problème de compatibilité !
- désactivation de plusieurs fonctions PHP : dans un contexte Safe Mode Off, il serait tres déraisonnable de laisser l'utilisateur avoir accès à toutes les fonctions proposées par ce language. Il existe diverses fonctions, qui de par leur nature même peuvent poser des problèmes de sécurités. C'est notement le cas de toutes les fonctions permettant de faire executer des programme sur le serveur (exec, popen, shell_exec . . .). Sachez toutefois que l'utilisation de ces fonctions critiques est TRES RARE et que leur désactivation ne devrait pas vous gêner. Nous avons également désactivé plusieurs fonctions ne posant pas de problème de sécurité de manière directe, mais permattant à un hackeur d'obtenir des informations pertinante sur le système, c'est le cas de la fonction phpinfo() entre autre.
A venir . . .
|
|
|
