Iyas

Je te garanti que le problème de sécurité n'est pas apache...Ni Vbulletin, ... Je crois avoir clairement expliqué le problème mais si vous croyez savoir mieux que tout le monde, c'est bien Clap Clap Clap comme on dit

Si t'avais lu le reste du thread, tu aurais compris que le problème n'était pas Vbulletin mais un autre site hébergé sur le serveur qui avait été mal codé et qui rendait donc le serveur vulnérable. A bon entendeur...salut

En même temps quand je vois ça... Je me demande si ils comprennent bien ce qu'ils font... 41.200.243.107 - - [25/May/2009:17:45:04 +0200] "GET /forumdz.com HTTP/1.1" 404 209 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10" 41.200.243.107 - - [25/May/2009:17:45:12 +0200] "GET /~forumdz.com HTTP/1.1" 404 210 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10" 41.200.243.107 - - [25/May/2009:17:45:15 +0200] "GET /~forumdz.com HTTP/1.1" 404 210 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10" Pour info ce sont les logs d'un site autre que forumdz Bref... Aller sur ce je m'en vais.

Ben écoute je suis assez d'accord sur ce que tu dis. La chose à en retenir c'est que certes, ça fait chier, mais d'un autre coté ça nous démontre en général un problème dans la configuration Et comme tu le dis ça permet d'améliorer l'architecture WEB par la suite. Ce qui me gène un peu plus est leur façon de faire... Je trouve ces petits jeunes très malin. Comme tu dis même si ils ne font qu'utiliser des programmes déjà fait, ils le font très bien. Mais, si je peux me permettre une remarque, la seule et unique chance qu'ils ont est le fait de vivre en Algérie. Les gars laissent leurs IPs partout, c'est super crade. La même attaque en Europe, tu peux enclancher des poursuites et je peux te certifier que le mec à la fin ben il pleure Mais bon, il faut reconnaître que ces jeunes crackers sont malins et savent très bien utiliser leur outils. Et puis bon comme tu dis, ça nous permet de nous améliorer (Je me répète non ? ) Bon aller sur ce je file. Bon courage à tous et à plus tard pour de nouvelles aventures...

Alors... Comment dire... Bon je ne vais pas rentrer dans les détails car ça serait trop long. En gros la base repose sur le fait de faire tourner le serveur web dans un environnement chrooté. A partir de la on possède un fichier /etc/passwd et /etc/group complétement indépendant du système principal permettant ainsi a tous les programmes tournant dans l'environnement chroot d'avoir une base d'utilisateurs "virutelle". Ensuite il suffit d'utiliser un serveur WEB adapté (APACHE est ton ami). Il existe pour apache plusieurs solutions. La plus connue: SuPHP, ce qui implique que php soit installé en module. Il existe également des patch pour apache qui permettent de préciser sous quel UID/GID le vhost est exécuté. Un petit plus serait d'ajouter à apache le "security module" qui permet d'intercepter les attaques de type injection SQL, PHP include et ce genre de choses. Voilà en gros. Ensuite concernant le service FTP qui permet en général aux utilisateurs de déposer leur site, je vous conseille pure-ftpd. Il permet également de gérer une base d'utilisateurs virtuels auxquels vous pouvez définir leur propre UID/GID. Il suffit ensuite de maintenir ces services à jour et çà devrait aller. Quoi qu'il en soit il n'existe pas de sécurité efficace à 100%. Donc il faut rester vigilant. Si un site se fait pirater, ben ce n'est pas si grave, ça arrive... Ce qu'ils faut c'est limiter l'impact que cela pourrait avoir sur les autres sites hébergés sur le serveur et faire en sorte que tes autres clients ne soient pas impactés. Ah oui ! Personnellement pour ce qui est des services Internet je suis contre le "apt-get install". Car la plupart des exploit sont fait pour des distributions bien précises. Le fait de compiler ses services à la main permet de déplacer certains offset rendant l'exploitation un peu plus triviale. Et enfin pour finir, un petit SNORT peut s'avérer très pratique. En espérant que cela puisse vous servir.. ++

Salut, En effet On va dire merci le chroot sur ce coup la Bref, le truc que j'avais omis, honte a moi, concernait la sévérité des permissions des répertoires... Chaque site est éxecuté via un user dédié qui ne doit pas normalement pouvoir lire le contenu des autres sites... Un petit oubli corrigé. Personnellement je trouve ça distrayant et ça permet de détecter des petites conneries de ce genre, donc ça reste intéressant on va dire même si ca perturbe un peu le service de temps en temps ... Et puis encore une fois les gars n'inventent rien. Ils appliquent le RTFM que l'on connait tous si bien Pour info, ils continuent d'attaquer depuis quelques minutes...Voici le log. 41.200.243.107 - - [25/May/2009:16:35:09 +0200] "GET /in.php?do=ls&d=%2Fhome%2Fligue94.com&sort=0a HTTP/1.1" 404 204 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10" in.php ici est tout simplement le C99SHELL utilisé par tous nos kiddiz bien aimés Il ce dit : "peut être que j'en ai laissé trainer un quelque part...qu'on aurait pas vu... Qui sait..." Vous pouvez "mass flooder" l'adresse IP 41.200.243.107 si vous vous ennuyez ++

Salut, Non du tout. Ils sont passés par un site hébergé sur le même serveur qui avait un module non sécurisé permettant de déposer des fichiers en local. A partir de la ils ont ensuite déposé un shell PHP Ils ont ainsi pu accéder en lecture aux fichiers de configuration de Vbulletin et accéder à la base SQL. Bref, rien de bien sorcier... Et ça ce dit Hacker Moi je dirai plutôt prépubaires boutonneux en mal d'amour Ils ne font qu'utiliser des programmes que n'importe qui peut trouver sur le NET. Même pas un peu d'imagination et de savoir faire... Bref des bidons. ++

Salut, Vous trouverez ci dessous une partie des règles d'un référentiel sécurité (best practice) que j'ai rédigé, référentiel qui concerne la sécurité des droits d'accès et la gestion des mots de passe. Il contient l'ensemble des règles relatives à ce domaine, devant être respectées au sein d'un système d'informations. Ca interessera peut être certains d'entre vous. C'est le genre de document à joindre à la politique de sécurité et ca pourra toujours vous servir de support pour la suite Bonne lecture. -------> Ca commence ici 1. Créer un bon mot de passe Un bon mot de passe est un mot de passe fort, qui sera donc difficile à retrouver même à l'aide d'outils automatisés, mais facile à retenir. En effet, si un mot de passe est trop compliqué à retenir, l'utilisateur mettra en place des moyens mettant en péril la sécurité du SI, comme par exemple l'inscription du mot de passe sur un papier collé sur l'écran ou sous le clavier où l'utilisateur doit s'authentifier. Pour se faire, il existe des moyens mnémotechniques pour fabriquer et retenir des mots de passe forts. 1.1 Méthode phonétique Cette méthode consiste à utiliser les sons de chaque syllabe pour fabriquer une phrase facile à retenir. Par exemple la phrase « J'ai acheté huit CD pour cent euros cet après-midi » deviendra ght8CD%E7am. 1.2 Méthode « des premières lettres » Cette méthode consiste à garder les premières lettres d'une phrase (citation, paroles de chanson...) en veillant à ne pas utiliser que des minuscules. Par exemple, la citation « un tiens vaut mieux que deux tu l'auras » deviendra 1tvmQ2tl'A. 2. Authentification, Autorisation, Accès 2.1 Gestion des profils et des accès Règle n° 1. La gestion des droits d’accès doit être rigoureuse. Une gestion laxiste entraînerait des failles de sécurité ne pouvant être compensé par un système d’authentification. Règle n° 2. Les comptes d’accès génériques ou partagés sont strictement prohibés. Règle n° 3. Le droit d’accès attribué à l’utilisateur est personnel, incessible et révocable à tout moment. L’utilisateur est personnellement responsable de l’utilisation qui peut en être fait. Règle n° 4. Le droit d’accès de l’utilisateur est limité exclusivement aux ressources qui sont rendues nécessaires par l’exercice de son activité prévu dans le cadre de sa fonction dans l’entreprise. Règle n° 5. L’utilisateur est tenu d’assurer la confidentialité des moyens d’accès qui sont mis à sa disposition. Règle n° 6. En cas de perte, l’utilisateur doit prévenir son responsable hiérarchique dans les plus brefs délais. Règle n° 7. Le rattachement d’une personne à un ou des profils doit être mis à jour à chaque changement de ses fonctions. Règle n° 8. Les comptes d’accès qui ne sont pas/plus nécessaires doivent être désactivés. Règle n° 9. Les comptes et droits d’accès assignés doivent être documentés. Profils « Administrateurs » Règle n° 10. En raison des responsabilités spécifiques qui lui sont confiées, l’administrateur a le devoir impératif de confidentialité sur les informations auxquelles il a accès dans le cadre de l'exercice de sa fonction. Il n'effectue des consultations ou copies de fichiers que dans la stricte limite des nécessités de ses missions. Règle n° 11. L'administrateur doit respecter scrupuleusement les règles d'accès en vigueur aux systèmes informatiques, soit depuis son poste de travail, soit depuis l'extérieur. Les habilitations particulières, les codes confidentiels d'accès, sont strictement personnels. Règle n° 12. La connexion en qualité d'administrateur n'est autorisée que dans le cadre des interventions nécessaires à la bonne marche des systèmes dont ce dernier assure l'administration : toute utilisation en dehors de ces interventions pourra être considéré comme une faute. 2.2 Gestion des mots de passe Règle n° 13. La durée de validité d’un mot de passe est définie suivant les critères suivants : • Données vitales : 6 mois • Données critiques : 9 mois • Données sensibles 12 mois • Données non sensibles : pas de contraintes Règle n° 14. Le mot de passe doit être différent pour chaque utilisateur et doit rester secret AAA / Règle n° 15. Les utilisateurs doivent être capables de changer eux-mêmes leur mot de passe Règle n° 16. Lors d’un changement de mot de passe, ce dernier doit être saisis deux fois Règle n° 17. La saisie du mot de passe doit être masquée. Règle n° 18. Le système doit inviter l'utilisateur à changer son mot de passe à chaque connexion 4 semaines avant la date d'expiration. Règle n° 19. Le mot de passe doit être renouvelé au minimum tous les 6 mois Règle n° 20. Le mot de passe doit être robuste et se composer d’au moins 8 caractères formant une combinaison de caractères spéciaux et de lettres alphanumériques Règle n° 21. Si le mot de passe à été compromis, ce dernier doit être changé dans les plus brefs délais. Règle n° 22. Si des mots de passes sont conservés sur support numérique, le fichier doit être chiffré Règle n° 23. Toutes communications de mots de passe via email doivent être chiffrées Règle n° 24. Il est strictement interdit de conserver un mot de passe sur support papier Tests de robustesse des mots de passe Règle n° 25. Afin d’éviter la réutilisation des précédents mots s de passe, le système doit permettre l’historisation des 3 derniers mots de passe d’un utilisateur. Règle n° 26. Les intervenants sécurité ayant en charge la sécurité du système se doivent de tester régulièrement la robustesse des mots de passe à l’aide d’outils adaptés tel que « John the Ripper, Crack5, …). Tous les comptes d’accès n’ayant pas passé le test de robustesse des mots de passes doivent être désactivés.

Hello, Sécurise avant tout ton serveur web... mod_security est ton ami Et tu verras tu auras bcp moins de soucis. http://www.modsecurity.org Bien entendu ce module ne fonctionne qu'avec Apache version 2 ++

Salam, Une petite URL qui devrait intéresser certains d'entre vous http://www.metasploit.com/ Have fun !

Salam, Il semble que personne n'en n'a encore parlé alors je lance le thread au cas ou http://www.milw0rm.com/exploits/5622 http://www.milw0rm.com/exploits/5632 Je ne rentre pas dans les détails vu que tout est expliqué dans les deux URLs ci dessus. Juste pensez à mettre à jour vos libssl. ++

Salam, C'est réglé. Ce n'est pas paramètrable par chaque utilisateur mais pour l'ensemble. Now on affiche 20 messages par page. Je ne crois pas que ca le fasse chez moi... D'autres personnes sont concernées ? ++

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 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... ++

La concevoir ? Dans ce cas cela signifie que l'admin sait développer un minimum ce qui n'est pas toujours le cas Cela dit il existe déjà des programmes permettant de faire ce genre de choses. Mais sinon oui je suis d'accord. Par contre en ce qui concerne l'audit système de la manipulation de fichiers et des accès à certaines zones du serveur c'est une autre histoire. Le seul OS que je connaisse qui sache faire ça plus ou moins bien c'est Solaris 10. Pour Linux je ne sais pas s'il est possible d'aller si loin.... En fait si, c'est possible avec des patchs kernels du type Grsecurity mais c'est une vraie galère à maintenir et en plus la stabilité et les performances du système peuvent être impactées. Pour info: http://www.grsecurity.net/ Ensuite je crois qu'il y'a également SELinux...Je ne l'ai jamais testé mais je n'ai pas entendu bcp de bien à son sujet. Mais je me trompe peut être... ++

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

Toujours d'accord avec toi. J'espere juste que, quand tu parles des fichiers jounaux, tu ne parles pas des logs apaches... Parce que de mon coté j'ai des sites qui me genèrent pas loin de 100Mo de logs / jours...Alors imagine si je dois analyser tout ca avec mes yeux ... Sinon j'ajouterai également: 1- L'utilisation de SNORT pour la détection d'intrusions: http://www.snort.org/ 2- L'usage de PRELUDE-LML pour l'analyse des fichiers de logs temps réel: https://trac.prelude-ids.org/wiki/PreludeLML ++

Tellement difficile que le site ne marche même plus

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.

En fait faut être entre les deux... Il suffit de connaitre les outils qui vont bien, ainsi que le système sur lequel le serveur WEB s'appuie. Comme disait Havoc, ca ne se fait pas en claquant des doigts. Il suffit de faire l'architecture qui va bien pour être tranquille... Si il fallait dire 1 serveur web = 1 appli on ne s'en sortirait pas. Et que fais tu des hébergements mutualisés ? On doit également leur fournir un service sécurisé. Après c'est sur si tu autorises n'importe qui à faire n'importe quoi on ne s'en sort plus... Quoi qu'il en soit la sécurité se situe normalement aux deux niveaux. Coté service (serveur web etc..) et coté developpeurs (PHP, HTML etc..). Si tu sais respecter les deux normalement tu n'as pas trop de problèmes

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

Re, http://www.overthewire.org/ Voici un site qui devrait interesser les experts en matière de HACK et plus particulièrement la rubrique WARGAME. Notons ici que le niveau technique est assez élevé donc HALT AUX KIDDIES Pour vous donner une idée: Vortex By touring through the most common exploitable bugs, users of this wargame are expected to have gained mastery in the basic fundamentals of system exploitation. Semtex Network-Based challenges, builds skills used in creating server/client applications and challenges the user to figure out problems with various network protocols. Blacksun Blacksun is a wargame for learning more advanced exploitation techniques against hardened hosts and environments. Drifter Drifter is a new wargame, along the lines of vortex. It is currently under development, if you would like to contribute levels / ideas, please contact us. At this point in time, there is 5 levels. Sur ce que dire à part bonne chance ++

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à

Oui je suis d'accord avec toi. Certes Apache installé par défaut même avec les modules PHP n'est pas vulnérable en soit. A moins que demain une personne trouve une vulnérabilité directement dans le code source d'apache ou du module PHP. Ce sont ensuite les sites hébergés qui peuvent rendre vulnérable ton serveur. Dans ce cas il te reste deux solutions possibles: 1 - Tu crées un environnement ou une architecture WEB sécurisé 2 - Tu audites tous les sites web avant de les mettre en ligne si tu en as le courage Quoi qu'il en soit un serveur 100% sécurisé n'existe pas... En fait si mais uniquement si tu le débranches du réseau et encore... Un piratage via accès physique est toujours possible (oui je suis parano et alors ? ) ++

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

Salam, Un autre petit site sympa qui pourrait aider à faire avancer la communauté http://www.gotroot.com/ ++