Guide pour comprendre : Réseaux et Sécurité
Guide rédigé par Mattéo Boissière.
Merci à Jade “Luapix” Guiton, Baptiste “curlyboi” Fournier et Thomas “SLF” Sainrat pour leur
expertise informatique.
Ce guide n’a pas l’ambition d’être exhaustif vis-à-vis du cours, mais plutôt de présenter des méthodes
pour les questions les plus récurrentes en examen, et aider à la validation ceux en difficulté.
Table des matières
1 Introduction
2
2 Réseaux
2.1 Rôles des couches OSI . . . . . . . . . . . . . .
2.2 Paquets . . . . . . . . . . . . . . . . . . . . . .
2.3 Peering et transit . . . . . . . . . . . . . . . . .
2.4 Calculs de délais . . . . . . . . . . . . . . . . .
2.5 Modes de communication . . . . . . . . . . . . .
2.6 Calculs liés à un sous-réseau IP . . . . . . . . .
2.7 Algorithmes de routage . . . . . . . . . . . . . .
2.8 MTU et fragmentation . . . . . . . . . . . . . .
2.9 Le protocole ARP . . . . . . . . . . . . . . . . .
2.10 Le protocole IP . . . . . . . . . . . . . . . . . .
2.10.1 Propriétés du protocole IP . . . . . . . .
2.10.2 Protocole de contrôle de l’IP . . . . . . .
2.10.3 Le protocole IPv6 . . . . . . . . . . . . .
2.11 Le protocole DHCP . . . . . . . . . . . . . . . .
2.11.1 Principe . . . . . . . . . . . . . . . . . .
2.11.2 Requêtes . . . . . . . . . . . . . . . . . .
2.12 Les ports TCP/UDP . . . . . . . . . . . . . . .
2.13 Le protocole UDP . . . . . . . . . . . . . . . . .
2.14 Le protocole TCP . . . . . . . . . . . . . . . . .
2.14.1 Définition d’un socket TCP . . . . . . .
2.14.2 Propriétés et garanties assurées par TCP
2.14.3 Fenêtre d’émission dans une TCP . . . .
2.15 Le protocole HTTP . . . . . . . . . . . . . . . .
2.15.1 Requêtes HTTP usuelles . . . . . . . . .
2.15.2 Propriétés des requêtes HTTP . . . . . .
2.16 Cookies . . . . . . . . . . . . . . . . . . . . . .
2.16.1 Utilisation d’un cookie . . . . . . . . . .
2.17 Spécification de protocoles . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
2
2
3
3
3
4
4
4
4
4
4
4
5
5
5
5
5
5
5
5
6
6
6
6
6
6
6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
7
7
7
8
8
8
8
8
9
9
9
9
9
9
10
10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Sécurité
3.1 Les propriétés ≪ fondamentales ≫de la sécurité . .
3.2 Propriétés de diverses formes d’attaque . . . . . .
3.3 Sécurisation d’un système d’informations . . . . .
3.3.1 Permissions UNIX . . . . . . . . . . . . .
3.3.2 Pare-feu . . . . . . . . . . . . . . . . . . .
3.3.3 VPN . . . . . . . . . . . . . . . . . . . . .
3.3.4 Proxy . . . . . . . . . . . . . . . . . . . .
3.4 Injections SQL . . . . . . . . . . . . . . . . . . .
3.4.1 Comment fonctionne une injection SQL . .
3.4.2 Comment se protéger d’une injection SQL
3.5 Méthodes de chiffrement . . . . . . . . . . . . . .
3.5.1 Propriétés d’une méthode de chiffrement .
3.5.2 Chiffrement par enchaı̂nement des blocs ou
3.6 Cryptographie symétrique et asymétrique . . . . .
3.6.1 Cryptographie symétrique . . . . . . . . .
3.6.2 Cryptographie asymétrique . . . . . . . .
3.6.3 Certificats . . . . . . . . . . . . . . . . . .
3.6.4 Combinaison symétrique + asymétrique .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Cipher Block Chaining
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
(CBC)
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.7
Attaques de logiciels malveillants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.1 Fonctionnement d’un ver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7.2 Fonctionnement d’un path traversal . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Le mot de la fin
1
10
10
10
10
Introduction
L’examen final du cours de Réseaux et Sécurité a la réputation d’être chaque année un QCM évaluant des
connaissances assez spécifiques sur le cours. De plus, les questions qui tombent se retrouvent souvent d’une
année à l’autre. Ainsi, cette fiche a été rédigée ≪ à l’envers ≫ : au lieu d’essayer de synthétiser le cours (aux
slides quelquefois très longues et détaillées pour pas grand-chose...), j’ai examiné ce qui est déjà tombé à
l’examen final les années passées, et tenté d’expliquer le nécessaire pour comprendre ces concepts.
Tout cela, je n’aurais pu le faire sans de gentils VRgens à qui j’ai posé une multitude de questions pendant
pas mal de temps. Merci beaucoup à eux pour leur patience et leur pédagogie !
NB : Faute de temps, cette fiche est incomplète et il manque tout de même quelques points du cours que
j’aurais aimé expliquer plus. Ainsi, même si j’espère vous aider dans vos révisions, ne basez pas celles-ci
entièrement sur cette fiche non plus...
2
Réseaux
2.1
—
—
—
—
—
—
—
2.2
Rôles des couches OSI
Couche 1 (Physique) - Émission et réception de bits
Couche 2 (Liaison de données) - Livraison des paquets sur un réseau local
Couche 3 (Réseau) - Adresse IPv4, routage et contrôle de trafic
Couche 4 (Transport) - Segmentation de paquets, acquittement (acknowledgement), multiplexage
Couche 5 (Session) - Synchronisation des transactions, ouverture et fermeture de session
Couche 6 (Présentation) - Codage des caractères, compression de données et chiffrement
Couche 7 (Application) - Interface de programmation au niveau de l’application
Paquets
Un paquet, une trame et un datagramme, c’est globalement la même chose : un morceau d’information
qu’on essaie d’envoyer via un réseau. Les notations différentes viennent du fait que, plus on ≪ monte ≫ dans
les couches, plus on ajoute des informations à nos données de bases (on parle d’encapsulation). Il ne faut
donc pas être surpris si on parle de trame dans les couches basses et de datagramme dans les couches
hautes.
2.3
Peering et transit
— Lien de transit - Un opérateur est client d’un autre opérateur, qui lui fournit des routes Internet.
— Lien de peering - Deux opérateurs ont un accord pour échanger du trafic venant de leurs réseaux.
— Opérateurs de niveau 1 - Ils fournissent des liens de transit à d’autres opérateurs. Ils ne paient
pas eux-mêmes des liens de transit, ils n’ont besoin que de liens de peering pour accéder à
Internet.
— Opérateurs de niveau 2 - Ils utilisent à la fois des liens de transit et de peering pour accéder
à Internet. Ils peuvent aussi fournir des liens de transit à leurs clients.
— Opérateurs de niveau 3 - Ils souscrivent des liens de transit auprès d’opérateurs de niveau
1 ou 2. Ils n’utilisent pas de liens de peering et ne fournissent pas de liens de transit.
Intuitivement, les opérateurs de niveau 1 c’est les ≪ gros poissons ≫ genre Orange, Bouygues, etc... alors
que les petits fournisseurs Internet tels que ViaRézo doivent acheter du trafic à un opérateur plus gros.
2
2.4
Calculs de délais
— Temps de transmission - Temps nécessaire pour envoyer tous les bits de données sur le canal.
transmission =
taille des données
débit
— Temps de propagation - Temps nécessaire pour physiquement aller d’un bout à l’autre du canal.
propagation =
distance
vitesse de propagation
En Wi-Fi cette vitesse vaut c, en filaire c’est 0, 7 × c.
— Temps de traitement des données - Temps nécessaire pour gérer les paquets.
traitement = temps total du ping − transmission − propagation
2.5
Modes de communication
Attention à ne pas confondre multicast (plusieurs machines) et broadcast (toutes les machines) !
2.6
Calculs liés à un sous-réseau IP
— Calcul de masque - À la fin d’une adresse IP,
valent 1, et les autres valent 0.
≪
/x
≫
signifie que les x premiers bits du masque
Exemple : le masque de 52.84.91.20/20 est 11111111.11111111.11110000.00000000 en binaire,
c’est-à-dire 255.255.240.0.
— Calcul des adresses dans le sous-réseau - Les x premiers bits de l’adresse sont imposés, donc sont
les mêmes pour toutes les adresses du sous-réseau. Donc si une adresse est donnée, on garde les x
premiers bits intacts, tandis que les bits restants peuvent varier comme on le souhaite.
Exemple : si une adresse du sous-réseau est 52.84.91.20/20, ou encore en écriture binaire
00110100.01010100.01011011.00010100, alors toutes les adresses qui en écriture binaire sont comprises entre 00110100.01010100.01010000.00000000 et 00110100.01010100.01011111.11111111,
c’est-à-dire entre 52.84.80.0 et 52.84.95.255, appartiennent au sous-réseau.
— Calcul de l’adresse de diffusion - Les x premiers bits de l’adresse sont imposés, et les bits restants
sont fixés à ≪ 1 ≫.
Exemple : si une adresse du sous-réseau est 52.84.91.20/20 ou encore en écriture binaire
00110100.01010100.01011011.00010100, alors l’adresse de diffusion s’écrit
00110100.01010100.01011111.11111111 en écriture binaire, ou encore 52.84.95.255.
3
2.7
Algorithmes de routage
— Les algorithmes de type link-state ont un raisonnement global : ils considèrent l’ensemble de
la topologie du réseau dans les calculs. Ainsi, on utilise l’algorithme de Dijkstra qui est plus
adapté pour calculer des plus courts chemins dans cette approche globale.
— Les algorithmes de type distance vector ont un raisonnement local : ils raisonnent de proche
en proche sur les nœuds en incrémentant des ≪ vecteurs de distance ≫. Ainsi, on utilise l’algorithme
de Bellman-Ford qui est plus adapté à l’approche locale.
2.8
MTU et fragmentation
Le MTU (Maximum Transmission Unit) est la taille maximale d’un paquet pouvant être
transmis en une seule fois sur une interface.
Quelquefois, le MTU d’un réseau à traverser est trop faible pour envoyer un paquet en une seule fois, il
faut alors mettre en œuvre une fragmentation. Le paquet est alors découpé en autant de fragments que
nécessaire pour respecter le MTU, envoyés sur le réseau comme des paquets indépendants, et réassemblés
par le destinataire.
2.9
Le protocole ARP
Ce protocole fait le lien entre les adresses IP et les adresses MAC, en utilisant des messages
broadcast. Par exemple, une machine veut faire un ping à une certaine adresse IP dans un sous-réseau.
Le protocole ARP demande à tout le monde ≪ est-ce que tu as cette adresse ? ≫, la machine concernée
répond oui, les autres ne renvoient rien. Ensuite le paquet repasse par la switch, qui va enregistrer l’adresse
MAC associée à l’IP.
2.10
Le protocole IP
NB : Quand on dit
2.10.1
—
—
—
—
—
—
≪
IP ≫, par défaut, on parle du protocole IPv4.
Propriétés du protocole IP
Mode non connecté (pas de lien persistant entre émetteur et destinataire)
Pas de garantie de remise (il peut y avoir des pertes sur le parcours)
Pas de garantie d’intégrité (les données peuvent être altérées sur le parcours)
Pas d’accusé de réception (on ne sait pas si les données sont arrivées)
Pas de garantie sur l’ordonnancement (les paquets peuvent arriver dans le désordre)
Pas de garantie sur un débit minimum, sur une latence minimum, ou sur un chemin
suivi
Le protocole IP est dit en “best effort”, c’est-à-dire qu’il est assez pauvre en fonctionnalités mais au moins
il marche bien.
2.10.2
Protocole de contrôle de l’IP
ICMP (Internet Control Message Protocol) est un protocole envoyant des messages de contrôle, ce qui
permet à IP de fonctionner au mieux. Par exemple ICMP peut avertir une machine lorsqu’un réseau est
injoignable, lorsqu’une route choisie est trop longue, etc. . .
2.10.3
Le protocole IPv6
Avantages par rapport à l’IPv4 :
—
—
—
—
—
L’espace d’adressage est plus grand ce qui permet d’avoir beaucoup plus d’adresses.
Les paquets n’ont pas besoin d’être fragmentés.
La taille de l’en-tête est fixe ce qui est plus simple
La taille de l’adresse du réseau est fixe, ce qui fait que :
Le traitement est beaucoup plus simple pour les routeurs.
Moins important, mais on a aussi :
— Utilisation plus large de la multidiffusion
— Acquisition d’adresses IPv6 automatique
4
2.11
Le protocole DHCP
2.11.1
Principe
Le protocole DHCP permet à un client d’obtenir une adresse IP de la part d’un serveur, puisqu’en pratique
il est très laborieux de configurer manuellement les adresses IP d’un réseau.
2.11.2
Requêtes
— DHCP DISCOVER : le client envoie en broadcast une demande de configuration – l’adresse
source est toujours 0.0.0.0 et l’adresse destination est toujours 255.255.255.255.
— DHCP OFFER : un ou plusieurs serveurs envoient des informations de configuration.
— DHCP REQUEST : le client choisir d’accepter une configuration.
— DHCP ACK : le serveur confirme l’affectation de l’adresse.
Attention : même si le QCM le propose, il n’y a aucune raison d’envoyer une requête ARP auparavant puisque justement on n’a pas d’adresse IP et on cherche à en avoir une !
2.12
Les ports TCP/UDP
Les 1023 premiers ports d’un protocole de transport sont dits ≪ well-known ≫ pour ce protocole. Ils ne peuvent être utilisés qu’avec des privilèges élevés sur le système. Voici les ports utilisés par
certains protocoles usuels :
—
—
—
—
—
—
—
DNS : UDP 53
DHCP : UDP 67 et 68
FTP : TCP 20
SMTP : TCP 25 et 587
HTTP : TCP 80
IMAP : TCP 143
HTTPS : TCP 443
Attention, si par exemple on parle de ports UDP well-known, HTTP n’en est pas un, puisque c’est un
port TCP well-known !
2.13
Le protocole UDP
Propriétés assurées par UDP :
— Protocole best-effort (on envoie les données et on prie)
— Mode non connecté (on n’établit pas de session de communication)
2.14
Le protocole TCP
2.14.1
Définition d’un socket TCP
Un socket est une interface aidant à établir une session de communication via TCP. Pas besoin de rentrer
dans les détails, mais il faut savoir qu’elle est caractérisée par :
—
—
—
—
2.14.2
—
—
—
—
—
—
L’IP locale
L’IP de destination
Le port local
Le port de destination
Propriétés et garanties assurées par TCP
Fiabilité (garantie de remise via réémission en cas de pertes)
Ordonnancement (les segments sont numérotés et réordonnés à la réception)
Mode connecté (établissement d’une session de communication entre deux parties)
Contrôle de flux (l’émetteur adapte son débit aux capacités de traitement du récepteur)
Contrôle de congestion (l’émetteur adapte son débit à l’encombrement du réseau)
Détection des erreurs de transmission
Le TCP est capable de grandes choses et établit des connections durables contrairement à UDP, c’est
pourquoi il est peut-être plus simple de se souvenir ce dont le TCP n’est pas capable :
— Le TCP n’a pas de garantie de débit minimum
— Le TCP n’a pas de garantie de latence maximum (c’est même le cas d’aucun protocole !)
5
2.14.3
Fenêtre d’émission dans une TCP
La fenêtre d’émission, quelquefois appelée le champ “window ”, sert à indiquer le nombre d’octets qui
peuvent encore être envoyés avant de recevoir un ACK, c’est-à-dire un paquet d’acquittement.
2.15
Le protocole HTTP
2.15.1
Requêtes HTTP usuelles
Lorsqu’on récupère des données d’un site, elles sont préfacées par un header, qui contient des informations
pratiques sur le paquet. On appelle payload les données utiles, privées du header donc.
—
—
—
—
—
2.15.2
GET (demande d’une ressource au serveur)
HEAD (demande d’une ressource au serveur, mais uniquement le header)
POST (envoie une ressource au serveur, plus précisément un payload)
PUT (mettre à jour une cible avec des données)
DELETE (détruire la cible)
Propriétés des requêtes HTTP
— Safe (l’état du serveur n’est pas modifié)
— Idempotent (on peut envoyer une double requête)
— Cacheable (peut être mise en cache) (⇔ safe et idempotent)
Safe Idempotent Cacheable
DELETE ✗
✓
✗
GET
✓
✓
✓
HEAD
✓
✓
✓
POST
✗
✗
✗
PUT
✗
✓
✗
2.16
Cookies
2.16.1
Utilisation d’un cookie
En gros, un cookie garde en mémoire des données sur les utilisateurs, ce qui permet de :
— Maintenir l’authentification d’un utilisateur, pour qu’il n’ait pas à se reconnecter.
— ≪ Tracer ≫ un utilisateur, pour pouvoir lui proposer des publicités ciblées.
— Maintenir du paramétrage pour l’utilisateur, par exemple la langue.
Puisque HTTP n’est pas chiffré, on essaie d’éviter que le client renvoie un cookie d’authentification, ce qui
serait grave niveau sécurité. Il existe HTTPS pour sécuriser le cookie.
2.17
Spécification de protocoles
La mise en œuvre d’un protocole applicatif peut être représenté par une paire d’automates client/serveur.
Les transitions, quand elles sont de la forme ≪ Gauche/Droite ≫, signifient : c’est la transition Gauche
sur cet automate, et franchir la transition enverra le message ≪ Droite ≫ à l’autre automate.
6
(Exemple : le client va directement en C1 et le serveur en S1 car les transitions sont activées par le mot
vide. Puis le client va directement en C2 et envoie ≪ CONN ≫ à l’automate serveur, puis celui-ci va en
S2 et envoie ≪ ACK ≫ à l’automate client, etc etc)
3
Sécurité
3.1
Les propriétés
≪
fondamentales ≫ de la sécurité
— Confidentiality (confidentialité – les partis non autorisés ne doivent pas accéder aux données)
— Integrity (intégrité – les données ne sont pas modifiées par un utilisateur non autorisé)
— Availability (disponibilité – les utilisateurs autorisés doivent pouvoir accéder aux données)
3.2
Propriétés de diverses formes d’attaque
— L’attaque par force brute revient à tester, une à une, toutes les combinaisons possibles. Le
temps de cassage est fini, mais augmente exponentiellement avec la longueur du mot de passe. Le
temps augmente également dès qu’on utilise des caractères spéciaux, chiffres, qu’on alterne entre
majuscules et minuscules, etc. . .
— L’attaque par dictionnaire est similaire, mais recherche uniquement des mots ou des séries de
mots qui sont dans le dictionnaire. L’idée, c’est que la plupart des gens utilisent des mots courants
dans leur mot de passe, donc on peut déchiffrer plus vite des mots de passe longs.
Par exemple, ≪ b@J 86 ≫ est très facile à casser par force brute, mais pas par dictionnaire. Tandis que
≪ MotDePasseVraimentPasOuf ≫ met une éternité à être cassé par force brute, mais se casse très facilement
par dictionnaire.
— L’attaque par rainbow table utilise une structure de données particulière, la table arc-en-ciel.
En gros, vu que les bases de données stockent des mots de passe cryptés via une fonction de hashage,
l’idéal serait d’avoir chaque paire MDP texte / MDP hashé possible pour pouvoir retrouver un mot
de passe à partir d’un hash. Il est impossible de stocker chaque possibilité, ainsi les tables arc-en-ciel
sont un compromis temps/mémoire. On parle d’attaque pré-calculée car on utilise un dictionnaire
(la table arc-en-ciel) pré-calculé.
Une façon de lutter contre une telle attaque, c’est le salage, c’est-à-dire l’introduction d’un peu d’aléatoire
dans la fonction de hashage. Ainsi, deux mêmes mots de passe aboutissent généralement à un hash différent,
ce qui complique le ≪ retour en arrière ≫ de l’attaquant.
NB : Attention à la formulation des réponses du QCM, car le principe des mesures de sécurité c’est
qu’on ne fait que se prémunir et qu’on n’est jamais certain de ne pas se faire avoir malgré tout. Par exemple
une réponse du type ≪ il est nécessaire d’utiliser x pour éviter y ≫ peut être vraie, mais une réponse du
type ≪ il est suffisant d’utiliser x pour éviter y ≫ sera généralement fausse.
3.3
Sécurisation d’un système d’informations
3.3.1
Permissions UNIX
Lorsqu’on entre la commande ls -l, on a accès à une liste des fichiers avec une chaı̂ne de caractères au
début, qui précise les permissions des utilisateurs. Il y a trois types de permissions :
— ‘r’ : lecture
— ‘w’ : écriture
— ‘x’ : exécution du fichier, ou passage dans un répertoire
La syntaxe est la suivante :
—
—
—
—
1
3
3
3
caractère, ‘-‘ pour un fichier standard
caractères qui précisent les permissions
caractères qui précisent les permissions
caractères qui précisent les permissions
et ‘d’ pour un répertoire
du propriétaire
du groupe propriétaire
de tout le monde
Par exemple : -rwxr-xr-- 1 owner betatesters 150 nov 3 11:22 game signifie que game est un fichier
que owner peut lire, modifier et exécuter, que le groupe betatesters peut lire et exécuter, et que le commun
des mortels peut lire seulement.
Par ailleurs, 150, c’est la taille en octets de game, qui a été créé le 3 novembre à 11h22.
3.3.2
Pare-feu
Un pare-feu est un équipement qui inspecte des paquets entrants et sortants d’un réseau à l’autre, et
implémente un mécanisme de filtrage basé sur des règles imposées.
7
En termes de politique de sécurité, il est conseillé d’adopter une politique fermée, c’est-à-dire de tout
interdire par défaut et laisser seulement passer des paquets explicitement autorisés. Il peut filtrer les
connexions en fonction des :
—
—
—
—
Protocoles
Adresses IP source et destination
Ports source et destination
Sens de circulation d’un paquet
Seulement, ce n’est pas encore suffisant de filtrer comme ça sans se poser de questions. Par exemple, un
pare-feu pourrait bloquer tout sauf l’HTTP en ouvrant le port 80, et un attaquant peut envoyer une charge
malveillante en lui attribuant comme port source le port 80.
Il faut alors suivre l’état des connexions TCP, on dit qu’un tel pare-feu filtre le trafic par états. Il faut
donc maintenir une table résumant les connexions existantes. C’est plus facile quand on a un mode connecté
(session client-serveur qui reste ouverte), mais une filtration par états peut également marcher avec
un protocole non connecté.
3.3.3
VPN
Un VPN permet de créer un lien direct avec des ordinateurs distants, d’y accéder comme
si l’on était connecté à un réseau local. Un VPN dispose également d’une ≪ passerelle ≫ permettant
à accéder à l’extérieur – on utilise ceci de nos jours pour changer l’adresse IP source apparente de nos
connexions et ainsi rendre plus difficile la localisation de notre ordinateur. Mais ce n’est pas sa seule
utilisation. Un VPN, par défaut, n’assure pas particulièrement la sécurité d’une connexion
entre deux ordinateurs distants.
3.3.4
Proxy
Un proxy est un programme servant d’intermédiaire pour accéder à un autre réseau, le plus
souvent Internet. Se placer ainsi entre deux hôtes permet de faciliter ou bien de surveiller les échanges
se produisant.
Il y a plusieurs utilités à cela :
— Filtrer les pages web autorisées d’accès aux utilisateurs (on parle de proxy filtrant).
— Contourner un filtre web si on passe par un proxy d’un autre pays par exemple.
— Compliquer la remontée vers l’internaute ce qui permet une meilleure anonymisation.
3.4
3.4.1
Injections SQL
Comment fonctionne une injection SQL
Puisqu’une requête SQL est de la forme SELECT machin FROM truc WHERE monChamp = ‘[string]’;
l’idée est d’écrire quelque chose qui permet à l’utilisateur de forcer l’accès.
Par exemple, pour SELECT id FROM Users WHERE name = ‘Nom’ AND password = ‘45723a2af’;
— Si on entre comme nom d’utilisateur Nom’;-- et n’importe quel mot de passe, la requête devient
SELECT id FROM Users WHERE name = ‘Nom’;--’AND password = ‘45723a2af’; ce qui permet
d’accéder aux données sans besoin du mot de passe car en SQL les caractères -- marquent le début
d’un commentaire.
— Si on entre comme nom d’utilisateur Nom et comme mot de passe ’ or 1=1 --, la requête devient
SELECT id FROM Users WHERE name = ‘Nom’ AND password = ‘’ or 1=1 {-’; et, puisque ‘1=1’
est toujours vrai, le booléen est vrai et de même on accède aux données.
Attention à bien garder en tête que SQL clôt ce qu’on entre par des apostrophes ‘’, et que justement il
faut jouer avec pour obtenir une syntaxe correcte !
3.4.2
Comment se protéger d’une injection SQL
La meilleure façon d’éviter tout cela est d’utiliser une requête pré-faite. On compile ainsi la requête
avant d’y rentrer les paramètres de l’utilisateur, ainsi si un morceau de code est inséré dans les paramètres
il ne sera pas interprété comme tel.
8
3.5
3.5.1
Méthodes de chiffrement
Propriétés d’une méthode de chiffrement
— Confusion : la relation entre la clé de chiffrement et le texte chiffré doit être la plus complexe
possible. Notamment chaque bit du texte chiffré doit dépendre de plusieurs parties de la clé, ce qui
obscure les connexions entre les deux.
— Diffusion : le moindre changement dans le texte clair doit radicalement changer le texte chiffré
(statistiquement, 1 bit dans le texte clair change 50% des bits dans le texte chiffré), et par ailleurs
le même message crypté deux fois devrait donner deux résultats différents.
3.5.2
Chiffrement par enchaı̂nement des blocs ou Cipher Block Chaining (CBC)
On sépare les messages en blocs, et on crée un “Initialization Vector” (en gros une chaı̂ne de bits) aléatoire.
On applique un XOR entre le premier bloc et l’IV, qu’on chiffre, puis on utilise le résultat pour faire un
XOR avec le deuxième bloc, et ainsi de suite.
(le ⊕ dans la figure représente un XOR)
Résultat des courses : le chiffrement de chaque bloc dépend du bloc précédent, qui lui-même dépend du
bloc précédent, etc etc... donc finalement dépend de tous les blocs précédents. C’est cool, ça augmente
la diffusion, mais du coup l’encryption est coûteuse en temps (non parallélisable. . .)
3.6
3.6.1
Cryptographie symétrique et asymétrique
Cryptographie symétrique
Principe : le message est chiffré et déchiffré avec la même clé. Dans le cas général, les algorithmes de
chiffrage et de déchiffrage ne sont pas les mêmes, mais il existe certaines méthodes où c’est le cas. La
confidentialité vient du fait que les deux interlocuteurs se partagent une même clé qui est secrète aux
autres.
Exemple : le code César – la clé, c’est le nombre de décalages dans l’alphabet, et c’est bien la même
à l’encodage et au décodage. Mais pendant l’encodage, on avance dans l’alphabet, alors que pendant le
décodage on recule. Donc l’algorithme n’est pas le même.
Remarque : pour assurer des échanges entre n utilisateurs de manière sûre, il faut une clé pour chaque
paire de personnes, soit n(n−1)
clés.
2
3.6.2
Cryptographie asymétrique
Si Alice veut envoyer un message à Bob, ils partagent chacun une clé publique et une clé privée, qu’on
notera (Apub , Apriv ) et (Bpub , Bpriv ). Il y a deux aspects importants qu’on gère ici :
— l’encryption et la décryption : Alice chiffre son message avec la clé publique de Bob, et Bob
décrypte le message avec sa propre clé secrète. Ainsi tout le monde peut envoyer un message à Bob,
mais seul lui peut le décoder. (Intuitivement, la clé publique est une fonction qui rend le message
très difficile à comprendre, et la clé privée est une brèche secrète qui rend la résolution très facile)
9
— la signature : Alice signe son message avec sa propre clé privée, et Bob peut vérifier la signature
avec la clé publique d’Alice. Ainsi tout le monde peut vérifier qu’un message d’Alice vient bien
d’Alice, mais elle seule peut signer sous son nom.
Exemple : l’algorithme RSA. On choisit p et q nombres premiers très grands, on calcule n = p × q et
φ(n) = (p − 1)(q − 1). On choisit e entier tel que 1 < e < φ(n) et e ∧ φ(n) = 1. On cherche d entier tel que
1 < d < φ(n) et e × d ≡ 1 mod φ(n). La clé publique est (e, n) et la clé privée est d.
Si Alice veut envoyer un message, elle reçoit la clé publique de Bob (e, n) et elle code son message par un
entier m tel que 1 < m < n. Elle envoie ensuite le message codé c = me mod n à Bob. Bob calcule ensuite
m = cd mod n grâce à sa clé privée (par la magie de l’arithmétique ça marche).
3.6.3
Certificats
Les certificats sont décernés par des autorités en qui on a confiance, elles sont appliquées à la clé
publique et font office de preuve que la personne ou l’entreprise ayant cette clé publique
a également la clé privée correspondante. Par exemple, pour un site HTTPS, c’est mieux si la clé
publique du domaine possède un certificat, comme ça on a confiance en le site.
3.6.4
Combinaison symétrique + asymétrique
La cryptographie asymétrique c’est assez lent, donc on préfère éviter de n’utiliser que ça.
En pratique, on crée une clé de session, c’est-à-dire une clé de cryptage symétrique qui ne sera valable
que pour une session. Il faut bien transmettre cette clé aux interlocuteurs de façon sécurisée, donc on utilise
des clés de cryptage asymétrique au début, seulement pour chiffrer la clé de session. On rappelle que
c’est toujours la clé publique qui chiffre le message !
3.7
3.7.1
Attaques de logiciels malveillants
Fonctionnement d’un ver
Un ver se propage en exploitant des failles dans un réseau. Ils passent d’abord inaperçus, en se
camouflant dans du trafic normal, puis peuvent s’activer par action humaine.
3.7.2
Fonctionnement d’un path traversal
Une attaque path traversal est une attaque utilisée par un malware exploitant des failles de sécurité dans
un système de fichiers, et permettant de parcourir tout le système de fichiers.
4
Le mot de la fin
Merci d’avoir lu cette fiche ! J’espère qu’elle vous sera utile dans vos révisions.
Si vous avez un retour à faire, ou bien si vous souhaitez accéder au fichier LaTeX afin de faire des ajouts,
vous pouvez me contacter à l’adresse suivante : matteo.boissiere@student-cs.fr. Bon courage !
10