Bonjour,
J'ai une application web (php) assez sensible d'un point de vue sécurité car elle permet à des gens de soumettre des codes source que l'application va compiler et lancer.
J'aimerais la faire tourner dans un environnement ultra sécurisé donc pour ne pas compromettre la sécurité du serveur.
Ma première piste était de chrooter l'appli avec l'option chroot de suphp (pour le moment je n'y suis pas arrivé car j'ai déjà suphp pour les autres utilisateurs et il ne veut pas utiliser une config différente pour mon utilisateur, j'ai pas voulu y passer trop de temps encore).
Mais même, je ne suis pas convaincu..
Une autre solution serait de faire tourner un second apache directement chrooté et limiter l'utilisateur de cet apache pour éviter qu'il ne fasse planter la machine.
Bref, pour le moment je sais pas précisément quoi faire et j'ai peur de faire un truc qui au final ne serait pas aussi sécurisé que je ne le pensais. Donc je fais appel à vous.
Merci :)
Forum général.général Application sensible
16
août
2008
# Changement d'utilisateur
Posté par Kerro . Évalué à 2.
Tu peux sérieusement limiter la casse en changeant d'utilisateur avant de lancer l'application. Tu te fais un bête script shell en SUID root (ou autre si c'est défini dans /etc/sudoers ou dans PAM). Ce script change d'utilisateur (celui que tu crée exprès) et lance ensuite l'application désirée. Le top étant un bon petit chroot avant. Et le top du top étant de mettre tout ça sur une machine séparée, ou dans une machine virtuelle.
[^] # Re: Changement d'utilisateur
Posté par Maxime (site web personnel) . Évalué à 2.
Mes utilisateurs ils peuvent faire des trucs sensibles mais ils sont grands, je leur fais confiance (et encore, ils lancent les scripts avec leur compte donc c'est aussi sensible que lorsqu'ils sont connectés en ssh sur le serveur).
Par contre cette appli donne la possibilité à n'importe qui (que je ne connais pas forcement) de compiler une appli et de la lancer...
Donc première chose, il me faut bloquer la possibilité de faire une fork bomb. Ensuite je veux pouvoir limiter l'utilisation mémoire par processus et enfin, je veux chrooter le tout.
C'est vrai qu'une machine virtuelle me ferait tout ça mais je n'ai pas envie d'avoir une VM qui me bouffe de manière constante une partie de ma mémoire qui est utile pour le reste du serveur. Et je ne veux pas installer linux-vserver qui serait parfait pour ça pour d'autres raisons.
[^] # Re: Changement d'utilisateur
Posté par Kerro . Évalué à 3.
Si vraiment n'importe qui peut compiler puis lancer son programme, alors ça veut dire qu'on peut saturer ta connexion réseau (un simple wget en boucle), qu'on peut saturer la lecture/écriture sur le disque, et même tenter de le détruire en faisant constament bouger les têtes, qu'on peut saturer le processeur, qu'on peut vider /dev/random en premanance, etc etc.
Tu n'es pas sorti de l'auberge :-)
[^] # Re: Changement d'utilisateur
Posté par Maxime (site web personnel) . Évalué à 2.
Ensuite, et justement c'est le but de ma question à l'origine, je cherche à avoir un environnement sécurisé où l'on ne peut rien faire de dangereux pour le système.
[^] # Re: Changement d'utilisateur
Posté par Kerro . Évalué à 3.
Tente toujours cette commande:
# aptitude install protection-magique
[^] # Re: Changement d'utilisateur
Posté par Maxime (site web personnel) . Évalué à 4.
Ce que j'aimerais savoir c'est si c'est suffisant. Et d'ailleurs, tu as pointé, et je t'en remercie, des points qui pourront poser problème : saturation du réseau et accès disques dans le but de détériorer le matériel.
Ce que j'aimerais savoir c'est ce que je dois faire pour éviter des problèmes comme ceux là.
Autre chose, j'aimerais savoir s'il est possible de lancer une application en lui limitant sa consommation mémoire et la tuer en cas de dépassement.
[^] # Re: Changement d'utilisateur
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Changement d'utilisateur
Posté par Maxime (site web personnel) . Évalué à 2.
[^] # Re: Changement d'utilisateur
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Pour sécuriser un serveur, il y a de nombreux outils. Le chroot en est un, mais il ne faut pas croire que c'est magique.
Déjà dans php, il y a un certain nombre de mécanismes de sécurité intéressants :
- openbasedir
- safe-mode
- limitation des ressources (memory_limit, max_execution_time)...
- interdiction de certaines fonctions (fsockopen pfsockopen..)
Pour apache :
- il faut des Timeout courts
- il faut qu'il soit exécuté par un utilisateur sans shell.
- il faut installer et paramétrer mod_security.
Au niveau réseau.
- Il faut tout interdire en entrée et en sortie. Puis juste autoriser le minimum pour que son appli fonctionne.
- Il faut détecter les paquets pourris et éventuellement bannir les IP en cause (quoique).
- Il faut surtout utiliser des ports atypiques pour les services annexes (ssh entre autre)
Au niveau système de fichier :
- il faut que / et /usr soient en lecture seule.
- il faut que tous les utilisateurs aient des quotas sur les partitions sur lesquelles ils sont susceptibles d'écrire.
- il faut que toutes les partitions (/tmp /var /home) ou rien ne doit être executé soient montées en noexec
Au niveau des utilisateurs:
- il ne faut pas que les utilisateurs qui n'en ont pas besoin aient un shell valide et que les autres aient un shell le plus limité possible.
- il faut définir (si le système le permet ) des limites en ressources basses pour chaque utilisateurs (man limits).
Au niveau de L'OS,
Il faut interdire :
- les changements de règles de firewalling
- les passages de root vers noyau (chargement de modules ...)
Puis il faut surveiller. Traquer les process au comportement anormal, débusquer les finteux, les spammeurs, les spammés. Bref administrer la bête. ..
[^] # Re: Changement d'utilisateur
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
pour php :
- allow_url_fopen off
- register_globals off
pour apache :
_ AllowOverwrite None
L'installation d'un ids (snort) est également indispensable.
Tout cela n'est bien sûr qu'un aperçu de ce qu'il y a a faire pour sécuriser une environnement.
[^] # Re: Changement d'utilisateur
Posté par chuchunain (site web personnel) . Évalué à 2.
T'as le bonjour de JavaScript !
[^] # Re: Changement d'utilisateur
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
- un serveur sur lequel dotclear2, joomla, gallery ... sont inutilisables sans un travail poussé d'installation et de personnalisation.
- un serveur qu'il faut rebooter pour faire des mises à jour de sécurité ou un fsck et donc avec un downtime *relativement" important.
C'est plutôt la config grand comptes avec audit de sécurité tout les 6 mois :)
[^] # Re: Changement d'utilisateur
Posté par chuchunain (site web personnel) . Évalué à 1.
T'as le bonjour de JavaScript !
[^] # Re: Changement d'utilisateur
Posté par Maxime (site web personnel) . Évalué à 3.
Moi ce qui est délicat c'est que mon appli permet de compiler et d'executer de manière automatique des programmes en C, C++, Java, Python etc.
En gros, oublions le coté web de la chose :
Je veux pouvoir lancer un programme dont je ne sais rien sans qu'il ne puisse engendrer de dégats.
[^] # Re: Changement d'utilisateur
Posté par Joris Dedieu (site web personnel) . Évalué à 0.
Il faut réduire le path, les ressources, et le temps maximal d'exécution.
Si tu as une machine avec des comptes en ssh. Chacun peut compiler et exécuter ce qu'il veut. Ca ne pose pas de problème particulier de sécurité. Il suffit de limiter les ressources de chaque utilisateurs. Cela se fait au niveau de l'OS.
Tu vérifie périodiquement qu'un process ne soit pas en train de dépasser les bornes et de le tuer via un cron ou autre.
Mais là, il s'agit d'utilisateurs identifiés dont tu peux surveiller l'activité et suspendre les comptes.
Ce qui est critique, c'est l'aspect web. Parce que justement tu ouvres ta machine et donne la possibilité a quelqu'un d'accéder aux ressources sans être identifié au sens unix du terme ou en usurpant une identité.
Après il y en a toujours pour croire que d'afficher /etc/passwd, faire des uname -a pose un problème de sécurité.
Moi ce que je crois c'est que tu vas avoir deux types de problèmes :
- les erreurs de code type fork bomb
- les tentatives d'intrusions et d'installation de daemons.
Pour le premier aspect l'os bien configuré sait bien géré ça tout seul.
Pour le second aspect, la réponse doit être globale au niveau de ton code, de l'os et du serveur web et c'est ce que je proposais tout à l'heure.
Mes deux cents
[^] # Re: Changement d'utilisateur
Posté par Maxime (site web personnel) . Évalué à 2.
[^] # Re: Changement d'utilisateur
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Mais si tu limites le temps de run, attention aux compilations qui peuvent être longue. Tu peux aussi jouer avec nice et faire tourner toutes les commandes en nice +20 ce qui rendra peu génant une boucle infini. Pour les forks bombes, tu as la limitation du nombre de processus créé.
"La première sécurité est la liberté"
[^] # Re: Changement d'utilisateur
Posté par Joris Dedieu (site web personnel) . Évalué à 1.
Sous Net/OpenBSD, il y a aussi systrace[3] qui permet de faire de grandes choses.
Sous Linux comme dit plus haut, il y a ulimit et bien sur selinux et grsecurity que je connais moins bien.
Dans tout les cas il te faut :
- un moyen simple d'identifier les processus (par exemple avec un uid distincte par tâche : pour le serveur web, pour php, pour la compil en C, pour l'execution ... Les ACL permettent de bien gérer celà.
- des quotas disques (pour éviter les écritures de fichier récursives ou les cat /dev/zero ... ).
- un firewalling sur le sortant pour éviter l'ouverture de socket illégitimes.
Il ne faut pas négliger les outils simples avec par exemple un cron qui fait :
- si un processus de tel utilisateur dure + de n minutes ou prends plus de n ressouces cpu (man ps) alors kill $p ; sleep 5; kill -9 $p
[1]http://www.freebsd.org/doc/en/books/handbook/users-limiting.(...)
[2]http://wiki.gcu.info/doku.php?id=freebsd:sysctl_avance&s(...)
[3]http://www.unixgarden.com/index.php/securite/systracesysjail
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.