L'authentification htaccess








télécharger 132.71 Kb.
titreL'authentification htaccess
page1/4
date de publication05.12.2018
taille132.71 Kb.
typeDocumentos
p.21-bal.com > loi > Documentos
  1   2   3   4

L'authentification htaccess



Concept d'authentification

Ce système d'authentification est fréquemment utilisé pour restreindre l'accès au contenu de répertoires spécifiques, sur un intranet ou sur Internet. Le fichier contenant les informations de configuration relatives aux personnes ou groupes de personnes habilitées à accéder les données protégées, ainsi que leurs droits, se nomme ".htaccess" par défaut. Il est stocké dans le même répertoire où résident les données à portéger.

Fonctionnement

La méthode d'authentification htaccess a été développée en même temps que les programmes destinés à récupérer des données "Web" sur Internet, tel que les démons HTTPd. Ainsi, dans une url (Universal Resource Locator), la commande "http://" va être interprétée par le démon (il s'agit du programme sur le serveur Web attendant toute connexion ou requête pour la traiter); celui-ci dispose d'un fichier global de gestion des accès stocké à la racine le plus souvent. Les fichiers .htaccess représentent des niveaux additionnels dans la gestion des accès, et apportent un raffinement lié à chaque répertoire.

Ainsi, si le démon trouve un fichier .htaccess dans l'arborescence à parcourir pour accéder au fichier requis par le client, il va procéder suivant les informations contenues dans ce fichier : il va soit interdire l'accès et refuser la requête, soit demander une authentification de l'utilisateur via login/password. Il est intéressant de noter que la plupart du temps les données d'authentification (à l'inverse des données de configuration) sont stockées à un autre endroit dans l'arborescence, protégées de tout accès via le Web (par exemple avec un fichier .htaccess où est spécifié "Deny from All"). Le démon va comparer ces données avec celles renvoyées par l'utilisateur lors de la requête d'authentification et autoriser, suivant le résultat du test, l'utilisateur à accéder ou non à la page web.

Aspects pratiques : le fichier .htaccess

On retrouve ce type d'authentification dans la plupart des distributions : Apache permet l'utilisation de fichiers nommés ".htaccess" par défaut. Netscape utilise des fichiers nommés ".nsconfig" dont la syntaxe varie quelque peu.

Du côté de cette syntaxe, nous allons voir celle qui est la plus habituelle, à savoir celle utilisée par Apache ou NCSA HTTPd; un exemple typique de fichier .htaccess est le suivant :

AuthUserFile /repertoire_protege/.htpasswd
AuthGroupFile /dev/null
AuthName Area_51
AuthType Basic

require user roswell


Nous utilisons ici un fichier ".htpasswd" qui est placé dans le répertoire "/repertoire_protege", et qui contient nos paires de login/password de références. Nous verrons ce fichier un peu plus loin; nous n'utilisons pas de fichier définissant des groupes d'utilisateurs : nous sommes dans un cas simple (le paramètre "/dev/null" correspond au device null sous Unix, autrement dit à quelquechose d'inexistant). "Area_51" est le nom que nous donnons à cette authentification (éviter les espaces) et "Basic" est le type d'authentification.

La deuxième partie du fichier est celle où nous allons définir les droits requis pour accéder au contenu du répertoire dans lequel se trouve notre fichier .htaccess . Ainsi dans le cas présent, nous n'autorisons que l'utilisateur "roswell" (attention à la casse) à accéder à notre répertoire. Lors de l'authentification, cet utilisateur donnera son mot de passe qui sera alors comparé à la valeur contenue dans notre fichier de mots de passe, à savoir .htpasswd .


Nous allons voir maintenant qu'il est possible d'affiner ces droits en limitant suivant le cas les hôtes, requêtes HTTP, fichiers accédés, protocoles, etc...

- premier cas, la limitation des requêtes HTTP. HTTP est un protocole de transfert de données utilisé pour le web (c.f. la rfc 2616), qui comporte un nombre limité de fonctions; il est possible de n'accepter que certains types de fonctions pour que, par exemple, les utilisateurs ne puissent qu'accéder en lecture au répertoire. C'est le cas dans l'exemple suivant où nous limitons l'accès aux requêtes (fonctions HTTP) de type GET (lecture) pour les utilisateurs roswell et mulder :


require user roswell mulder


Plus généralement, nous aurons :


require valid-user


où tout utilisateur présent dans la liste du fichier .htpasswd sera autorisé à effectuer des requêtes GET sur le répertoire protégé.


- autre cas, limitation des fichiers accédés :


require valid-user


Nous limitons ici l'accès au fichier spécifié, "index.html", en excluant le reste du répertoire. Cet accès est lui-même limité aux utilisateurs valides (autorisés).


- cas suivant, les restrictions suivant les hôtes :

Expliquons tout d'abord les options utilisées : Order, Deny et Allow. Order permet de spécifier un ordre d'évaluation des critères de test. Allow signifie autoriser les entités satisfaisant le test correspondant et Deny signifie rejeter les entités satisfaisant également le test correspondant. On utilise généralement un combinaison des 2, et suivant l'ordre, la politique de sécurité varie quelque peu.
Dans l'ordre Deny,Allow, les directives Deny sont évaluées avant celles de la clause Allow. Le défaut est d'autoriser l'accès. Tout client qui ne correspond pas à la directive de déni ou qui satisfait au test d'autorisation spécifique Allow se verra autorisé l'accès au serveur web.
Dans l'ordre Allow,Deny, les directives Allow sont évaluées avant celles de la clause Deny. Le défaut est d'interdire l'accès. Tout client qui ne correspond pas à la directive d'autorisation ou qui satisfait au test de déni se verra refusé l'accès au serveur web.

Exemple :

Order Allow,Deny
Allow from apache.org
Deny from foo.apache.org

Tout le monde provenant du domaine apache.org est autorisé à accéder au serveur web sauf une sous partie qui est refusée (sous-domaine foo). Le reste du monde est refusé puisqu'il s'agit du défaut dans ce cas.

Variantes : pour autoriser seulement un groupe d'adresses IP : ici celles contenues dans la classe B 129.21 .

Order Deny,Allow
Allow from 129.21
Deny from All

Pour autoriser seulement un groupe d'hôtes ou réseaux : ici le domaine rit.edu .

Order Deny,Allow
Allow from rit.edu
Deny from All

Pour exclure seulement un groupe d'adresses IP : ici celles contenues dans 129.21.3 .

Order Allow,Deny
Allow from All
Deny from 129.21.3

Pour exclure seulement un groupe d'hôtes ou réseaux : ici le domaine isc.rit.edu .

Order Allow,Deny
Allow from All
Deny from isc.rit.edu


- dernier cas, l'authentification sécurisée : elle fait appel au protocole SSL (ou sa version standardisée, TLS) pour les échanges de données, ce qui évite que les mots de passe circulent en clair sur le réseau. Pour l'utiliser, il faut faire des requêtes de type https://... sur un serveur correctement configuré.

AuthDCE On
AuthType Basic
AuthName dce
require valid-user


Aspects pratiques : le fichier .htpasswd

Le fichier htpasswd contient les login et mots de passe des utilisateurs autorisés à accéder aux pages web. Plusieurs fichiers htaccess peuvent utiliser le même fichier htpasswd comme base de secrets (credentials) centrale si la méthode d'authentification est basique. Mais dans tous les cas ce fichier doit être clairement protégé (bien qu'accessible en lecture par le démon pour lui permettre de l'utiliser); le plus souvent, on utilise là encore une protection par htaccess au moyen de la ligne de configuration : "Deny from All", ce qui signifie qu'aucun accès (du démon donc via le web) n'est autorisé.
Par contre, ce fichier reste accessible comme tout autre fichier par le système d'exploitation et donc via les autres services tel que FTP.

Pour créer le fichier ".htpasswd", il faut utiliser la commande *nix htpasswd ou utiliser un site web qui fournit le même service. La commande type est (-c pour création d'un nouveau fichier):

htpasswd -c /répertoire_destination/.htpasswd login

Le système va ensuite demander le mot de passe associé à ce login qu'il va crypter et rajouter au fichier .htpasswd. Voici un exemple de ce que l'on peut trouver dans un fichier .htpasswd :

foobar:Z39sR$s9xLyx
karen:44KvbqBfLZ5Yw

La fonction htpasswd accepte plusieurs types de cryptage des mots de passe :

  • -m utilise la fonction de hachage MD5 (128 bits). Attention, Apache utilise une version spécifique de l'algorithme, ce qui signifie qu'il n'est pas interoperable avec les autres serveurs web.

  • -d utilise la fonction système crypt(). Pour rappel, cette fonction est basée sur le DES, et est également utilisée pour le cryptage des most de passe système (fichier passwd ou shadow).

  • -s utilise la fonction de hachage SHA-1 (160 bits).

  • -p laisse les mots de passe en clair.


Faiblesse htaccess : l'authentification HTTP

Comme nous l'avons vu précédemment, htaccess est un processus d'authentification qui va être reconnu par le démon HTTP lorsqu'il essayera d'accéder aux fichiers pour les envoyer au client. Mais cette authentification repose en fait complètement sur les fonctionnalités du protocole HTTP (c.f. la rfc 2617), et le démon va demander au client de s'authentifier via une requête particulière. Prenons l'exemple suivant :

GET http://www.securiteinfo.com/restricted_zone/ HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*
Accept-Language: fr
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
Host: www.securiteinfo.com
Proxy-Connection: Keep-Alive

HTTP/1.1 401 Authorization Required
Via: 1.1 PROXY2
Connection: close
Content-type: text/html; charset=iso-8859-1
Date: Wed, 22 Aug 2001 15:25:40 GMT
Server: Apache/1.3.12 (Unix) Debian/GNU mod_perl/1.24
Www-authenticate: Basic realm="Acces Restreint"

GET http://www.securiteinfo.com/restricted_zone/ HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*
Accept-Language: fr
Authorization: Basic QWxpY2U6TGFwaW4=
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
Host: www.securiteinfo.com
Proxy-Connection: Keep-Alive

HTTP/1.1 200 OK
Via: 1.1 PROXY2
Connection: close
Content-type: text/html
Date: Wed, 22 Aug 2001 15:25:45 GMT
Server: Apache/1.3.12 (Unix) Debian/GNU mod_perl/1.24


Explications :

  • L'utilisateur souhaite accéder à une page web qui s'avère être protégée par htaccess. Concrètement, il y a 2 échanges requête/réponse HTTP qui sont éffectués pour donner accès à cette page.

  • Le premier est une requête simple (un GET) signifiant que le client souhaite accéder à la page. La réponse est "401 Authorization Required", ce qui signifie que la page est protégée et nécessite une authentification (de type "Basic"). L'utilisateur ne voit pas cette réponse, seul le navigateur (browser) la voit et affiche en réponse une popup dans laquelle il demande à l'utilisateur de taper son login et mot de passe.

  • Après cette opération, le navigateur réitère son GET en ajoutant cette fois-ci les informations de l'utilisateur ("Authorization: Basic QWxpY2U6TGFwaW4=") qui serviront au serveur pour l'authentifier.

  • Si tout se passe bien, la requête est acceptée ("200 OK") et l'utilisateur peut accéder à la page web.



Nous avons ici le cas le plus simple : les informations de l'utilisateur circulent quasiment en clair sur le réseau. Prenons l'élément "crypté" : QWxpY2U6TGFwaW4=. Cet élément est en fait "login:password" uuencodé en base 64, ce qui n'est d'aucune protection (l'uuencodage est un procédé servant à coder du binaire en ASCII et inversement, autrement dit de passer de 24 à 32 bits tout en restant dans l'intervalle des caractères imprimables, ce qui permet de transférer des fichiers binaires sous forme de texte par exemple).

Copions cet élément dans un fichier type :

begin-base64 644 my_file
QWxpY2U6TGFwaW4=
====

Un simple passage dans la fonction *nix uudecode nous donne :

Alice:Lapin

Nous avons retrouvé le login : "Alice" et le mot de passe : "Lapin".


Il existe une autre méthode utilisée pour coder les informations transitant sur le réseau : on utilise l'algorithme de hash MD5 (c.f. la rfc 1321). Les propriétés d'une fonction de hachage rendent impossible le fait qu'un attaquant puisse remonter aux informations initiales (login/password); de plus, le hasché reste caractéristique de ces données, autrement dit un hasché correspond à un et un seul texte original (dans la limite de son intervalle de sortie, à savoir 2^128 possibilités pour MD5).
Néanmoins, cela ne préserve pas des "replay-attacks", dans lesquelles l'attaquant va se contenter d'intercepter ce hasché et de l'utiliser à son propre compte comme s'il s'agissait du sien : il n'a nul besoin de posséder le texte original puisque c'est le hasché qui est demandé! Pour remédier à cette faiblesse, l'authentification HTTP utilisant cet algorithme va donc rajouter des éléments -uniques- dans le calcul du hasché, le plus souvent en envoyant un challenge (le "nonce") au client lors de la requête d'authentification. Le client va rajouter ce challenge dans le calcul du hasché, le rendant unique par la même occasion (c.f. la rfc 2069 et suivantes).

HTTP/1.1 401 Unauthorized
(...)




WWW-Authenticate: Digest

realm="testHash",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"



Authorization header:

Authorization: Digest
username="Alice",
realm="testHash",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
response="e966c932a9242554e42c8ee200cec7f6",
opaque="5ccc069c403ebaf9f0171e9517f40e41"


Malheureusement, cette deuxième méthode d'authentification est peu utilisée (cela dépend entre autres des fonctionnalités du serveur, du navigateur, etc...).
Les navigateurs suivants supportent l'authentification basée sur MD5 :


Alors que ceux-ci ne la supportent pas (liste non-exhaustive):

  • Netscape Communicator 4.5 (Mac) et 4.7 (PC)

  • iCab Preview 1.7 (Mac)


Avantages et désavantages

La méthode d'authentification par htaccess permet de déléguer le contrôle d'accès au niveau local, et autorise ainsi plus de flexibilité pour créer et changer les droits d'accès suivant les besoins.

Par contre, on comprendra que ce système devient rapidement ingérable lorsque le nombre d'utilisateurs et/ou de répertoires augmentent, rendant toute politique de sécurité globale impossible.
D'autre part, le système reste faible dans son concept; il est basé sur les services du Web à l'exclusion de tous les autres sevices d'Internet, ce qui n'est pas une hypothèse raisonnable. En effet, tout utilisateur malveillant qui a accès au serveur par un autre moyen ou service (ce qui n'est pas irréaliste) sera capable de modifier et corrompre complètement ce système d'authentification. Ainsi on peut dresser une liste (non-exhaustive bien sûr) qui permet de se faire une idée du nombre de menaces à prendre en compte lorsque l'on souhaite utiliser ce système d'authentification :

- accès via FTP (utilisateur autorisé)
- accès via FTP (utilisateur non-autorisé, buffer-overflows et autres exploits type wu-ftpd)
- accès via Telnet (sur services particuliers, la liste étant trop longue pour être citée...)
- accès via Web (script cgi non protégé type PHF, débordements)
- ...

Conclusion

Nous avons vu que la méthode d'authentification par htaccess comporte beaucoup d'inconvénients, voir de faiblesses, pour un nombre d'avantages assez restreint. Néanmoins, il ne faut pas oublier son principal intérêt qui est le fait qu'elle reste la seule méthode facilement utilisable par le client de base d'un fournisseur d'accès internet et d'espace web. En effet la plupart du temps cette personne n'a pas accès aux serveurs et ne peut donc pas faire appel à des services auxiliaires pour des types d'authentifications alternatives. Les quelques options restantes sont plus compliquées à implémenter (PHP/MySQL par exemple) surtout si l'on souhaite assurer un bon niveau de sécurité (modules cryptographiques en PHP). Et l'on ne parle même pas des solutions utilisées par la plupart des interfaces web de mail gratuit type Yahoo!, où l'on utilise un simple POST dans lequel le mot de passe est présent en clair!

Pour finir, la méthode htaccess peut très bien être sécurisée car elle en possède les moyens : cryptographie avec MD5 ou sécurisation de bout en bout grace à SSL... A chacun de s'assurer que ces mesures soient correctement utilisées.


Les mots de passe


Introduction

Les mots de passe ont été, dès le début de l'informatique, la solution la plus simple à mettre en oeuvre, et qui procure un minimum de sécurité. Encore aujourd'hui, les mots de passe font légion dans les logiciels, les systèmes d'exploitation, les systèmes embarqués, etc. Pourtant, on considère qu'environ 30% des mots de passe sont amenés à être découverts. Il faut donc les choisir avec soin pour minimiser les risques.

Choix d'un mot de passe

Choisir un bon mot de passe n'est pas si évident que ça en a l'air. Il faut respecter quelques règles :

  • Ne jamais choisir un mot du langage courant. Des logiciels spéciaux de type dictionary cracking sont spécialisés dans ce domaine.

  • Ne jamais prendre un mot qui est proche de vous : Votre prénom, le nom de jeune fille de votre femme, le nom du chien, des enfants, de votre hobby préféré...

  • Ne jamais prendre un mot inférieur à 6 lettres. Des logiciels spéciaux de type brute force cracking sont spécialisés dans ce domaine.

  • Un mot de passe ne doit jamais être écrit quelque part. La première chose que fait un pirate, est de fouiller dans vos affaires : Regarder dans votre agenda, sous l'écran, sous le clavier, dans votre poubelle, rechercher un fichier du type "mdp.txt" dans votre disque dur, etc.


Bref, le mieux est de prendre un mot de passe constitué de chiffres et de lettres, et éventuellement de majuscules et minuscules. Par exemple : diZmLvc4dKJvc51 est un excellent mot de passe ! Le problème est qu'il est difficile à retenir. Une bonne méthode est de constituer un anagramme. Par exemple, si l'on prend " bonjour toi 2000 ", on peut prendre une lettre sur deux (on oublie les espaces), et couper le chiffre en deux. Ca donne : 20bnoroojuti00. Il n'y a guère mieux comme mot de passe... Encore plus facile à retenir, on peut utiliser le verlant, cela donne : 20toijourbon00. Bien sûr, il existe d'autres méthodes, à vous d'imaginer la vôtre.

Conclusion

Maintenant que l'on a un bon mot de passe, il est préférable de prendre deux mesures supplémentaires :

  • Prendre un mot de passe différent par application (comptes mail, login FTP, accès à un site web...).

  • Changer régulièrement de mot de passe.


Les risques d'intrusion par détection de votre mot de passe sont maintenant considérablement réduits.


Quelle détection d'intrusion adopter ?


Les IDS en question
Le but de ce document n'est absolument pas d'orienter vers un outil ou un autre mais simplement d'analyser les avantages et les inconvénients des techniques de détection d'intrusion afin d'établir des critères de choix pour ce type d'outils. On parle souvent d'IDS (Intrusion Detection System) pour désigner l'ensemble des outils de détection d 'intrusion.


Bibliothèques de signatures contre détection d'anomalies
On peut dans un premier temps classer tous les outils de détection d'intrusion selon deux modes de fonctionnement selon qu'ils se basent sur des signatures d'attaques ou sur des modèles comportementaux.


IDS à Bibliothèques de signatures
Le concept de bibliothèque de signatures d'attaque est l'approche la plus basique et la plus ancienne. Cette approche consiste à rechercher dans l'activité de l'élément surveillé les empreintes (ou signatures) d'attaques connues. Cette démarche appliquée à la détection d'intrusion, est très similaire à celle des outils antivirus et présente les même inconvénients que celle ci. Il est aisé de comprendre que ce type d'IDS est purement réactif ; il ne peut détecter que les attaques dont il possède la signature. De ce fait, il nécessite des mises à jour quotidiennes. De plus, ce système de détection est aussi bon que l'est la base de signature. Si les signatures sont erronées ou incorrectement conçues l'ensemble du système est inefficace. C'est pourquoi ces systèmes sont souvent contournés par les pirates qui utilisent des techniques dites " d'évasion " qui consistent à maquiller les attaques utilisées. Ces techniques de maquillage tendent à faire varier les signatures des attaques qui ainsi ne sont plus reconnues par l'IDS. Ce modèle est par contre très aisé à implémenter et à optimiser. Il permet la séparation du moteur logiciel de la base de signature qui peut ainsi être mise à jour indépendamment. Il permet également une classification relativement facile de la criticité des attaques signalées.


IDS à Modèles comportementaux
Les modèles comportementaux sont apparus bien plus tard que les IDS à signatures. Ils ont pour principe la détection d'anomalies. Leur mise en oeuvre comprend toujours une phase d'apprentissage au cours de laquelle ils vont " découvrir " le fonctionnement " normal " des éléments surveillés. Une fois cet apprentissage effectué ces IDS signaleront les divergences par rapport au fonctionnement de référence. Les modèles comportementaux peuvent être élaborés à partir d'analyses statistiques ou de techniques proches de l'intelligence artificielle. La principale promesse des IDS comportementaux est la détection des nouveaux type d'attaque. En effet ces IDS ne sont pas programmés pour reconnaître des attaques spécifiques mais signalent toute activité " anormale ". De ce fait une attaque ne doit pas nécessairement être connue d'avance ; dès lors qu'elle représente une activité anormale elle peut être détectée par l'IDS comportemental. Du fait même de leur conception ces IDS sont incapables de qualifier la criticité des attaques. De plus, ces IDS signaleront par exemple tout changement dans le comportement d'un utilisateur qu'il soit hostile ou non. De fréquents ajustements sont nécessaires afin de faire évoluer le modèle de référence de sorte qu'il reflète l'activité normale des utilisateurs et réduire le nombre de fausses alertes générées.


Réseau contre Système
Les IDS peuvent également se classer selon deux catégories majeures selon qu'ils s'attachent à surveiller le trafic réseau ou l'activité des machines. On parle d'IDS réseau (NIDS : Network IDS) ou d'IDS Système (Host based IDS).


IDS Réseau
Ces outils analysent le trafic réseau ; ils comportent généralement une sonde qui " écoute " sur le segment de réseau à surveiller et un moteur qui réalise l'analyse du trafic afin de détecter les signatures d'attaques ou les divergences face au modèle de référence. Les IDS Réseau à base de signatures sont confrontés actuellement à deux problèmes majeurs qui sont : le développement de l'utilisation du cryptage et le développement des réseaux commutés. En effet, il est d'une part plus difficile " d'écouter " sur les réseaux commutés et le cryptage rend l'analyse du contenu des paquets presque impossible. La plupart des NIDS sont aussi dits IDS inline car ils analysent le flux en temps réel. Pour cette raison, la question des performances est très importante car de tels IDS doivent être de plus en plus performants afin d'analyser les volumes de plus en plus importants pouvant transiter sur les réseaux.


IDS Système
Les IDS Systèmes analysent quant à eux le fonctionnement ou l'état des machines sur lesquelles ils sont installés afin de détecter les attaques. Ils sont très dépendants du système sur lequel ils sont installés. Il faut donc des outils spécifiques en fonction des systèmes déployés. Ces IDS peuvent s'appuyer sur des fonctionnalités d'audit propres au système d'exploitation ou non pour vérifier l'intégrité du système et générer des alertes. Il faut cependant noter qu'ils sont incapables de détecter les attaques affectant les couches réseaux de la machine ; typiquement les Déni de service comme SYN FLOOD ou autre.


La réalité du marché
Actuellement de nombreux produits sont disponibles, certains appartiennent même au domaine public. Leur complexité de mise en oeuvre et leur degré d'intégration sont très divers. Même si les outils strictement basés sur des modèles comportementaux sont actuellement en perte de vitesse ; des modèles de ce type sont de plus en plus intégrés à des IDS initialement basés sur une bibliothèque de signatures. En effet, certains éditeurs ont déjà fait le choix de compléter leur base de signature par un modèle comportemental basique permettant de signaler des événements non identifiables. Les IDS systèmes sont un peu en retrait face aux IDS réseaux même si ces derniers sont confrontés comme nous l'avons vu à des problématiques qui devraient beaucoup peser sur leur avenir.


Le futur
On peut penser que dans un futur proche devrait apparaître et se développer les IDS distribués. Ceux si consisteraient en agents déployés sur tous (ou presque) les noeuds du réseau et agissant comme autant de sondes réseau et d'IDS systèmes. Ces agents analyseraient le trafic réseau à destination de la machine sur laquelle ils seraient installés et contrôleraient également l'intégrité de ce système. Le point central deviendrait alors un " serveur IDS " auquel tous les agent devraient rendre compte et qui serait en mesure d'agréger et de consolider les informations en provenance des agents afin de générer les alertes.


Critères de choix
Aujourd'hui les systèmes de détection d'intrusion sont réellement devenus indispensables lors de la mise en place d'une infrastructure de sécurité opérationnelle. Ils s'intègrent donc toujours dans un contexte et une architecture qui imposent des contraintes pouvant être très diverses. C'est pourquoi il n'existe pas de grille d'évaluation unique pour ce type d'outil. Pourtant un certain nombre de critères peuvent être dégagés ; ceux ci devront nécessairement être pondérés en fonction du contexte de l'étude.

  • Fiabilité : Un détecteur d'intrusion doit être fiable ; les alertes qu'il génère doivent être justifiées et aucune intrusion ne doit pouvoir lui échapper. Un IDS générant trop de fausses alertes sera à coup sûr désactivé par l'administrateur et un IDS ne détectant rien sera rapidement considéré comme inutile.

  • Réactivité : Un IDS doit être capable de détecter les nouveaux types d'attaque le plus rapidement possible ; pour cela il doit rester constamment à jour. Des capacités de mise à jour automatique sont pour ainsi dire indispensables.

  • Facilité de mise en oeuvre et adaptabilité : Un IDS doit être facile à mettre en oeuvre et doit pouvoir surtout s'adapter au contexte dans lequel il doit opérer ; il est inutile d'avoir un IDS émettant des alertes en moins de 10 secondes si les ressources nécessaires à une réaction ne sont pas disponible pour agir dans les mêmes contraintes de temps.

  • Performance : la mise en place d'un IDS ne doit en aucun cas affecter les performance des systèmes surveillés. De plus, il faut toujours avoir la certitude que l'IDS a la capacité de traiter toute l'information à sa disposition (par exemple un IDS réseau doit être capable de traiter l'ensemble du flux pouvant se présenter à un instant donné sans jamais dropper de paquets) car dans le cas contraire il devient trivial de masquer les attaques en augmentant la quantité d'information.

  • Multicanal : Un bon IDS doit pouvoir utiliser plusieurs canaux d'alerte (email, pager, téléphone, fax...) afin de pouvoir garantir que les alertes seront effectivement émises. Information : L'IDS doit donner un maximum d'information sur l'attaque détectée afin de préparer la réaction. Classification : il doit être aisé de hiérarchiser la gravité des attaques détectées afin d'adapter le mode d'alerte.


Conclusion
Les IDS sont actuellement des produits mûrs et aboutis. Ils continuent d'évoluer pour répondre aux exigences technologiques du moment mais offrent d'ores et déjà un éventail de fonctionnalités capables de satisfaire les besoins de tous les types d'utilisateurs. Néanmoins comme tous les outils techniques ils ont des limites que seule une analyse humaine peut compenser. Un peu comme les Firewalls, les détecteurs d'intrusion deviennent chaque jour meilleurs grâce à l'expérience acquise avec le temps mais ils deviennent aussi de plus en plus sensibles aux erreurs de configuration et de paramétrage. Par conséquent, il est plus que fondamental de former correctement les personnes chargées de la mises en oeuvre et de l'exploitation des IDS. Malheureusement, il semble que c'est encore là où aujourd'hui encore subsiste la plus grande partie de la difficulté.


La Biométrie



Introduction

La biométrie est une technique globale visant à établir l'identité d'une personne en mesurant une de ses caractéristiques physiques. Il peut y avoir plusieurs types de caractéristiques physiques, les unes plus fiables que d'autres, mais toutes doivent être infalsifiables et uniques pour pouvoir être représentatives d'un et un seul individu. D'autre part, comme nous allons le voir, les caractéristiques physiques sont loins d'être si parfaites et si précises, et l'on atteint très vite des limites pour ces techniques.

Usage

Les techniques basées sur la biométrie jouissent à l'heure actuelle d'un engouement général favorisé par un phénomène de mode, principalement véhiculé par les films au cinéma et à la télévision. Ainsi, il n'est pas rare de voir des scanners rétiniens avec de superbes lasers rouges, des lecteurs d'empreintes digitales avec de très jolis voyants -clignotants-, etc... tout cela représentant le summum de la technologie du contrôle d'accès. Or, les techniques de biométrie sont belle et bien en train de se répandre dans notre vie quotidienne, et ce tout en gardant une image quelque peu trompeuse.
Car le problème est bien de savoir quelles techniques existent réellement, et quelles sont leurs limites. Cet article ne se veut pas exhaustif sur un sujet aussi vaste que la biométrie, mais il a tout de même pour vocation de sensibiliser au maximum les lecteurs et de leur donner quelques bases indispensables.

Caractéristiques physiques :

Il existe plusieurs caractéristiques physiques qui se révèlent être uniques pour un individu, et il existe également pour chacune d'entre elles plusieurs façons de les mesurer :
  1   2   3   4

similaire:

L\Arttrust, la solution de certification et d'authentification des œuvres d'Art








Tous droits réservés. Copyright © 2016
contacts
p.21-bal.com