Journal Sécurisation d'applications PHP hébergées sur du LAMP

Posté par  .
Étiquettes : aucune
17
18
sept.
2009
Cher journal,

Je t'écris car depuis quelques temps j'essaie de trouver une solution pour éviter que des script-kiddies "explosent" des applications PHP mal codées.
J'ai remarqué que la plupart du temps, ils modifient du code php existant, ou il rajoute leurs fichiers pour avoir un tracker bittorrent pour partager des films XXX.

Après 5 piratages, j'ai mis en place petit à petit certaines règles, d'après mes expériences et ce que j'ai lu sur le Web.

Je vous les fait partager car cela pourrait également vous servir:

1. Faire tourner Apache avec un user différent par vhost grâce à apache2-mpm-itk (packagé dans Debian), ainsi le pirate ne pourra pas lire les fichiers des autres virtualhosts.

2. Les fichiers PHP appartiennent à un autre utilisateur que celui d'Apache, afin que le pirate ne puisse pas écrire dedans, avec les bons droits.
Apache a le bon groupe pour pouvoir uniquement lire. N'étant que dans le groupe, Apache ne peut pas modifier les droits.
Apache a par contre le droit d'écrire dans le dossier qui contiendra les fichiers uploadés.

Exemple concret: pour le site www.toto.com, apache tourne en tant que toto_apache:toto.
Le site se situe dans /var/www/toto.com, les droits d'accès des fichiers sont:
rw-r----- toto:toto index.php
rw-r----- toto:toto db.php
rwxrwx--- toto:toto files/

3. Pour éviter que le pirate ne puisse exécuter des fichiers PHP dans le dossier où les fichiers sont uploadés, j'ajoute ceci dans le virtualhost:
[Directory /var/www/toto.com/files]
php_admin_flag engine off

AddType text/html .php
AddType text/html .phtml
AddType text/html .php4
AddType text/html .php3

Options -Indexes
Options -ExecCGI
AddHandler cgi-script .php .php3 .php4 .phtml .pl .py .jsp .asp .htm .shtml .sh .cgi
[/directory]

4. Desactivation des .htaccess via AllowOverride None: Ainsi, le pirate ne pourra pas modifier la configuration d'Apache
Il faut penser à rapatrier tous les .htaccess dans la configuration du virtualhost

5. Désactiver les informations de version fournies par Apache via ServerTokens et ServerSignature

6. Enlever le shell à toto_apache

7. Utiliser la variable de configuration PHP open_basedir pour éviter que le pirate puisse se promener sur le serveur avec PHP
Exemple: php_admin_value open_basedir "/var/www/toto.com:/tmp:/usr/share/php"

Depuis que j'ai mis tout ceci en place, je suis pour l'instant tranquille.

Et vous, avez-vous d'autres recettes pour sécuriser les applications PHP ? Pensez-vous à d'autres failles ?

Merci pour vos commentaires.
  • # D'autres trucs

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

    * Désactiver les fonctions dangereuses connus et moins connus (style dlopen http://seclists.org/fulldisclosure/2003/Aug/0633.html )
    * Utiliser seLinux pour restreindre encore plus le service Web.
    • [^] # Re: D'autres trucs

      Posté par  . Évalué à 8.

      - utiliser fail2ban
      - dans php.ini, positionner les directives :
      --- expose_php = off
      --- register_globals = off
      --- magic_quotes_gpc = on
      --- display_errors = off [1]
      --- allow_url_fopen = off
      - ne pas mettre le safe_mode à on, c'est une fausse sécurité
      - désactiver certaines fonctions si on en a pas besoin (peut être fait via le vhost) soit : disable_functions = proc_open , popen, disk_free_space, diskfreespace, set_time_limit, leak, tmpfile, exec, system, shell_exec, passthru

      après on peut compliquer :
      - modifier les scripts pour scanner la variable globale $_REQUEST pour y dénicher les injections à l'aide regexps avant tout traîtement ou les passer par mysql_real_escape_string
      - modifier les applis pour ne permettre qu'un certain nombre de tentatives de login par minutes (à la fail2ban)
      - éventuellement utiliser le safemode pour mysql, mais normalement pas de soucis de ce coté si le reste est ok
      - chrooter apache...
      - ne pas héberger de site web... là pour le coup tu risques plus rien :)




      [1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant) qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine, ou le régler via le vhost pour obtenir le même effet
      • [^] # Re: D'autres trucs

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


        --- magic_quotes_gpc = on

        Pas sûr que mettre magic_quotes_gpc à on soit une bonne solution : la plupart des applis php existantes blindent déjà les échappements des requêtes, et activer le magic_quotes_gpc introduira des effets de bord importants. Cette option est d'ailleurs obsolète depuis php 5.3.

        Coté parades, il y a aussi l'installation de mod_security. Il faut en revanche passer un certain temps à posteriori pour supprimer les règles un peu trop extrêmes...
        • [^] # Re: D'autres trucs

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

          « Pas sûr que mettre magic_quotes_gpc à on soit une bonne solution »

          C'est surtout une grosse blague qui n'empêche sûrement pas les injections SQL (on peut injecter du SQL sans apostrophe ou guillemet si la requête SQL est mal écrite), mais emmerde surtout les développeurs.

          PHP a enfin décidé de supprimer cette vieille blague (magic_quotes) dans PHP6. Voir la décision et les raisons :
          http://www.php.net/~derick/meeting-notes.html#magic-quotes

          Quelques lignes plus bas, on lit que le safe_mode sera également supprimé de PHP.
        • [^] # Re: D'autres trucs

          Posté par  . Évalué à 2.

          en effet : coquille
      • [^] # Re: D'autres trucs

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

        display_errors = off [1]

        Par contre, en cours développement, il FAUT afficher TOUS les avertissements (et le corriger bien sûr ;-)).

        register_globals = off
        allow_url_fopen = off


        C'est encore activé par défaut ces horreurs ?

        désactiver certaines fonctions si on en a pas besoin

        Ce modèle de sécurité (liste noire) est bancal à mon avis. Plutôt que de lister quelques fonctions dangeureuses, il vaut mieux dresser une liste exhaustive des fonctions dont on a besoin (liste blanche). Je ne sais pas si c'est possible en PHP, mais ça serait la meilleure solution.

        Pour illustrer mon propros (liste blanche vs liste noire) : c'est comme les protections « anti-include ». Refuser le motif « ../ » dans un nom de fichier est insuffisant. Si l'attaquant arrive à obtenir le chemin absolu (facile en général), il pourra accéder à n'importe quel fichier. La bonne solution est d'utiliser real_path() et vérifier que le fichier (ou le chemin) est dans une liste blanche.

        modifier les applis pour ne permettre qu'un certain nombre de tentatives de login par minutes (à la fail2ban)

        Moui. Enfin, il faut aussi remonter les alertes au webmestre. Il existe par exemple http://php-ids.org/

        éventuellement utiliser le safemode pour mysql, mais normalement pas de soucis de ce coté si le reste est ok

        Je pense qu'il vaudrait mieux créer un utilisateur MySQL aux droits restreints (ex : LOAD_FILE / SELECT INTO / ... sont-ils vraiment utiles sur un site web ?).

        --

        De ma petite expérience, PHP souffre de plusieurs problèmes :

        * Le langage est trop laxiste, PHP devrait obliger les développeurs à corriger les erreurs. D'ailleurs, il faut beaucoup de motivation pour activer tous les avertissements et tous les corriger. Je vous déconseille de le faire sur un gros projet existant sous peine de dépression :-)

        * Sites web développés par des développeurs ayant appris la programmation sur le tas (comme tout le monde) et n'ayant aucune connaissance en sécurité (comme la grande majorité des développeurs). Dans le cas de PHP, ça importe car les applications (sites web) sont accessibles depuis Internet.

        * PHP et MySQL sont souvent installés avec un maximum de fonctionnalités, alors que du point de vue sécurité, il faudrait l'inverse. Exemple : allow_url_fopen activé par défaut.

        * Pas de politique de sécurité globale : une faille PHP permet d'accéder à la base de données, au FTP, (parfois) aux autres sites hébergés sur le même serveur, puis à la boîte mail, etc. Un des problèmes courant est que le mot de passe est le même partout (FTP, MySQL, mail, etc.).

        --

        Je ne suis pas sûr que PHP soit l'origine du mal. C'est plutôt que les développeurs web débutent avec PHP. Il y a une association PHP = programmeur débutant, et donc indirectement PHP = site web peu sûr, puis PHP = langage peu sûr.

        PS : Bien sûr, le langage en lui-même est vraiment une grosse merde comparés à ses concurrents (notamment Python et Ruby).
        • [^] # Re: D'autres trucs

          Posté par  . Évalué à 3.


          Par contre, en cours développement, il FAUT afficher TOUS les avertissements (et le corriger bien sûr ;-)).


          Oui mais normalement on restreint l'accès aux scripts en dev... ou alors on n'affiche les erreurs que pour le dev

          C'est encore activé par défaut ces horreurs ?

          ça dépend des distributions, et puis on ne sait jamais, si on arrive après un admin foireux, on pourra les trouver activées...

          Ce modèle de sécurité (liste noire) est bancal à mon avis.

          peut être mais on a pas le choix, et d'un autre coté ça permet d'être plus souple dans la gestion de la liste : en supprimant les fonctions à risque, on est relativement tranquille par la suite... et vu le nombre de fonctions de PHP, la lite noire sera toujours plus rapide à constituer et lire que la blanche.

          Moui. Enfin, il faut aussi remonter les alertes au webmestre. Il existe par exemple http://php-ids.org/

          je m'interroge sur l'utilité de remonter ça au mainteneur : si un utilisateur légitime a oublié son mot de passe : il le redemandera, les autres seront de faux utilisateurs essayant de trouver le mot de passe d'un utilisateur légitime... qu'est-ce qu'il s'en tape le mainteneur de savoir qu'un type a essayé de craquer un pass ? tant que le bloquage est efficace...

          Je pense qu'il vaudrait mieux créer un utilisateur MySQL aux droits restreints (ex : LOAD_FILE / SELECT INTO / ... sont-ils vraiment utiles sur un site web ?).

          ça dépend de ce que tu fais avec ton "site web"... et puis pour l'utilisateur : c'est évident je pense.

          De ma petite expérience, PHP souffre de plusieurs problèmes :

          on est déjà au courant et c'est hors de propos : l'objet du journal n'est pas de connaître les pb de php ou d'en faire le procès ni de le comparer à d'autres langages et n'est pas non plus un appel aux trolls poilus, mais juste une demande de constitution d'une liste de choses à faire pour sécuriser php autant que faire se peut.
          Tout ce que tu dis est évident et notoire, cependant même en sachant ça, on ne sait pas forcément comment se prémunir de ces risques : ce journal devrait permettre à certains de savoir comment faire, point barre.
        • [^] # Re: D'autres trucs

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

          >> désactiver certaines fonctions si on en a pas besoin
          >
          > Ce modèle de sécurité (liste noire) est bancal à mon avis. Plutôt que de lister
          > quelques fonctions dangeureuses, il vaut mieux dresser une liste exhaustive des
          > fonctions dont on a besoin (liste blanche). Je ne sais pas si c'est possible en PHP,
          > mais ça serait la meilleure solution.

          C'est pas beaucoup mieux : il suffit qu'une des fonctions whitelistées ne soit pas blindée pour qu'on puisse faire ce qu'on veut dans le contexte de PHP. De plus, je ne vois pas beaucoup de cas d'utilisation de PHP dans lesquels il serait faisable d'auditer toutes les fonctions utilisées.

          Il me semle plus efficace de s'appuyer sur les mécanismes de sécurité du système qui sont a priori bien mieux audités et donc fiables. Chaque contexte dans son espace d'adressage propre sans possibilité d'interagir avec le monde extérieur en dehors de certaines interfaces prédéfinies. Bon, après il y a un problème de performances potentiel mais il existe des compromis.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: D'autres trucs

        Posté par  . Évalué à 1.

        Oui, en effet, je n'en ai pas parlé, mais j'utilise également:
        - fail2ban
        - expose_php = off
        - register_globals = off
        - display_errors = off
        - allow_url_fopen = off

        Ainsi que logwatch pour avoir des informations de ce qui se passe sur le serveur.
      • [^] # Re: D'autres trucs

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

        > --- expose_php = off
        > --- display_errors = off [1]
        > - ne pas mettre le safe_mode à on, c'est une fausse sécurité

        En quoi safe_mode=on est-il plus une fausse sécurité que expose_php=off ou display_errors=off ?

        > [1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant)
        > qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine,

        Excellente idée pour introduire encore plus de failles potentielles.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

        • [^] # Re: D'autres trucs

          Posté par  . Évalué à 2.

          En quoi safe_mode=on est-il plus une fausse sécurité que expose_php=off ou display_errors=off ?

          Parce que le safe mode est tout sauf safe et introduit même de l'insécurité... en plus du fait que certains se permettent n'imp sous prétexte qu'ils sont en safe-mode...
          Le expose_php et display_errors à off permettent simplement de ne pas donner trop d'infos concernant la configuration du serveur, ça évite, par exemple, que des robots scanent les page d'un serveur à la recherche d'une version de php ou d'une appli web particulière connue pour avoir telle et tell faille. Ça n'est pas, en soi un rempart infranchissable, mais ça permet d'éviter d'être trop facilement repéré.

          > [1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant)
          > qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine,

          Excellente idée pour introduire encore plus de failles potentielles.


          Le but de la manœuvre étant de ne pas afficher les erreurs pour le quidam ou simplement l'utilisateur final mais permettre aux mainteneurs d'avoir un retour en cas d'erreur, voire un meilleur retour : inscription dans une bdd des données utiles (utilisateur identifié, page, variables de session et tout ce qui peut être utile au debug) voire alerte plus importante dans le cas ou telle ou telle erreur survient sur tel ou tel script.
          Évidemment, c'est comme tout, quand on sait pas faire : vaut mieux ne pas faire... si on garde ça en tête, on devrait éviter certaines grosses failles...
          Si on va dans ce sens, la meilleur façon de ne pas avoir d'emmerde : c'est ne pas héberger de site web...
  • # Accès FTP

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

    Outre les très bon conseils déjà donnés, il peut y avoir un point sensible, pas forcément lié ni à Apache, ni à PHP, mais directement à FTP.

    En effet, depuis quelques temps sévissent un certain nombre de trojans qui se contentent de capturer les login/password qui transitent sur des flux ftp. Dans certains cas, les informations capturées sont uploadées sur un serveur distant. Il ne reste plus aux utilisateurs malveillants que de sniffer les espaces FTP ainsi récupérés, et injecter leur code dans tous les index.php trouvés, souvent un iframe qui contient un lien vers un SWF infecté.

    C'est un sujet qui revient souvent sur les forums des hébergeurs, et il n'est pas aisé d'y remédier. Je suis tombé sur ce site qui évoque le déroulement de l'attaque : http://www.lepotlatch.org/index.php/post/2009/04/22/Mon-site(...)

    Donc, pour sécuriser un peu plus le site :
    * Recommander à ses utilisateurs d'avoir des logiciels de protection à jour
    * Filtrer les IP ayant accès au FTP
    * Eventuellement passer au sftp, en espérant que les trojans n'évoluent pas trop vite...
    • [^] # Re: Accès FTP

      Posté par  . Évalué à 2.

      Certains virus récupèrent directement les mots de passe enregistrés en clair dans le client FTP (filezilla par exemple)

      dans ce cas le FTPS ne change rien malheureusement.

      » ne jamais stocker un mot de passe en clair :)
      • [^] # Re: Accès FTP

        Posté par  . Évalué à 7.

        De toute manière si un virus est capable de lire les mots de passe sauvegardés, il est probablement également capable d'écouter le clavier lors de la frappe des mots de passe dans ce même logiciel.
    • [^] # Re: Accès FTP

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

      Pendant de longues années, mon site perso était hébergé sur en « mutualisé » chez OVH. Je n'avais qu'un accès FTP, protocole vieillot, qui passe mal les parefeux, lents, et surtout NON CHIFFRÉ ! Je viens de découvrir l'hébergeur AlwaysData qui propose un accès SSH, ce qui permet d'utiliser scp pour envoyer des fichiers, et offre donc un shell pour modifier directement les fichiers sur le serveur.

      SSH est plus rapide et surtout beaucoup plus sûr (chiffré) que l'horrible FTP.
      • [^] # Re: Accès FTP

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

        Non, SSH est plus lent que le FTP... malheureusement.

        Lorsqu'on rapatrie plus 200Go des centres de calcul, c'est toujours en FTP, avec SSH, c'est quasiment impossible.
        • [^] # Re: Accès FTP

          Posté par  . Évalué à 2.

          Euh. Pour qu'ssh soit plus lent que FTP de façon notable il faut vraiment des débits importants. En local ça ne m'a jamais posé de problème de faire du 10Mo/s avec scp (en saturant le lien donc). Certes ça utilise quelques dizaines de pourcent d'un CPU mais ça pourrait aller encore bien plus vite.
          • [^] # Re: Accès FTP

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

            10Mo/s c'est pas beaucoup (relativement). Pour les long fat pipes, OpenSSH sucks mais il y a des patches tiers : http://www.psc.edu/networking/projects/hpn-ssh/

            Après, si on veut bricoler, on peut utiliser SSH pour l'admin et netcat pour transférer les gros trucs sans chiffrer ni faire passer de mot de passe en clair.

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Accès FTP

        Posté par  . Évalué à 3.

        les mutu d'ovh sont accessibles via ssh depuis pas mal de temps déjà... (au moins 3 ans je pense)
        • [^] # Re: Accès FTP

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

          Pas sur toutes les versions apparemment:
          L'utilisation de ssh sur nos mutualisés est possible à partir des hébergements de la gamme plan.

          source: http://guides.ovh.com/SshMutualise

          Donc, en dessous il faut faire sans. (On peut tout à fait comprendre qu'on ait pas accès à SSH pour les offres les moins chères, je ne discute pas ici le choix fait par ovh.)
          • [^] # Re: Accès FTP

            Posté par  . Évalué à 2.

            anéfé... m'enfin vu la différence de prix qui existait entre les gammes gp et plan... autant prendre un 90 plan... d'où ma confusion...
  • # bon sens

    Posté par  (Mastodon) . Évalué à 5.

    Je t'écris car depuis quelques temps j'essaie de trouver une solution pour éviter que des script-kiddies "explosent" des applications PHP mal codées.

    euh... c'est moi ou la réponse est dans la question ?

    Si ces applications sont mal codées, il convient tout simplement de ne pas les utiliser au lieu de trouver des solution pour sécuriser la merde !

    La suite de ton message, ce sont des pratiques applicables quelque soit la qualité du code de l'application utilisée. Mais si tu sais que le code que tu fais n'est pas sûr, il ne faut pas le faire tourner. Pas de négotiation possible.
    • [^] # Re: bon sens

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

      Tu parles de théorie, lui parle de pratique.

      (en pratique, toutes les applis ont des trous de sécurité, personne n'est parfait, la question est de savoir quand la faille va être trouvée. Ta solution revient à ne rien installer, c'est effectivement très sécurisé mais peu utile. En pratique, il y a des oublis sur les patch de sécurité. En pratique, on ne demande jamais à l'admin système si telle appli est utilisable, on dit "on a besoin de l'appli X, installe-la" etc...)

      Pas de négotiation possible.

      Effectivement, pas de négociation possible face à un admin comme ceci : à la porte, merci, mais on a besoin d'une personne qui fasse quelque chose (à la porte = soit plus de salaire, soit plus de responsabilité dans une association n'importe laquelle, une asso a aussi besoin de son serveur pour communiquer)

      Si, tout est une question de négociation, et de gestion des contraintes (sécurité, utilisabilité, maintenabilité, fonctionnalités, délais...)
    • [^] # Re: bon sens

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

      Et si tu fais de l'hébergement, par exemple, tu es certain que la plus grande partie de tes scripts php sont du gruyère. Donc tu trouves des solutions à ces problèmes.

      Pas de négotiation possible.

      Pas une question de négociation, ton job c'est de faire tourner des scripts (tout pourri) sur des serveurs, donc soit tu fais le job, soit tu en trouves un autre.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: bon sens

      Posté par  . Évalué à 5.

      Comme répondu ci-dessus, tous les sites ne sont pas sous la responsabilité d'admins capables d'auditer le code PHP pour éliminer les failles...

      Je pense en particulier à tous les sites personnels, associatifs, etc.
      Tu installes un CMS toi-même, tu dois le mettre à jour toi-même, et dans ton cas tu audites le code toi-même systématiquement au cas où?

      Et encore, je ne parle pas des scripts perso...
  • # Mes remarques ...

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

    3. Pour éviter que le pirate ne puisse exécuter des fichiers PHP dans le dossier où les fichiers sont uploadés, j'ajoute ceci dans le virtualhost:

    Tu ferais pas mieux de mettre ton répertoir d'upload à l'extérieur de l'arborescence web ?

    4. Desactivation des .htaccess via AllowOverride None: Ainsi, le pirate ne pourra pas modifier la configuration d'Apache
    Il faut penser à rapatrier tous les .htaccess dans la configuration du virtualhost


    root:root 0644 sur .htaccess permet d'éviter des modifications. Car pour faire des petites redirections ça reste super pratique.

    5. Désactiver les informations de version fournies par Apache via ServerTokens et ServerSignature

    Je sais pas si ça a beaucoup d'importance, mais c'est pas un mal non plus.

    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: Mes remarques ...

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

      > root:root 0644 sur .htaccess permet d'éviter des modifications. Car pour faire des petites redirections ça reste super pratique.

      Dans ce cas, il faut aussi penser a créer un .htaccess vide dans "tous" les répertoires car sinon, rien n'empêche le pirate d'en créer un là ou li n'y en avait pas... Je préfère quand même la solution "pas de .htaccess", ça laisse mon de chance d'oublier un truc quelque part... Quitte à le réactiver sur quelques vhosts ou dossiers où l'on sait exactement ce que l'on fait...
      • [^] # Re: Mes remarques ...

        Posté par  . Évalué à 1.

        De plus actievr les .htaccess ralenti les perfs du serveur web, qui est obligé s'il sont activé de vérifier dans chaque répertoire et chaque répertoire parent s'il n'y a pas de .htaccess.
        • [^] # Re: Mes remarques ...

          Posté par  . Évalué à 1.

          A préférer l'utilisation des .cfg (chargé une fois au démarrage). bien sur tout modif demande redémarrage et don capacité de le faire.
      • [^] # Re: Mes remarques ...

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

        De toute façon, quelles que soient les permissions sur le .htaccess, toute personne ayant accès en écriture sur le répertoire peut effacer le fichier, éventuellement pour le remplacer par un autre.
        Ce changement de droits est complètement inutile parce que justement, l'utilisateur du site, pour pouvoir uploader ses fichiers, a les droits en écriture sur le dossier.
    • [^] # Re: Mes remarques ...

      Posté par  . Évalué à 2.

      3. comment fais-tu pour rendre les fichiers accessibles au téléchargement après l'upload s'ils sont en dehors de l'aborescence Web ?

      4. L'autre problème, c'est qu'en autorisant la lecture de ces fichiers, tu fais perdre du temps à Apache qui devra les lire à chaque requête, contrairement au fichier de conf apache, où c'est lu uniquement au démarrage.
      • [^] # Re: Mes remarques ...

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

        Pour faire suite, désactiver .htacess en prod est toujours une bonne idée, que ça soit pour la sécu (empêcher le pirate de mettre une règle rewrite qui tourne en boucle et tue ton serveur), que pour les perfs, en effet si tu active, imagine tu as une requête sur http://site.tld/index.php qui est dans /home/bohwaz/www/site.tld/www/index.php, pour chaque requête apache va chercher :

        /home/bohwaz/www/site.tld/www/.htaccess
        /home/bohwaz/www/site.tld/.htaccess
        /home/bohwaz/www/.htaccess
        /home/bohwaz/.htaccess
        /home/.htaccess
        /.htaccess

        Voilà, 6 accès au FS pour rien, en une requête. Imagine maintenant pour des centaines de requêtes secondes...

        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: Mes remarques ...

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

        3. comment fais-tu pour rendre les fichiers accessibles au téléchargement après l'upload s'ils sont en dehors de l'aborescence Web ?

        Il y a la méthode autre serveur sur le port 8080 sans possibilité de scripts ou cgi. Donc tu dois adapter tes liens (http://www.example.com:8080/fichier.jpeg) ou alors directement depuis ton script php (mes_fichiers.php?id=xxx).
        Tu peux toujours utiliser une réécriture apache pour ça (www.example.com/fichiers/fichiers.jpeg -> www.example.com:8080/fichiers.jpeg), c'est transparent ou alors directement un autre serveur (fichier.example.com/fichier.jpeg). Tu retrouves cette dernière méthode sur des trucs comme yahoo (http://l.yimg.com/a/i/ww/beta/y3.gif).

        J'aime bien la méthode autre serveur web juste pour les fichiers statiques. Mais ça dépend pourquoi tu le fais, sur un hébergement mutualisé, tu ne pourrais pas le faire.

        4. L'autre problème ...

        Oui, c'est pas parfait, ça dépend après ce que tu veux. J'aime bien avoir un fichier htaccess, qui généralement a les droits suivant : root:web 0664. Le groupe web étant les personnes autorisées à modifier les sites web.
        Dans le cas d'un hébergement mutualisé, on pourrait imaginer avoir ftpuser:www-data 0640 (ftpuser étant différent pour chaque utilisateur, bien entendu).

        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

        • [^] # Re: Mes remarques ...

          Posté par  . Évalué à 1.

          3. sans vouloir te vexer, je ne vois pas vraiment le côté plus secure d'utiliser un autre serveur par rapport au fait de dire à Apache qu'il ne peut pas executer de code PHP.

          Aurais-tu un exemple ?
          • [^] # Re: Mes remarques ...

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

            Rien de plus en terme de sécurité (enfin un peu, en cas d'erreur de configuration sur apache on risque de pouvoir exécuter le code, mais bon, c'est pas significatif). Donc même sécurité, par contre c'est plus évolutif.
            Ensuite, et c'est personnel, j'aime bien avoir le minimum de configuration par démon. Donc avec deux serveurs web, tu as des configurations simple, presque "par défaut", donc moins de risque de te tromper.

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # itk, open_basedir, bof .. vive mpm_peruser :)

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

    mpm_peruser, c'est comme mpm_itk, mais avec de bien meilleures perfs, et qui en plus permet de chrooter l'apache en question.

    Voir :
    http://www.peruser.org/trac/projects/peruser

    Un truc que j'avais fait dans le cadre d'un cours de sécu et qui parle de ça:
    http://xf.iksaif.net/papers/securing-a-shared-web-server.pdf
    • [^] # Re: itk, open_basedir, bof .. vive mpm_peruser :)

      Posté par  . Évalué à 1.

      Le gros soucis de mpm_peruser pour moi, c'est qu'il n'y a pas à ma connaissance de paquet Debian, et je n'ai pas très envie de recompiler apache à la mano à chaque update de sécurité ;-)
      • [^] # Re: itk, open_basedir, bof .. vive mpm_peruser :)

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

        Sous debian, peut être en effet.
        Sous gentoo peruser est activé avec un simple useflag. Je l'utilise en prod depuis un ou deux ans sans problèmes notable (à part dans le cas de config ssl avec plusieurs virtual hosts, mais c'est reglé dans la prochaine version).
        • [^] # Re: itk, open_basedir, bof .. vive mpm_peruser :)

          Posté par  . Évalué à 1.

          J'utilise aussi Gentoo pour certains serveurs, mais je me sens plus rassuré lors des mises à jour pour un environnement mutualisé avec Debian ;-)

          J'ai déjà eu quelques aventures avec une Gentoo stable en production.

          J'utilise Gentoo pour héberger des applications en Ruby on rails.
    • [^] # Re: itk, open_basedir, bof .. vive mpm_peruser :)

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

      Sauf que itk est packagé pour debian et mis à jour régulièrement, et que peruser n'est pas prêt pour la prod selon son site... Du coup c'est un bon projet mais pas encore utilisable à mon sens.

      itk + open_basedir reste pour le moment la meilleure solution pour un environnement de prod.

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Investigation ?

    Posté par  . Évalué à 2.

    Hello,

    Je pense que les règles que tu proposes sont un bon début pour sécuriser la production. Avec un peu de chance, ça devrait suffire pour écarter bon nombre de script-kiddies en bouchant la(les) faille(s) qui a(ont) fait que ton serveur s'est retrouvé compromis.

    Cependant, tu pourrais travailler sur un autre axe - l'analyse post mortem. J'en parle ici car je suis à la recherche d'idées ou de "bonnes manières" sur le sujet.

    En ce moment, je réfléchis à une petite infrastructure pour externaliser un maximum d'informations décrivant le fonctionnement d'un serveur, dans le but de faire une analyse post-attaque. Globalement, cela consiste à :
    -Envoyer une copie des logs sur un autre serveur avec les tentatives d'auth sur le ssh, le ftp, etc... (syslog en réseau)
    -Activer le process accounting (paquet acct sous Debian et dérivés) qui donne beaucoup d'informations sur ce qui se passe et répliquer ces informations en dehors du serveur
    -...
    En sachant ce qui s'est passé pour que le serveur tombe, on peut en apprendre beaucoup sur l'attaque, et donc boucher les trous plus efficacement. Par contre, à part les deux sources d'infos que j'ai cité, je manque d'idées. Vous en avez d'autres ?

    Au passage, changer le port par défaut de ssh est une TRES bonne idée si votre serveur est en public sur internet. La preuve : en 1 an, j'ai eu environ 1.500.000(!) tentatives de connection sur ssh, avec des login / pass très variés, la plupart du temps des bots qui déroulaient des listes. Depuis que ssh n'écoute plus sur le port 22 mais sur un port à 5 chiffres, je n'ai plus aucune tentative.
    (Bon évidemment si on peut faire de l'authentif par clé, c'est mieux, mais vos clients n'aimeront peut-être pas toujours...)
    • [^] # Re: Investigation ?

      Posté par  (Mastodon) . Évalué à 4.

      fait un honey-pot
      ça t'évitera certainement de faire "l'analyse post-mortem" sur des serveurs de prod.
      • [^] # Re: Investigation ?

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

        Une technique intéressante est d'avoir en parallèle la prod et un honeypot avec un IDS/IPS devant les deux. Si l'IPS/IDS détecte un truc qui cloche, il envoit le trafic vers le honeypot plutôt que la prod.

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Investigation ?

      Posté par  . Évalué à 5.

      Pour le SSH, un knocker peut être également pratique.
    • [^] # Re: Investigation ?

      Posté par  . Évalué à 1.

      La modification du port d'écoute n'est pas suffisante, un balayage de port le retrouvera. SSH est un protocole solide et 'secure', il faut le configurer de manière restrictive si il est exposé sur le net.
      Je conseille fortement d'utiliser ce protocole plutôt que FTP pour la mise à jour d'un site.
  • # Sinon si tu ne crains pas de lire

    Posté par  . Évalué à 5.

    l'anglais, je te conseille de faire un tour sur OWASP . Parmis les dizaines de documents sur la sécurisation des applis web tu trouveras surement ton bonheur.
  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Des principes, en vrac, que j'utilise

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

        Au minimum /usr et surtout, avec Debian :
        DPKG {
        Pre-Invoke {
        "mount -o rw,remount /usr";
        }
        Post-Invoke {
        "mount -f -o ro,remount /usr";
        }
        }

        Dans apt.conf te permets "d'oublier" tranquillement que tu as ton système en lecture seule.

        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: Des principes, en vrac, que j'utilise

      Posté par  . Évalué à 1.

      De même avec les machines virtuelles, par contre les chroot, j'avais lu qu'il était assez facile d'en sortir contrairement au jail de BSD.

      Quelqu'un aurait des informations à ce sujet ?
      • [^] # Re: Des principes, en vrac, que j'utilise

        Posté par  . Évalué à 2.

        facile... oui si la machine (hôte du chroot) est déjà compromise (à l'aide d'un fifo par exemple) ou si le chroot est mis en place avec les pieds et sans réfléchir... d'un autre coté, si on ne sait pas qu'il y a un chroot, on ne va ptet pas forcément chercher à en sortir...

        Pas plus d'infos concernant «chroot vs jail BSD»
  • # Répertoire d'upload

    Posté par  . Évalué à 2.

    3. Pour éviter que le pirate ne puisse exécuter des fichiers PHP dans le dossier où les fichiers sont uploadés, j'ajoute ceci dans le virtualhost:

    Chez moi, les fichiers utilisateurs ne sont jamais uploadés dans un répertoire accessible directement depuis la racine du site. J'accède aux fichiers via une page PHP qui est faite pour, et qui me permet au passage d'ajouter par exemple une gestion des droits.

    Si vraiment on doit pouvoir écrire dans un répertoire accessible directement, le mieux est encore de filtrer les fichiers en n'autorisant que certains types, voir même en forçant le nom du fichier (par exemple pour un avatar de forum, imposer que ça soit <hash du nom d'utilisateur>.jpg).
  • # ModSecurity ?

    Posté par  . Évalué à 1.

    ModSecurity [1] peut-il être utile dans ce genre de cas ?
    Quelqu'un l'utilise en production ?

    [1] http://www.modsecurity.org/
  • # /o\

    Posté par  . Évalué à 1.

    8. Utiliser un autre langage que PHP ?
    • [^] # Re: /o\

      Posté par  . Évalué à 2.

      En quoi cela serait différent ave Python par exemple ?
      • [^] # Re: /o\

        Posté par  . Évalué à 2.

        Bah, dans les framework Python que je connais (en fait, surtout Django), je vois assez peu de moyen de faire des conneries (oui, il y en aura toujours ...). Les "remèdes" décrits ici sont faits pour palier le manque de sécurité intrinsèque du langage et l'amateurisme de ses utilisateurs (OK, pas tous), ce qui n'est pas le cas (selon moi) pour Python, qui est (toujours selon moi) un bien meilleur langage que PHP et dont les utilisateurs sont plus "avertis" (parce que moins diffusé, je te l'accorde).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.