2008-09-28 11 views
18

J'ai Apache fonctionnant sur un serveur Debian public, et je suis un peu inquiet pour la sécurité de l'installation. Il s'agit d'une machine qui héberge plusieurs projets de loisirs, donc aucun d'entre nous qui utilise la machine n'a vraiment le temps de constamment surveiller les correctifs en amont, rester conscient des problèmes de sécurité, etc. Mais je voudrais empêcher les méchants ou, s'ils entrent, gardez-les dans un bac à sable.Meilleure façon de mettre en sandbox Apache sur Linux

Alors, quel est le meilleur, facile à installer, facile à maintenir la solution ici? Est-il facile de configurer un sandbox Linux en mode utilisateur sur Debian? Ou peut-être une prison chroot? Je voudrais avoir un accès facile aux fichiers à l'intérieur de la boîte noire de l'extérieur. C'est l'un de ces moments où il devient très clair pour moi que je suis un programmeur, pas un administrateur système. Toute aide serait très appréciée!

Répondre

15

Les prisons chroot peuvent être vraiment non sécurisées lorsque vous utilisez un environnement de bac à sable complet. Les attaquants ont un accès complet aux fonctionnalités du noyau et peuvent, par exemple, monter des lecteurs pour accéder au système "hôte".

Je vous suggère d'utiliser linux-vserver. Vous pouvez voir linux-vserver comme une prison chroot améliorée avec une installation complète de Debian à l'intérieur. Il est très rapide car il s'exécute dans un seul noyau, et toute l'exécution de code est nativement.

Personnellement, j'utilise linux-vserver pour la séparation de tous mes services et il n'y a que des différences de performance à peine perceptibles. Pour obtenir des instructions d'installation, consultez la section linux-vserver wiki.

Cordialement, Dennis

3

Vous pouvez toujours le configurer à l'intérieur d'une machine virtuelle et en conserver une image, afin de pouvoir la relancer si nécessaire. De cette façon, le serveur est extrait de votre ordinateur réel, et tout virus, etc., est contenu dans la machine virtuelle. Comme je l'ai déjà dit, si vous conservez une image en tant que sauvegarde, vous pouvez restaurer votre état précédent assez facilement.

0

Créer une machine virtuelle. essayez quelque chose comme vmware ou qemu

3

pour vous assurer qu'il est dit, chroot sont rarement Jails une bonne idée, il est, en dépit de l'intention, très facile à sortir de, enfait je l'ai vu faire par les utilisateurs accidentellement!

3

Sans vouloir vous offenser, mais si vous n'avez pas le temps de surveiller les correctifs de sécurité et de rester conscient des problèmes de sécurité, vous devriez être concerné, peu importe votre configuration. D'un autre côté, le simple fait que vous réfléchissiez à ces problèmes vous distingue des autres 99,9% des propriétaires de ces machines. Vous êtes sur le bon chemin!

4

Je seconde ce que xardias dit, mais recommande OpenVZ à la place. Il est similaire à Linux-Vserver, donc vous pouvez vouloir comparer ces deux-là en allant dans cette direction.

J'ai configuré un serveur Web avec un serveur http proxy (nginx), qui délègue ensuite le trafic vers différents conteneurs OpenVZ (en fonction du nom d'hôte ou du chemin demandé). À l'intérieur de chaque conteneur, vous pouvez configurer Apache ou tout autre serveur Web (par exemple, nginx, lighttpd, ..). De cette façon, vous n'avez pas un seul Apache pour tout, mais vous pouvez créer un conteneur pour tout sous-ensemble de services (par exemple, par projet).

conteneurs OpenVZ peuvent facilement obtenir mis à jour tout à fait ("for i in $ (vzlist), faire apt-get vzctl exec mise à niveau; fait")

Les fichiers des différents conteneurs sont stockés dans le nœud de matériel et par conséquent, vous pouvez facilement y accéder par SFTP dans le nœud matériel. En plus de cela, vous pouvez ajouter une adresse IP publique à certains de vos conteneurs, y installer SSH, puis y accéder directement à partir du conteneur. J'ai même entendu parler de proxies SSH, donc l'adresse IP publique supplémentaire pourrait être inutile même dans ce cas.

0

Quel problème essayez-vous vraiment de résoudre? Si vous vous souciez de ce qu'il y a sur ce serveur, vous devez empêcher les intrus d'y accéder. Si vous vous souciez de ce que les intrus feraient avec votre serveur, vous devez restreindre les capacités du serveur lui-même.

Aucun de ces problèmes n'a pu être résolu avec la virtualisation, sans sévèrement critiquer le serveur lui-même. Je pense que la vraie réponse à votre problème est la suivante:

  1. exécutez un système d'exploitation qui vous fournit un mécanisme facile pour les mises à jour du système d'exploitation.
  2. utilisez le logiciel fourni par le fournisseur.
  3. sauvegarde tout souvent.
+0

Bien que tout cela soit fondamentalement vrai, une sorte de bac à sable offre une couche de sécurité supplémentaire utile. Que cela vaille la peine de le faire dépend de combien d'autre est sur le serveur - si la seule utilisation de la machine est d'être un serveur web, il n'y a pas grand intérêt à mettre le serveur web dans un bac à sable. –

3

Je trouve étonnant que personne n'a mentionné mod_chroot et suEXEC, qui sont les choses de base que vous devriez commencer, et, très probablement les seules choses dont vous avez besoin.

+0

Corrigez-moi si je me trompe, mais chroot n'a jamais été destiné à être un élément de sécurité. Les prisons chroot ne sont pas sécurisées. – Alexander

+1

Le programme UNIX chroot (8) n'est pas * conçu * comme un logiciel de sécurité - vous avez raison, mais Apache mod_chroot n'a rien à voir avec ce programme.Il utilise simplement l'appel système chroot (2) pour isoler Apache du reste du système. – Terminus

+1

Lors de l'utilisation de mod_chroot, Apache s'exécute dans un environnement dépourvu de tout ce qui pourrait modifier le monde extérieur. suexec permet alors d'exécuter n'importe quel VirtualHost sous un utilisateur différent, afin qu'ils ne puissent pas se jouer les uns avec les autres. – Terminus

1

Vous devez utiliser SELinux. Je ne sais pas si c'est supporté par Debian. si ce n'est pas le cas, installez simplement Centos 5.2 avec SELinux activé dans une machine virtuelle. Ne devrait pas être trop de travail, et beaucoup plus sûr que tout amateur chrooting, qui n'est pas aussi sûr que la plupart des gens croient. SELinux a la réputation d'être difficile à administrer, mais si vous utilisez un serveur Web, cela ne devrait pas poser de problème. Vous devrez peut-être faire quelques "sebool" pour laisser httpd se connecter à la DB, mais c'est à peu près tout.

+0

Les crochets LSM sont plutôt morts au cerveau et ne s'appliquent pas vraiment ici. –

1

Bien que tout ce qui précède soit de bonnes suggestions, je suggère également d'ajouter une règle iptables pour interdire les connexions réseau sortantes inattendues. Depuis la première chose que la plupart des exploits Web automatisés font est de télécharger le reste de leur charge utile, empêchant la connexion réseau peut ralentir l'attaquant. Certaines règles similaires à celles-ci peuvent être utilisées (Attention, votre serveur web peut avoir besoin d'accéder à d'autres protocoles): iptables --append OUTPUT -m propriétaire --uid-owner apache -m état --state ESTABLISHED, RELATED - -jump ACCEPT iptables --append OUTPUT -m propriétaire --uid-owner apache --protocole udp --destination-port 53 --jump ACCEPT iptables --append OUTPUT -m propriétaire --uid-owner apache --jump REJECT

1

Si vous utilisez Debian, debootstrap est votre ami couplé avec QEMU, Xen, OpenVZ, Lguest ou une pléthore d'autres.

Questions connexes