K E R B E R O S V S N T L M SRS Epita Promo 2009 SÉCURITÉ DU SI SUJET (2): Authentification centralisée et SSO Version : 1.0 Denoun Jérémy De Daniloff Cyril Bettan Michael 1 4-1 6 r u e v o l t a i r e 9 4 2 3 0 K r e m l i n B i c ê t r e - S R S
Introduction Objectif Le dossier suivant a pour objectif de mise en place de la sécurisation de la navigation en centrale. Il s'agit de réaliser un dossier d'étude sécurité autour du proxy SQUID (www.squid-cache.org) avec un certain nombre de briques sécurisées complémentaires. 1. TECHNOLOGIES SQUID Squid est un logiciel open source qui fait partie de ses logiciels dit mandataires, dont l objectif est de fournir un service de relai des demandes utilisateurs. Les fonctionnalités de SQUID peuvent permettent d ajouter dans une infrastructure différentes briques de contrôle, sécurité et optimisation. On utilise principalement SQUID en tant que serveur proxy (mise en cache du contenu fréquemment demandés) mais on peut utiliser les fonctionnalités de filtrage ou de journalisation dans le cadre d une politique de sécurité. SQUID est multi plateforme et supporte de nombreux protocoles (HTTP, HTTPS, FTP, requêtes DNS) NTLM NTLM est un protocole d'authentification principalement utilisé dans les protocoles Microsoft, on l utilise principalement pour fournir un mécanisme d identification unique. NTLM repose sur un mécanisme de challenge, mais ne traverse pas les pare-feu (caractéristiques à prendre en compte dans les choix d infrastructures) Kerberos Kerberos est également un protocole d authentification issu du MIT, on l utilise également pour une identification unique mais son système repose sur un mécanisme d émission de ticket valable dans le temps (en heure) qui identifie le client au yeux du serveur. 2. PROJET L objectif est de fournir à une PME, des briques matériels et logiciels afin de contrôler l'accès à Internet des utilisateurs des ressources informatique de l entreprise. Le parc est déjà constitué de plusieurs briques technique tels : Un serveur DNS Un serveur DHCP Un serveur Active Directory Un firewall L objectif du projet est de comparer 2 technologies d authentification unique afin de déterminer une solution pour cette PME et d établir une maquette constitué d un mandataire pour l'accès Internet. Le serveur mandataire aura la charge de journalisation et de contrôle du contenu distribué aux utilisateurs. 1
3. CRITIQUES Le fait de rationaliser les accès internet dans une PME est un bon choix car : D un point de vue législatif, l entreprise est responsable juridiquement des activités de ses employés, pour se justifier en cas de problèmes elle se doit de contrôler les accès quelle met à disposition de ses employés et pouvoir associer une requête à un utilisateur. D un point de vue de l utilisation des ressources informatique, l utilisation abusive du matériel fournit par l entreprise peut engendrer des ralentissements voir des pannes du système d information de l entreprise, d où une perte financière immédiate. Contrôler les accès permettra à l entreprise d analyser les abus de ressources et d en bloquer l'utilisation. Enfin d un point de vue productivité contrôler les accès au site web peut augmenter la productivité des employés de la société. Toutefois, la mise en place d un système intelligent (capable d établir des règles dynamiquement) qui pourrait autoriser selon l heure, le jour, l utilisateur certains accès peut améliorer l acceptation de la solution. Un proxy applicatif est la brique de base liée au besoin de la PME, l utilisation de SQUID grâce à ses nombreux modules et options de configuration permet de proposer à moindre coût les services demandés. Les technologies de SSO apporterons aux utilisateurs du SI, un confort d utilisation et permettrons d améliorer la sécurité sur certaines vulnérabilité. Les choix techniques de solution d authentification centralisée unique imposent des avantages/inconvénients spécifiques au modèle du fonctionnement de la technologie. L objectif est de comparer deux méthodes (NTLM, Kerberos) basée sur une authentification par challenge et d en présenter le fonctionnement. 2
Mise en place du proxy SQUID Squid est un proxy permettant d utiliser plusieurs protocoles : http, https, ftp, Gopher, il permet de mettre en caches les pages les plus fréquemment utilisées et d accélérer ainsi l accès web. INSTALLATION DE SQUID On installe tous d abord le logiciel (en fonction de sa distribution) $ aptitude install squid (pour une debian). Pour activer le support de certaines fonctionnalités on peut passer par une phase de recompilation des sources (ajout d option d authentification et d activation de certains modules) CONFIGURATION DE SQUID On configure le fichier /etc/squid/squid.conf (cf Annexe Squid) 2 objectifs doivent être mis en avant lors de la configuration de notre proxy : Sécuriser au maximum notre proxy en autorisant seulement les personnes habilités à accéder à certains sites web. Optimiser le cache de notre proxy afin d avoir un accès internet plus rapide. La sécurité Autorisation au proxy par l adresse source de l utilisateur On bloque l accès au proxy à toutes les adresses inconnues. On ouvre le proxy seulement aux machines autorisés à avoir un accès web. Authentification des utilisateurs du proxy Par défaut, on bloque l accès au proxy à tout utilisateur. Ce n est pas un proxy transparent. Seules les personnes de l entreprise habilités à utiliser le proxy sont autorisées. Filtrage des protocoles disponibles Squid permet l utilisation de nombreux protocoles différents. L entreprise recherche juste à fournir à ses employés un accès au protocole http et https. On va donc autoriser seulement ces protocoles. Protection contre des attaques externes On limite la taille des requêtes pour restreindre les risques d'attaques de type "refus de service". On configure notre proxy Squid afin d empêcher une personne mal intentionné ne puisses exploiter notre proxy à la manière d'un tunnel pour requérir à des services interdits. La performance On augmente la taille du cache maximum utilisé en mémoire vive pour améliorer l efficacité de notre cache et ainsi de notre accès web. Test de Squid Après configuration de notre proxy Squid, nous pouvons procéder à un test d execution : Squid z 3
SCRIPT DE CONNEXION A L OUVERTURE DE SESSION Pour améliorer l expérience utilisateur ainsi que l administration des postes, l administrateur de l active directory peut mettre en place un script d ouverture de session afin de configurer le poste pour l utilisation des différents services de l entreprise. Sur le contrôleur de domaine du réseau d'entreprise se trouve un répertoire système C:\WINDOWS\SYSVOL\sysvol\Nom_du_domaine\SCRIPTS. L'accès aux données de ce dossier se fait grâce aux systèmes de partage de fichier réseaux (droit de lecture) et permet aux utilisateurs d accéder aux scripts de configuration et éventuellement de montage réseaux. Dans l'outil d'administration "Utilisateurs et ordinateurs du domaine" vous pouvez éditer les profils utilisateur. Dans l'onglet "Profil", un champ permet de renseigner un script d'ouverture de session "Logon script". Le script de connexion est généralement un fichier bat (langage de script Microsoft) qui fournit une interface type script shell. Afin de faciliter les opérations de configuration l administrateur peut utiliser des langages de scripts avancer tels VBS (Visual Basic Script) qui fournit de nombreuses API de contrôle. L administrateur a également la possibilité d utiliser le langage de script Kix développé par un ingénieur Microsoft diffuser dans le ressource kit NT4 et adapter aux taches d administration de service entreprise. Ex de script kix à déployer dans l infrastructure : CLS SELECT CASE INGROUP("staff") WriteValue("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings","ProxyEnable","1","REG_DWORD") WriteValue("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings","ProxyServer","192.168.25.3:3128","REG_SZ") WriteValue("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings","ProxyOverride","","REG_SZ") WriteValue("HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main","Start Page","about:blank","REG_SZ") CASE DEFAULT WriteValue("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings","ProxyEnable","0","REG_DWORD") WriteValue("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings","ProxyServer","","REG_SZ") WriteValue("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings","ProxyOverride","","REG_SZ") WriteValue("HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main","Start Page","about:blank","REG_SZ") ENDSELECT 4
Mise en place d ACLs Solution de filtrage Pour mettre en place notre solution de filtrage nous pouvons utilisé plusieurs solutions : - Des règles de filtrage au niveau du fichier de configuration - Le module squid_guard (qui fonctionne sur un système de blacklist) Tous d abord dans notre configuration nous allons partir sur une stratégie du tous interdit c est à dire qu on ajoute une règle : http_access deny all Ensuite nous pouvons définir des acl afin de d autoriser des ports, des sites (unique, liste, expression régulière) sur le modèle suivant : acl name type (string "filename") [string2] [string3] ["filename2"] Les acls peuvent être du type suivant : * Source/Destination adresse IP * Source/Destination Domaine * Expression Régulière liée à un domaine * Mots contenu dans une url * Mots contenu dans un domaine * Date/Jour courant * Port de destination * Protocole (FTP, HTTP, SSL) * Méthode (HTTP GET ou HTTP POST) * Type de Browser * Nom d utilisateur (Protocole Ident) * Numéro d AS (Autonomous System) * Login/Mot de passe * SNMP Enfin on autorise l acl avec http_access allow name_acl Dans notre contexte on pourra donc utiliser les règles suivantes : acl pme_rules url_regex /etc/squid/pme_squid_white_list http_access allow pme_rules acl pme_gouv srcdomain.gouv.fr acl allow pme_gouv 5
Authentification utilisateurs Scénario 1 : Full Microsoft NTLM Dans ce premier cas nous allons mettre en oeuvre une authentification Full Microsoft NTLM, ce scénario respecte le schéma suivant : Pour mettre en place cette solution nous devrons passer par plusieurs phases d installation et configuration. Dans la suite de la manipulation nous supposerons que le serveur Active Directory est opérationnel et configuré, ainsi que les postes s identifient correctement sur le domaine. Pour assurer la connexion au domaine les logiciels suivant doivent être installés sur le serveur proxy : Winbind (qui permet de récupérer les utilisateurs et les groupes du contrôleur de domaine) Samba (qui permet d intégrer le domaine) L outil ntml_auth qui se charge d interroger le contrôleur de domaine afin d établir une authentification (selon la distribution ce logiciel peut être installé avec squid) 6
Configuration samba Voici les points principales du smb.conf : [global]... security = domain #Type de sécurité... winbind separator = / encrypt passwords = yes winbind cache time = 15 winbind enum users = yes winbind enum groups = yes winbind use default domain = yes idmap uid = 10000-20000 #liaison utilisateur AD <-> Utilisateur unix idmap gid = 10000-20000... Pour assurer le fonctionnement de la connexion au domaine il faut s assurer que la résolution du nom de domaine et du contrôleur est assurée (par le serveur DNS ou par le fichier resolv.conf et hosts) Ensuite vous pouvez tester la connexion au domaines par la commande suivante : #net join -U Administrateur Une fois connecté vous pouvez tester les commandes suivantes : wbinfo -g (affiche les groupes du domaine), wbinfo -u (affiche les utilisateurs du domaine), wbinfo -t (teste la connexion) Si les étapes précédentes ont réussis, on passe à l étape suivante configuration de squid, on teste tous d abord le module ntlm_auth qui sera l interface entre squid et l active directory (par le protocole NTLM). On exécute ntlm_auth, on tape le login et password d un utilisateur. Si la connexion est correctement effectuée ntlm_auth nous retourne OK pour une connexion correcte et ERR pour un échec. Configuration Squid Voici les points principales du squid.conf : TAG: auth_param auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 5 auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic auth_param basic children 5 auth_param basic realm Squid AD auth_param basic credentialsttl 2 hours l option --require-membership-of=domainead\\groupead peut rajouter une sécurité pour autoriser uniquement un groupe de l active directory 7
TAG: acl acl ntlm proxy_auth REQUIRED TAG: http_access http_access allow ntlm TAG: append_domain append_domain commun.ma-pme.fr On peut rajouter forwarded_for off pour masquer l ip du proxy, cache_effective_group proxy pour les droits des journaux d'accès. On teste la configuration en redémarrant squid : /etc/init.d/squid restart Le serveur une fois démarré est opérationnel. Attention, les droits des différents fichiers peuvent empêcher le bon fonctionnement du proxy (voir les journaux pour plus d information) en particulier winbind_privileged. Test sur le poste client Le client Windows XP lors d une requête HTTP établit une connexion avec le serveur mandataire, Internet Explorer 7 permet d assurer une authentification intégrée c est à dire une séquence d authentification basée sur les éléments de session. 8
Dans notre cas, Internet Explorer va envoyer automatiquement un challenge Kerberos ou NTLM (celui qui nous intéressent) avec les données récupérées lors de la séquence d authentification sur le contrôleur de domaine, en cas d échec une authentification basic sera déclenchée. Par ce mécanisme l authentification est transparente pour l utilisateur. Grâce à la configuration du Squid les accès du client sont enregistrés (avec le login sur l AD) dans le journal de log, ainsi que contrôlés grâce à la liste de filtrage. Analyse du journal squid & échanges réseaux Une fois la solution mis en place on peut analyser le fichier access.log : 1205234559.892 10 192.168.25.100 TCP_DENIED/407 1922 GET http://go.microsoft.com/fwlink/? - NONE/- text/html 1205234560.335 443 192.168.25.100 TCP_MISS/302 614 GET http://www.impots.gouv.fr/porttal/dgi/home?pageid=home&dsfid=00 jeremy.denoun DIRECT/145.242.6.153 text/html 1205234636.542 264 192.168.25.101 TCP_MISS/303 321 GET http://www.legifrance.gouv.fr cyril.de-daniloff DIRECT/160.92.185.162 text/html 1205234956.239 264 192.168.25.102 TCP_DENIED/407 427 GET http://www.google.fr michael.bettan NONE/ text/html On remarque donc que toutes les transactions sont journalisées et répondent donc au problématique de l entreprise. ATTENTION : La mise en place cette solution en entreprise, impose que le personnel soit informé car il permet de tracer un utilisateur, savoir ce qu il a visité. (Voir le site de la CNIL) Ces fichiers peuvent donc faire l objet d une déclaration préalable CNIL. Certains outils permettent d analyser ces logs et de construire des statistiques d accès pour voir quels sont les ressources les plus souvent sollicitées, le temps passé sur Internet par utilisateurs, Analyse du trafic réseau Pour vérifier les communications entre les différentes machines ont analyse le trafic avec l utilitaire tcpdump. 07:18:47.966836 IP 192.168.25.3.1515 > commun.ma-pme.fr.microsoft-ds: P 751794577:751795023(446) ack 166732375 win 3812 <nop,nop,timestamp 637793 31930> 07:18:47.970495 IP commun.ma-pme.fr.microsoft-ds > 192.168.25.3.1515: P 1:493(492) ack 446 win 16098 <nop,nop,timestamp 32801 637793> 07:18:47.970576 IP 192.168.25.3.1515 > commun.ma-pme.fr.microsoft-ds:. ack 493 win 3946 <nop,nop,timestamp 637794 32801> En analysant la trame on remarque un chiffrage du paquet et l établissement du challenge d authentification. On signalera que le nombre de trame échangé est assez faible et permettra une montée en charge correcte. 9
Scénario 2 : Kerberos INTRODUCTION Le protocole Kerberos permet la mise en place de serveurs d authentification. Il permet à des utilisateurs d accéder à des services réseau à partir de la même ouverture de session. Le service Kerberos (appellé KDC) se trouve dans chaque contrôleur de domaine stockant toutes les informations relatives aux comptes. Pour établir ce scénario on a utilisé MIT Kerberos afin de mettre en place un système full Kerberos. srv2003class.commun.ma-pme.fr <=> 192.168.25.2 squid.cummun.ma-pme.fr <=> 192.168.25.3 client1.commun.ma-pme.fr <=> 192.168.25.4 FONCTIONNEMENT DU SCÉNARIO : Lorsque client1.ma-pme.fr se connecte à son poste de travail (par l active directory). Son identifiant est envoyé au KDC (service kerberos) du serveur srv2003class.commun.ma-pme.fr comme une demande de TGT (Ticket Granting Ticket). Le KDC (service kerberos), srv2003class.commun.ma-pme.fr, vérifie que l'identifiant existe et crée un ticket TGT en le cryptant avec la clé du client1 puis l envoie à client1.commun.ma-pme.fr. client1.commun.ma-pme.fr décrypte le TGT à l'aide de la clé de l'utilisateur (qu'il recompose à partir du mot de passe). Lorsque le client1.commun.ma-pme.fr veut accéder au serveur proxy SQUID de squid.commun.ma-pme.fr le ticket TGT demande un ticket au TGS (Ticket Granting Service, service d'émission de tickets) fonctionnant sur le KDC du serveur srv2003class.commun.ma-pme.fr LES ÉLÉMENTS DU SCÉNARIO : COMMUN.MA-PME.FR est le domaine Windows et le Kerberos-realm que nous allons utiliser pour l authentification. srv2003class.commun.ma-pme.fr est le contrôleur de domaine (DC) et l active directory du domaine COMMUN.MA-PME.FR. Il comporte un KDC (Key Distribution Center) du realm COMMUN.MA-PME.FR intégré au contrôleur de domaine. squid.commun.ma-pme.fr est notre serveur proxy (SQUID) sous debian etch qui comporte squid, squid_kerb_auth et un client kerberos. client1.commun.ma-pme.fr est notre client Widows XP SP2 IE7 membre du domaine COMMUN.MA-PME.FR. Nous voulons qu Internet Explorer s authentifie via le ticket kerberos sans aucune authentification manuelle (login/password). 10
MISE EN PLACE DU SERVEUR 2003 (SRV2003CLASS.COMMUN.MA-PME.FR) Nous avons effectués ces tâches dans les précédentes parties : Installation d un contrôleur de domaine (DC) appelé COMMUN.MA-PME.FR. Celui comportait de base un service kerberos (KDC) Installation d un serveur DNS Installation d un serveur DHCP CONFIGURATION DU SERVEUR DNS On a configuré notre serveur dns du serveur Windows 2003 pour que l host squid.commun.ma-pme.fr pointe sur 192.168.25.3, ainsi que son reverse. squid.commun.ma-pme.fr <-> 192.168.25.3 Cette étape est primordiale pour que l authentification par keberos fonctionne. CRÉATION D UN UTILISATEUR Afin que le client Windows XP SP2 (client1.commun.ma-pme.fr) puisse avoir accès au service proxy grâce au protocole Kerberos : On crée un compte mik dans le domaine Windows COMMUN.MA-PME.FR GÉNÉRATION DE LA KEYTAB ET MAPPING PRINCIPAL/UTILISATEUR On installe Support tool du CD Windows 2003 afin d obtenir l outil Ktpass.exe 1. On utilise l outil Ktpass.exe pour mapper le compte mik au service principal HTTP/squid.commun.ma-pme.fr@COMMUN.MA-PME.FR et générer la keytab squid.keytab.mik 11
2. On vérifie à l aide de l outil setspn.exe le bon mapping principal/utilisateur On voit bien que le principal HTTP/squid.commun.ma-pme.fr est mappé à l utilisateur mik MISE EN PLACE DU PROXY SQUID (SQUID.COMMUN.MA-PME.FR) Le but de cette partie est de configurer le serveur proxy squid (squid.commun.ma-pme.fr) pour fonctionner avec le protocole kerberos. INSTALLATION DU SERVEUR SQUID L installation du serveur squid est plus complexe que dans les parties précédentes. En effet, afin d installer le module d authentification kerberos pour squid (squid_kerb_auth), cela nécessite la compilation et l installation manuelle des sources de SQUID. Par défaut, le package debian ne comporte pas squid_kerb_auth On recompile squid avec des paramètres spécifiques. $tar -zxvf squid-2.6.stable18.tar.gz && cd squid-2.6.stable18 $./configure enable-auth= basic negotiate -enable-negotiate-authhelpers="squid_kerb_auth" $make && make install $useradd -s /bin/false -r squid $usermod -d /var/spool/squid squid $mkdir -p /var/log/squid $mkdir -p /var/spool/squid $mkdir -p /etc/squid $chown squid.squid /var/spool/squid -R $chown squid.squid /var/log/squid -R $chown squid.squid /etc/squid -R CONFIGURATION DU SERVEUR SQUID On a reprit la configuration de base de SQUID, définit dans les précédentes parties. On a rajouté ces lignes : # Kerberos auth_param negotiate program /usr/local/squid/libexec/squid_kerb_auth -d -s HTTP/squid.commun.ma-pme.fr auth_param negotiate children 10 auth_param negotiate keep_alive on acl Authenticated proxy_auth REQUIRED http_access allow Authenticated # Interdire tout le monde http_access deny all Dans ces lignes, on crée une ACL (Authenticated) qui oblige l authentification par kerberos utilisant la librairie executable squid_kerb_auth. L option d nous permet de passer en mode full debug et de voir les transactions au niveau de cache.log L option s permet de préciser le principal 12
INSTALLATION DE KERBEROS CLIENT $ aptitude install krb5-config krb5-pkinit krb5-user CONFIGURATION DE KERBEROS CLIENT On copie le keytab généré sur le serveur 2003 sur notre serveur squid On configure Kerberos client par le fichier de config /etc/krb5.conf [libdefaults] default_realm = COMMUN.MA-PME.FR [realms] COMMUN.MA-PME.FR = { kdc = srv2003class } On exporte les deux variables d environnements suivantes : On teste que le protocole kerberos fonctionne : 13
MISE EN PLACE DU CLIENT (CLIENT1.COMMUN.MA-PME.FR) CONFIGURATION DE LA CARTE RÉSEAU Adresse IP: 192.168.25.4 Serveur DNS: 192.168.25.2 (notre serveur 2003) TEST D UN RESOLVE DNS DU SERVEUR SQUID On teste un resolve dns du serveur proxy squid afin de vérifier de la bonne configuration du dns. Cette étape est importante pour la bonne fonctionnalité du protocole Kerberos, étant donné que le service principal est régler grâce l host. 14
CONFIGURATION DE INTERNET EXPLORER On règle le proxy : Adresse: squid.commun.ma-pme.fr Port: 3128 TEST DU PROTOCOLE KERBEROS Le protocole Kerberos est mis en place et fonctionne parfaitement : on peut désormais payer nos impôts grâce à notre ticket Kerberos : 15
Grâce à l outil KERBTRAY.EXE, on peut voir le ticket sous le client : Sur le serveur SQUID, dans le fichier de log cache.log on peut retrouver les différentes transactions effectué par la squid_kerb_auth 16
ANALYSE DU TRAFFIC RÉSEAU TRAFFIC AVEC COMME SOURCE LE CLIENT (192.168.1.4) tcpdump -XX -s0 -i eth0 src net 192.168.25.4 On reconnaît l authentification negociate : 17
TRAFFIC AVEC COMME SOURCE LE SERVEUR SQUID tcpdump -XX -s0 -i eth0 src net 192.168.25.3 Vers le serveur 2003 (192.168.25.2) 18
Vers le client (192.168.25.4) 19
TRAFFIC DU SERVEUR WINDOWS 2003 (192.168.25.2) Vers le serveur squid On voit transiter le site web demandé du client entre le serveur 2003 et le proxy squid. Tous ses échanges nous montrent que les échanges entre les différents postes : client, serveur AD, serveur Proxy s effectue correctement et correspond à la thérorie CONCLUSION On a réussit à mettre en place une solution SSO, Kerberos, utilisant un service KDC intégré au contrôleur de domaine de notre serveur Windows 2003. Cette solution fut assez compliqué à mettre en place mais reste une solution envisageable pour notre pme. L inconvénient majeure est la difficulté de mise en place pour chacune des applications voulant utilisé cette solution SSO. L étape suivante pour améliorer la solution serait de remplacer le service KDC (du contrôleur de domaine) par un serveur extérieure (type MIT ou Heimdal). Cette solution permettrai en cas d indisponibilité du contrôleur de domaine de maintenir l authentification. Cependant cette solution demanderait d installer des outils supplémentaires sur les postes clients. 20
Conclusion L utilisation d un système SSO (single Log-On) pour la PME est une solution intéressante. Celui-ci permet d éviter de s authentifier une seule fois qu elles que soient les applications utiliser. Ainsi, ce système simplifie la vie des utilisateurs, employés de la pme, en ne multipliant pas les accès aux applications, car une fois authentifié, on peut lancer toutes les applications sans remettre de mot de passes. Dans ce dossier, nous avons mis en place 2 solutions SSO : KERBEROS et NTLM. KERBEROS nous a permit, grâce à travers un système de ticket, de mettre en place un service SSO. On a pu relevé plusieurs exigences : Sécurité du réseau Selon les versions du serveur Active Directory le chiffrage par défaut est différent, dans notre maquette nous avons réglé notre protocole KERBEROS avec un cryptage RC4, mais on aurait pu régler en cryptage DES. Fiabilité Transparence pour l utilisateur: à l ouverture de session, l utilisateur est authentifier pour toutes les applications utilisant le système SSO KERBEROS Evolutif en terme d architecture Difficulté de mise en place: le système est assez compliqué à mettre en place et nécessite que chaque application gère le protocole kerberos Pour l architecture de la PME, la solution SSO,KERBEROS, peut être une solution convenable. Mais nous avons relevés 2 inconvénients majeures lors de nos tests. La mise en place de ce protocole pour chacune des applications client peut se relever une tâche assez difficile pour l administrateur. D autre part, ce système nous a paru assez lent avec une latence assez marqué du navigateur IE7, ce point reste à vérifier à l aide d indicateurs. NTLM nous a permit de mettre en oeuvre une authentification par challenge, le système d exploitation gère ce type d authentification nativement ce qui en fait un système très simple à mettre en oeuvre du coté client. Sécurité du réseau NTLM est nativement chiffrée mais qui aujourd hui n est plus considéré comme un chiffrement sur. Cependant pour une pme ce niveau de sécurité peut être considéré comme suffisant pour une PME. (Un complément à ce dossier sur la gestion de risque/cout peut être nécessaire pour approfondir le sujet) Fiabilité & Transparence Comme Kerberos, NTLM assure une authentification unique à l adhésion au domaine Evolutif & Montée en charge Le peu de trame réseaux pour l identification peut permettre une montée en charge importante et le support de nouveaux utilisateur. Pour l architecture de la pme, la solution NTLM est une bonne solution car facile à mettre en oeuvre et nativement supporté par windows (authentification intégrée) ce qui en fait un choix très intéressant. Selon nous, aujourd hui la meilleur solution semble être basée sur NTLM pour sa simplicité et sa montée en charge, à moyen terme long terme, une solution plus construite et plus ouverte comme Kerberos sera sans doute plus indiqué. 21
Bibliographie Source Internet Site officiel Squid : http://www.squid-cache.org/ Wiki Squid : http://fr.wikipedia.org/wiki/squid Wiki NTLM : Kerberos Technique : http://technet.microsoft.com/fr-fr/library/bb742433(enus).aspx http://grolmsnet.de/kerbtut/ http://klaubert.wordpress.com/ http://msdn.microsoft.com/library/default.asp?url=/libr ary/en-us/dnsecure/html/http-sso-1.asp http://fr.wikipedia.org/wiki/ntlm Wiki Kerberos : http://fr.wikipedia.org/wiki/kerberos Installation de Kerberos : http://lfs.traduc.org/view/blfs-5.1-fr/postlfs/mitkrb.html Activation NTLM v2 : http://support.microsoft.com/kb/239869/fr NTLM & Firefox : http://wiki.ovidentia.org/index.php/authentification_par _identifiant_nt mod_ntlm : http://modntlm.sourceforge.net/ Squid : http://okki666.free.fr/docmaster/articles/linux073.htm Kix : http://www.kixtart.org/ 22
Annexe smb.conf pour NTLM [global] workgroup = PME netbios name = debian server string = Proxy (Samba Server) load printers = no log file = /var/log/samba/log.%m max log size = 500 password server = srv2003class security = domain winbind separator = / encrypt passwords = yes winbind cache time = 15 winbind enum users = yes winbind enum groups = yes winbind use default domain = yes idmap uid = 10000-20000 idmap gid = 10000-20000 local master = no os level = 233 domain master = no preferred master = no 23
squid.conf ############################ # Squid Configuration File # ############################ # Port d'ecoute de SQUID http_port 3128 # Port sur lequel le cache peut être interroge par un cache fils ou voisin, cas d'une hierarchie icp_port 3128 # Ne pas utiliser le cache pour.cgi et? hierarchy_stoplist cgi-bin? acl QUERY urlpath_regex cgi-bin \? no_cache deny QUERY # Taille maximum du cacher en memoire vive cache_mem 20 MB # Interval maximum des objets stockes dans le cache minimum_object_size 0 MB maximum_object_size 15 MB #################################################################### #### ### Dossier du Cache ### On peut definir plusieurs repertoires #### #################################################################### # Repertoire dans lequel le swap de cache s'effectue (1go en Cache) cache_dir ufs /var/spool/squid1024 16 256 # Format des logs # on = format standard CLF # off = format de logs de squid emulate_httpd_log off # Duree de la session authentifiee (ici: 2 heures) refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern. 0 20% 4320 #################################################################### ####### ## DNS #################################################################### # Cela d'utiliser dns1 et dsn2 au lieu d'aller chercher ces dns dans le fichier /etc/resolv.conf dns_nameservers 192.168.1.1 192.168.1.2 # Evitez les longs timeout dns_timeout 2 minutes #################################################################### 24
#################################################################### #### ### ACL (Regles d'acces au cache dit access-list) ### On peut definir plusieurs repertoires #### #################################################################### # Liste des acl par defaut -> A conserver acl all src 0.0.0.0/0.0.0.0 acl manager proto cache_object acl localhost src 127.0.0.1/255.255.255.255 acl to_localhost dst 127.0.0.0/8 # Ces regles évitent qu'un utilisateur mal intentionné n'exploite votre proxy à la maniere d'un tunnel pour requérir des services interdits acl SSL_ports port 443 563 # https, snews acl Safe_ports port 21 70 80 210 280 443 488 563 591 777 1025-65535 acl CONNECT method CONNECT http_access deny!safe_ports http_access deny CONNECT!SSL_ports #Autoriser tout le monde à utiliser le cache http_access allow all # Autorise les reponses pour tout le monde (par defaut) http_reply_access allow all # Autorise le protocole icp pour tout le monde (par defaut) icp_access allow all coredump_dir /var/spool/squid # Limitez la taille des requêtes pour restreindre les risques d'attaques de type "refus de service". request_header_max_size 10 KB request_body_max_size 64 KB ##### Administration ######## # Nom que renvoi squid lorsqu'il est interroge de l'exterieur visible_hostname proxy.commun.ma-pme.fr 25