Sécuriser les protocoles
• DHCP
• DNS
• FTP
• SNMP
• WIFI
• HTTP
DHCPLe protocole DHCP est utilisé pour délivrer dynamiquement une adresse IP unique pour chaque machine le demandant sur l...
Domain Name Service – DNSGarder une trace des allocations d’adresses IP sur les postes directement connecté aux commutateu...
Domain Name Service – DNSComment s’en protéger ?
Désactiver ou modifier l'affichage de la version du serveur DNS.(Bind)
Ac...
FTPFTP (File Transfert Protocol, en écoute par défaut sur les ports 20 et 21) est le service utilisé pour assurer le trans...
SNMPSNMP v3
Cette nouvelle version du protocole SNMP vise essentiellement à inclure la sécurité des transactions. La sécur...
SNMP1.2 - Le cryptage
Le cryptage a pour but d'empêcher que quelqu'un n'obtienne les informations de gestion en écoutant s...
WIFIUn réseau sans fil, et par extension un réseau WiFi, est beaucoup plus sensible qu'un réseau filaire car les données c...
WIFI
WEP - Wired Equivalent Privacy
Pour remédier aux problèmes de confidentialité des échanges sur les réseaux sans fils,...
HTTPUn serveur HTTP est en écoute sur le port 80. Le protocole HTTP est sûrement le plus utilisé sur le web. Ce protocole ...
HTTPSécuriser le service Apache :
Cacher la version d'Apache & du OS :
En paramétrant la directive ServerTokens à Prod.
Ai...
HTTP1.4.3.5. Gestion des droits
Nous présenterons ici les mesures préventives liées aux fichiers contenus dans l'arboresce...
HTTPUn pirate pouvant écrire dans un répertoire du serveur web, par exemple via un partage NFS, peut en profiter pour accé...
HTTPPerl: mod_perl
Le module mod_perl a été le résultat d'une intégration plus poussée des scripts CGI écrits en Perl. Il ...
Prochain SlideShare
Chargement dans…5
×

7 sécuriser les protocoles

568 vues

Publié le

splc

Publié dans : Formation
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
568
Sur SlideShare
0
Issues des intégrations
0
Intégrations
140
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

7 sécuriser les protocoles

  1. 1. Sécuriser les protocoles • DHCP • DNS • FTP • SNMP • WIFI • HTTP
  2. 2. DHCPLe protocole DHCP est utilisé pour délivrer dynamiquement une adresse IP unique pour chaque machine le demandant sur le réseau interne. En clair, si un client interne veut obtenir une adresse IP pour bénéficier des services réseau, il envoie un message DHCP à tout le réseau (broadcast) pour trouver le serveur DHCP. Le serveur DHCP répondra en lui envoyant tous les paramètres de configuration réseau. Ce service permet «d’alléger» la gestion du réseau en évitant d’avoir des configurations statiques à maintenir sur chaque machine. Malheureusement, le protocole DHCP comporte diverses failles que nous allons vous présenter. Attaque par épuisement de ressources Comme il l’a été décrit, un serveur DHCP possède un stock d’adresses IP qu’il distribue aux différents clients. Ce stock est bien sûr limité. Il y aura seulement un nombre défini de clients pouvant disposer des différentes adresses IP en même temps. Si le serveur est bien administré avec une liste «fermée» de correspondances entre adresses MAC et IP aucune attaque par épuisement n’est possible. Si le service est mal administré ; c’est à dire que les correspondances entre adresses MAC et IP se font dynamiquement à partir d’une plage d’adresses IP vacantes, le scénario suivant est possible. Si un pirate génère un grand nombre de requêtes DHCP semblant venir d’un grand nombre de clients différents, le serveur épuisera vite son stock d’adresses. Les «vrais» clients ne pourront donc plus obtenir d’adresse IP : le trafic réseau sera paralysé. Faux serveurs DHCP Cette attaque vient en complément de la première. Si un pirate a réussi à saturer un serveur DHCP par épuisement de ressources, il peut très bien en activer un autre à la place. Ainsi il pourra ainsi contrôler tout le trafic réseau. Comment s’en protéger ? Chaque fois que c’est possible, il faut limiter le service DHCP à une liste «fermée» de correspondances d’adresses MAC et IP. De cette façon toute requête «étrangère» à cette liste est systématiquement rejetée.(Réservations) DHCP Snooping : Cisco utilise une solution dans ces commutateurs appelée "DHCP snooping" qui permet de : • L’administrateur pourra communiquer à chaque commutateur les ports ou sont connectés le(s) serveur(s) DHCP ou sur lesquels une réponse DHCP pourra être reçue. A partir de cet instant aucun autre port du réseau n’acceptera de « reply » DHCP. Ce sera typiquement le cas d’un port d’accès où peut être connecté un PC d’entreprise. Il deviendra donc impossible de démarrer un serveur DHCP illégitime sur un de ces ports. • Limiter le nombre de paquets DHCP envoyés au serveur (rate limiting en nombre de paquets par seconde). • Garder une trace des allocations d’adresses IP sur les postes directement connecté aux commutateurs. Le commutateur fera l’apprentissage des correspondances MAC/IP sur chacun de ces ports. Cette fonction ne protège pas directement le service DHCP mais sera très utile pour la protection contre les usurpations d’identités.
  3. 3. Domain Name Service – DNSGarder une trace des allocations d’adresses IP sur les postes directement connecté aux commutateurs. Le commutateur fera l’apprentissage des correspondances MAC/IP sur chacun de ces ports. Cette fonction ne protège pas directement le service DHCP mais sera très utile pour la protection contre les usurpations d’identités. Le protocole DNS assure la correspondance entre le nom d’une machine et son adresse IP. Un serveur DNS est en écoute par défaut sur le UDP port 53. Les attaques décrites ici concernent les faiblesses du protocole DNS. Le DNS ID spoofing Elle aboutit à un détournement de flux entre deux machines à l’avantage du pirate. Imaginons qu’un client A veuille établir une connexion avec une machine B. La machine A connaît le nom de la machine B mais pas son adresse IP, ce qui lui empêche pouvoir communiquer avec. La machine A va donc envoyer une requête au serveur DNS du réseau de B pour connaître l’adresse IP de B, cette requête sera identifiée par un numéro d’identification (ID). Le serveur répond à cette requête en fournissant l’adresse IP de B et en utilisant le même numéro d’ID. Ce numéro a une valeur comprise entre 0 et 65535. Le DNS ID spoofing a pour but de d’envoyer une fausse réponse à une requête DNS avant le serveur DNS. De cette façon, le pirate peut rediriger vers lui le trafic à destination d’une machine qu’il l’intéresse. Dans notre exemple, un pirate C doit répondre à A avant le serveur DNS (D) du réseau de B. Ainsi, il envoie à A son adresse IP associée au nom de la machine B. A communiquera alors avec le pirate C au lieu de la machine B. Néanmoins, pour implémenter cette attaque, le pirate doit connaître l’ ID de requête DNS. Pour cela, il peut utiliser un sniffer s’il est sur le même réseau, soit prédire les numéros d’ID par l’envoi de plusieurs requêtes et l’analyse des réponses. Le DNS cache poisoning Le principe de cette attaque est très similaire à celui de l’ARP-Poisoning. Pour gagner du temps dans la gestion des requêtes, le serveur DNS possède un cache temporaire contenant les correspondances adresses IP - noms de machine. En effet, un serveur DNS n’a que la table de correspondance des machines du réseau sur lequel il a autorité. Pour des machines distantes, il doit interroger d’autres serveurs DNS. Pour éviter de les interroger à chaque requête, il garde en mémoire (dans un cache), le résultat des précédentes requêtes. L’objectif du pirate est d’empoisonner ce cache avec de fausses informations. Pour cela, il doit avoir un nom de domaine sous contrôle et son serveur DNS. Imaginons qu’un pirate (A) possède le nom de domaine attaquant.com, et son serveur DNS (C) et qu’il veuille empoisonner le cache du serveur DNS (B) du réseau cible.net. Le pirate envoie une requête au serveur DNS (B) du réseau cible.net demandant la résolution du nom de domaine attaquant.com. Le serveur DNS (B) de cible.net va donc envoyer une requête sur le serveur DNS (C) de l’attaquant (c’est lui qui a autorité sur le domaine attaquant.com). Celui-ci répondra et joindra des informations additionnelles falsifiées par le pirate (un nom de machine (D) associé à l’adresse IP (A) du pirate). Ces informations seront mises en cache sur le serveur DNS (B) de cible.net. Si un client quelconque (E) demande l’adresse IP pour le nom de la machine (D), il recevra l’adresse du pirate (A) en retour.
  4. 4. Domain Name Service – DNSComment s’en protéger ? Désactiver ou modifier l'affichage de la version du serveur DNS.(Bind) Activer la sécurité TSIG pour le transfert de zones DNS.(identification à l'aide de clés stockées dans le SM et SS) Les serveurs ne doivent stocker les informations obtenues que si le serveur DNS fait autorité pour les différentes zones. Le numéro ID du requête DNS est aléatoire mais comme le champ est sur 16 bits, il est possible dans des conditions proches de l'idéal (grande bande passante...) de générer les 65536 paquets réponses. Cette attaque peut être détectée en vérifiant le nombre de paquets réponses avec des ID erronés par serveur et par requête. Lorsque ce nombre atteint 5, un nouveau paquet est généré avec un nouvel ID. Et enfin, si aucun résultat n'est obtenu au bout de trois tentatives, le serveur renvoie une erreur SERVFAIL. DNSSEC DNSSEC est un ensemble de protocoles utilisant de la cryptographie symétrique et/ou asymétrique incorporant un système de stockage et de publication des clés publiques. Ainsi, il permet de résoudre les différents problèmes de sécurité lors des transferts de zone, des mises à jour (update dynamique par exemple) et de rendre inopérant le DNS spoofing. A ces nouveautés s'ajoute la compatibilité avec IPv6 et surtout l'interopérabilité des deux systèmes d'adressages, ce qui en fait un système très complexe. Les dernières versions de Bind 9 incorporent ces dernières possibilités, mais il faudrait un déploiement à l'échelle mondiale pour que le système soit réellement utilisable.
  5. 5. FTPFTP (File Transfert Protocol, en écoute par défaut sur les ports 20 et 21) est le service utilisé pour assurer le transfert de fichiers. Il y a deux types de serveurs FTP : les serveurs FTP avec authentification par mots de passe et les serveurs anonymes. Pour les premiers, le client désirant se connecter devra fournir un login accompagné d’un mot de passe pour authentification. Dans le cas du serveur FTP anonyme, tout le monde peut s’y connecter librement. Le premier défaut du protocole FTP est de ne pas encrypter les mots de passe lors de leur transit sur le réseau. Les mots de passe associés aux logins circulent en clair à la merci des sniffers. Voici l’exemple d’une interception par un sniffer d’une authentification FTP : Le serveur FTP anonyme Le serveur FTP anonyme pose de plus gros problèmes. Le premier est qu’une mauvaise gestion des droits d’accès peut s’avérer être une erreur fatale. Laisser trop de répertoires en droit d’écriture et/ou d’exécution est plus que dangereux pour la sûreté du système. Le pirate pourrait y installer ou y exécuter des codes malveillants lui permettant d’accroître son pouvoir sur la machine. Boucing attack - Attaque par rebonds Les serveurs FTP anonymes peuvent être sujets à des attaques par rebonds. Ces attaques consistent à utiliser un serveur FTP anonyme comme relais pour se connecter à d’autres serveurs FTP. Imaginons qu’un pirate se voit refuser l’accès par un serveur FTP dont l’accès est alloué à seulement un certain groupe d’adresses IP. Imaginons que le pirate ne fait pas partie de ce groupe, mais qu’un serveur FTP anonyme y appartienne. Le pirate peut très bien se connecter sur le serveur FTP anonyme, utiliser les commandes assurant la connexion sur le serveur FTP protégé et y récupérer des fichiers. Comment s’en protéger ? Installez un serveur FTP anonyme seulement en cas d’absolue nécessité. Si vous devez le faire, limitez au maximum les droits sur les différents répertoires et fichiers laissés au public. Pour vous protéger des attaques par sniffer, je vous recommande d’utiliser SFTP (Secure FTP) pour vos transactions FTP. SFTP encryptera les échanges et les protégera ainsi des écoutes indiscrètes. Vous pouvez aussi utiliser des tunnels comme IPSec pour protéger vos connexions Filtrez les accès (via un firewall) en allouant seulement l’accès à un certain groupe d’adresses IP (en évitant d’inclure des serveurs anonymes permettant de servir de relais).
  6. 6. SNMPSNMP v3 Cette nouvelle version du protocole SNMP vise essentiellement à inclure la sécurité des transactions. La sécurité comprend l'identification des parties qui communiquent et l'assurance que la conversation soit privée, même si elle passe par un réseau public. Cette sécurité est basée sur 2 concepts : USM (User-based Security Model) [1.3.6.1.SNMPv2(6).SNMPModules(3).USM(15)] VACM (View- based Access Control Model) [1.3.6.1.SNMPv2(6).SNMPModules(3).VACM(16)] 1 - User Security Module (USM) Trois mécanismes sont utilisés. Chacun de ces mécanismes a pour but d'empêcher un type d'attaque. L'authentification : Empêche quelqu'un de changer le paquet SNMPv3 en cours de route et de valider le mot de passe de la personne qui transmet la requête. Le cryptage : Empêche quiconque de lire les informations de gestions contenues dans un paquet SNMPv3. L'estampillage du temps : Empêche la réutilisation d'un paquet SNMPv3 valide a déjà transmis par quelqu'un. 1.1 - L'authentification L'authentification a pour rôle d'assurer que le paquet reste inchangé pendant la transmission, et que le mot de passe est valide pour l'usager qui fait la requête. Pour construire ce mécanisme, on doit avoir connaissance des fonctions de hachage à une seule direction. Des exemples de ces fonctions sont : MD5 et SHA-1. Ces fonctions prennent en entrée une chaîne de caractères de longueur indéfinie, et génèrent en sortie une chaîne d'octets de longueur finie (16 octets pour MD5, 20 octets pour SHA-1). Pour authentifier l'information qui va être transmise, on doit aussi avoir un mot de passe qui est « partagé ». Le mot de passe ne doit donc être connu que par les deux entités qui s'envoient les messages, et préférablement par personne d'autre. Les étapes d'authentification sont les suivantes : Le transmetteur groupe des informations à transmettre avec le mot de passe. On passe ensuite ce groupe dans la fonction de hachage à une direction. Les données et le code de hachage sont ensuite transmis sur le réseau. Le receveur prend le bloc des données, et y ajoute le mot de passe. On passe ce groupe dans la fonction de hachage à une direction. Si le code de hachage est identique à celui transmis, le transmetteur est authentifié. Avec cette technique, le mot de passe est validé sans qu'il ait été transmis sur le réseau. Quelqu'un qui saisit les paquets SNMPv3 passants sur le réseau ne peut pas facilement trouver le mot de passe. Pour ce qui est de SNMPv3, l'authentification se fait à l'aide de HMAC-MD5-96 ou de HMAC-SHA- 96, qui est un peu plus compliqué que ce qui a été décrit ici. Le résultat de la fonction de hachage est placé dans le bloc paramètres de sécurité du paquet SNMPv3. L'authentification se fait sur tout le paquet. L'étape d'authentification ne vise pas à cacher l'existence du paquet ou à le crypter. Si l'on utilise uniquement l'authentification, les personnes qui saisissent les paquets passants sur le réseau peuvent encore en voir le contenu. Toutefois, elles ne peuvent pas changer le contenu sans connaître le mot de passe.
  7. 7. SNMP1.2 - Le cryptage Le cryptage a pour but d'empêcher que quelqu'un n'obtienne les informations de gestion en écoutant sur le réseau les requêtes et les réponses de quelqu'un d'autre. Avec SNMPv3, le cryptage de base se fait sur un mot de passe « partagé » entre le manager et l'agent. Ce mot de passe ne doit être connu par personne d'autre. Pour des raisons de sécurité, SNMPv3 utilise deux mots de passe : un pour l'authentification et un pour le cryptage. Ceci permet au système d'authentification et au système de cryptage d'être indépendants. Un de ces systèmes ne peut pas compromettre l'autre. SNMPv3 se base sur DES (Data Encryption Standard) pour effectuer le cryptage. On utilise une clé de 64 bits (8 des 64 bits sont des parités, la clé réelle est donc longue de 56 bits) et DES encrypte 64 bits à la fois. Comme les informations que l'on doit encrypter sont plus longues que 8 octets, on utilise du chaînage de blocs DES de 64 bits. Contrairement à l'authentification qui est appliquée à tout le paquet, le cryptage est seulement appliquée sur le PDU. 1.3 - L'estampillage de temps (Horodatage) Si une requête est transmise, les mécanismes d'authentification et de cryptage n'empêchent pas quelqu'un de saisir un paquet SNMPv3 valide du réseau et de tenter de le réutiliser plus tard, sans modification. Par exemple, si l'administrateur effectue l'opération de remise à jours d'un équipement, quelqu'un peut saisir ce paquet et tenter de le retransmettre à l'équipement à chaque fois que cette personne désire faire une mise à jour illicite de l'équipement. Même si la personne n'a pas l'autorisation nécessaire, elle envoie un paquet, authentifié et encrypté correctement pour l'administration de l'équipement. On appelle ce type d'attaques le « Replay Attack ». Pour éviter ceci, le temps est estampillé sur chaque paquet. Quand on reçoit un paquet SNMPv3, on compare le temps actuel avec le temps dans le paquet. Si la différence est plus que supérieur à 150 secondes, le paquet est ignoré. SNMPv3 n'utilise pas l'heure normale. On utilise plutôt une horloge différente dans chaque agent. Ceux-ci gardent en mémoire le nombre de secondes écoulées depuis que l'agent a été mis en circuit. Ils gardent également un compteur pour connaître le nombre de fois où l'équipement a été mis en fonctionnement. On appelle ces compteurs BOOTS (Nombre de fois ou l'équipement a été allumé) et TIME (Nombre de secondes depuis la dernière fois que l'équipement a été mis en fonctionnement). 1.4 - Niveaux de sécurité dans SNMPv3 L'agent SNMPv3 prend en charge des niveaux de sûreté tels que définis dans la USM MIB (RFC 2574) : •noAuthnoPriv - Communication sans authentification et Confidentialité (privacy) -cryptage-. •authNoPriv - Communication avec l'authentification et sans cryptage. Les protocoles utilisés pour l'authentification MD5 et SHA sont (Secure Hash Algorithm). •authPriv - Communication avec l'authentification et cryptage. Les protocoles utilisés pour l'authentification MD5 et SHA sont, et de cryptage, DES (Data Encryption Standard) et AES (Advanced Encryption Standard) protocoles peuvent être utilisés. L'agent SNMPv3 prend également en charge les MIB VACM comme un modèle de contrôle d'accès par défaut. Il se compose de quatre tables. Le nom de contexte, le nom du groupe et de lecture / écriture pour un utilisateur sont configurés dans ces tableaux. 2 - VACM (View Access Control Model) Permet le contrôle d'accès au MIB. Ainsi on a la possibilité de restreindre l'accès en lecture et/ou écriture pour un groupe ou par utilisateur. VACM gère le contrôle d'accès en se basant sur 4 tables : SecurityToGroupTable : La première vérification est réalisée au niveau du couple (securityName, securityModel) , le Principal qui essaye d’accéder doit être associé à un modèle de sécurité, et appartenir à un groupe figurant dans la table « securityToGroupTable ». Il est important de voir qu’on peut trouver des groupes dont le modèle de sécurité est SNMPv1, ou v2C. Un couple (securityName, securityModel) ne peut appartenir qu’à un groupe, mais un Principal (securityName) peut appartenir à plusieurs groupes avec des modèles de sécurité différents. Le modèle de sécurité v1 ou v2C, avec securityName associé est dérivé de la communauté. VacmContextTable : On peut être amené à distinguer dans un équipement des zones à traiter séparément les unes des autres (on a évoqué des interfaces de commutateurs ATM par exemple, considérés comme des contextes différents). Cette table contiendra les noms des contextes. VacmAccessTable : Cette table détermine la nature de l’accès demandé (Read/Write/Notify). Quatre index (groupe, modèle de sécurité, niveau de sécurité, et nom de contexte) déterminent la nature de l’opération. C'est la table dans laquelle les règles de chaque groupe sont sauvegardées : La recherche dans cette table se fait par rapport au 4 champs suivants : groupName, contextPrefix, securityModel, et securityLevel
  8. 8. WIFIUn réseau sans fil, et par extension un réseau WiFi, est beaucoup plus sensible qu'un réseau filaire car les données circulent librement dans l'air. Il est essentiel de protéger son réseau sans fil, même si vous considérez que les données qui circulent n'ont rien de confidentiel. En effet, un réseau sans fil non protégé et sans aucun effort de configuration, peut permettre à n'importe quel utilisateur du voisinage (éventuellement dans les étages supérieurs et inférieurs) d'utiliser votre connexion internet et éventuellement lancer un certains nombre d'attaques. Ainsi, en cas de problème, le responsable sera le propriétaire de la connexion à internet, c'est-à-dire vous. Puissance de la borne La première chose à faire lors de la mise en place d'un réseau sans fil consiste à positionner intelligemment les points d'accès selon la zone que l'on souhaite couvrir. Il n'est toutefois pas rare que la zone effectivement couverte soit largement plus grande que souhaitée, auquel cas il est possible de réduire la puissance de la borne d'accès afin d'adapter sa portée à la zone à couvrir. Valeurs par défaut Lors de la première installation d'un point d'accès, celui-ci est configuré avec des valeurs par défaut, y compris en ce qui concerne le mot de passe de l'administrateur. Un grand nombre d'administrateurs en herbe considèrent qu'à partir du moment où le réseau fonctionne il est inutile de modifier la configuration du point d'accès. Toutefois les paramètres par défaut sont tels que la sécurité est minimale. Il est donc impératif de se connecter à l'interface d'administration (généralement via une interface web sur un port spécifique de la borne d'accès) notamment pour définir un mot de passe d'administration. D'autre part, afin de se connecter à un point d'accès il est indispensable de connaître l'identifiant du réseau (SSID:Service Set Identifier). Ainsi il est vivement conseillé de modifier le nom du réseau par défaut et de désactiver la diffusion (broadcast) de ce dernier sur le réseau. Le changement de l'identifiant réseau par défaut est d'autant plus important qu'il peut donner aux pirates des éléments d'information sur la marque ou le modèle du point d'accès utilisé. Filtrage des adresses MAC Chaque adaptateur réseau (nom générique pour la carte réseau) possède une adresse physique qui lui est propre (appelée adresse MAC). Cette adresse est représentée par 12 chiffres hexadécimaux groupés par paires et séparés par des tirets. Les points d'accès permettent généralement dans leur interface de configuration de gérer une liste de droits d'accès (appelée ACL) basée sur les adresses MAC des équipements autorisés à se connecter au réseau sans fil. Cette précaution un peu contraignante permet de limiter l'accès au réseau à un certain nombre de machines. En contrepartie cela ne résoud pas le problème de la confidentialité des échanges. Ce filtrage reste de plus facilement contournable pour un utilisateur expérimenté.
  9. 9. WIFI WEP - Wired Equivalent Privacy Pour remédier aux problèmes de confidentialité des échanges sur les réseaux sans fils, le standard 802.11 intègre un mécanisme simple de chiffrement des données, il s'agit du WEP, Wired equivalent privacy. Le WEP est un protocole chargé du chiffrement des trames 802.11 utilisant l'algorithme symétrique RC4 avec des clés d'une longueur de 64 bits ou 128 bits. Le principe du WEP consiste à définir dans un premier temps une clé secrète de 40 ou 128 bits. Cette clé secrète doit être déclarée au niveau du point d'accès et des clients. La clé sert à créer un nombre pseudo-aléatoire d'une longueur égale à la longueur de la trame. Chaque transmission de donnée est ainsi chiffrée en utilisant le nombre pseudo-aléatoire comme masque grâce à un OU Exclusif entre le nombre pseudo-aléatoire et la trame. La clé de session partagé par toutes les stations est statique, c'est-à-dire que pour déployer un grand nombre de stations WiFi il est nécessaire de les configurer en utilisant la même clé de session. Ainsi la connaissance de la clé est suffisante pour déchiffrer les communications. De plus, 24 bits de la clé servent uniquement pour l'initialisation, ce qui signifie que seuls 40 bits de la clé de 64 bits servent réellement à chiffrer et 104 bits pour la clé de 128 bits. Dans le cas de la clé de 40 bits, une attaque par force brute (c'est-à-dire en essayant toutes les possibilités de clés) peut très vite amener le pirate à trouver la clé de session. De plus une faille décelée par Fluhrer, Mantin et Shamir concernant la génération de la chaîne pseudo-aléatoire rend possible la découverte de la clé de session en stockant 100 Mo à 1 Go de traffic créés intentionnellement. Le WEP n'est donc pas suffisant pour garantir une réelle confidentialité des données. Pour autant, il est vivement conseillé de mettre au moins en oeuvre une protection WEP 128 bits afin d'assurer un niveau de confidentialité minimum et d'éviter de cette façon 90% des risques d'intrusion. WPA / WPA2 (wifi protected access) Pour obtenir un niveau de sécurité supérieur, il convient d'utiliser le cryptage WPA ou WPA2. Améliorer l'authentification Afin de gérer plus efficacement les authentifications, les autorisations et la gestion des comptes utilisateurs (en anglais AAA pour Authentication, Authorization, and Accounting) il est possible de recourir à un serveur RADIUS (Remote Authentication Dial-In User Service). Le protocole RADIUS (défini par les RFC 2865 et 2866), est un système client/serveur permettant de gérer de façon centralisée les comptes des utilisateurs et les droits d'accès associés. Mise en place d'un VPN Pour toutes les communications nécessitant un haut niveau de sécurisation, il est préférable de recourir à un chiffrement fort des données en mettant en place un réseau privé virtuel (VPN).
  10. 10. HTTPUn serveur HTTP est en écoute sur le port 80. Le protocole HTTP est sûrement le plus utilisé sur le web. Ce protocole ne comporte pas de failles intrinsèques majeures. Par contre, les applications assurant son traitement sont souvent bourrées de failles. Cela vient du fait que le web devient de plus en plus demandeur en terme de convivialité et cela génère une complexité plus grande des applications, d’où un risque de failles plus important. Les serveurs trop bavards Parfois, les bannières des serveurs web sont trop explicites. Exemple sur un serveur Apache : Server: Apache/1.3.29 (Debian GNU/Linux) Lors de l’envoi de la commande HEAD / HTTP/1.0, trop d’informations sont données. Les pages d’erreurs (404 : page non trouvée) peuvent aussi contenir des informations sur le système. Vulnérabilités liées aux applications web La complexité des serveurs ou des navigateurs (clients) web pose de gros problèmes de sécurité. Ces applications sont vulnérables à de nombreux bugs. Chaque application a son type de faille. Netscape par exemple devient vulnérable lors du traitement de certaines chaînes de caractères. Cela peut permettre de remonter toute l’arborescence des fichiers du serveur. Les serveurs IIS peuvent renvoyer un shell système pour un envoi de commandes particulières. Les langages comme Javascript, Perl, PHP, ASP pour la réalisation de scripts peuvent se rélèver dangereux. L’origine d’une faille dans une application web peut apparaître à cause de deux problèmes. Le premier est la fiabilité de la conception du script, le second est la fiabilité des fonctions utilisées. Si un script est mal conçu, il peut être la source de nombreuses failles. De même, si sa conception est bonne mais qu’il utilise des fonctions boguées, il peut se révéler encore plus dangereux. Comment se protéger ? Vérifiez que votre serveur web n’est pas trop bavard. Si c’est le cas, modifiez sa configuration pour qu’il se taise. Pour cela, consultez la documentation pour modifier le contenu des messages d’erreur ou de bienvenue. Un serveur web ne devrait jamais être exécuté avec les droits administrateurs. Mettez à jour les navigateurs et les serveurs pour prévoir d’éventuelles failles. Lors du développement de scripts, prenez garde lors de la conception à la gestion des droits des utilisateurs pour son exécution. Informez-vous aussi sur les fonctions connues pour être «sensibles». Les NIDS peuvent être une bonne parade contre les attaques reposant sur des failles logicielles. Ils permettent de détecter l’exécution de telles attaques. L’utilisation de SHTTP (Secure HTTP) est aussi une bonne parade contre les attaques HTTP. Une bonne définition de SHTTP est donné par E.Rescorla et A. Schiffman : "Le protocole SHTTP est une extension de HTTP qui fournit des services de sécurité, applicables indépendamment, qui permettent de garantir la confidentialité, l’authenticité/intégrité, et le non refus d’origine." SSL ("Secure Socket Layer" pour Netscape) permet de protéger les transactions web, il peut être judicieux de l’utiliser.
  11. 11. HTTPSécuriser le service Apache : Cacher la version d'Apache & du OS : En paramétrant la directive ServerTokens à Prod. Ainsi, la bannière Server: Apache/1.3.14 (Unix) (Red-Hat/Linux) PHP/4.0.3pl1 mod_perl/1.24 se limite à Server: Apache. Cela ne suffit toujours pas à masquer la version d'Apache : si vous demandez une page inexistante, Apache renvoie une page d'erreur 404 avec en bas de la page, le message Apache/1.3.14 Server at www.mon-serveur.org Port 80 qui révèle la version du serveur d'Apache. Pour empêcher cela, il faut désactiver l'insertion de la signature du serveur avec la commande ServerSignature Off. Utiliser ErrorDocument 404 /missing.html pour définir votre propre page d'erreur 404. Limitations contre les DoS De façon à limiter la portée des attaques de type Denial of Service, il est conseillé de limiter le nombre de connexions simultanées MaxClients et en particulier le nombre de connexions persistantes MaxKeepAliveRequests. Celles-ci sont apparues avec la norme HTTP 1.1. Elles permettent d'effectuer des requêtes successives lors de la même connexion, ce qui augmente les performances du serveur. L'utilisation d'un timeout empêche les connexions sans fin. Exemple pour un petit serveur : MaxClients 150 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 5 Bien définir un virtual host Apache permet la définition de Virtual Host, c'est-à-dire que le même serveur peut héberger, y compris sur une même adresse IP, plusieurs sites différenciés par leur nom. Pour limiter les risques liés à une panne des serveurs DNS ou à des manipulations frauduleuses, il convient de définir le VirtualHost par une adresse IP puis de préciser son nom. ServerName www.esiea.fr Gérer ses fichiers de log Apache permet de définir ses propres formats LogFormat pour les enregistrements dans les fichiers de log. LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined LogFormat "%h %l %u %t "%r" %>s %b" common LogFormat "%{Referer}i -> %U" referer LogFormat "%{User-agent}i" agent Ensuite, on enregistre les informations de log précisées par le format dans le fichier de son choix CustomLog /var/log/httpd/access_log common. Suivant l'utilisation de ces fichiers de logs (reporting,...), il peut être intéressant de faire apparaître le nom des machines se connectant au serveur web au lieu de leur adresse IP : HostnameLookups On active la résolution inverse.
  12. 12. HTTP1.4.3.5. Gestion des droits Nous présenterons ici les mesures préventives liées aux fichiers contenus dans l'arborescence du serveur web. Directory, Files, Location La gestion des accès est effectuée par le module mod_access. On manipule principalement trois catégories d'objets : Directory désigne un répertoire du serveur ; Location une arborescence du serveur web ; Files un fichier. Voici un exemple un peu farfelu extrait du manuel d'Apache, qui autorise la consultation du répertoire /docroot aux personnes utilisant le brower KnockKnock/2.0. Si vous voulez restreindre la consultation d'une partie de votre site aux personnes n'utilisant pas I.E., vous n'aurez pas trop de difficultés =:-) BrowserMatch ^KnockKnock/2.0 let_me_in order deny,allow deny from all allow from env=let_me_in Mesure défensive Plus sérieusement, il est fortement conseillé de tout interdire par défaut : Order deny,allow Deny from all Ensuite, il ne reste qu'à valider l'accès aux répertoires correspondant aux sites Order indique dans quel ordre les directives deny et allow sont évaluées. Deny from all interdit l'accès depuis partout. On aurait pu indiquer un nom de machine, un nom de domaine, une adresse IP, un couple IP/masque de réseau. Options, AllowOverride Options contrôle le suivi des liens symboliques FollowSymLinks/SymLinksIfOwnerMatch ; l'exécution des scripts CGI ExecCGI ; les Server Side Includes Includes et IncludesNOEXEC ; la génération de pages d'index Indexes en l'absence de celles-ci ; ainsi que l'orientation multilingue MultiViews. All regroupe les différentes options sauf MultiViews, None supprime les options. MultiViews redirige une demande pour index.html vers index.html.en ou index.html.fr selon la préférence signalée par le navigateur au serveur web. Il est important d'être le plus restrictif possible par défaut, je conseille de n'autoriser que le suivi des liens symboliques où liens et destinations ont le même propriétaire : Options SymLinksIfOwnerMatch AllowOverride None
  13. 13. HTTPUn pirate pouvant écrire dans un répertoire du serveur web, par exemple via un partage NFS, peut en profiter pour accéder au fichier /etc/passwd via un lien symbolique si l'option FollowSymLinks est présente, Includes ou ExecCGI permet d'exécuter des programmes... En un mot, soyez prudent. La directive AllowOverride peut prendre n'importe quel paramètre qu'aurait pris Options. Protection par mot de passe Le module mod_auth permet de protéger l'accès à un répertoire par mot de passe. En pratique, c'est souvent utiliser pour filtrer les accès à un sous-répertoires d'une page personnelle. AllowOverride AuthConfig Options SymLinksIfOwnerMatch ou pour bloquer l'accès à un répertoire déterminé <Location "/private"> Options None AllowOverride None AuthName "restricted stuff" AuthType Basic AuthUserFile "/etc/httpd/.passwd" require valid-user Dans le cas des pages personnelles /home/*/public_html des utilisateurs, l'accès est déterminé par un fichier .htaccess que peut utiliser ou non un utilisateur, le nom du fichier même est défini dans la section générale de la configuration du serveur. Ce fichier protége l'accès au répertoire dans lequel il est placé ainsi que l'accès aux sous-répertoires. AllowOverride AuthConfig permet à ce fichier d'être pris en compte. Par précaution, il faut empêcher un utilisateur de les récupérer via le web : AccessFileName .htaccess Order deny,allow Deny from all Si on veut pouvoir définir explicitement des exceptions pour les fichiers .htpipo par exemple, il faut spécifier l'ordre allow puis deny pour que l'autorisation prime sur l'interdiction. Le fichier .htaccess contient les mêmes champs que pour le répertoire /private de l'exemple, c'est-à-dire un nom qui apparaîtra sur la fenêtre de demande d'identification (AuthName), la méthode d'identification (AuthType), le fichier de mot de passe (AuthUserFile) et enfin require valid-user : AuthName "my restricted stuff" AuthType Basic AuthUserFile "/home/titi/.htpasswd" require valid-user 1.5. Les modules Apache Le serveur Apache s'articule sur un ensemble de modules qu'il convient de restreindre au strict nécessaire. Server Side Includes : mod_include Les SSI ont déjà été présentés lors du sixième article sur la programmation sécurisée. Il s'agit d'un vestige de l'époque où les Perl et PHP n'avaient pas encore fait leurs apparitions. Il est fortement conseillé de le supprimé ou de ne l'activé qu'avec prudence Options +IncludesNOEXEC ou Options +Includes.
  14. 14. HTTPPerl: mod_perl Le module mod_perl a été le résultat d'une intégration plus poussée des scripts CGI écrits en Perl. Il permet de meilleures performances qu'un script CGI classique. En terme de sécurité, il présente des risques identiques. PHP: mod_php PHP a été conçu spécifiquement pour la programmation web en tenant compte d'impératif de sécurité. Il est grandement paramétrable. Il est conseillé de définir les options suivantes dans son fichier de configuration /etc/php.ini. safe_mode surveille les fichiers accédés et interdit l'usage de commande à risque, expose_php contrôle l'affichage de sa banner, max_execution_time et memory_limit limite les risques de DoS, magic_quotes_gpc ajoute des quotes pour les données reçues des GET/POST et des cookies. Enfin, souvent oublié en production, il faut éviter l'affichage des lignes fautives lorsque les scripts PHP plantent. safe_mode = On expose_php = Off max_execution_time = 30 ; Maximum execution time of each script, in seconds memory_limit = 8M magic_quotes_gpc = On display_errors = Off [SQL] sql.safe_mode = On CGI Il faut limiter leur présence à des répertoires bien déterminés, ils sont alors autorisés par un Options +ExecCGI sur la base d'un répertoire particulier. Répertoires des utilisateurs : mod_userdir Les utilisateurs du serveur peuvent bien souvent publier leurs pages dans leur répertoire public_html, configuré via le paramètre UserDir public_html. De façon à éviter une mauvaise surprise, root n'est pas autorisé à faire de même : UserDir disabled root. Directory listing : mod_dir, mod_autoindex La directive DirectoryIndex définit les pages d'index souvent index.html ou index.php3 et en l'absence de celle-ci, le module mod_autoindex en génère une si l'option Indexes est présente. Les index peuvent aider un pirate à découvrir d'anciennes versions de script, un backup du site ou d'autres documents sensibles. Users et users Le serveur web est lancé par l'utilisateur root ce qui lui permet d'utiliser le port privilégié 80, ensuite il prend l'identité d'un utilisateur sans pouvoir apache ou nobody. User apache Group apache suexec Le problème est que les scripts s'exécutent tous avec le même id (i.e. le même propriétaire). En conséquence, ils peuvent interférer entre eux. Le programme suexec permet d'utiliser des User/Group différents pour chaque virtual host de façon à séparer les utilisateurs. En contrepartie, un pirate disposant du compte apache est capable d'utiliser ce programme pour corrompre d'autres comptes, c'est pour cela qu'il n'est pas actif par défaut. Il faut lire très attentivement la documentation. Il est déjà compilé sur une RedHat mais pas forcément activé, il suffit alors d'un chmod u+s /usr/sbin/suexec pour le rendre actif. ls -l /usr/sbin/suexec -r-s--x--- 1 root apache 10976 Mar 29 19:52 /usr/sbin/suexec # httpd -l Compiled-in modules: http_core.c mod_so.c suexec: enabled; valid wrapper /usr/sbin/suexec

×