Forum général.général Application sensible

Posté par  (site web personnel) .
Étiquettes : aucune
0
16
août
2008
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 :)
  • # Changement d'utilisateur

    Posté par  . Évalué à 2.

    Ce n'est pas plus dangereux que de permettre la mise en place de scripts php. Au final les problèmes de sécurité sont les mêmes en php, en C, en machin. Que ton application soient compilée ou pas, c'est kif-kif: elle vient de l'extérieur, donc gros problèmes en vue.

    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  (site web personnel) . Évalué à 2.

      Tu me parles de suphp là... "Ce script change d'utilisateur (celui que tu crée exprès) et lance ensuite l'application désirée."


      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  . Évalué à 3.

        Je n'ai parlé nulle part de suphp. Personne ne t'oblige à l'utiliser pour lancer une commande avec un autre utilisateur.

        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  (site web personnel) . Évalué à 2.

          "Je n'ai parlé nulle part de suphp." => Je sais mais ce que je voulais dire c'est que le rôle du script dont tu parles c'est ce que permet de faire suphp.

          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  . Évalué à 3.

            Sans chroot ou sans machine virtuelle, je ne saisi pas bien ce que tu attends comme réponse.

            Tente toujours cette commande:
            # aptitude install protection-magique
            • [^] # Re: Changement d'utilisateur

              Posté par  (site web personnel) . Évalué à 4.

              Je n'ai pas dit sans chroot. C'est une solution que j'ai cité.

              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  (site web personnel) . Évalué à 2.

                J'ai pas bien compris si tu es dans un cadre de serveur publique, dans ce cas, un bête login/mot de passe htaccess pour ton serveur web que tout le monde connait, évite une bonne partie des indésirables potentiels.

                "La première sécurité est la liberté"

                • [^] # Re: Changement d'utilisateur

                  Posté par  (site web personnel) . Évalué à 2.

                  Serveur public, je pense bloquer l'accès aux personnes enregistrés seulement mais ça représente quand même une 30 aine de personnes que je ne connais pas forcement personnellement.
              • [^] # Re: Changement d'utilisateur

                Posté par  (site web personnel) . Évalué à 2.

                En fait n'importe quel serveur Apache/Php, permet d'uploader son code et de le compiler. Surtout quand ils sont bien développer friendly :) Mais c'est un autre débat.

                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  (site web personnel) . Évalué à 1.

                  J'ai oublié :
                  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  (site web personnel) . Évalué à 2.

                    tout cet excellent résumé me rapelle les conf des hébergeurs de serveurs mutualisés (sivit, ovh, etc).

                    T'as le bonjour de JavaScript !

                    • [^] # Re: Changement d'utilisateur

                      Posté par  (site web personnel) . Évalué à 1.

                      T'es pas fou ? Tu ne peux pas en faire un mutualisé :

                      - 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  (site web personnel) . Évalué à 3.

                  C'est très intéressant mais ça c'est pour sécuriser un serveur web.

                  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  (site web personnel) . Évalué à 0.

                    Je ne vois pas ce qu'il y a de délicat à ça.
                    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  (site web personnel) . Évalué à 2.

                      Je suis intéressé par les méthodes pour limiter les ressources justement.
                      • [^] # Re: Changement d'utilisateur

                        Posté par  (site web personnel) . Évalué à 3.

                        "ulimit" ?

                        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  (site web personnel) . Évalué à 1.

                        Sous FreeBSD, ça se fait avec limits/ulimit et login.conf . Il faut aussi régler le securelevel a au moins 1 et utiliser sysctl.conf pour limiter quelques valeurs [1][2].

                        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.