Travail de fin d'études : Les firewalls

3. Les protections

Dans ce chapitre nous parlerons dans un premier temps des règles que peut appliquer un firewall, à savoir le blocage de port, le blocage conditionnel et la dislocation de paquets. Dans un deuxième temps nous vous parlerons du SSH et du RSA.

3.1. Le blocage de port

Une IP ne suffit pas pour exécuter des tâches sur un réseau. Il faut des ports, qui vont permettre à l'ordinateur de pouvoir distinguer les différentes sources de données et ainsi exécuter l'application souhaitée.

Plusieurs cas peuvent se présenter, nous vous présenterons les plus fréquents.

3.1.1. D'un client vers le serveur d'une entreprise :

Nous avons plusieurs clients qui veulent se connecter au serveur web d'une entreprise. Etant donné que c'est un serveur web, seul le port 80 sera accessible et autorisé lorsque les clients voudront se connecter sur le serveur. Le firewall laissera donc passer tout les clients qui veulent voir le site web de l'entreprise. Par contre, les clients qui veulent accéder à une autre porte que la porte 80, par exemple la porte 5631, du serveur ne pourront pas y accéder car le trafic sur ce port n'est pas autorisé. Le firewall leur bloque donc l'accès.

D'un client vers le serveur d'une entreprise

3.1.2. D'une entreprise vers l'extérieur :

Nous voici dans l'autre sens. Ici, ce sont les clients de l'entreprise qui veulent accéder à différente application. Dans l'exemple ci-dessous, nous remarquons que les clients peuvent voir des pages web, mais qu'ils ne peuvent pas aller sur Msn Messenger.

En effet, le firewall bloque tout accès au port 1863 aux personnes de l'entreprise. Le port 1863 étant celui utilisé par le programme Msn Messenger.

D'une entreprise vers l'extérieur

3.1.3. Le proxy d'une entreprise :

Ce genre de blocage de ports se retrouve plus souvent dans les grandes entreprises. Lorsque les clients de l'entreprise veulent aller sur un site web ou accéder à d'autres services (FTP, mail, ...), ils doivent d'abord passer par le proxy. Le proxy demandera les informations au serveur et les renverra à l'utilisateur les ayant demandées. S'ils essaient de ne pas passer par le proxy, ils ne peuvent rien atteindre.

Le rôle d'un proxy est de limiter le nombre de connexions sortantes. En effet, seul le proxy accède à internet en direct.

Le proxy d'une entreprise

3.2. Le blocage conditionnel :

Le blocage conditionnel est un peu plus complexe que le blocage de ports. Il peut y en avoir de plusieurs sortes. Tout comme le blocage de ports, les blocages conditionnels nous permettent de bloquer l'accès à des sites web, des réseaux internes d'entreprises, etc. Nous parlerons des quatre méthodes de blocages conditionnels les plus fréquents.

3.2.1. Les IP sources :

Pour refuser l'accès à un serveur, nous pouvons nous baser sur les IP sources. C'est à dire que nous pouvons par exemple refuser l'accès d'un site web selon l'adresse IP de l'utilisateur qui tente de s'y connecter.

Ainsi, un fournisseur d'accès internet peut n'accepter que les connexions venant de chez ses propres clients pour accéder à certaines pages (comme la gestion de l'abonnement, le paramétrage des comptes de courrier électronique, ...)

C'est le cas avec le fournisseur d'accès belge Skynet.

Les IP sources

3.2.2. Par authentification :

Avant que le firewall ne laisse passer un client, il faut que celui-ci s'authentifie. Il peut le faire grâce à un login et un mot de passe, ou bien par un code généré.

Le plus souvent, lorsque l'on parle de code généré, on parle de "Secure ID". Ces codes sont valables pendant une minute et sont fait de six chiffres. Aujourd'hui, utiliser des Secure ID est monnaie courante. En effet, vous utilisez ce système pour vos connecter à votre compte bancaire via internet.

Prenons un exemple concret. Nous avons deux personnes qui veulent accéder à un compte bancaire. Entre les clients et le serveur sécurisé, il y a le firewall et le serveur Secure ID.

Le premier demande pour se connecter au serveur sécurisé en donnant la Secure ID, qu'il a générée, au firewall. Le firewall va alors envoyer cette clé au serveur Secure ID pour savoir si la clé est bonne ou non (1). Pour notre premier client, elle est bonne. Le serveur Secure ID renvoie alors une confirmation au firewall disant que la clé envoyée est bonne (2). Le firewall va donc laisser le client accéder à son compte.

C'est la même chose pour le deuxième jusqu'au moment où le firewall à envoyé la clé au serveur Secure ID. Ici, la clé est incorrecte. Le serveur Secure ID envoie donc l'information au firewall comme quoi la clé est incorrecte (2). Le firewall ne laissera donc pas passer le client.

L'authentification

3.2.3. Le nombre de connections :

Un firewall peut vérifier le nombre de connexion simultanée chez une personne pour qu'elle ne se connecte pas plus de 2, ou 3 fois simultanément à un même site.

3.2.4. La gestion du matériel :

Cette méthode de protection est généralement utilisée sur les réseaux ethernet. Ici, on vérifie physiquement où se trouve la connexion internet grâce aux " Mac Address ". Cette Mac Address est un code spécifique à chaque carte réseau.

Cette méthode est plus souvent utilisé dans les grandes sociétés.

3.3. Dislocation de paquets :

Ici, le firewall regarde ce qu'il y a dans chaque paquets d'informations envoyés par le client vers le serveur de l'entreprise.

Dans notre exemple, le client essaie de se connecter au serveur web de l'entreprise. Entre les deux, nous avons notre firewall qui analyse ce que demande le client. Le firewall va s'assurer de la nature des paquets, de leur contenu. Il ne faut pas que les informations que le client envoie sur le serveur web soient autres que de l'http et donc à destination du port 80. En effet, les autres protocoles sont interdits.

Un firewall est capable de faire de la dislocation de paquets pour d'autres protocoles bien connus tel que FTP, POP, SMTP, etc.

Avant que le firewall ne fasse une dislocation des paquets, il exécute d'abord les protections par blocage de ports et les blocages conditionnels. En effet, regarder à l'intérieur de chaque paquet demande beaucoup de ressources, il ne faut donc pas faire cela inutilement.

Le firewall peut aussi utiliser des systèmes de détection, tels que l'IDS. En effet, il existe certaines méthodes pour contrer certains envois de paquets envoyés d'une manière plus spéciale. Snort est un système IDS (http://www.snort.org).

La dislocation de paquets

3.4. SSH :

Avant qu'il n'y ait SSH, il y avait des services comme Telnet qui permettaient d'envoyer des informations. Malheureusement, Telnet ne cryptait rien, et une personne qui sniffait le trafic entre deux réseaux pouvait facilement voir ce qui passait d'un réseau à l'autre et ainsi voler des données personnelles telles que des mots de passe, des textes, etc.

Il fallait donc remédier à ce problème, et la réponse fut le "Secure Shell" ou SSH.

SSH apporta deux nouveautés majeures par rapport à Telnet : le cryptage des données, et un système d'authentification de machines.

3.4.1. Le cryptage des données :

Grâce au cryptage de données, la moindre information est cryptée, plus rien ne passe en clair. Ainsi, il est beaucoup plus difficile pour les pirates de sniffer des logins et des mots de passe. Celui-ci peut toujours les sniffer, mais il sera obligé de les décrypter. Le décryptage peut prendre très peu comme beaucoup de temps. Cela dépend de la puissance de chiffrement, qui peut-être de 1 bit, à l'infini de bits.

Si l'émetteur envoie une information à une autre personne en crypté, comment le destinataire fait il pour la décrypter ? Et si il peut la décrypter, le sniffer pourra en faire de même ! C'est ici qu'interviennent les clés publiques et les clés privées !

L'expéditeur crypte l'information grâce à la clé publique du destinataire et celui-ci décrypte l'information grâce à sa clé privée, que lui seul possède ! Le sniffer, qui ne possède pas la clé privée du destinataire, devra donc trouver la clé privée pour arriver à lire le message !

Si la puissance de chiffrement est petite, comme du 16 bits, cela ne demandera que quelques minutes à l'ordinateur du sniffer pour trouver la clé privée ... Mais si la puissance de chiffrement est plus grande, du 1024 bits par exemple, il n'y arrivera pas ! Pourquoi ? Tout simplement parce que la clé devient de plus en plus grande suivant la puissance du chiffrement. Même si nous utilisions tous les ordinateurs sur terre, avec leur puissance actuelle, la recherche d'une clé privée de 1024 bits prendrait, accrochez-vous bien, plus de temps que l'âge de l'univers pour être décryptée ! ... Notre sniffer peut donc tout de suite aller se rhabiller !

Lorsqu'une clé publique est générée, une clé privée l'est aussi en même temps. Ainsi, chaque clé publique va de paire avec une, et une seule clé privée. Notre destinataire possédant la clé privée, il n'aura aucune difficulté pour décrypter le message de l'expéditeur qui a été crypté avec la clé publique du récepteur.

Sceptique, je vous entend déjà dire : " Oui, mais si une personne lui vole sa clé privée, cette personne pourra lire le message ".

Mais il faut savoir que ces clés sont impossibles à mémoriser ... En effet, elles sont composées de nombres, de lettres en majuscules ou minuscules, et sont très longues ...

De plus, mais moins fréquent, des mots de passe peuvent être rajoutés à ces clés, ce qui rendra la tâche du sniffer encore plus difficile !

En effet, il devra à la fois voler la clé privée, mais aussi un mot de passe ...

Rapidement, les clés publiques et les clés privées sont générées grâce à une formule mathématique qui est : (A x B) MOD N = 1. Cette méthode de cryptage est appelée RSA et est utilisée par SSH. Nous en reparlerons dans le point suivant.

3.4.2. L'authentification des machines :

L'authentification de machines sur un serveur est une chose assez pratique, et de sécurisant grâce au système de clés publiques et clés privées.

Par exemple, vous vous connectez à un serveur X pour la première fois. Lors de cette première connexion, un échange de clés publiques s'effectuera entre le client et le serveur, qui sera votre login et votre mot de passe pour aller dessus. Ce dernier va mémoriser votre clé publique. Ainsi, à chaque connexion, le serveur regardera si votre clé publique correspond à sa clé privée, et vous ne devrez plus taper de nom d'utilisateur, ni de mot de passe pour être authentifié.

3.5. RSA

Ce système de cryptographie est le plus connu et le plus sûr de nos jours. L'abréviation RSA provient des noms des trois mathématiciens qui l'ont mis au point en 1977 : Rivest, Shamir et Adleman.

Le RSA se base sur la formule mathématique dont nous parlions plus haut, à savoir : (A x B) MOD N = 1. Cette formule générant, je vous le rappelle, une paire de clé publique et privée.

Comme le RSA se base sur cette formule, il répondra à la même problématique que celle-ci, c'est-à-dire qu'il est impossible de trouver grâce à la clé publique A, la clé privée B.

La nouveauté du RSA, se trouve dans l'utilisation de nombres premiers, ce qui le rend plus sécurisé. En effet, il n'existe pas actuellement sur terre une fonction mathématique permettant de les trouver. Nous sommes donc obligés de les " découvrir " lorsqu'on échoue en essayant de les diviser par tous ceux existant déjà.

Nos trois mathématiciens se sont alors demandés si le N, de (A x B) MOD N = 1, pouvait ne pas être le même N que celui utilisé comme constante dans l'algorithme de chiffrement final ... Et Bingo ! C'est possible !

Vous retrouverez un exemple en annexe.

TFE : Les Firewalls

Autres