« Linux-VServer » : différence entre les versions

Seul l'hôte àa la possibilité de manipuler iptables. Les règles sont très restrictives, et correspondent strictement aux services déployés sur le VServer. Ceux-ci ne peuvent initier des connexions, hors celles nécessaires pour assurer le service. Ainsi un pirate, même root sur un VServer, restera enfermé car il ne pourra pas lancer de connexions vers l'extérieur.

Un risque est constitué par l'escalade de privilège d'un VServer vers le serveur hôte. En effet, les VServers sont basés sur une couche de virtualisation logique assez fine. Par le passé, elle a été contournée une fois. Cet unique bug a été rapidement corrigé (chroot barrier), mais prouve que le concept n'est pas à l'épreuve des balles. Si l'escalade arrive jusqu'à l'hôte, en tant que root, (ou si l'hôte fait tourner des services exploitables), alors la sécurité est mise à mal, puisque le serveur hôte a une vision complète de tous les fichiers des VServers, et peut accéder à chacun des processus de ceux-ci, ainsi que de s'y logguer en tant que root... Il ne s'agit plus cette fois d'un seul serveur piraté, mais de la totalité des VServers hébergés sur cet hôte. Il n'y a cependant actuellement pas de faille de ce type connue.

Les précautions conseillées sont les suivantes : Tous les service importants déployés sur des VServers sont redondés. Les VServers co-hébergés sur une même machine hôte sont, autant que possible, avec des catégories d'usage et des contraintes de sécurité proches. Et bien sursûr, la règle primordiale est de ne faire tourner AUCUN service sur l'hôte à part SSH et les iptables.