Guide bonnes pratiques Web V2

  • Published on
    20-Jun-2015

  • View
    432

  • Download
    1

Transcript

1. GUIDE DES BONNES PRATIQUES POUR LA SECURITE DES PLATEFORMES WEB V2 .0Scurit, Web, Serveur, Application, Hbergement La scurit des applications web est de plus en plus menace. Ce document traite les bonnes pratiques recommandes pour aider les administrateurs et les dveloppeurs scuriser leurs plateformes web qui englobe le systme dexploitation, le serveur web, le serveur base de donnes, le contenu web et linfrastructure du rseau dhbergement.Agence Nationale de la Scurit Informatique 2. G E S T IO N D O CU ME N TA I RE AuteurVersionDate de la versionModification apporteANSI/SET1.013/04/2009Premier draftANSI/SET1.225/05/2009Premire rvisionANSI/SET2.014/04/2010Deuxime versionDocument PubliqueDocument Interne Document Confidentiel1 3. TABLE DES MATIERES1.INTRODUCTION ......................................................................................................................... 42.SECURISATION DU SYSTEME DEXPLOITATION DU SERVEUR WEB ...................... 52.1. Installation et configuration du systme d'exploitation ............................................................. 5 2.1.1. Patch et mise niveau du systme d'exploitation ............................................................... 5 2.1.2. Supprimer ou dsactiver les services et applications inutiles ........................................... 5 2.1.3. Configurer l'authentification des utilisateurs du systme d'exploitation .......................... 6 2.1.4. Installer et configurer des outils de scurit supplmentaires .......................................... 6 2.2. Evaluation de la scurit du systme d'exploitation .................................................................. 7 2.3. Check-list de scurit du systme d'exploitation du serveur web ........................................... 7 3.SECURISATION DU SERVEUR WEB ..................................................................................... 83.1. Installation scurise du serveur web ......................................................................................... 8 3.2. Configuration des contrles d'accs ........................................................................................... 9 3.3. Configuration scurise du rpertoire de contenu web ............................................................ 9 3.4. Check-list de scurit du serveur web......................................................................................... 9 4.SECURISATION DU SERVEUR BASE DE DONNEES ..................................................... 114.1. Configuration scurise du serveur base de donnes ............................................................ 11 4.2. Check-list de scurit du serveur base de donnes ................................................................ 12 5.SECURISATION DU CONTENU WEB .................................................................................. 135.1. Publication d'informations sur les sites web publics .............................................................. 13 5.2. Considrations de scurit ct client et serveur .................................................................... 13 5.2.1Vulnrabilits ct client .................................................................................................... 145.2.2Considrations ct serveur ............................................................................................. 145.3. Check-list pour la scurisation du contenu web ...................................................................... 16 6.SECURISATION DES COMMUNICATIONS........................................................................ 186.1. Check-list pour la scurit des communications ..................................................................... 18 7.IMPLEMENTATION DUNE INFRASTRUCTURE RESEAU SECURISEE .................. 207.1. Emplacements dconseills pour lhbergement dun serveur web ...................................... 20 7.2. Zone Dmilitarise (DMZ) ............................................................................................................ 20 7.3. Configuration des lments du rseau ..................................................................................... 23 7.3.1.Configuration Routeur / Firewall .................................................................................... 247.3.2.Systmes de dtection et de prvention d'intrusions (IDS/IPS) ................................. 257.3.3.Commutateurs rseau ..................................................................................................... 267.3.4.Rpartiteurs de charge (Load balancers) ..................................................................... 267.3.5.Reverse Proxy .................................................................................................................. 267.4. Check-list pour mettre en place une infrastructure rseau scurise ................................... 26 2 4. 8.ADMINISTRATION SECURISEE DU SERVEUR WEB ..................................................... 288.1. Journalisation ............................................................................................................................... 28 8.2. Sauvegarde du serveur web ....................................................................................................... 28 8.3. Audit priodique de la plateforme web ...................................................................................... 29 8.3.1.Scan de vulnrabilits ..................................................................................................... 298.3.2.Test de pntration.......................................................................................................... 308.3.3.Audit de code source ...................................................................................................... 308.4. Supervision ................................................................................................................................... 30 8.4.1.Supervision systme ....................................................................................................... 318.4.2.Supervision rseau.......................................................................................................... 318.4.3.Supervision des applications ......................................................................................... 318.5. Gestion des incidents .................................................................................................................. 31 8.6. Check-list pour la gestion du serveur web ................................................................................ 32 9.BIBLIOGRAPHIE ...................................................................................................................... 3510. ANNEXES .................................................................................................................................... 363 5. 1. INTRODUCTION Une plateforme web est lensemble de composants matriels et logiciels configur et connect Internet permettant de servir des pages web sur demande. Les informations sur les serveurs web public peuvent tre consultes par les internautes n'importe o sur Internet. De ce fait, ils peuvent tre soumis des tentatives dattaques par les pirates. Les pirates peuvent modifier le contenu des sites web et voler des donnes critiques du systme. Cela peut se traduire par une perte importante de revenu si cest une institution financire ou un site e-commerce et une perte ou vol de donnes pour dautres entreprises. Un incident de web defacement peut causer aussi bien des dommages importants l'image de marque d'une entreprise. Les menaces communes un serveur web public peuvent tre classes comme suit : Accs non autoris o Defacement o Vol de donnes o Manipulation de donnes Mauvaise utilisation o Lancement dattaques o Hbergement de contenus malicieux Dni de Service Menaces physiques Ce document traite les bonnes pratiques recommandes pour aider les administrateurs et les dveloppeurs scuriser leurs plateformes web qui englobe le systme dexploitation, le serveur web, le serveur base de donnes, le contenu web et linfrastructure du rseau dhbergement.4 6. 2. SECURISATIONDU SYSTEME DEXPLOITATION DU SERVEURWEB La premire tape de scurisation d'un serveur web est le durcissement du systme d'exploitation sous-jacent. La majorit des systmes dexploitation sont configurs par dfaut ; des configurations matrielles et logicielles qui sont gnralement fixes par les fabricants qui mettant l'accent sur les caractristiques, les fonctions et la facilit d'utilisation, au dtriment de la scurit. Ceci du fait que ces constructeurs ne sont pas conscients des besoins en scurit de chaque entreprise. Pour cela, chaque administrateur doit configurer de nouveaux les systmes dexploitation afin de reflter les exigences de scurit de sa plateforme. 2.1. Installation et configuration du systme d'exploitation 2.1.1. Patch et mise niveau du systme d'exploitationUne fois un systme d'exploitation est install, l'application des correctifs ou mises niveau ncessaires pour corriger les vulnrabilits connues est essentielle. Toute vulnrabilit connue sur lOS utilis pour lhbergement devrait tre corrige avant la mise en exploitation du serveur web sinon il sera exposer des utilisateurs malveillants. Pour dtecter correctement et corriger ces failles, les administrateurs de serveur web doivent faire ce qui suit: Crer, documenter et mettre en place une procdure de patch Identifier les vulnrabilits et les patches manquants o Pour vrifier les vulnrabilits des systmes d'exploitation, des services et d'autres applications, vous pouvez consulter : http://www.securityfocus.com/vulnerabilities, le NIST National Vulnerability Database (NVD) ladresse http://nvd.nist.gov/, etc. (voir annexe pour plus de ressources) Installer les correctifs et les mises jour partir du site web officiel de lOS utilis Si des correctifs ne sont pas encore disponibles, dsactiver les services qui sont en relation avec la vulnrabilit si cela est possible2.1.2. Supprimer ou dsactiver les services et applications inutilesIl est fortement recommand quun serveur web soit sur un hte ddi. Lors de la configuration du systme d'exploitation :5 7. Dsactiver ou supprimer tous les services et applications inutiles (ractiver seulement ceux requis par le serveur web)Si possible, installer la configuration OS minimale, puis ajouter les services et les applications ncessaires. Parmi les services et applications qui devraient normalement tre dsactive si non ncessaire sont les suivants: les services de partage de fichiers et d'imprimantes (par exemple Windows Network Basic Input / Output System [NetBIOS], Network File System [NFS], File Transfer Protocol [FTP]) les services sans fil les programmes d'accs distance, en particulier ceux qui ne cryptent pas leurs communications (par exemple, Telnet) Lightweight Directory Access Protocol [LDAP], Kerberos, Network Information System [NIS]) les services e-mail (par exemple, Simple Mail Transfer Protocol [SMTP]) les compilateurs de langage et les bibliothques Les outils de dveloppement Les outils et utilitaires de gestion systme et rseau, y compris Simple Network Management Protocol (SNMP)2.1.3. Configurer l'authentification des utilisateurs du systme d'exploitationPour sassurer quune authentification approprie des utilisateurs est en place, il fallait prendre les mesures suivantes : -Supprimer ou dsactiver les comptes par dfaut et les groupes inutiles Vrifier le choix des mots de passe (Longueur, Complexit, Rutilisation, ) Prvenir le devine mot de passe (par exemple, refuser la connexion aprs un nombre dfini de tentatives non russis) Installer et configurer d'autres mcanismes de scurit pour renforcer l'authentification2.1.4. Installer et configurer des outils de scurit supplmentairesLes systmes d'exploitation, souvent, ne comprennent pas tous les outils ncessaires pour garantir la scurit du systme d'exploitation, des services et des applications de manire adquate. Pour cela, les administrateurs ont besoin de choisir, installer et configurer des logiciels supplmentaires pour assurer une scurit plus efficace tels que : Les logiciels anti-malware : tels que les logiciels antivirus, les logiciels anti spyware et les dtecteurs de rootkit ceci afin de protger le systme d'exploitation6 8. locale des logiciels malveillants et afin de dtecter et liminer toutes les infections qui peuvent se produire. Les logiciels de dtection et de prvention d'intrusion hte (HIDS)2.2. Evaluation de la scurit du systme d'exploitationLe test priodique de la scurit de l'OS est un moyen essentiel pour identifier les vulnrabilits et veiller ce que les mesures de scurit existantes sont efficaces. Les mthodes courantes pour tester lOS sont notamment le scan de vulnrabilits et les tests de pntration. Le scan des vulnrabilits devraient tre effectus priodiquement, au moins hebdomadaire mensuel et les tests de pntration doivent tre effectues au moins chaque anne (Pour plus dinformations, consulter la partie 8.1.3 : Audit priodique de la plateforme web) 2.3. Check-list de scurit du systme d'exploitation du serveur web CompltActionPatch et mise niveau du systme d'exploitationCrer, documenter et mettre en place une procdure de patchTester les patchs sur un serveur de test avant de les appliquer sur le serveur en exploitationIdentifier et installer tous les correctifs et mises niveau du systme d'exploitationIdentifier et installer tous les correctifs et mises niveau des applications et des services inclus avec le systme d'exploitationInstaller les correctifs et les mises jour partir du site web officiel de lOS utilisSi des correctifs ne sont pas encore disponibles, dsactiver les services qui sont en relation avec la vulnrabilit identifie si cela est possible Supprimer ou dsactiver les services et applications inutilesDsactiver ou supprimer tous les services et applications inutiles Configurer l'authentification des utilisateurs du systme d'exploitationSupprimer ou dsactiver les comptes et les groupes par dfaut ou inutilesVrifier le choix des mots de passe (Longueur, Complexit, Rutilisation, )7 9. Prvenir le devine de mot de passe (par exemple, refuser la connexion aprs un nombre dfini de tentatives non russis)Installer et configurer d'autres mcanismes de scurit pour renforcer l'authentification Installer et configurer des contrles de scurit supplmentaires Choisir, installer et configurer des logiciels supplmentaires pour assurer les contrles ncessaires ne figurant pas dans le systme d'exploitation, tels que : les logiciels anti malwares : (antivirus, logiciel antiespion, les dtecteurs de rootkit) des logiciels de dtection et de prvention d'intrusion hte (HIDS)Evaluation de la scurit du systme d'exploitationEffectuer le scan de vulnrabilit de lOS aprs linstallation initiale afin didentifier les vulnrabilitsTester lOS priodiquement pour identifier de nouvelles vulnrabilitsEffectuer un test de pntration au moins une fois par an3. SECURISATION DU SERVEUR WEB 3.1. Installation scurise du serveur web Installer le logiciel serveur web sur un serveur ddi ou sur un systme d'exploitation virtualis. Appliquer les correctifs et les mises jour pour neutraliser les vulnrabilits connues Crer un disque physique ddi ou une partition logique (spar de l'OS et du serveur web) pour le contenu web Supprimer ou dsactiver tous les services inutiles installs avec le serveur web (par exemple, Gopher, FTP, administration distance) Supprimer ou dsactiver tous les comptes par dfaut ou inutiles cres lors de l'installation du serveur web Supprimer du serveur toutes les documentations du constructeur Supprimer tous les fichiers et rpertoires inutiles partir du serveur (les fichiers de test, les scripts, codes excutables, etc.) Appliquer un modle de scurit appropri ou suivre un guide de hardening du serveur web8 10. Reconfigurer la bannire HTTP afin de ne pas signaler le type du serveur web et la version de lOS3.2. Configuration des contrles d'accs Configurer le processus du serveur web sexcuter en tant qu'un simple utilisateur avec une limite des privilges Configurer le serveur web en lecture seule sur les rpertoires de lapplication web Configurer le serveur web afin que seuls les processus autoriss pour ladministration de serveurs web puissent crire des fichiers Configurer le systme d'exploitation pour que le serveur web puisse crire des fichiers journaux mais pas les lire Installer le contenu web sur un autre disque dur ou une partition logique autre que celle de l'OS et du serveur web Si lcriture est autorise sur le serveur web, limiter la taille des fichiers uploader sur lespace disque qui est ddi cet effet. Les fichiers ajouts doivent tre placs sur une partition spare S'assurer que les fichiers journaux sont stocks dans un emplacement qui est dimensionn de faon approprie; les fichiers journaux doivent tre placs sur une partition spare Configurer le nombre maximal de processus de serveur web et / ou des connexions rseau que le serveur web doit permettre Sassurer que les utilisateurs et les administrateurs sont en mesure de changer leurs mots de passe priodiquement Dsactiver les utilisateurs aprs une certaine priode d'inactivit3.3. Configuration scurise du rpertoire de contenu web Ddier un seul disque dur ou une partition logique pour les contenus web Dfinir un rpertoire exclusif pour tous les scripts externes ou les programmes excutable (par exemple, CGI, ASP, PHP) Dsactiver l'utilisation des liens physiques ou symboliques (par exemple, des raccourcis pour Windows) Dfinir une matrice daccs au contenu web permettant didentifier qui peut accder aux dossiers et fichiers du contenu du serveur web Configurer la protection anti-spambot (par exemple, les CAPTCHA, mail [at] mail [point] com au lieu de mail@mail.com)3.4. Check-list de scurit du serveur web CompltActionInstallation scurise du serveur webInstaller le logiciel serveur web sur un serveur ddi ou sur un systme d'exploitation virtualis9 11. Appliquer les correctifs et les mises jour pour neutraliser les vulnrabilits connuesCrer un disque physique ddi ou une partition logique (spar de l'OS et du serveur web) pour le contenu WebSupprimer ou dsactiver tous les services inutiles installs avec le serveur web (par exemple, Gopher, FTP, administration distance)Supprimer ou dsactiver tous les comptes de connexion par dfaut ou inutiles cres lors de l'installation du serveur webEnlever toute la documentation du fabricant du serveur webSupprimer tous les fichiers et rpertoires inutiles partir du serveur (les fichiers de test, les scripts, codes excutables, etc.) Appliquer un modle de scurit appropri ou suivre un guide de hardening du serveur Reconfigurer la bannire http afin de ne pas signaler le type du serveur web et la version de lOS Configuration des contrles d'accsConfigurer le processus du serveur web excuter en tant qu'un simple utilisateur avec une limite des privilgesConfigurer le serveur web en lecture seule sur les rpertoires de lapplication webConfigurer le serveur web afin que seuls les processus autoriss pour ladministration de serveurs web puissent crire des fichiersConfigurer le systme d'exploitation pour que le serveur web puisse crire des fichiers journaux mais pas les lireSi lcriture est autorise sur le serveur web, limiter la taille des fichiers uploader sur lespace disque qui est ddi cet effet. Les fichiers ajouts doivent tre placs sur une partition spareS'assurer que les fichiers journaux sont stocks dans un emplacement qui est dimensionn de faon approprie; les fichiers journaux doivent tre placs sur une partition spareConfigurer le nombre maximal de processus de serveur Web et / ou des connexions rseau que le serveur Web doit permettreSassurer que les utilisateurs et les administrateurs sont en mesure de changer leurs mots de passe priodiquementDsactiver les utilisateurs aprs une certaine priode d'inactivit10 12. Configuration scurise du rpertoire de contenu webDdier un seul disque dur ou une partition logique pour les contenus webDfinir un rpertoire exclusif pour tous les scripts externes ou les programmes excutable (par exemple, CGI, ASP, PHP)Dsactiver l'utilisation des liens physiques ou symboliques (par exemple, des raccourcis pour Windows)Dfinir une matrice daccs au contenu web permettant didentifier qui peut accder aux dossiers et fichiers du contenu du serveur web Configurer la protection anti-spambot (par exemple, les CAPTCHA, mail [at] mail [point] com au lieu de mail@mail.com)4.SECURISATION DU SERVEUR BASE DE DONNEESUne base de donnes est installe comme tant un composant de serveur de back-end au service d'une application web grce l'utilisation du langage de requte, gnralement SQL. 4.1. Configuration scurise du serveur base de donnesAssurer la scurit de la base de donnes est primordiale et doit tre mis en place afin de protger les donnes et limiter l'accs seulement aux utilisateurs autoriss. Les points suivants devraient tre pris en considration pour garantir la scurit dun systme de gestion de base de donnes : Mettre jour le SGBD avec les derniers correctifs stables Utiliser des algorithmes de hachage/cryptage pour stocker les donnes critiques Scuriser le serveur de base de donnes derrire un firewall et utiliser un IDS pour dtecter toute tentative dintrusion Le processus serveur base de donnes devrait fonctionner comme tant un utilisateur avec des privilges minimum et jamais en tant qu'administrateur Mettre en place une politique stricte de contrle d'accs physique et logique Activer les logs sur les tables jugs critiques Certains serveurs de base de donnes comprennent des serveurs dapplications par dfaut. Il est recommand qu'ils soient supprims sils sont inutiles Le serveur de base de donnes ne devrait pas avoir une adresse IP accessible au public L'accs la base de donnes ne devrait tre autoris qu' partir du serveur web sur un port bien particulier 11 13. Voici quelques rfrences intressantes : Microsoft: SQL Server Security Center http://www.microsoft.com/technet/security/prodtech/dbsql/default.mspxMicrosoft: SQL Server Best Practices Analyzer http://www.microsoft.com/download s / details.aspx? FamilyID = b352eb1f-d3ca 44ee-893E-9e07339c1f22 & displaylang = frCISecurity: Oracle Security Testing tools and guide www.cisecurity.comAutres http://www.petefinnigan.com http://www.appsecinc.com4.2. Check-list de scurit du serveur base de donnes CompltActionMettre jour le SGBD avec les derniers correctifs stablesUtiliser des algorithmes de hachage/cryptage pour stocker les donnes critiquesScuriser le serveur de base de donnes derrire un firewall et utiliser un IDS pour dtecter toute tentative dintrusionLe processus serveur base de donnes devrait fonctionner comme tant un utilisateur avec des privilges minimum et jamais en tant qu'administrateurMettre en place une politique stricte de contrle d'accs physique et logiqueActiver les logs sur les tables jugs critiquesCertains serveurs de base de donnes comprennent des serveurs dapplications par dfaut. Il est recommand qu'ils soient supprims sils sont inutilesLe serveur de base de donnes ne devrait pas avoir une adresse IP accessible au publicL'accs la base de donnes ne devrait tre autoris qu' partir du serveur web sur un port bien particulier12 14. 5. SECURISATION DU CONTENU WEB Trop souvent, peu de rflexion est donne la scurit du contenu du site web. Le choix des informations publier sur le site web doit tre bien tudi. 5.1. Publication d'informations sur les sites web publicsUn site web public ne doit pas contenir les informations suivantes: Documents classifis (document priv, confidentiel, top secret) Procdures internes Informations sensibles ou propritaires Renseignements sur le personnel de lentreprise (tels que les adresses, les numros de tlphone, les membres de famille des personnels, etc.) Politique et procdures de scurit de l'information Information concernant le rseau et l'infrastructure de systme d'information (par exemple, des plages d'adresses, les conventions de nommage) Donnes qui impliquent des informations sur la scurit physique de lentreprise (plans, cartes, schmas, photographies ariennes et de plans architecturaux du btiment de l'entreprise) Information sur le plan de continuit dactivit de lentreprise (dtails sur les procdures d'intervention d'urgence, les voies d'vacuation, le personnel responsable)Prvoir une procdure pour dcider des informations publier sur le site web. Une telle procdure devrait comprendre les tapes suivantes: Identifier les informations qui doivent tre publis sur le web Identifier le public cible (pourquoi publier si aucune audience nexiste?) Identifier les consquences ngatives de la publication des informations Dterminer qui doit tre responsable de la cration, la publication et le maintien de ces informations Publier ces informations Vrifier les informations publies Revoir priodiquement les informations publies pour vrifier la conformit du contenu avec les lignes directrices de lentreprise5.2. Considrations de scurit ct client et serveurAujourd'hui, divers types d'lments interactifs ont t introduites offrant de nouvelles faons aux utilisateurs d'interagir de manire plus dynamique avec les sites web. Toutefois, ces lments interactifs mettent en place de nombreuses vulnrabilits lies au web. 13 15. Une varit de technologies de contenu actif existe tels que ActiveX, VBScript, JavaScript, Asynchronous JavaScript and XML (AJAX). L'utilisation du contenu actif exige souvent les utilisateurs rduire les paramtres de scurit sur leur navigateur web afin de pouvoir sxcuter. Si ce n'est pas correctement mis en uvre, le contenu actif peut prsenter une menace grave pour l'utilisateur final. 5.2.1Vulnrabilits ct clientChaque technologie de contenu actif a ses forces et ses faiblesses, aucune n'est parfaitement scurise. Tout administrateur web ou webmaster qui envisage dployer un site web avec des fonctions qui exigent une technologie de contenu actif ct client doit soigneusement valuer les risques et les avantages de la technologie avant son utilisation. Parce que ces technologies consistent placer le code au niveau du client, un attaquant peut tenter de dsassembler le code pour comprendre sa relation avec lapplication web et exploiter cette relation. Parmi ces technologies, on cite : JavaScript, Adobe Flash, Adobe Shockwave, AJAX, Visual Basic Script (VBScript) et ActiveX. Parmi les attaques ct client les plus connues, on cite le Cross Site Scripting XSS qui exploite les vulnrabilits des pages web dynamiques (crites en PHP, ASP ou JSP). Un hacker peut alors rcuprer les cookies (normalement utiliss pour identifier un utilisateur sur un site web) ce qui lui permet de se connecter sur le systme cible sous l'identit de sa victime. 5.2.2Considrations ct serveurLes applications ct serveur peuvent tre crites en utilisant diffrents langages de programmation web. Si les scripts et les composants ne sont pas dvelopps avec soin, les attaquants peuvent trouver et exploiter des failles dans le code afin de pntrer dans le serveur web ou dans les composants backend. Par consquent, les scripts doivent tre dvelopps en tenant compte des besoins en scurit. Les gnrateurs de contenu ct serveur peuvent crer les failles de scurit suivantes sur le serveur: Ils peuvent crer des fuites d'informations sur la plateforme web ce qui peut servir un attaquant prparer une attaque cible Ils peuvent, intentionnellement ou non ngliger, le contrle de la valeur des inputs au niveau des formulaires remplis par les utilisateurs, des paramtres dURL ou au niveau des requtes de recherche facilitant ainsi un attaquant lexcution de commandes arbitraires (exemple : XSS, SQL injection) Ils peuvent permettre des attaquants de modifier le contenu du site web (exemple : Web defacement, File include)14 16. Lors de l'examen ou le dveloppement du code, prendre ce qui suit en considration : Un contrle sur les diffrents inputs est ncessaire afin de filtrer et valider la taille et les valeurs des paramtres dentre de sorte qu'un attaquant ne peut pas dpasser les limites de la mmoire ou excuter des commandes arbitraires.Le code doit utiliser les noms de chemin d'accs explicite lors de l'invocation des programmes externes. Il nest pas recommand dutiliser la variable d'environnement PATH pour rsoudre les noms de chemin d'accs partielPour les formulaires contenant des champs de saisie des donnes, tablir une liste des caractres attendus et filtrer les caractres inattendus avant de traiter un formulaire. Par exemple, sur la plupart des formulaires, les donnes attendues sont gnralement dans ces catgories: les lettres a-z, A-Z et 0-9. Des prcautions doivent tre prises au moment d'accepter des caractres spciaux tels que &, ', ", @, et ! Ces symboles peuvent tre mal interprts par le langage de programmation utilis Les cookies doivent tre examins en filtrant tous les caractres spciaux Un mcanisme de cryptage doit tre utilis pour crypter les mots de passe entrs travers les formulaires dauthentification pour viter leur passage en clair sur le rseau Pour les applications web qui sont restreints par nom d'utilisateur et mot de passe, aucune des pages web dans lapplication ne devrait tre accessible sans passer par la page dauthentification Eliminer tous les exemples de scripts, les excutables ou toute documentation installs inutilement avec le serveur web. Limiter lutilisation des fonctions qui lisent, crivent ou excutent des fichiers sur le serveur car ce type de code peut violer les restrictions daccs et modifier ou endommager le systme Vrifier linteraction du code avec dautres programmes ou applications afin didentifier les failles de scurit Lemplacement et la configuration des permissions affects aux rpertoires du contenu web doit tre bien tudi. En effet, il est recommand ce qui suit : Les fichiers accessibles en criture devraient tre identifis et placs dans des dossiers distincts. Aucun fichier script ne doit exister dans des dossiers accessibles en criture Les fichiers excutables (par exemple, CGI, .EXE, .CMD, et PL) doivent tre placs dans des dossiers distincts. Aucun autre document lisible ou accessible en criture ne devrait tre plac dans ces dossiers Les fichiers de script (par exemple ASP, PHP et PL) doivent tre placs dans des dossiers distincts. Il est galement recommand de stocker ces scripts dans un dossier avec un nom non vident (par exemple, pas "Scripts") pour rendre plus difficile pour un attaquant de trouver les scripts par navigation directe15 17. Les fichiers Include (par exemple, INC, PHP et ASP) crs pour la rutilisabilit du code doivent tre placs dans des rpertoires distincts. Notez qu'une grande partie du risque avec les fichiers include est dans leur capacit d'excution. Si la capacit d'excution est dsactive, ce risque est considrablement rduit.5.3. Check-list pour la scurisation du contenu web ActionCompltVeiller ce que le site web ne contient pas les informations suivantes :Documents classifis (document priv, confidentiel, top secret)Procdures internesInformations sensibles ou propritairesRenseignements sur le personnel de lentreprise (tels que les adresses, les numros de tlphone, les membres de famille des personnels, etc.)Politique et procdures de scurit de l'informationInformation concernant le rseau et l'infrastructure du systme d'information (par exemple, des plages d'adresses, les conventions de nommage)Donnes qui impliquent des informations sur la scurit physique de lentreprise (plans, cartes, schmas, photographies ariennes et de plans architecturaux du btiment de l'entreprise)Information sur le plan de continuit dactivit de lentreprise (dtails sur les procdures d'intervention d'urgence, les voies d'vacuation, le personnel responsable) tablir une politique organisationnelle formelle bien documente et un processus d'approbation des contenus web publics:Identifier les informations qui doivent tre publis sur le webIdentifier le public cibleIdentifier les consquences ngatives de la publication des informationsDterminer qui doit tre responsable de la cration, la publication et le maintien de ces informationsPublier ces informations16 18. Vrifier les informations publiesRevoir priodiquement les informations publies pour vrifier la conformit de contenu avec les lignes directrices de lentreprise Considrations ct client sur la scurit du contenu actifEstimer (peser) les risques et les avantages du contenu actif ct clientNe prendre aucune action sans l'autorisation expresse de l'utilisateurSi possible, utilisez uniquement le contenu actif largement adopt tel que JavaScript, PDF et FlashLorsque c'est possible, proposer des alternatives (par exemple, HTML fourni avec PDF) Considrations ct serveurUn contrle sur les diffrents inputs est ncessaire afin de filtrer et valider la taille et les valeurs des paramtres dentre de sorte qu'un attaquant ne peut pas dpasser les limites de la mmoire ou excuter des commandes arbitrairesLe code doit utiliser les noms de chemin d'accs explicite lors de l'invocation des programmes externes. Il nest pas recommand dutiliser la variable d'environnement PATH pour rsoudre les noms de chemin d'accs partielPour les formulaires contenant des champs de saisie des donnes, tablir une liste des caractres attendus et filtrer les caractres inattendus avant de traiter un formulaire. Par exemple, sur la plupart des formulaires, les donnes attendues sont gnralement dans ces catgories: les lettres a-z, A-Z et 0-9. Des prcautions doivent tre prises au moment d'accepter des caractres spciaux tels que &, ', ", @, et ! Ces symboles peuvent tre mal interprts par le langage de programmation utilisLes cookies doivent tre examins en filtrant tous les caractres spciauxUn mcanisme de cryptage doit tre utilis pour crypter les mots de passe entrs travers les formulaires dauthentification pour viter leur passage en clair sur le rseauPour les applications web qui sont restreints par nom d'utilisateur et mot de passe, aucune des pages web dans lapplication ne devrait tre accessible sans passer par la page dauthentificationEliminer tous les exemples de scripts, les excutables ou toute documentation installs inutilement avec le serveur web17 19. Limiter lutilisation des fonctions qui lisent, crivent ou excutent des fichiers sur le serveur car ce type de code peut violer les restrictions daccs et modifier ou endommager le systmeVrifier linteraction du code avec dautres programmes ou applications afin didentifier les failles de scuritLes fichiers accessibles en criture devraient tre identifis et placs dans des dossiers distincts. Aucun fichier script ne doit exister dans des dossiers accessibles en critureLes fichiers excutables (par exemple, CGI, .EXE, .CMD, et PL) doivent tre placs dans des dossiers distincts. Aucun autre document lisible ou accessible en criture ne devrait tre plac dans ces dossiersLes fichiers de script (par exemple, ASP, PHP et PL) doivent tre placs dans des dossiers distincts. Il est galement recommand de stocker ces scripts dans un dossier avec un nom non vident (par exemple, pas "Scripts") pour rendre plus difficile pour un attaquant de trouver les scripts par navigation directeLes fichiers Include (par exemple, INC, PHP et ASP) crs pour la rutilisabilit du code doivent tre placs dans des rpertoires distincts.6. SECURISATION DES COMMUNICATIONS Le chiffrement est utilis pour protger les donnes transmis entre un client web et un serveur web public. Sans cryptage, n'importe qui ayant accs au trafic rseau peut couter, et, ventuellement, modifier, le contenu des informations sensibles. Selon limportance des ressources web, il est recommand de choisir un mcanisme dauthentification appropri (authentification basique, authentification par adresse IP, authentification digest, authentification du client et du serveur et cryptage des communications base sur SSL/TLS). 6.1. Check-list pour la scurit des communications CompltAction Configurer l'authentification web et les technologies de chiffrementPour les ressources web qui ncessitent une protection minimale et pour lesquels il existe un petit public cible clairement dfini, configurer l'authentification basique18 20. Pour les ressources web qui ncessitent une protection supplmentaire, mais pour lesquels il existe un petit public cible clairement dfini, configurer l'authentification base sur ladresse IP comme une seconde ligne de dfensePour les ressources web qui ncessitent une protection minimale, mais pour lesquelles il n'existe pas de dfinition claire du public, configurer une authentification basique ou digest (meilleure)Pour les ressources web qui ncessitent une protection contre les robots collecteurs ou les robots de bombardement, configurer l'authentification de base ou digest (mieux) ou appliquer dautres techniques (tels que captcha, nofollow, etc.)Pour les ressources web qui ncessitent une protection maximale, configurer SSL/TLSConfigurer SSL/TLSSassurer que le SSL / TLS mis en uvre est entirement mis jourUtiliser un certificat mis par une tierce partie pour l'authentification du serveurPour les configurations qui ncessitent un niveau moyen dauthentification du client, configurer le serveur pour exiger un nom d'utilisateur et un mot de passe via SSL / TLSPour les configurations qui ncessitent un niveau lev d'authentification de clients, configurer le serveur exiger des certificats client via SSL / TLSS'assurer que les algorithmes de chiffrement faibles sont dsactivsConfigurer un contrleur d'intgrit pour surveiller le certificat de serveur webSi seulement SSL / TLS doit tre utilis dans le serveur web, s'assurer que l'accs via n'importe quel port TCP autre que le 443 est dsactiv Protger contre les attaques de brute forceUtiliser l'authentification forte, si possible (one time password, certificat numrique, etc.)Verrouiller un compte aprs un nombre dtermin de tentatives de connexion a chouAppliquer une politique de mot de passeMettre une liste noire des adresses IP connus de tenter des attaques en brute forceUtiliser un logiciel de contrle du journal (log) pour dtecter les attaques en brute force19 21. 7. IMPLEMENTATIONDUNEINFRASTRUCTURERESEAUSECURISEE L'infrastructure rseau qui hberge le serveur web joue un rle critique dans la scurit du serveur web. Dans la plupart des configurations, l'infrastructure de rseau est la premire ligne de dfense entre l'Internet et un serveur web public. Cette section dcrit les composants de rseau qui peuvent soutenir et protger les serveurs web afin de renforcer leur scurit globale. 7.1. Emplacements dconseills pour lhbergement dun serveur webCertaines entreprises choisissent dimplanter leurs serveurs web public sur leurs rseaux de production interne. La principale faiblesse de ce plan est quil expose les composants du rseau interne des risques additionnels. Les serveurs web sont souvent la cible des personnes malveillantes. Si des attaquants russissent compromettre un serveur web, ils auront accs au rseau interne et pourront plus facilement compromettre les htes internes. Par consquent, cette disposition nest pas recommande.Une autre configuration de rseau qui nest pas recommande est de placer le serveur web avant le pare-feu dune entreprise ou un routeur qui permet le filtrage IP. Dans cette architecture, le rseau fournit peu de protection pour le serveur web. En effet, le serveur web doit lui-mme maintenir la scurit : lOS du serveur web et les applications doivent tre extrmement hardened, tous les services inutiles et non scuriss doivent tre dsactives et tous les patches de scurit ncessaires doivent tre appliques.7.2. Zone Dmilitarise (DMZ)Une zone dmilitarise (DMZ) dcrit un hte ou un segment de rseau insre comme une zone accs publique entre le rseau priv d'une entreprise et l'Internet. Il existe une grande varit de configurations DMZ, chacune ayant ses forces et ses faiblesses. La cration d'une DMZ consiste placer un pare-feu entre le routeur frontal d'une entreprise et son rseau interne, et ceci en crant un nouveau segment de rseau qui ne peut tre atteint qu travers le dispositif zone dmilitarise. Le serveur web est mis sur le nouveau segment, avec d'autres composants d'infrastructure de rseau et des serveurs qui doivent tre accessibles de l'extrieur. Dans certaines configurations, le routeur frontire lui-mme peut agir comme un pare-feu de base. La Figure ci-dessous illustre un exemple de cette DMZ simple l'aide d'un routeur avec des listes de contrle d'accs (ACL) pour limiter certains types de trafic rseau depuis et vers la zone dmilitarise.20 22. Un seul pare-feu DMZ est une approche faible cot, car l'entreprise a besoin seulement d'ajouter un pare-feu simple et d'utiliser son routeur frontal existant pour assurer une protection la zone dmilitarise. Il est gnralement opportun que pour les petites entreprises qui font face un risque minime.Figure 1 : Simple et unique-Firewall DMZLa faiblesse fondamentale dans cette approche est que, bien que le routeur est capable de protger contre la plupart des attaques de rseau, il n'est pas au courant des protocoles de la couche d'application de serveur web (par exemple, HTTP) et ne peut donc pas protger contre les attaques de la couche application visant le serveur web. Une meilleure approche consiste ajouter un second pare-feu entre l'Internet et la zone dmilitarise, comme le montre la figure suivante :21 23. Figure 2 : Deux-Firewall DMZ Une configuration deux-firewall DMZ amliore la protection par rapport un routeur- firewall DMZ car les pare-feu ddis peuvent avoir plus de rgles de scurit. En outre, comme un pare-feu ddi est souvent en mesure d'analyser le trafic HTTP entrant et sortant, il peut dtecter et se dfendre contre les attaques de la couche d'application visant le serveur web. Selon lensemble des rgles dfinies au niveau des pare-feu et le niveau du trafic de la zone dmilitarise reu, ce type de zone dmilitarise peut entraner une certaine dgradation de performances. Pour les entreprises qui cherchent la scurit assure par deux-firewall DMZ mais qui n'ont pas les moyens d'acheter deux pare-feu, une autre option existe ; appel "service leg" DMZ. Dans cette configuration, un pare-feu est construit avec trois (ou plus) interfaces rseau. Une interface rseau attache au routeur frontal, une autre attache au rseau interne et une troisime interface rseau se connectant la zone dmilitarise (voir Figure 1.3).22 24. Figure 3 : Service Leg DMZ Cette configuration du pare-feu est sujette un risque accru de dgradation du service lors d'une attaque DoS visant la zone dmilitarise. En effet, dans la configuration standard simple et unique Firewall DMZ discut ci-dessus, une attaque de dni de service contre le serveur web naffecte gnralement que le serveur web. Par contre, dans la configuration du service leg DMZ, le pare-feu est la principale victime d'une attaque DoS puisquil fallait examiner tout le trafic rseau avant quil atteigne le serveur web (ou toute autre DMZ ou ressource du rseau interne). Les avantages d'une zone dmilitarise d'un point de vue scurit sont les suivantes: -Le serveur web peut tre mieux protg et le trafic rseau depuis et vers le serveur web peut tre suivi-Lattaque visant le serveur web ne menace pas directement le rseau de production interne-Un meilleur contrle peut tre propos sur la scurit du serveur web, car le trafic vers et depuis le serveur web peut tre contrl-La configuration de la zone DMZ peut tre optimise pour soutenir et protger les serveurs web7.3. Configuration des lments du rseauUne fois le serveur web est mis en place dans le rseau, les lments de l'infrastructure rseau doivent tre configurs de faon le supporter et le protger. Les principaux lments d'une infrastructure rseau qui affectent la scurit du23 25. serveur web sont les pare-feu, les routeurs, les IDS/IPS, les commutateurs, les rpartiteurs de charge et les reverse proxy. Chacun a un rle important jouer et qui est essentiel la stratgie globale de protection du serveur web. En effet, il n'existe pas de "solution miracle ". Un pare-feu ou IPS seule ne peut pas protger adquatement un serveur web publique de toutes les menaces ou attaques. 7.3.1. Configuration Routeur / FirewallIl existe plusieurs types de firewalls. Les pare-feu les plus basiques sont ceux qui fonctionnent sur le principe du filtrage simple de paquets. Ensuite, nous avons les firewalls Stateful qui peuvent offrir en plus un contrle d'accs bas sur TCP et UDP. Les pare-feu les plus puissants sont firewalls applicatifs qui sont en mesure de comprendre et de filtrer le contenu web. Une perception errone commune sur les firewalls (et les routeurs agissant comme pare-feu) est qu'ils liminent tous les risques et peuvent protger contre une mauvaise configuration du serveur web ou une mauvaise conception de rseau. Malheureusement, ce n'est pas le cas. Les pare-feu et les routeurs sont eux mme vulnrables une mauvaise configuration et des vulnrabilits logiciels. En outre, beaucoup de firewalls ont des limites pour la couche application o de nombreuses attaques se produisent. Toutefois, il est noter que les serveurs web peuvent tre vulnrables de nombreuses attaques mme lorsquils sont situs derrire un pare-feu scuris et bien configur. Un firewall qui protge un serveur web doit tre configur pour bloquer tous les accs au serveur web de l'Internet, sauf les ports ncessaires, tels que les ports TCP 80 (HTTP) et 443 (HTTPS). Afin de protger avec succs un serveur web en utilisant un pare-feu, assurez-vous que le firewall est mis jour avec les derniers correctifs stables et est configur pour effectuer les oprations suivantes : -Contrler tout le trafic entre l'Internet et le serveur web-Bloquer tout trafic entrant au serveur web l'exception du trafic qui est requis, tels que les ports TCP 80 (HTTP) et / ou 443 (HTTPS)-Bloquer tout le trafic entrant avec une adresse IP interne (pour viter les attaques de type IP spoofing)-Bloquer les connexions client partir du serveur web pour l'Internet et le rseau interne de lentreprise-Bloquer les adresses IP que l'IDS/IPS reporte en tant que des adresses dattaques24 26. -Avertissez ladministrateur du serveur web des activits suspectes par un moyen appropri (par exemple, e-mail, sms, etc.)-Fournir le filtrage de contenu-Protger contre les attaques DoS-Dtecter les requtes malformes ou les URL dattaques connus-Enregistrer les vnements critiques7.3.2. Systmes de dtection et de prvention d'intrusions (IDS/IPS)Afin de protger avec succs un serveur web en utilisant un IDS/IPS, il fallait s'assurer quil est configur pour : -Surveiller le trafic rseau depuis et vers le serveur web-Surveiller les changements apports aux fichiers importants sur le serveur web-Surveiller les ressources systmes disponibles sur le serveur web-Bloquer (en conjonction avec le pare-feu) les adresses IP ou les sousrseaux qui attaquent le rseau de lentreprise-Aviser les parties appropries (par exemple, administrateur IDS/IPS, administrateur de serveur web, l'quipe de rponse aux incidents) des attaques souponnes par des moyens appropris conformment la politique et aux procdures de rponse aux incidents de lentreprise-Dtecter la plus large varit des scans et des attaques avec un niveau acceptable de faux positifs-Enregistrer les vnements du journal, y compris les dtails suivants: Heure / date Adresse IP du sensor Nom de l'vnement type dattaque (s'il en existe un) adresses IP source et destination numro de port source et destination protocole rseau-Pour les vnements de rseau, capturer l'information d'en-tte de paquet pour aider l'analyse et au processus dinvestigation-Mise jour frquente avec de nouvelles signatures d'attaque (par exemple, sur une base quotidienne hebdomadaire, gnralement aprs avoir test les mises jour) 25 27. 7.3.3. Commutateurs rseauLes commutateurs doivent tre configurs afin de protger contre les coutes rseau et vaincre l'usurpation ARP. 7.3.4. Rpartiteurs de charge (Load balancers)Les rpartiteurs de charge sont utiliss pour augmenter la disponibilit du serveur web et sont complts par les caches web (s'il ya lieu) 7.3.5. Reverse ProxyUn reverse proxy est utilis comme une passerelle de scurit pour accrotre la disponibilit du serveur web. Il inclue l'ensemble ou certaines des fonctionnalits suivantes: -Acclrateur de chiffrement qui dchargent le traitement des calculs coteux requis pour initier des connexions SSL / TLS-Passerelle de scurit qui surveille le trafic HTTP depuis et vers le serveur web pour les attaques potentielles et prendre les mesures ncessaires, agissant ainsi comme pare-feu niveau applicatif-Le filtre de contenu qui peut contrler le trafic depuis et vers le serveur web pour les donnes potentiellement sensibles ou inappropries et prendre les mesures ncessaires-Passerelle d'authentification qui authentifie les utilisateurs via une varit de mcanismes et contrle l'accs aux URL hberges sur le serveur web lui-mme7.4. Check-list pour mettre en place une infrastructure rseau scurise CompltAction Identifier l'emplacement dans le rseauServeur web est situ dans une DMZvaluer la configuration du firewallServeur web est protg par un pare-feu de couche d'applicationFirewall contrle tout le trafic entre l'Internet et le serveur webPare-feu bloque tout le trafic entrant vers le serveur web, sauf les ports TCP 80 (HTTP) et / ou 443 (HTTPS)26 28. Pare-feu bloque les adresses IP que lIDS/IPS reporte en tant que des adresses dattaquePare-feu rseau notifie l'administrateur du serveur web des activits suspectes par un moyen appropriPare-feu offre le filtrage de contenu (pare-feu de couche d'application)Pare-feu est configur pour se protger contre les attaques DoSFirewall dtecte les requtes mal forms ou les URL dattaque connusFirewall journalise (logue) les vnements critiquesLe firewall est mis jour avec les derniers correctifs stables valuer les systmes de dtection et de prvention d'intrusionIDS/IPS est configur pour surveiller le trafic rseau depuis et vers le serveur webIDS/IPS est configur pour surveiller les changements apports aux fichiers importants sur le serveur web (IDS/IPS hte ou contrleur d'intgrit de fichiers)IDS/IPS bloque (en conjonction avec le firewall) les adresses IP ou les sous-rseaux qui attaquent le rseau de lentrepriseIDS/IPS avise ladministrateur du serveur web des attaques souponnes par des moyens approprisIDS/IPS est configur de manire maximiser la dtection avec un niveau acceptable de faux positifsIDS/IPS est configur pour enregistrer les vnements du journalIDS/IPS est mis jour frquemment avec de nouvelles signatures d'attaque (par exemple, sur une base quotidienne)IDS/IPS hte est configur pour surveiller les ressourcessystme disponibles au niveau du serveur web valuer les commutateurs rseauLes commutateurs sont utiliss pour protger contre les coutes rseauLes commutateurs sont configurs en mode haute scurit afin de vaincre les attaques ARP poisoningLes commutateurs sont configurs pour envoyer tout le trafic sur le segment de rseau vers lIDS/IPS rseau valuer les rpartiteurs de charge (Load balancers)27 29. Les rpartiteurs de charge sont utiliss pour augmenter laLes quilibreurs de charge sont complts par les caches webdisponibilit du serveur webEvaluer le reverse proxy 8.Le reverse proxy est utilis comme une passerelle de scuritLe reverse proxy est complt par une acclration de chiffrement, une authentification des utilisateurs et des fonctionnalits de filtrage de contenupour accrotre la disponibilit du serveur webADMINISTRATION SECURISEE DU SERVEUR WEBCette section fournit des recommandations gnrales pour l'administration scurise des serveurs web. Les activits essentielles incluent l'analyse des fichiers journaux, les sauvegardes rgulires, le contrle rgulier de la scurit du serveur web, l'administration distance scurise, la supervision et la gestion des incidents. 8.1. JournalisationPour une gestion efficace du serveur web, il est ncessaire de disposer d'un retour d'informations (feedback) propos de l'activit et des performances du serveur, ainsi que de tout problme qui pourrait survenir. Pour cela, une journalisation souple et complte savre primordiale. Par consquent, le suivi et lanalyse des logs sont des activits essentielles pour se rendre compte des comportements suspects. Dans ce cadre, les points suivants doivent tre considrs : Utiliser un serveur Syslog centralis Avoir des mcanismes d'alerte (mail, SMS) pour avertir l'administrateur en cas d'actes malveillants dtects dans les logs Utiliser un format de journal bien appropri (tel que Combined Log format) Mettre en place des noms diffrents des fichiers journaux pour les diffrents sites web virtuels qui peuvent tre dploys sur un seul serveur web physique S'assurer que des procdures sont en place pour que les fichiers log ne remplissent pas le disque dur Sassurer que les fichiers journaux sont rgulirement archivs, scuriss et analyss8.2. Sauvegarde du serveur webUne politique de sauvegarde du contenu de la plateforme web (code source, fichiers de configuration, base de donnes) devrait tre applique et une sauvegarde rgulire des fichiers devrait tre assure 28 30. Maintenir la copie la plus rcente de contenu de site web sur un hte scuris ou sur des mdias Maintenir la vrification de l'intgrit de tous les fichiers importants dans le systme. Cela peut tre fait par gnration des tables de hachage MD5 des fichiers importants ou en utilisant des logiciels de vrification dintgrit (tel que Tripwire)8.3. Audit priodique de la plateforme webLaudit priodique de la scurit de la plateforme web est fortement recommand. Sans ces tests priodiques, il ny a aucune assurance que les mesures de scurit sont mises en place de faon appropri. Plusieurs techniques de test de la scurit existent (scan de vulnrabilits, test de pntration, audit de code source) 8.3.1. Scan de vulnrabilitsLe scan de vulnrabilits permet didentifier les vulnrabilits et de vrifier si les mesures de scurit dj mises en place sont efficaces. Plusieurs scanners de vulnrabilits (commerciales et open sources) existent. La plupart de ces scanners donnent une classification de la criticit et de limpact des vulnrabilits dcouvertes ainsi que les mesures ncessaires mettre en place. Voici les points relevs par un scanner de vulnrabilits : -Identification des machines/serveurs actives dans un rseau-Identification des services (ports) actifs sur les machines/serveurs-Identification des applications installes.-Identification des systmes dexploitation-Identification des vulnrabilits associes aux systmes dexploitation, applications installes et services actifs-Test de conformit par rapport aux bonnes pratiques de configuration et dutilisation de la plateforme web et par rapport la politique de scurit.Il est recommand de mener un scan de vulnrabilits afin de sassurer que le systme dexploitation et le serveur web sont mis jour. Les rsultats de scan de vulnrabilit devraient tre documents et analyss et les dfaillances constates doivent tre corrigs. Lutilisation de plusieurs scanners de vulnrabilits est recommande puisquaucun scanner nest capable de dtecter toutes les vulnrabilits connues.29 31. 8.3.2.Test de pntrationLes tests de pntration sont les tests de scurit o les valuateurs tentent de contourner les dispositifs de scurit d'un systme en se basant sur la comprhension de la conception du systme et des applications. Le but des tests de pntration est d'essayer de contourner les mcanismes de protection mis en place en utilisant des outils et des techniques propritaires ou dvelopps par des pirates. Ces tests sont fortement recommands pour les systmes complexes ou critiques. Il est noter que suite aux diffrents tests de pntration, le temps de rponse des serveurs se ralentisse et le systme peut tre endommag. Ce risque peut tre minimis en faisant appel des pentesteurs de haut niveau dexprience. Les avantages du test de pntration sont les suivants : Tester le rseau en utilisant les mthodologies et les outils employs par les hackers.Vrifier si des vulnrabilits existentMontrer comment les vulnrabilits identifies peuvent tre exploites itrativement pour obtenir un accsTester les procdures et sensibiliser le personnel de lentreprise face aux attaques de type ingnierie sociale 8.3.3. Audit de code sourceLaudit de code source est lanalyse dtaille du code source des diffrents modules de lapplication. En effet, par mconnaissance des risques ou par malveillance, les dveloppeurs peuvent introduire des vulnrabilits dans les applications quils dveloppent. En outre, sous contraintes des dlais respecter et suite la complexit de lapplication, plusieurs failles peuvent tre induites lors du dveloppement. Ces vulnrabilits peuvent avoir des consquences nfastes sur la plateforme. Il est alors fortement recommand de mener un audit de code source afin didentifier les vulnrabilits de niveau applicatif qui nont pas pu tre dtectes au niveau des scans de vulnrabilits et des tests de pntration. 8.4. SupervisionLa supervision du serveur (ou monitoring serveur) permet de surveiller les diffrents composants propres de la machine et le fonctionnement des applicatifs qu'elle hberge. Principalement, trois types de supervision existent.30 32. 8.4.1. Supervision systmeLa supervision systme porte principalement sur les trois ressources systme suivants: i. Processeur ii. Mmoire iii. Stockage 8.4.2. Supervision rseauLa supervision rseau assure les principales fonctionnalits suivantes : Vue d'ensemble du rseauSurveillance des services rseaux (SMTP, POP3, HTTP, NNTP, PING, etc.)Surveillance des ressources des quipements rseaux (charge processeur, mmoires, etc.)Surveillance de la disponibilit des services en ligneSurveillance des dbitsSuivi les flux en temps-relSuivi et remonte d'alertesQuelques outils permettent de raliser ces fonctionnalits tels que : NetCrunch 5, Checklan Monitor, Nagios, Centreon, ACGVision, MRTG, Cacti, Zabbix, Visual I/O, Iperf, Nagios2Cacti, Eyesofnetwork et Opennms.8.4.3. Supervision des applicationsLa supervision des applications (ou supervision applicative) permet de connatre la disponibilit des machines en terme de services rendus et ceci en testant les applications hberges par les serveurs. A titre d'exemple, un serveur web peut avoir une supervision systme et rseau avec des signaux au vert et pourtant la machine nest pas disponible au sens du service web si apache n'est pas dmarr. 8.5. Gestion des incidentsUn incident de scurit informatique peut tre un acte de violation de la politique de scurit qui peut tre traduit par un accs non autoris, un dni de service ou une perturbation du systme, etc.31 33. Une quipe de rponse aux incidents doit tre cre au sein de lentreprise et laquelle doivent tre signal les incidents. Si ce nest pas possible par manque de ressources (comptences techniques, matriels et logiciels pour le traitement des incidents), il est recommand de remonter linformation lAgence Nationale de la Scurit Informatique ANSI (incident@ansi.tn) Voici comment ragir en cas dincident : -Identification/Qualification de lincident Analyser les anomalies signales Rechercher dautres traces suspectes Confirmer lincident-Limitation de lventuelle extension de lincident Isoler les machines infectes ou protger les machines saines Retirer ou sauvegarder certaines donnes critiques Passer en mode de crise si la gravit est leve-Investigation Identifier les scnarios de lincident Analyser les fichiers logs pertinents Comprendre la nature du problme Retour la Normale Renforcer le niveau de scurit (niveau de patch, fermeture de ports inutiles, etc.) Restaurer les donnes et les applications affectes partir des sauvegardes--Tirer les leons Identifier les amliorations apporter au systme dinformation Maintenir une surveillance sur le systme qui a t affect Rdiger un rapport global dcrivant lincident8.6. Check-list pour la gestion du serveur web CompltAction Effectuer la journalisation (logging)Utiliser un serveur Syslog centralisAvoir des mcanismes d'alerte (mail, SMS) pour avertir l'administrateur en cas d'actes malveillants dtects dans les logsUtiliser un format de journal bien appropri (tel que Combined Log format)32 34. Mettre en place des noms diffrents des fichiers journaux pour les diffrents sites web virtuels qui peuvent tre dploys sur un seul serveur web physiqueS'assurer que des procdures sont en place pour que les fichiers log ne remplissent pas le disque durSassurer que les fichiers journaux sont rgulirement archivs, scuriss et analyss Effectuer des sauvegardes du serveur webUne politique de sauvegarde du contenu de la plateforme web (code source, fichiers de configuration, base de donnes) devrait tre applique et une sauvegarde rgulire des fichiers devrait tre assureMaintenir la copie la plus rcente de contenu de site web sur un hte scuris ou sur des mdiasMaintenir la vrification de l'intgrit de tous les fichiers importants dans le systme. Cela peut tre fait par gnration des tables de hachage MD5 des fichiers importants ou en utilisant des logiciels de vrification dintgrit tel que Tripwire Audit priodique de la plateforme webMener priodiquement des scans de vulnrabilits sur le systme dexploitation, le serveur web, le contenu dynamiquement gnr et sur le rseau supportMise jour du scanner de vulnrabilit avant utilisationCorriger les failles identifies par le scanner de vulnrabilitEffectuer des tests de pntration sur le serveur web et l'infrastructure du rseau supportCorriger les vulnrabilits identifies par les tests de pntration Conduite d'administration distance et mises jour du contenuUtiliser un mcanisme d'authentification forteRestreindre les htes, qui peuvent administrer distance ou qui mettent jour le contenu du serveur web, par adresse IP et au rseau interneNe pas autoriser l'administration distance partir d'Internet moins que des mcanismes tels que les VPN sont utilissUtiliser des protocoles scuriss (par exemple, SSH, HTTPS)Faire appliquer le concept du moindre privilge pour l'administration distance et pour la mise jour de contenu (par exemple, tenter de minimiser les droits d'accs pour l'administration distante / mise jour des 33 35. comptes)Changer tous les comptes et les mots de passe par dfaut partir de l'utilitaire d'administration distance ou par l'application elle-mmeNe monter pas de partages de fichiers sur le rseau interne partir du serveur web ou vice-versa SupervisionSupervision systmeSupervision rseauSupervision des applications Gestion dincidentUne quipe de rponse aux incidents cre au sein de lentrepriseIdentification/Qualification de lincident Analyser les anomalies signales Rechercher dautres traces suspectes Confirmer lincidentLimitation de lventuelle extension de lincident Isoler les machines infectes ou protger les machines saines Retirer ou sauvegarder certaines donnes critiques Passer en mode de crise si la gravit est leveInvestigation Identifier les scnarios de lincident Analyser les fichiers logs pertinents Comprendre la nature du problmeRetour la Normale Renforcer le niveau de scurit (niveau de patch, fermeture de ports inutiles, etc.) Restaurer les donnes et les applications affectes partir des sauvegardesTirer les leons Identifier les amliorations apporter au systme dinformation Maintenir une surveillance sur le systme qui a t affect Rdiger un rapport global dcrivant lincident34 36. 9. BIBLIOGRAPHIE -http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf-http://www.cert-in.org.in/knowledgebase/guidelines/cisg-2004-04.htm35 37. 10.ANNEXES* Liste de quelques bases de donnes de vulnrabilits Secuniahttp://secunia.com/Vupenhttp://www.vupen.com/?frCVE-MITREhttp://cve.mitre.org/ http://cme.mitre.org/Cert-IST OSVDB NIST FIRST Securityfocus Securitytracker SecurityVulns SecurityTeam Milw0rm Sebug US-CERT CERTAhttp://www.cert-ist.com/ http://osvdb.org/ http://csrc.nist.gov/ http://www.first.org/ http://www.securityfocus.com/ http://www.securitytracker.com/ http://securityvulns.com/ http://www.securiteam.com/ http://www.milw0rm.com/ http://www.sebug.net/ http://www.us-cert.gov/ http://www.certa.ssi.gouv.fr/** OWASP Top 10 Application Security Risks 2010 http://www.owasp.org/index.php/File:OWASP_T10_-_2010_rc1.pdf*** CWE/SANS TOP 25 Most Dangerous Programming Errors http://www.sans.org/top25-programming-errors/ http://cwe.mitre.org/top25/36

Recommended

View more >