IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

Cloisonner des applications


Sujet :

Sécurité

  1. #1
    Membre du Club
    Profil pro
    Développeur Full Stack
    Inscrit en
    Mars 2009
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Full Stack

    Informations forums :
    Inscription : Mars 2009
    Messages : 94
    Points : 69
    Points
    69
    Par défaut Cloisonner des applications
    Bonjour,

    Je souhaite avoir un serveur hébergeant plusieurs applications accessible par Internet. Le serveur (Debian squeeze) hébergera diverses applications, PHP et Java (Apache2 et Tomcat notamment).

    N'ayant jamais sécurisé un serveur, je ne sais pas comment procéder pour réaliser ce que je souhaite faire. Pourriez-vous m'aider dans la démarche ?

    Je souhaiterais faire les choses suivantes sur mon serveur :

    - Cloisonner les applications, si l'application web A a une faille et qu'un utilisateur pénètre sur le système, je ne veux pas qu'il puisse aller dans les répertoires de l'application web B et les répertoires systèmes. Surtout que je vais avoir des pplication qui enregistrent des fichiers sur le serveur (dépôts de fichiers par exemple).
    - Isoler le serveur : disponible sur Internet, pouvoir accéder à son système par SSH, mais l'isoler de mon réseau local (si il est infecté, il ne doit pas toucher les autres machines)
    - Pas de virtualisation, je ne peux pas lancer plusieurs mahines virtuelles ou plusieurs systèmes d'exploitation. Je n'aurai pas les ressources nécessaires pour cela.

    J'ai plusieurs pistes. Je ne cherche pas la sécurité ultime mais quelque chose de propre, acceptable en milieu professionel. Je vous les cite sans savoir lesquelles sont les plus intéressantes pour ce que je veux faire ou si il y en a plusieurs à mettre, dans quel ordre les installer. Les voici :

    - chroot : mais si je comprends bien, toutes l'application doit être en un seul endroit, par exemple je ne pourrai pas dire "dépôt de fichiers dans un dossier /srv/files/ accessible par une application web qui est dans /srv/www ou /var/www
    - autre solutions que chroot citée sur la page http://en.wikipedia.org/wiki/Operati...virtualization
    - droits systèmes : suffisant ?
    - LDAP pour la gestion des utilisateurs systèmes et applicatifs
    - Un reverse-proxy : utile ne serait-ce que pour avoir une url unique pour plusieurs applications (https://srv/A, https://srv/B etc.) et devrait fournir une protection de base efficace.

    Merci

  2. #2
    Membre éclairé
    Profil pro
    Ingénieur sécurité
    Inscrit en
    Février 2007
    Messages
    574
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : Ingénieur sécurité
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2007
    Messages : 574
    Points : 751
    Points
    751
    Par défaut
    Citation Envoyé par Steph0 Voir le message
    - Cloisonner les applications, si l'application web A a une faille et qu'un utilisateur pénètre sur le système, je ne veux pas qu'il puisse aller dans les répertoires de l'application web B et les répertoires systèmes. Surtout que je vais avoir des pplication qui enregistrent des fichiers sur le serveur (dépôts de fichiers par exemple).
    SELinux/AppArmor sont fait pour ca. Ca prends du temps a configurer, mais ca creee des contextes de securite associe a une application. En gros tu tag l'ensemble de ton systeme - fichier/processus/user/network - et tu autorises ton application a acceder seulement a certain de ces labels.
    Si une application est compromise, elle n'a pas access a d'autres labels que ceux definis. Tu ne peux donc pas acceder a des ressources en dehors du scope de l'application.

    Citation Envoyé par Steph0 Voir le message
    - Isoler le serveur : disponible sur Internet, pouvoir accéder à son système par SSH, mais l'isoler de mon réseau local (si il est infecté, il ne doit pas toucher les autres machines)
    Ne le connecte pas au reseau local . Sinon bloque tout paquet sortant a destination de ton reseau local, mais ca ne bloquera qu'un attaquant sans privileges.

    Citation Envoyé par Steph0 Voir le message
    - Pas de virtualisation, je ne peux pas lancer plusieurs mahines virtuelles ou plusieurs systèmes d'exploitation. Je n'aurai pas les ressources nécessaires pour cela.
    Certaines solutions apportent que tres peu d'overhead pour un gain en securite important. OpenVZ pour ne pas le cite est une solution de sandboxing avec un overhead tres leger.

    Citation Envoyé par Steph0 Voir le message
    - chroot : mais si je comprends bien, toutes l'application doit être en un seul endroit, par exemple je ne pourrai pas dire "dépôt de fichiers dans un dossier /srv/files/ accessible par une application web qui est dans /srv/www ou /var/www
    Ca depend de la racine du chroot. Apres un etant root s'echapper du chroot est simple. Prefere une solution SELinux si tu as le temps.

    Citation Envoyé par Steph0 Voir le message
    - droits systèmes : suffisant ?
    Oui, mais y'a de grande chance de faire d'oublier des trucs. /tmp, /proc... Au passage GRSec/PAX permettent de durcir les fuites d'informations noyaux et ajoute des mechanismes de securite interessants.

    Citation Envoyé par Steph0 Voir le message
    - LDAP pour la gestion des utilisateurs systèmes et applicatifs
    Oui, et tracabilite.

    Citation Envoyé par Steph0 Voir le message
    - Un reverse-proxy : utile ne serait-ce que pour avoir une url unique pour plusieurs applications (https://srv/A, https://srv/B etc.) et devrait fournir une protection de base efficace.
    Oui, avantage en terme de performance, et tu peux encore ajouter de la securite la dessus, de type WAF pour proteger tes resources webs.


    Derner point, j'avais ecrit un post un peu detaille sur developpez sur le durcissement serveur au niveau systeme si ca t'interesses: http://www.developpez.net/forums/d11...m/#post6114932

  3. #3
    Membre du Club
    Profil pro
    Développeur Full Stack
    Inscrit en
    Mars 2009
    Messages
    94
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Full Stack

    Informations forums :
    Inscription : Mars 2009
    Messages : 94
    Points : 69
    Points
    69
    Par défaut
    Bonjour,

    Merci pour cette réponse très complète.

    Du coup je pense que je vais suivre le plan suivant :

    • mettre en place ma Debian
      ajouter un fail2ban
      ensuite LDAP
      mettre en place mes applications, le plus possible par les dépôts Debian
      reverse-proxy
      AppArmor ou SELinux : lequel est le plus utilisé en milieu professionnel ? J'ai lu que SELinux est significativement plus difficile à paramétrer que SELinux


    Cela semble-t-il bien ?

    Merci

Discussions similaires

  1. [Kylix] Fermer des applications
    Par duviau dans le forum EDI
    Réponses: 2
    Dernier message: 27/05/2005, 18h21
  2. [Kylix] portabilité des applications Kylix
    Par leclaudio25 dans le forum EDI
    Réponses: 14
    Dernier message: 30/07/2004, 16h05
  3. [installeur] Le couteau suisse des applications web
    Par Tournesol dans le forum Développement Web en Java
    Réponses: 3
    Dernier message: 05/01/2004, 18h19
  4. quel langage pour créer des "applications" sur 1 s
    Par jaribu dans le forum Langages de programmation
    Réponses: 7
    Dernier message: 30/07/2003, 15h06
  5. Liste des applications installées
    Par Reisubar dans le forum API, COM et SDKs
    Réponses: 7
    Dernier message: 17/05/2003, 14h43

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo