Monter une architecture WEB Sécurisée

Salam,

L'objectif de ce thread est de vous donner les premiers éléments qui vous permettront de mettre en place un serveur web sécurisé qui sera protégé des attaques de type PHP file injection, SQL injection, file disclosure etc...

Pour info, je ne rentrerai pas dans les détails techniques des installations mais vous donnerai juste le schéma directeur.

La préconisation ici est faite pour un serveur type Standalone. Nous verrons plus tard pour des architectures web du type 3 tiers etc...

Lorsque j'aurais un peu de temps, j'essaierai également de mettre à votre disposition un serveur sécurisé , de la manière décrite ci dessous, accompagnés de codes PHP vulnérables.

L'objectif bien entendu sera ensuite de prendre la main sur le système et de modifier par exemple la page d'accueil.

En attendant je vous propose de lire les recommandations décrites ci dessous. Bien entendu je reste à l'écoute de toutes suggestions, remarques, etc..

-----[ Les accès aux services ]

Aujourd'hui les serveurs qui font de l'hébergement ont besoin d'au moins 3 services:

- Le service HTTP

- Le service FTP

- Le service SQL

Imaginons que le serveur héberge forumdz.com (au hasard ). L'utilisateur ici aura donc besoin d'un compte FTP pour déposer les documents WEB, et d'un accès à une base SQL.

La première règle ici sera d'utiliser un mot de passe différent pour l'accès FTP et pour l'accès à la base SQL. Certes pour certains d'entre vous, cela semble être une règle de base mais ce n'est pas le cas pour tout le monde...

Bien entendu chaque mot de passe devrait être composé d'au moins 8 caractères alphas numériques + 1 caractère spécial + 1 lettre majuscule.

Exemple: fJrR!9dc

-----[ Architecture système ]

---[ Service Mysqld ]

L'installation de MYSQL ici peut être faite en utilisant les ports UBUNTU.

Les seules règles MSQL à respecter devront être:

1 - Utilisation de la dernière version disponible du serveur MYSQL 5

2 - Utilisation d'un mot de passe robuste pour l'utilisateur root (8 caractères + 1 caractères spécial + 1 caractères majuscule)

3 - Accessible uniquement via LOCALHOST

Un petit plus serait l'installation de la base dans un environnement chrooté. Cette préconisation ne sera pas forcément obligatoire pour ce service.

---[ Service FTP ]

Je préconise ici l'installation du serveur PURE-FTPD qui est je pense l'un des plus sécurisé disponible sur Internet avec VSFTPD. PURE-FTPD permet également de gérer une base d'utilisateur virtuelle permettant d'éviter l'ajout de comptes systèmes locaux directement dans /etc/passwd.

Il sera également important de supprimer l'accès FTP ANONYME et de forcer le CHROOT pour chaque connexion utilisateur.

---[ Service HTTP (le plus important) ]

Je préconise ici l'installation de la dernière version d'APACHE soit la version 2.2.8 accompagnée de la dernière version de PHP5 soit la version 5.2.5.

Il sera OBLIGATOIRE d'installer ce serveur WEB dans un environnement chrooté.

Enfin, et c'est le plus important, il sera OBLIGATOIRE d'installer le module mod_security version 2.5.3 fonctionnant uniquement avec APACHE 2.2.

C'est en effet grâce à ce module que seront bloquées les attaques du type PHP files injections, SQL injections, files disclosures etc... etc...

Enfin pour une meilleur sécurité, en particulier pour du contenu web statique, les fichiers html et php devront appartenir à un utilisateur qui sera différent de l'utilisateur sous lequel tourne le serveur WEB.

Dans un hébergement mutualisé, il sera nécessaire d'utiliser suPHP, suEXEC, ou apache-mpm-ITK, qui vous permettront d'exécuter du contenu HTML sous un UID/GID pré définis dans les paramètres de chaque VIRTUALHOST

-----[ URLs ]

- Sécuriser apache

http://www.securityfocus.com/infocus/1694

- Apache Mod_Security

http://www.modsecurity.org/

- Derniers fichiers de règles pour modsecurity 2.5.3

http://downloads.prometheus-group.com/delayed/rules/

- Apache mpm-itk

http://mpm-itk.sesse.net/

- Apache suPHP

http://www.suphp.org/Documentation-Module-Installation.en.html

- Apache suEXEC

http://httpd.apache.org/docs/1.3/suexec.html

2 - Utilisation d'un mot de passe robuste pour l'utilisateur root (8 caractères + 1 caractères spécial + 1 caractères majuscule)

pour quoi ta spécifié +1 spécial +1 majuscule si j'ai bien compris le mot de passe risque d'être décrypté si on ne respecte pas cette régle ?

sinon j'aime bien tous ces conseils vraiment merçi

pour quoi ta spécifié +1 spécial +1 majuscule si j'ai bien compris le mot de passe risque d'être décrypté si on ne respecte pas cette régle ?

sinon j'aime bien tous ces conseils vraiment merçi

En fait je voulais dire un mot de passe comprenant 8 caractères minimum DONT:

- un caractère numérique

- un cacractère en majuscule

- un caractère spécial

En effet si tu respectes cette consigne, tu as peu de chance que ton mot de passe soit présent dans un simple dictionnaire d'attaque utilisé par exemple par John The Ripper.

Bon certes il sera toujours vulnérable à un bruteforce bête et méchant mais si tu configures bien ton système tu auras le temps de voir les tentatives avant que ce dernier ne soit découvert. Tu auras même largement le temps.

Ensuite tu demandes pourquoi un mot de passe si robuste ? Je vais te répondre simplement que cette consigne fait parti des béabas de la sécurité. Beaucoup d'utilisateurs utilisent comme mot de passe des prénoms, des dates ou ce genre de choses...Donc autant les sensibiliser dès le départ...

Quoi qu'il en soit l'une des bases de la politique de sécurité est la robustesse des mots de passe, et l'utilisation de mots de passe différents pour chaque application (SQL, FTP, SSH, etc..).

Voilà

Intéressant comme topic, merci !

ah ok je pige donc ça prend plus de temp mais ça reste faisable quand méme

en tout ca merci

ah ok je pige donc ça prend plus de temp mais ça reste faisable quand méme

en tout ca merci

Si tu as quelques mois à perdre oui ca doit être possible

ah bon lol installe john the riper avec une gande liste de mot sur un serveur zombie et laisse le travaillé ça peut marcher lol

ah bon lol installe john the riper avec une gande liste de mot sur un serveur zombie et laisse le travaillé ça peut marcher lol

Oui mais la on part du principe ou tu as déjà la version DES/MD5 du mot de passe.

Ensuite, si tu suis une politique de sécurité "correct", tes utilisateurs devront changer leur mot de passe régulièrement. Donc à la finale si il faut attendre plusieurs mois avant de trouver le password, ton john the ripper ne te sera d'aucune utilité.

Moi je parlais plus de bruteforce directement sur le service comme savent le faire certains kiddies sur le service SSH/FTP par exemple. Mais ces attaques laissent des traces et sont donc détectable rapidement.

Salam,

A mon avis l'une des pires vulnérabilités actuelles du PHP/MySQL est que le mot de passe MySQL ne soit pas crypté lors de la connexion du PHP à la base de données. Et puisque il est souvent le cas que les webmasters gardent le même mot de passe partout, les hackers concentrent très souvent leurs attaques afin de subtiliser ce mot de passe qui traine en claire sur une page PHP.

Je sais qu'on peut compiler des rançons de code PHP, ça peut s'avérer utile pour cacher le mot de passe de la BD, mais est-ce suffisant? A mon avis non, on peut utiliser cette portion de code qui se connecte à la BD sans être obligé de savoir ce qu'elle contient, l'essentielle qu'elle nous permet de se connecter .... et puis aussi, décompiler c'est possible!

Q: Que proposez vous afin d'éviter de laisser le mot de passe MySQL trainer en claire?

Autre chose je ne suis pas très d'accord pour les mots des passes à 8 caractères... A mon avis un peu plus de caractères ne fera pas de mal surtout que les techniques de déhachage par raibowtables commencent à montrer leurs efficacités. Moi personnellement je mets toujours de 5 à 8 caractères de plus que les plus puissantes techniques de déhshage actuelles , afin de garder une avance, ce qui fait des mdp à environ 16 caractères mixalpha+numérique+spécial dans mes mdp les plus chers

Salam,

 

A mon avis l'une des pires vulnérabilités actuelles du PHP/MySQL est que le mot de passe MySQL ne soit pas crypté lors de la connexion du PHP à la base de données. Et puisque il est souvent le cas que les webmasters gardent le même mot de passe partout, les hackers concentrent très souvent leurs attaques afin de subtiliser ce mot de passe qui traine en claire sur une page PHP.

 

Je sais qu'on peut compiler des rançons de code PHP, ça peut s'avérer utile pour cacher le mot de passe de la BD, mais est-ce suffisant? A mon avis non, on peut utiliser cette portion de code qui se connecte à la BD sans être obligé de savoir ce qu'elle contient, l'essentielle qu'elle nous permet de se connecter .... et puis aussi, décompiler c'est possible!

 

Q: Que proposez vous afin d'éviter de laisser le mot de passe MySQL trainer en claire?

 

Autre chose je ne suis pas très d'accord pour les mots des passes à 8 caractères... A mon avis un peu plus de caractères ne fera pas de mal surtout que les techniques de déhachage par raibowtables commencent à montrer leurs efficacités. Moi personnellement je mets toujours de 5 à 8 caractères de plus que les plus puissantes techniques de déhshage actuelles , afin de garder une avance, ce qui fait des mdp à environ 16 caractères mixalpha+numérique+spécial dans mes mdp les plus chers

Salam,

En effet, les programmes PHP utilisent des paramètres stockés en clair directement sur le site. J'ai vu très peu de programmes qui permettaient de chiffrer le mot de passe de connexion à la DB.

Ensuite il faut savoir que cet mot de passe n'est accessible que si ton site est vulnérable. Mais c'est en effet l'un des problèmes majeur. Et c'est pour cela que je conseillais d'utiliser des mots de passe différents pour chaque application.

Pour ta question, je n'ai jamais réelement étudié le problème. Il suffirait éventuellement de coder un bout de code PHP qui serait capable de déchiffrer un mot de passe avant d'utiliser ce dernier pour la connexion SQL. On pourrait éventuellement partir sur le concept .htaccess .htpasswd... Ensuite encore faut il que ces fonctions existent directement dans PHP. Je ne suis pas expert PHP mais je vais prendre le point et je te ferai un retour si je trouve quelque chose à ce sujet.

Enfin pour les histoires de PLUS de 8 caractères, si tu relis le thead je disais 8 caractères minimum Après en effet tu peux toujours en rajouter mais cela peut vite devenir compliqué quand tu as des accès sur plusieurs applications / serveurs.

Mais c'est clair, plus y'en a mieux c'est

Oui mais la on part du principe ou tu as déjà la version DES/MD5 du mot de passe.

oui c'est ce que j'ai voulu dire quand on aura le passe de n'importe qu'elle façon on lancera la grande recherche dans un erveru à part.

Moi je parlais plus de bruteforce directement sur le service comme savent le faire certains kiddies sur le service SSH/FTP par exemple. Mais ces attaques laissent des traces et sont donc détectable rapidement.

oui oui je sais il y a brutus qui est pas male !

en tout cas pas détectables dans les petits sites a mon avis..

PS:tu déteste les kiddies à ce que je vois ^_^ mais c'est tjrs la première ligne droite qu'il faut prendre avant de commencer à tourner droite et à gauche

oui c'est ce que j'ai voulu dire quand on aura le passe de n'importe qu'elle façon on lancera la grande recherche dans un erveru à part.

Alors sache qu'ajourd'hui la majorité des systèmes ne stockent plus les mots de passes en clair dans le fichier /etc/passwd mais directement dans /etc/shadow, fichier accessible uniquement par l'utilisateur root. Donc si tu en arrives la, tu n'auras pas vraiment besoin d'utiliser un cracker de mdp

PS:tu déteste les kiddies à ce que je vois ^_^ mais c'est tjrs la première ligne droite qu'il faut prendre avant de commencer à tourner droite et à gauche

Il y'a kiddies et kiddies..A mon époque le kiddie que j'étais était déjà sous linux, n'utilisait que linux et rien d'autre On essayait de comprendre les problèmes de sécurité en les exploitant et surtout en essayant ensuite de les supprimer. Mais il est vrai que les vulnérabilités PHP n'existaient pas encore...je crois même que PHP n'existait pas non plus

Du coup les piratages se faisent uniquement en exploitant des vulnérabilités au niveau des services réseaux (buffer overflow puis format bug etc..). Du coup il fallait au minimum savoir compiler un code source sous linux.

Aujourd'hui pour les kiddies tout est automatique. Il sont tous, pour la plus part, sous Windows...Je click à gauche, je click a droite et oh regarde j'ai modifié ta page web !!

Donc oui ce genre de délires juste pour faire croire que t'es un BOSS du piratage je trouve ca un peu inutile... En même temps la plus part sont des gamins donc on ne peut pas vraiment leur en vouloir... Mais je ne crois pas que ce soit la meilleur solution pour apprendre...

++

Alors sache qu'ajourd'hui la majorité des systèmes ne stockent plus les mots de passes en clair dans le fichier /etc/passwd mais directement dans /etc/shadow, fichier accessible uniquement par l'utilisateur root. Donc si tu en arrives la, tu n'auras pas vraiment besoin d'utiliser un cracker de mdp

je sais mais qu'il n'est pas accessible dans le passwd mais c'est l'une des façons pour obtenir le mot de passe en tout cas moi j'en ai un en DES/MD5 que j'arrive pas à le décrypté (juste pour le fun)d'ailleur c'est le seul en + il n'est méme pas reconnue sous john the ripper mais bon

Mais il est vrai que les vulnérabilités PHP n'existaient pas encore...je crois même que PHP n'existait pas non plus

maintenant le PHP est le plus utilisé dans le piratage s'il n y a pas de vuln dans le site ils passent à un autre et ainsi de suite.

Mais je ne crois pas que ce soit la meilleur solution pour apprendre

ta raison ,,,