Validation des acquis- mot de passe: 423DTNZdg

- Systeme de gestion de sécurité et des droits d’accès à une ressource:

- AAA:
o Authentication:
 Prouver l’identité de l’utilisateur
o Autorisation:
 Vérifier si l’utilisateur identifié dispose des autorisations nécessaires pour
accéder à la resource
o Accounting:
 Traçabilité et journalisation de tout ce qui est effectué sur la resource.

- Exemple ubuntu:
o Execution d’une commande en tant que root:
 Amine$ sudo ls  vérifier si amine peut exécuter certaines
commandes en tant que root
o Mot de passe de amine qui doit être saisi  si c’est le bon
mot de passe  authentication réussie (1er A:
Authentication)
o Après l’authentification  est-ce que Amine a le droit
d’exécuter la commande ls en tant que root??  (2ème A:
Autorisation)
o Que ce soit utilisateur autorisé ou pas : la
tentative/connexion sont journalisées  tout est enregistré
dans les logs de linux

- Créer un utilisateur:
o Debian/ubuntu: useradd et adduser
 adduser <nom>
 Passwd <nom>
 su <nom> :
o switch user : se connecter à l’utilisateur
 la liste des utilisateurs est dans le fichier /etc/passwd (lire le fichier:
cat/less/…)
 sudo ls et vérifier si l’utilisateur créé peut exécuter la commande ou pas??
o Centos: useradd
 Authentication de user  A: Authentification
traçabilité
Bien authentifié mais il n’a pas le droit d’exécuter la commande
en tant que root  A: Autorisation

o Liste des utilisateur: /etc/passwd

o Liste des groups: /etc/group

- Système d’Information:
o L’esemble des outils mises à la disposition de l’entrperise pour collecter, stocker et
traiter les données de l’entreprise:
 Des outils matériels pour stockage
 Des outils softwares pour collecter les données (ssh/canaux sécurisés/
logs)
 Des mécanismes de traitement et generation de l’information utile :
 Envoi de l’information utile à la personne concerne
o Cookies:
 Des identifiants de session en cache pour une reconnexion  obligatoires
 D’autres paramètres identifiant / définissant les habitudes des utilisateurs
 optionnel
- Affaire de facebook: great hack
 - Directeurs: prendre la bonne
decision suite aux informations
retournées par les gestionnaires

- Gestionnaires: traiter la données

pour extraire l’information utile :
statistiques/vulnérabilités/mitigation

- Développeurs: collecter et
stocker les données

- Système d’Information:
o L’esemble des outils mises à la disposition de l’entrperise pour collecter, stocker et
traiter les données de l’entreprise:
 Des outils matériels pour stockage  disques et bases de données
 Des outils softwares pour collecter les données (ssh/canaux sécurisés/
logs)
 Des mécanismes de traitement et generation de l’information utile :
 Envoi de l’information utile à la personne concerne
 Sécurité du systeme d’information SSI:
o Sécurité physique des disques de stockage
o Sécurité logicielles:
 Pare-feu
 Proxy:
 Antivirus
 Systèmes de detection d’intrusion: IDS/IPS/IDPS:
 IDS: Intrusion Detection System
o Systeme passif permettant de détecter une éventuelle intrusion
et alerter l’administrateur (logs/mails/…)
 IPS: Intrusion Prevention system
o Systeme actif permettant de bloquer une intrusion détecter
(exemple: en cas de ddos : bloquer l’@ip source)
 IDPS: IDS+IPS : alerting et blocage à la fois
 IPS : cisco - Défense en profondeur : plusieurs
mécanismes de protection l’un à
IDS
la suite de l’autre  si l’IPS est
compromise alors il y a une
chance que l’IDS détecte
l’intrusion

- Ces solutions de sécurité vont garantir:

o Disponibilité
o Intégrité
o Confidentialité

- Anssi doit fournir une plateforme de signalements d’incidents criminels

o PHAROS: Plateforme d’Harmonisation, d’Analyse, de Recoupement et d’Orientation
des signalement

- DNS: Domain Name Server

o Conversion URL/IP
- Reverse DNS: conversion IP/URL

- Rgpd:

o DPO: Délégué de protection des données

 Sessions et chartes de sensisiblisation à la sécurité
 Il est à jour/lié à l’ANSSI

- Analyse de risqué:*
o QCM complet à envoyer à l’entreprise :
 Données
 SI
 Sécurité
 RGPD
o Risques rencontrés après QCM et analyse technique:
 Gravité du risqué: négligeable ou critique
 Vraisemblance: probabilité d’occurrence du risqué
  Gravité X vraisemblance : risques à prioriser en termes de gravité
et/ou vraisemblance

- Intégrité: détecter si le message ait été modifié ou pas ???  hachage : empreinte unique
de chaque objet/message/fichier
 Scenario:
 Eric envoie le message “bonjour” chiffré avec une clé de sécurité à
Anthony : le message devient azerty123 et son empreinte
H1=acd5ef
 L’homme du milieu (amine) intercepte le message et l’empreinte
o Il ne peut lire que : H1 et azerty123
 Il peut :
 Modifier le message crypté:
o Azerty0000123
 Modifier le hachage:
o L’intrus modifie H1 par le hachage
de la chaine “Bonsoir” = H2
 Anthony reçoit:
o Azerty0000123
o H2 = H(bonsoir)
 Déchiffrer (Azerty0000123) = chaine2 ou illisible
 Empreinte(chaine2) ???====???H2
o 2ème cas:
 L’homme du milieu (amine) intercepte le message et l’empreinte
o Il ne peut lire que : H1 et azerty123
 Il peut :
 Modifier le message crypté:
o Bonsoir
 Modifier le hachage:
o L’intrus modifie H1 par le hachage
de la chaine “Bonsoir” = H2
 Anthony reçoit:
o Bonsoir
o H2 = H(bonsoir)
 Déchiffrer (Bonsoir) = chaine2 ou illisible
 Empreinte(chaine2) ???====???H2

- ISO 2700x : standardization des mécanismes de sécurité et politiques à adapter

o ISO27002: définit les politiques de sécurité et bonnes pratiques
- EBIOS: méthode d’analyse de risqué définie par l’ANSSI
- MEHARI: analyse de risqué USA (mondiale)
- Autorisations:

o Règles selon les rôles: Prop/groupe/autres

o Règles ACL:
 Access List Control
 Règles d’accès directs à une entité spécifique (utilisateur/groupe)
- Traçabilité:
o Journalisation des connexions
o Linux: syslog : /var/log/

- Last: historique des sessions connectés sur le pc:

- Lastb: l’historiques des connexions échouées (mot de passe/ droits/…) : last bad
 o Attaques contre les saisies des mots de passe:
 Brute force  toutes les combinaisons ppossible : 10TB
 Dictionnaire  liste prédéfinies de mots de passe.
 Osint : données publiques open source informatiques
 Social engineering: habitudes/quotidien/loisirs/….
 keylogger

- Mots de passe sous linux:

o /etc/passwd: contient la liste des utilisateurs  lisible par tout le monde /
modifiable seulement par root
o /etc/shadow: la liste des hachages des mots de passe (lisible que par root)
 Grain de sel: chaine aléatoire liée au hachage

$6$: algorithme de hachakge utilisé (6: sha512)

 grain de sel (salt)

$H1$ : hachage de (saltmot_de_passe)

- En windows:
o Registres windows: contiennent les paramètres du systeme : comptes/mots de
passe/ sessions/ logiciels par défaut/…
 SAM: Security Account Manager:
 Gestionnaire de sécurité des comptes
o Il contient la liste des mots de passe hachés des utilisateurs
(sans grain de sel)
 Si on utilise un mot de passe trivial alors on peut le
craquer facilement
o Mécanisme d’authentification windows/mot de passe:
 Protocols de connexion sécurisé via remote desktop NTLM: Windows New
 Mécanismes de mot de passe Technology Lan Manager
 Verification et enc as d’oublie

- OTP: One Time Password:

o Un mot de passe à utilizer une seule fois et temporaire (expire sous 15 20 minutes)
 SMS/Mail : achats/accès bancaires
- En machines virtuelles:
o Connexion en NAT:
 Reseau privé entre la machine physique et la machine virtuelle
 La machine windows deviant l’équivalent du modem
 Un reseau cloisonné interne
 Les autres machines du reseau ne peuvent pas pinguer la VM
 Sandbox: une machine virtuelle cloisonnée et isolée du reseau de
prod pour tester des logiciels suspects
o Connexion en bridge (pont)
 Les VMs se connectent sur le modem externe du reseau
 Ca en fait une nouvelle VM du reseau
 Les autres machines du reseau peuvent pinguer la VM
- Changer les connexions des VMs en bridge:
o Définir la connexion en bridge
o Clic droit sur la connexion : modifier les connexions:

 Sélectionner votre reseau

 Onglet ipv4
 Selection manuelle:

o Ajouter une @ip manuelle:

 192.168.1.<suffixe_windows +150>
 Masque: 255.255.255.0
 Passerelle: 192.168.1.254
 Dns: 8.8.8.8
 
o Sudo apt install *openssh*
o Systemctl restart ssh

- Authentication forte:
o Utilizer plusieurs systèmes d’authentification:
 Code pin
 HSM: Hardware security Machine:
 Clés usb contenant un systeme de générateur de mot de passe
synchronusé avec un serveur distant (expel: clé privée)
 OTP: One Time Password:
 Attaques ciblées contre le OTP:
o Chaque telephone dispose de:
 IMEI: identifiant unique matériel
 Des identifiants du reseau: HLR + VLR
 HLR: Home Location Register :
o Identifiant global de la SIM auprès
des antennes de relais GSM
 VLR: Visitor Location Register:
o Identifiant dépendant de l’antenne
de relais
 o L’attaquant sniffe le reseau cellulaire; intercepte les
paramètres de l’utilisateur:
 Via un smartphone rooté : il modifier ses
IMEI/HLR/VLR pour les rendre identiques à la
victim pendant quelques seconds (pendant ce laps
de temps, la victim ne sera plus identifiée dans
cette region):
 Il amplifie son signal via une antenne
reseau:
o Le smartphone du hacker avec le
signal amplifié sera alors détecté en
premier lieu et contacté au lieu de
celui de la victim  le hacker reçoit
le OTP

- Non repudiation: l’émetteur ne peut pas nier avoir envoyé le message (juridique)

- SSO: Single Sign On:

o Utiliser un seul mot de passe pour accéder à un ensemble de ressources

o Connexion centralisée:
 Google: la connexion à google permet d’accéder à l’ensemble de ses
services (mail,youtube,play store, drive,maps,…..)
 Entreprises:
 Accéder via vpn au reseau de l’entreprise:  via proxy : serveur
relais pour assurer la redirection et connexion sécurisée
o En interne, se connecter via SSO à l’ensemble de ses
services
o SSO avec agent:
 Serveur contenant les services/ressources
 Serveur contenant les utilisateurs autorisés  Agent
 Lors de la connexion:
o Le navigateur se connecte à l’agent (serveur
d’authentification)
 Annnuaire d’utilisateurs autorisés  Active
Directory (Microsoft) / LDAP: linux
o Vérifie auprès de lui l’identité de l’utilisateur et les
ressources à lesquelles il a accès
 Le serveur fournit un ticket d’accès à l’utilisateur
pour les services autorisés
 o Selon le ticket fourni, l’utilisateur est redirigé vers les
services autorisés.
o SSO sans agent: un seul serveur contenant la base de données des utilisateurs + les
services.

- PAM : Pluggable Authentication Modules:

o Librairies d’authentification de linux
 Règles de definition des mots de passe
 Librairies à respecter lors de la definition des mots de passe dans les
environnements linux
 Il suffit de modifier les règles de mot de passe d’une librairie du
PAM pour que ça affecte un ensemble de services et programmes
qui vont faire appel à cette librairies
- PAM définit les liaisons service et librairies:
o Des règles à définir dans un dossier /etc/pam.d/: (règle par ligne)
 Service concerne: ssh/login/ftp
 Librairie liée:
 Auth: gestion des mots de passe d’accès
 Account: gestion du compte (limites de modification de mots de
passe, temps d’inactivité, nombre de tentative avant blocage)
 Password: règles du mot de passe (longueur minimale,nombre
minimal de majuscules,minuscules,….)
 Session: délai autorisé de connexion pour un utilisateur
 Règle de liaison entre service/librairie:
 Si la liaison est bloquante ou pas???

Database_lib règle l’ensemble des fichiers dans les librairies

 Règles:
 Required/requisite sont bloquantes :
o Required peut appeler d’autres libriaires/fichiers/modules
o Requisite ne fait pas appel à d’autres modules ou services
 Include /etc/pam.d/passwd  faire appel aux règles définies dans
ce fichier externe
 - Kerberos: serveur AAA
o Serveur de gestion d’accès aux ressources d’entreprises et il contient 3 sous-
serveur:
 Un serveur d’authentification: vérifier l’identité auprès d’un annuaire
interne et fournir un jeton d’accès à la ressource
 Un serveur d’autorisation: le jeton fourni permt d’accéder aux ressources
autorisées
 Un serveur de journalisation: traçabilité des connexions

- La gestion de la robustesse du mot de passe sous linux: /etc/security/pwquality.conf

o Description + paramètres à définir (il faur décommenter la ligne du parameter):

 Description: longueur minimale

 Parameter; minlen = 8  min 8 caractères
lcredit : lower credit  nombre de minuscules minimum/maximum:
o lcredit= 5  maximum 5 caractères minuscules
o lcredit= -5  minimum 5 caractères
- ucredit: upper – majuscules
- dcredit : digit – chiffres
- ocredit : other – les caractères spéciaux
- minclass : minimum – types de caractères différents
- maxrepeat : nombre maximal de repetition

- fail2ban : règles d bannissement de connexions distantes:

o fichier de config: /etc/fail2ban/fail2ban.conf
 logtarget = /var/log/fail2ban.log
o règles de banissement: /etc/fail2ban/jail.conf
 différentes sections définies par : [nom]
 règles pour ssh/telnet/ftp/…
 - le fichier de configuration de ssh est diffrent selon les distributions:
o ssh.conf
o sshd.conf
o ssh_conf
o sshd_conf
o ssh_config
o sshd_config

- dans linux:
o chaque fichier F1 appartient à :
 un propriétaire: Amine (rwx)
 un groupe: orsys (r--)
 le reste fait partie des others (---)
 chown: change owner : changement de propriétaire du fichier
Droits définis selon le role de o chown Nasser F1  Nasser devient le nouveau
l’utilisateur : prop/group/others propriétaire de F1
 si amine appartient au groupe du fichier  r--
sinon rien
 chgrp: change group : changement du groupe du fichier
o chgrp inetum F1  inetum devient le nouveau groupe de
F1
RBAC: Role Based Access Control  les members du groupe orsys auront r—s’ils
appartiennent à inetum sinon rien

- RBAC: des droits définis selon le type/niveau/role de l’utilisateur

- NB: chown

o Chown nvx_prop:nvx_group F1
 Chown Nasser F1  changement du propriétaire seulement
  Chown Nasser:inetum F1  le nvx prop est Nasser/ le nouveau groupe et
inetum
 Chown :inetum F1  changer juste le groupe en inetum

- Utilisateurs:
o Utilisateurs créés
o Utilisateurs systems  les utilisateurs créés par des processus
 Exemple: on installe oracle:
 Le paquet oracle crée un utilisateur et un groupe oracle:
o L’utilisateur oracle n’a pas de session graphique (nologin)
o Dans linux, toute personne qui veut utilizer oracle doit être
dans le groupe oracle créé  un groupe créé juste pour le
contrôle d’accès

- Suite à un incident cybercrime, on fait appel à un auditeur:

o On affecte des droits nominatifs à l’auditeur concerné
 DAC: Droits d’accès discrets (Discretionary Access Control)
 Affecter à un utilisateur spéciifique certains droits (ou les lui
revoquer)
o F1:
 Prop: Nasser (rwx)
 Groupe: Inetum (r--)
 DAC  Eric qui fait partie de inetum va
disposer des droits rwx
 DAC  Anthony qui fait partie de inetum
n’aura aucun droit (---)
 Sous linux: ACL  droits à affecter à une entité
spécifique (user ou groupe)
o Exceptions aux RBC  plus prioritaire
- MAC: Mandatory Access Control
o Des droits d’accès contrôlés par le noyau du système et qui vont au delà du root
 1er exemple – linux:
 Attributs des fichiers : restrictions d’utilisation des fichiers :
immutable (non modifiable) / non écrasable / non supprimable/…
o Lsattr F1 : lister les attributs de F1

 Chaque tiret represente un attribute

 Man chattr : liste des attributs existants
  Attributs: (même root est concerné)
 i: non modifiable
 u: undeletable : on peut le modifier mais
pas supprimer (rm ne marche pas)
o Chattr : change attribute
 Chattr +i f1  ajouter i
  Chattr -i f1  enlever i

 Chattr =u f1  seulement l’attribut u (non

supprimable)

 Avec le u active, personne meme root ne peut pas

le supprimer

- Exemple 2 : attribute a  pas écrasable avec “>”

- Roles – Discrets – MAC : ce sont des droits qui se basent sur des valeurs prédéfinies:
o Role(utilisateur) = owner Tests selon les valeurs de certains
o Nom(user) = amine éléments et qui sont appelés des attributs

o Autoriser la lecture si: role(user)= owner ou bien nom(user)=amine

 Gestion de droits d’accès basée sur les attributs: ABAC : Attributes based
Access Control
 A défini l’attribut utilisé (R/D/M/….)
  Analogie ABAC – RBAC:
o Sujet: utilisateur
o Resource : fichier/rep
o Action: rwx

- Exemple:
o Cat /etc/shadow
 Nom(sujet)= amine et nom(resource)= /etc/shadow et identif(action)
=read  decision : accepté ou pas ??

- Architecture:
o Suite à une action demandée:
 Consutlation de centre de prise de decision (PDP)
 PDP vérifie la base de données des règles (PIP)
o En analysant les règles, le PDP prend la decision necessaire
o Il fournit le résultat au PEP : IHM avec l’utilisateur et qui
affiche le résultat (accepté ou interdit)
- Règles  PIP:
o Nom(sujet)= amine ou groupe(sujet)=orsys et id(action)=read
o  que si read (pas de write) et seulement pour amine ou les utilisateurs du
groupe orsys

- Recapitulative:
1. Utilisateur saisit sa requête via le PEP
o PEP: frontend  interface de saisie de requete de l’utilisateur et de reception de la
réponse:
 Linux: terminal
 Windows: powershell
 Web: page d’authentification
2. Le PEP transmet la requête au PDP:
a. PDP: backend : communique avec la base de données des règles créées
3. PDP vérifie les valeurs des attributs reçus et les compare avec la PIP:
a. PIP: base de données des règles enregsitrées
4. Le résultat de la comparaison du PDP est envoyé au PEP
5. Le PEP affiche le résultat à l’utilisateur (connexion réussie ou bien erreur et échec)
- Journalisation & traçabilité:
o Une trace de toute tentative/connexion effectuée
o Accessible facilement et de manière optimisée:
 Un log par période (par jour, semaine,mois)

- Il faut que le serveur de journalisation soit un serveur séparé et qui synchronise tous les
logs en temps reel:
o Une attaque organisée se fait sur des étapes:
1.Detection de vulnérabilité
2.Exploiter la vulnérabilité et gagner l’accès root
3.Creation d’un backdoor: un deuxème accès au système
pirate
4.Effacer les traces de l’intrusion:
1. Manipuler le fichier journal:
a. Sous linux: accéder au /var/log/messages
et supprimer les évènements qui
concernent l’intrusion
b. Solution contre l’effacement des traces:
serveur centralisé de journalisation:
i. Serveur à part qui contient des
systems de collecte de logs depuis
toutes les machines de
l’entreprise:
1. Le serveur écoute en temps
reel le /var/log/messages
 synchronizer en temps
reel le contenu du log  le
contenu sera mis à jour sur
le serveur avant sa
modification  si le hacker
modifie les évènements
locaux, le serveur sera tjs à
jour et contenant l’attaque

- Serveur de logs centralisé est appelé : SIEM: splunk / QRadar:  prevention contre les
attaques
o Collecter en temps reel les logs  détecter toute intrusion en temps réel
o Générer des alertes et des dashboards  alertes : reactions suite à une intrusion
 Les solutions de AAA: un serveur / resource à part pour la journalisation:

- Définir l’attribut “a” sur le log  on peut seulement ajouter du contenu sans en écraser si
supprimer
- Le log recueille : les évènements :
o Un évènement est automatiquement horodaté

<date> <heure> <machine_utilisé> <processus_commande_lancée>

- Environnements centralisées:
o Un serveur central contenant les utilisateurs autorisés et fournissant des tickets
d’accès et de service.

- LDAP:
o Annuaire linux contenant les utilisateurs autorisés à accéder au SI de l’entrperise
(son equivalent sous windows est AD):
 Permet de définir des règles d’accès aux ressources pour chaque utilisateur:
 Reconnu ou pas (il faut que l’utilisateur soit dans l’annuaire)
 Autorisé ou pas à accéder à la resource.
o Exemple: myorsys.orsys.fr
 Une fois l’utilisateur ayant rempli la page d’authentification:
 Le serveur ldap se compose de 3 sous dossier:

fr

Annuaire : orsys.fr  utilisateur accepté sur orsys

orsys et autorisé sur myorsys.orsys.fr et
touchlite.orsys.fr

myorsys touchlite

Un utilisateur autorisé seulement Un utilisateur autorisé seulement

dans myorsys.orsys.fr dans touchlite.orsys.fr

- Organization : orsys
- LDAP:

o Un environnement SSO:
 Un utilisateur ajouté dans orsys est autorisé dans myorsys.orsys et dans
touchlite.orsys
o Un environnement PKI:
 Chiffrement asymétrique: clé privée/publique:
 PKI: architecture à clé publique  magasin de clé publiques
 Le certificate SSL/TLS : un systèment d’authentification du serveur
et client si besoin.
o TLS = SSL 3.0
o Un certificate SSL contient les:
 Clé publique du serveur
 Données du serveur : verifies par une autorité de certification de l’état
(ANSSI)
 Données du certificate: numéro de série, version,…
- Chaque serveur doit générer son certificate TLS:
1. Le serveur génère sa paire clé publique/privée
2. Il envoie à l’autorité de certification AC (qui s’occupe de la verification des
données envoyées): ANSSI
a. Clé publique
b. Nom du domaine
c. @ip
d. Pays
e. Localization
f. Informations privées pour verifier l’identité du propriétaire
3. L’AC vérifie les données reçues et génère le certificate:

Informations du serveur + clé

publique

Données du certificat : version/

identifiant/ algorithme ahchage
utilisé / date d’expiration

Informations de l’AC: identité + clé

publique + signature numérique

Signature du certificate = H(des

blocs précédents)
 - Client veut se connecter au serveur via le certificate https://orys.fr

AC client serveur

https://orsys.fr

Certificat du serveur

Si le certificate est Date d’expiration

toujours valide ou pas ??? + informations de
l’AC

Certificat valide
Clé de session aléatoire
basée sur l’horodatage / Ksession chiffrée par la clé
infos clients/ infos serveur publique du serveur
Ksession Déchiffrer
la clé

Session chiffrée symétriquement par

Ksession-

- LDAP:
o Annuaire d’authentification des utilisateurs : SSO et PKI (certificats)
- Serveurs AAA:
o Kerberos : authentification / autorisation d’accès / traçabilité
 Authentification:TGS: ticket Grant Service : l’utilisateur est authentifié et
peut accéder pendant un laps de temps aux ressources autorisées
 Autorisation: l’utilisateur envoie son TGS au serveur; ce dernier vérifie le
TGS contenant les ressources autorisées et la compare avec la demande de
l’utilisateur
 Selon le TGS et la demande; le serveur autorise l’utilisateur à
accéder ou pas à la resource
o Traçabilité: le serveur finale traçant toutes les actions de
l’utilisateur
- Plusieurs entreprises disposent de leur propre serveur d’authentification centralisé (CAS)
-
- SAML: la syntaxe de definition des règles de sécurité à transmettre via les reseaux
o Transmis via un protocole de communication proche du ssh.
- RADIUS = AAA pour les paiements en lignes et sites bancaires:
o On peut obliger la double authentification par certificate : client et serveur
envoient leurs certificats
o Radius est utile pour se connecter aux environnements de tunelling sécurisé via
VPN:
- 802.1x:
o Permettre une connexion distante sécurisée pour tout reseau (wifi, ethernet,…)
 Wifi:
 Wep: mot de passe – vulnérable
 Wpa2- plus sécurisé se basant sur des algorithms d’expansion et
division de clé et n’est attaquable que par dictionnaire.
 Wpa- tkip: wpa + certificate : necessaire pour les entreprise

- Wifi vulnerable face aux attaques:

o Honeypot:
 Creation d’un point d’accès identique à un existant sans mot de passe avec
un signal puissant  tout traffic transite via le point d’accès du hacker
o AP rogue
 Brancher un point d’accès wifi au bureau
 Accéder à ce wifi depuis l’extérieur pour s’infiltrer dans le reseau interne de
l’entreprise

- Règles LDAP:
o Target: cible  resource
o Permission: droit concerné  lecture/écriture
o Bind rule  Id de la règle
 Les règles dans LDAP sont définies dans des sections:
 Global  tout l’annuaire (tous les utilisateurs)
 Nom_user  règles d’un utilisateur ou groupe
 Sections définies : ssh/telnet/…
 Anonymous  les utilisateurs anonymes (invites)

- En bas niveau:
o Le client se connecte  fait appel à la méthode bind du ldap
 Bind contient les règles d’authentification (mot de passe, certificate,
double ou pas)
o Le client se déconnecte  la méthode unbind
  Action de déconnexion

- Openssl: bibliothèque de commandes pour créer des paires de clé publique/privé et

certificats TLS

- Samba:

o Protocole de partage des ressources entre windows/linux:

 Ensemble de services:
 Conversion entre utilisateurs windows/linux
 Conversion du pilote windows en format linux  lu et compris par
l’environnement linux
 Une url d’accès (ip d’accès à la resource physique partagée)
o Services/processus de samba:
Authentification +  SMBD: service contenant l’annuaire des fichiers et utilisateurs partagés avec
autorisation windows  annuaire d’authentification des utilisateurs windows et linux
 NMBD: les requetes autorisées sur les ressources et leur conversion en linux

 Winbind: canal de communication sécurisé entre linux/resource_windows

- Vulnérabilités relevées pour samba:

o CVE: Common Vulnerability Enumeration
 Les vulnérabilités connues et remontées par les utilisateurs
 cve.mitre.org
 vulnérabilités du protocole winbind permettant d’accéder à des
parties protégées
 vulnérabilités liées au serveur d’authentification permettant
d’injecter du code et extraire des données privée (injection SMB
 voler certaines informations en saisissant des requetes dans un
formulaire)