Les pare-feux (Firewalls).

La technologie des pare-feux est apparue dans les années 80 pour palier à un nouveau problème de sécurité lié à l’émergence de l’Internet. En 1988, un employé de NASA Armes Research Center en Californie a envoyé un mémo par courrier électronique à son collègue qui a pu lire « Nous sommes actuellement attaqué par un virus Internet appelé Morris Worm ». Ce virus était la première attaque à grande échelle sur Internet. La communauté d’Internet a collaboré à la recherche de nouveaux moyens de protection contre ces nouvelles menaces. A la suite de cela nous avons pu voire apparaître de nouveaux produits de protection contre ces attaques comme les anti-virus et les pare-feux.

Un pare-feu est un élément du réseau informatique, logiciel et/ou matériel, qui a pour fonction de sécuriser un réseau domestique ou professionnel en définissant les types de communication autorisés ou interdits.

L'origine du terme pare-feu se trouve au théâtre. Le pare-feu ou coupe-feu est un mécanisme qui permet, une fois déclenché, d'éviter au feu de se propager de la salle vers la scène. En informatique un pare-feu est donc une allégorie d'une porte empêchant feu est appelé Périphérique de protection en bordure (en anglais : Border Protection Device, ou BPD).

Peu importe le domaine dans lequel on parle de pare-feu, la définition nous ramène toujours à quelque chose bloquant ou empêchant autre chose de pénétrer librement quelque part.

2. Qu’es ce qu’un pare-feu.

Un pare-feu est un système ou un groupe de système qui gère les contrôles d’accès entre deux réseaux. Plusieurs méthodes sont utilisées à l’heure actuelle. Deux mécanismes sont utilisés : le premier consiste à interdire le trafic, et le deuxième à l’autoriser.

Certains pare-feux mettent beaucoup d’énergie à empêcher quiconque de passer alors d’autres tendent à tout laisser passer. La chose la plus importante à comprendre est qu’il représente une politique de contrôle d’accès.

Vous devez avoir une idée précise de cette politique dans son ensemble pour savoir ce que vous devez autoriser ou interdire.

Fig1. Pare-feu entre deux réseaux.

Fig2. Pare-feu entre l’internet et 1 pc. Fig3. Pare-feu entre l’internet et un réseau de pc.

3. Les protections que doit offrir tout système informatique

Le pare-feu est un système de protection basic, si vous allez installer un pare-feu, le premier chois de ton soucie est, Quesque vous allez protéger quand vous serez connecter a internet, les trois Risc potentiel sont :

Vos données : les informations que vous stoquez dans vote pc

Vos ressources : le matériel.

Votre réputation

4. De quoi protège un pare-feu?

Certains pare-feux laissent uniquement passer le courrier électronique. De cette manière, ils interdisent toute autre attaque qu’une attaque basée sur le service de courrier. D’autres pare-feux, moins strictes, bloquent uniquement les services reconnus comme étant des services dangereux.

Généralement, les pare-feux sont configurés pour protéger contre les accès non authentifié du réseau externe. Ceci, plus qu’autre chose, empêche les vandales de se logger sur des machines de votre réseau interne, mais autorise les utilisateurs de communiquer librement avec l’extérieur.

Les pare-feux sont également intéressants dans le sens où ils constituent un point unique où l’audit et la sécurité peuvent être imposés. Tous les échanges passeront par lui. Il pourra donner des résumés de trafic, des statistiques sur ce trafic, ou encore toutes les connexions entre les deux réseaux.

5. De quoi ne protège pas un pare-feu?

Un pare-feu ne protège pas des attaques qui ne passent pas par lui… Certaines entreprises achètent des pare-feux à des prix incroyables alors que certains de leurs employés sont parfois connectés par modem au monde extérieur.

Il est important de noter qu’un pare-feu doit être à la mesure de la politique de sécurité globale du réseau. Il ne sert à rien de mettre une porte blindée sur une maison en bois… Par exemple, un site contenant des documents isolé du reste du réseau !

Une autre chose contre laquelle un pare-feu ne peut vous protéger est les traitres et les idiots qui sont à l’intérieur de l’entreprise… Si un espion industriel décide de faire sortir des données, il y arrivera, surtout sur disquette… Il vaut mieux vérifier qui a accès aux informations que de mettre un pare-feu dans ce cas !

6. Que dire des virus?

Les pare-feux ne protège pas très bien des virus. Il y a trop de manières différentes de coder des fichiers pour les transférer. En d’autres termes, un pare-feu ne pourra pas remplacer l’attention et la conscience des utilisateurs qui doivent respecter un certain nombre de règles pour éviter les problèmes… La première étant bien évidemment de ne jamais ouvrir un fichier attaché à un mail sans être sûr de sa provenance.

Il faut prendre des mesures globales et importantes contre les virus. Avant de traquer les virus à l’entrée du réseau, il faut s’assurer que chaque poste de travail dispose d’un anti-virus. Les virus passent également très facilement par disquette… Les virus sur Internet son bien moins important que les virus sur disquette.

Quoiqu’il en soit, de plus en plus de vendeurs de pare-feux vous offrent des pare-feux qui détectent les virus. Ils permettent probablement d’arrêter les virus simples. Ne comptez pas sur leur protection !

7. Quelles sont les points à prendre en compte pour un pare-feu?

Il y a un certain nombre de règles qui doivent être prise par le chanceux qui a reçu la responsabilité de configurer et de gérer le pare-feu.

Le plus important est de refléter la politique de sécurité choisit par l’organisation. Entre tout interdire et tout autoriser, il y a différent degrés de paranoïa. Le choix final doit être le résultat d’une politique globale de sécurité plus que d’une décision d’un ingénieur…

La deuxième est de savoir le degré de contrôle que vous voulez. Après avoir analysés les risques, il faut définir ce qui doit être autorisé et interdit.

Le troisième point est financier : c’est de savoir le budget que vous allouez au pare-feu. Un pare-feu complet peut être gratuit, ou coûter 100 000 dollars. La solution gratuite, comme la configuration d’un routeur, ne coûte rien sinon beaucoup de temps et de café. D’autres solutions coûteront cher au départ et peu ensuite… Il est important de considérer le prix de départ, mais aussi celui du support.

Un pare-feu coûte cher et prend beaucoup de temps à administrer… Vérifiez que vous avez des bijoux avant d’acheter un coffre-fort hi-teck !

8. Les différents types de filtrages.

8.1 Le filtrage simple de paquet (Stateless).

8.1.1 Le principe.

C'est la méthode de filtrage la plus simple, elle opère au niveau de la couche réseau et transport du modèle OSI. La plupart des routeurs d'aujourd'hui permettent d'effectuer du filtrage simple de paquet. Cela consiste à accorder ou refuser le passage de paquet d'un réseau à un autre en se basant sur :

    - L'adresse IP Source/Destination.
    - Le numéro de port Source/Destination.
    - Et bien sur le protocole de niveaux 3 ou 4.

Cela nécessite de configurer le pare-feu ou le routeur par des règles de filtrages, généralement appelées des ACL (Access Control Lists).

8.1.2 Les limite.

Le premier problème vient du fait que l'administrateur réseau est rapidement contraint à autoriser un trop grand nombre d'accès, pour que le pare-feu offre une réelle protection. Par exemple, pour autoriser les connexions à Internet à partir du réseau privé, l'administrateur devra accepter toutes les connexions Tcp provenant de l'Internet avec un port supérieur à 1024. Ce qui laisse beaucoup de choix à un éventuel pirate.

Il est à noter que de définir des ACL sur des routeurs haut de gamme - c'est à dire, supportant un débit important - n'est pas sans répercussion sur le débit lui-même. Enfin, ce type de filtrage ne résiste pas à certaines attaques de type IP Spoofing / IP Flooding, la mutilation de paquet, ou encore certaines attaques de type DoS. Ceci est vrai sauf dans le cadre des routeurs fonctionnant en mode distribué. Ceci permettant de gérer les Acl directement sur les interfaces sans remonter à la carte de traitement central. Les performances impactées par les Acl sont alors quasi nulles.

8.2 Le filtrage de paquet avec état (Stateful).

8.2.1 Le Principe.

L'amélioration par rapport au filtrage simple, est la conservation de la trace des sessions et des connexions dans des tables d'états internes au pare-feu. Le pare-feu prend alors ses décisions en fonction des états de connexions, et peut réagir dans le cas de situations protocolaires anormales. Ce filtrage permet aussi de se protéger face à certains types d'attaques DoS.

Dans l'exemple précédent sur les connexions Internet, on va autoriser l'établissement des connexions à la demande, ce qui signifie que l'on aura plus besoin de garder tous les ports supérieurs à 1024 ouverts. Pour les protocoles Udp et Icmp, il n'y a pas de mode connecté. La solution consiste à autoriser pendant un certain délai les réponses légitimes aux paquets envoyés. Les paquets Icmp sont normalement bloqués par le pare-feu, qui doit en garder les traces. Cependant, il n'est pas nécessaire de bloquer les paquets Icmp de type 3 (destination inaccessible) et 4 (ralentissement de la source) qui ne sont pas utilisables par un attaquant. On peut donc choisir de les laisser passer, suite à l'échec d'une connexion Tcp ou après l'envoi d'un paquet Udp.

Fig4. Pare-feu en stateful.

Pour le protocole Ftp (et les protocoles fonctionnant de la même façon), c'est plus délicat puisqu'il va falloir gérer l'état de deux connexions. En effet, le protocole Ftp, gère un canal de contrôle établi par le client, et un canal de données établi par le serveur. Le pare-feu devra donc laisser passer le flux de données établi par le serveur. Ce qui implique que le pare-feu connaisse le protocole Ftp, et tous les protocoles fonctionnant sur le même principe. Cette technique est connue sous le nom de filtrage dynamique (Stateful Inspection) et a été inventée par Checkpoint. Mais cette technique est maintenant gérée par d'autres fabricants.

Pare-feu en stateful connections FTP.

8.2.2 Les limite.

Tout d'abord, il convient de s'assurer que les deux techniques sont bien implémentées par les pare-feux, car certains constructeurs ne l'implémentent pas toujours correctement. Ensuite une fois que l'accès à un service a été autorisé, il n'y a aucun contrôle effectué sur les requêtes et réponses des clients et serveurs. Un serveur Http pourra donc être attaqué impunément (Comme quoi il leur en arrive des choses aux serveurs WEB !). Enfin les protocoles maisons utilisant plusieurs flux de données ne passeront pas, puisque le système de filtrage dynamique n'aura pas connaissance du protocole.

8.3 Le filtrage applicatif (ou pare-feu de type proxy ou proxying applicatif).

8.3.1 Le principe.

Le filtrage applicatif est comme son nom l'indique réalisé au niveau de la couche Application. Pour cela, il faut bien sûr pouvoir extraire les données du protocole de niveau 7 pour les étudier. Les requêtes sont traitées par des processus dédiés, par exemple une requête de type Http sera filtrée par un processus proxy Http. Le pare-feu rejettera toutes les requêtes qui ne sont pas conformes aux spécifications du protocole. Cela implique que le pare-feu proxy connaisse toutes les règles protocolaires des protocoles qu'il doit filtrer.

8.3.2 Les limite.

Le premier problème qui se pose est la finesse du filtrage réalisé par le proxy. Il est extrêmement difficile de pouvoir réaliser un filtrage qui ne laisse rien passer, vu le nombre de protocoles de niveau 7. En outre le fait de devoir connaître les règles protocolaires de chaque protocole filtré pose des problèmes d'adaptabilité à de nouveaux protocoles ou des protocoles maisons.

Mais il est indéniable que le filtrage applicatif apporte plus de sécurité que le filtrage de paquet avec état, mais cela se paie en performance. Ce qui exclut l'utilisation d'une technologie 100 % proxy pour les réseaux à gros trafic au jour d'aujourd'hui. Néanmoins d'ici quelques années, le problème technologique sera sans doute résolu.

8.4 Que choisir.

Tout d'abord, il faut nuancer la supériorité du filtrage applicatif par rapport à la technologie Stateful. En effet les proxys doivent être paramétrés suffisamment finement pour limiter le champ d'action des attaquants, ce qui nécessite un très bonne connaissance des protocoles autorisés à traverser le pare-feu. Ensuite un proxy est plus susceptible de présenter une faille de sécurité permettant à un pirate d'en prendre le contrôle, et de lui donner un accès sans restriction à tout le système d'information.

Idéalement, il faut protéger le proxy par un pare-feu de type Stateful Inspection. Il vaut mieux éviter d'installer les deux types de filtrage sur le même pare-feu, car la compromission de l'un entraîne la compromission de l'autre. Enfin cette technique permet également de se protéger contre l'ARP spoofing.

Fig6. 2pare-feux en stateful entre l’internet, une DMZ et Réseau privé.

9 Les différents types de pare-feux.

9.1 Les pare-feux bridge.

Ces derniers sont relativement répandus. Ils agissent comme de vrais câbles réseau avec la fonction de filtrage en plus, d'où leur appellation de pare-feu. Leurs interfaces ne possèdent pas d'adresse Ip, et ne font que transférer les paquets d'une interface a une autre en leur appliquant les règles prédéfinies. Cette absence est particulièrement utile, car cela signifie que le pare-feu est indétectable pour un hacker lambda. En effet, quand une requête ARP est émise sur le câble réseau, le pare-feu ne répondra jamais. Ses adresses Mac ne circuleront jamais sur le réseau, et comme il ne fait que « transmettre » les paquets, il sera totalement invisible sur le réseau. Cela rend impossible toute attaque dirigée directement contre le pare-feu, étant donné qu'aucun paquet ne sera traité par ce dernier comme étant sa propre destination. Donc, la seule façon de le contourner est de passer outre ses règles de drop. Toute attaque devra donc « faire » avec ses règles, et essayer de les contourner.

Dans la plupart des cas, ces derniers ont une interface de configuration séparée. Un câble vient se brancher sur une troisième interface, série ou même Ethernet, et qui ne doit être utilisée que ponctuellement et dans un environnement sécurisé de préférence.

Ces pare-feux se trouvent typiquement sur les Switch.

9.1.1 Avantages.

- Impossible de l'éviter (les paquets passeront par ses interfaces)

- Peu coûteux

9.1.2 Inconvénients.

- Possibilité de le contourner (il suffit de passer outre ses règles)

- Configuration souvent contraignante

- Les fonctionnalités présentes sont très basiques (filtrage sur adresse IP, port, le plus souvent en Stateless).

9.2 Les pare-feux matériels.

Ils se trouvent souvent sur des routeurs achetés dans le commerce par de grands constructeurs comme Cisco ou Nortel. Intégrés directement dans la machine, ils font office de « boite noire », et ont une intégration parfaite avec le matériel. Leur configuration est souvent relativement ardue, mais leur avantage est que leur interaction avec les autres fonctionnalités du routeur est simplifiée de par leur présence sur le même équipement réseau. Souvent relativement peu flexibles en terme de configuration, ils sont aussi peu vulnérables aux attaques, car présent dans la « boite noire » qu'est le routeur. De plus, étant souvent très liés au matériel, l'accès à leur code est assez difficile, et le constructeur a eu toute latitude pour produire des système de codes « signés » afin d'authentifier le logiciel (système RSA ou assimilés). Ce système n'est implanté que dans les pare-feux haut de gamme, car cela évite un remplacement du logiciel par un autre non produit par le fabricant, ou toute modification de ce dernier, rendant ainsi le pare-feu très sûr. Son administration est souvent plus aisée que les pare-feu bridges, les grandes marques de routeurs utilisant cet argument comme argument de vente. Leur niveau de sécurité est de plus très bon, sauf découverte de faille éventuelle comme tout pare-feu. Néanmoins, il faut savoir que l'on est totalement dépendant du constructeur du matériel pour cette mise à jour, ce qui peut être, dans certains cas, assez contraignant. Enfin, seules les spécificités prévues par le constructeur du matériel sont implémentées. Cette dépendance induit que si une possibilité nous intéresse sur un pare-feu d'une autre marque, son utilisation est impossible. Il faut donc bien déterminer à l'avance ses besoin et choisir le constructeur du routeur avec soin.

Fig7. Quelques pare-feu "matériels"

9.2.1 Avantages.

- Intégré au matériel réseau.

- Administration relativement simple.

- Bon niveau de sécurité.

9.2.2 Inconvénients.

- Dépendant du constructeur pour les mises à jour.

- Souvent peu flexibles.

9.3 Les pare-feux logiciels.

Présents à la fois dans les serveurs et les routeurs « faits maison », on peut les classer en plusieurs catégories :

exemple de 2 pare-feux logiciel: jetico et zone alarm.

9.3.1 Les pare-feux personnels.

Ils sont assez souvent commerciaux et ont pour but de sécuriser un ordinateur particulier, et non pas un groupe d'ordinateurs. Souvent payants, ils peuvent être contraignants et quelque fois très peu sécurisés. En effet, ils s'orientent plus vers la simplicité d'utilisation plutôt que vers l'exhaustivité, afin de rester accessible à l'utilisateur final.

9.3.1.1 Avantages.

- Sécurité en bout de chaîne (le poste client)

- Personnalisable assez facilement

9.3.1.2 Inconvénients.

- Facilement contournable

- Difficiles a départager de par leur nombre énorme.

9.3.2 Les pare-feux plus « sérieux ».

Tournant généralement sous linux, car cet OS offre une sécurité réseau plus élevée et un contrôle plus adéquat, ils ont généralement pour but d'avoir le même comportement que les pare-feux matériels des routeurs, à ceci prêt qu'ils sont configurables à la main. Le plus courant est iptables (anciennement ipchains), qui utilise directement le noyau linux. Toute fonctionnalité des pare-feux de routeurs est potentiellement réalisable sur une telle plateforme.

9.3.2.1 Avantages.

- Personnalisables

- Niveau de sécurité très bon

9.3.2.2 Inconvénients.

Nécessite une administration système supplémentaire Ces pare-feux logiciels ont néanmoins une grande faille : ils n'utilisent pas la couche bas réseau. Il suffit donc de passer outre le noyau en ce qui concerne la récupération de ces paquets, en utilisant une librairie spéciale, pour récupérer les paquets qui auraient été normalement « droppés » par le pare-feu. Néanmoins, cette faille induit de s'introduire sur l'ordinateur en question pour y faire des modifications... chose qui induit déjà une intrusion dans le réseau, ou une prise de contrôle physique de l'ordinateur, ce qui est déjà Synonyme d'inefficacité de la part du pare-feu.

10 Attaques, outils, défenses.

10.1 Scénarios d'attaques (Pénétrations de réseaux).

Fig8. Scénarios d'attaques.

Qu'est-ce qu'une backdoor ? Une backdoor est un accès (« caché ») sur votre système qui permet à un pirate d'en prendre le contrôle à distance. Il existe une multitude de sortes de backdoor, et en général dans ce domaine, l'imagination des pirates rivalise avec l'incrédulité des utilisateurs. Voici quelques scénarios d'attaques plus ou moins classique.

10.1.1 Premier cas : Pas de protection.

Considérons un ordinateur victime sur lequel on a installé une backdoor en exploitant une des failles du système. L'attaquant a alors la possibilité d'utiliser tous les services présents sur cet ordinateur. Il lui suffit d'envoyer ses ordres à la backdoor et de récupérer les réponses.

10.1.2 Deuxième cas : Filtrer les flux entrants illégaux.

La sécurité de notre système ne nous semblant pas infaillible, nous décidons alors d'installer un pare-feu avec états (Un pare-feu sans état nous semblant quelque peu léger). Le trafic entrant est maintenant stoppé comme il se doit. Malheureusement, le pirate étant rusé et malicieux, il a pris soin de s'arranger pour que sa backdoor initie elle-même les sessions. Du coup le pare-feu laisse passer les requêtes de l'attaquant qui sont considérées comme des réponses par celui-ci.

Fig9. Scénarios d'attaques en présence de pare-feu.

10.1.3 Troisième cas : Bloquer les flux entrants et sortants.

Dans le cas précédent, le problème était dû aux flux sortants qui permettait au cheval de Troie d'initier les sessions avec la machine de l'attaquant. Il s'agit donc de bloquer les flux sortants. Pour cela la défense insère donc un proxy afin de contrôler ce qui sort du réseau. Malheureusement le trojan peut encore sortir, certes avec plus de difficultés puisqu'il devra se renseigner sur les flux autorisés à sortir par le proxy, et les utiliser pour passer le proxy. Par exemple on peut encapsuler des ordres dans du HTTP (Ip over Http),dans du SSL (Ip over Ssl), DNS (Ip over Dns), Smtp (Ip over Smtp).

Fig10. Scénarios d'attaques en présence de pare-feu et un serveur proxy.

Dans le cas d'un proxy avec authentification, le pirate fera preuve de grande imagination en réalisant un trojan capable de profiter des applications (comme IE par exemple) qui une fois qu'elles se sont authentifiées sont utilisées pour passer le proxy.

10.1.4 - Quatrième cas : Protection locale via un pare-feu personnel.

L'idée du pare-feu personnel est de surveiller le trafic entrant et sortant de la machine infectée. Malheureusement ceux-ci sont fortement attaquables, on peut :

Passer au-dessus du pare-feu via une application autorisée. ® Appel de CreateRemoteThread permettant de l'injection de code à la volée sous Windows.

Passer en dessous du pare-feu via une bibliothèque adaptée (Winpcap sous Windows ou pcap sous Linux).

Attaquer le pare-feu lui-même en tant qu'applicatif (Arrêt du processus).

10.1.5 Cinquième cas : piratage de VPN.

Imaginons qu'un pirate mal intentionné installe un trojan sur l'ordinateur d'un commercial. L'ordinateur possédant entre autre un système Windows et un client VPN. Normalement, le client VPN fonctionne de telle sorte que toutes les liaisons réseaux n'étant pas dans le VPN ne fonctionnent pas. Malheureusement, il s'agit du même problème que pour les pare-feu personnels et le trojan permet à l'attaquant d'accéder au réseau de l'entreprise via le VPN.

Fig11. piratage de VPN.

On peut se rendre compte de l'importance de la robustesse du système d'exploitation, sur lequel est installé le VPN. Après une attaque réussie et la prise de contrôle en root de la machine par le pirate, celui-ci va essayer d'installer ce que l'on appelle un rootkit.
Il existe deux types de rootkit, les rootkit simples et les rootkit noyaux. Les rootkit simples se contentent de remplacer toute une collection de programmes système (ps, netstat, ifconfig, ....) lui permettant d'effacer les traces de son passage et ainsi masquer complètement sa backdoor. Un simple outils tel que Tripwire permet de vérifier l'intégrité des commandes, en enregistrant de façon cryptée les signatures (générées par une fonction de hashage) des fichiers de commandes en question.

Les rootkit noyaux sont beaucoup plus difficiles à détecter, puisqu'ils modifient le noyau et donc modifient son comportement. Par exemple rendre invisible un processus à chaque appel (non pas de la commande ps) mais des fonctions systèmes du noyau, qui elles même sont appelées par la commande ps. Evidemment un rootkit noyau modifie en plus les routines de journalisassions du système, masque les connexions réseaux, ... Pour se protéger des rootkit noyaux, le plus simple est de s'en prémunir. Pour cela, l'idéal est de patcher son noyau pour empêcher l'installation d'un rootkit, et de désactiver les LKM (Loadable Kernel Modules qui permettent au root d'introduire un nouveau code dans le système d'exploitation pendant que ce dernier est en cours d'exécution), malheureusement cela ne suffit pas toujours (voir kinsmod.c). Il existe un outil pour Linux capable d'un certain nombre de vérification de modules de backdoor. Cet outil s'appelle rkscan et permet de détecter les versions de rootkits les plus populaires.

10.2 Les techniques et outils de découvertes de pare-feu.

Il existe beaucoup d'outils et beaucoup de techniques permettant d'identifier un pare-feu. L'objectif de ce paragraphe est d'en exposer quelques-uns et quelques-unes. Il est évident que la plupart des outils utilisés par les pirates pour découvrir les pare-feux sont utilisables pour une activité tout aussi louable telle que la vérification du bon fonctionnement du pare-feu et de la robustesse du réseau.

Dans un premier temps il convient de localiser le ou les pare-feux. La localisation du pare-feu ne pose pas de gros problèmes, un simple traceroute (ou tracert.exe) suffira, bien que dans certains cas netcat apporte de meilleurs résultats.

Exemple :

C:> nc -v -n 10.10.1.8 25
(UNKNOWN) [10.10.1.8] 25 (?) open
421 10.10.1.8 Sorry, the firewall does not provide mail service to you.

Ensuite l'attaquant cherchera à identifier le pare-feu, soit en espérant exploiter une faille même du pare-feu, soit il cherchera à identifier les règles du pare-feu afin d'y détecter une faille dans le filtrage de paquet. Pour identifier les règles d'un pare-feu, il faut utiliser un scanner de port. Il existe de nombreux scanner de ports, les plus connus sont Firewalk, Nmap et Hping2 :

10.2.1 Firewalk.

Le Firewalking est une technique qui permet de déterminer les règles de filtrages de niveau 4 (Transport) sur les équipements (routeurs, pare-feu, passerelles) qui acheminent des paquets de niveau 3 (Réseau).

Le principe de cette technique repose sur le champ Ttl (Time To Live) des en-têtes IP des paquets. C'est à dire le nombre d'équipement (routeur) que peut traverser le paquet. Le logiciel traceroute utilise aussi la technique du Ttl. Lorsque l'on envoie un paquet Udp avec un Ttl de 1, le premier routeur recevant le paquet émettra un paquet Icmp Ttl-exceeded. Et l'on répète le procédé en augmentant le Ttl de 1 à chaque fois. En fait ce procédé peut être réalisé avec d'autres protocoles de niveau 4 comme Tcp ou de niveau 3 comme Icmp.

Firewalk fonctionne en construisant des paquets avec un IP Ttl calculé de façon à expirer sur un segment situé après le pare-feu. En fait si le paquet est autorisé par le pare-feu, il pourra le passer et expirera comme prévu en envoyant un message "Icmp Ttl expired in transit". A l'inverse, si le paquet est bloqué par l'ACL du pare-feu, il sera abandonné et aucune réponse ne sera envoyée ou bien un paquet de filtre admin Icmp de type 13 sera envoyé.

Il est possible de bloquer les paquets Icmp Ttl EXPIRED au niveau de l'interface externe, mais le problème est que ses performances risquent d'en prendre un sérieux coup car des clients se connectant légitimement ne sauront jamais ce qui est arrivé à leur connexion.

10.2.2 Nmap.

Nmap (Network Mapper) est certainement le scanner de port le plus célèbre disponible sous linux, Windows et même MAC. En règle générale, Nmap vérifie que l'hôte à scanner est connecté au réseau. Il réalise pour cela à la fois un Tcp ping sur le port 80 et un ping Icmp normal. Ce comportement peut être détecté par un IDS (Inspection Detection System) et pour cela on peut changer le comportement de Nmap. Nmap permet d'effectuer différents types de scans, en voici les exemples principaux :

Tcp connect : option -sT Principe : une connexion Tcp habituelle est tentée sur chaque port. Inconvénient, ce genre de scan est visible dans les logs des pare-feux. Les noms de services sont associés aux ports ouverts par le fichier Nmap-services et non /etc/services. Il n'est donc pas exclu que le service désigné soit faux. Avantage, possibilité de déterminer l'utilisateur sous lequel est lancé un démon via Ident.

Syn scan : option -sS Principe : Seul un paquet Syn est envoyé. Si le port est ouvert, un Syn|ACK est renvoyé, sinon un RST est renvoyé. En cas de port ouvert Nmap renvoie un paquet RST pour fermer la connexion immédiatement. Avantages, rapide et moins détectable. Fait une différence entre les ports filtrés et ouverts. Inconvénient, impossibilité de déterminer l'utilisateur via Ident.

IDLE scan : option -sI @zombie:port zombie Principe : Une machine "zombie" permet de masquer la source du scan. Avantages, quasiment impossible à tracer, permet de déterminer les règles du pare-feu à partir du zombie plutôt que de la machine qui initie le scan. Inconvénients, pas de prise d'empreinte d'OS, ni d'utilisation de Ident.

Fig12. Schéma d’une attaque.

(0) S'assurer que la machine zombie n'est pas trop chargée pour permettre de bien mesurer l'incrémentation (un petit calibrage avant le scan est donc nécessaire en envoyant une dizaine de paquets Syn).
(1) et (6) Envoi d'un paquet Syn|ACK au zombie pour récupérer l'IP ID (le numéro de séquence).
(2) et (7) Réponse à (1) et (6) par un paquet RST contenant l'IP ID du zombie.
(3) Envoi d'un paquet Syn à la cible avec comme adresse source celle du zombie.
(4) Si le port est ouvert, la cible répond en envoyant un paquet Syn | ACK au zombie, sinon par un paquet RST.
(5) Le zombie incrémente son IP ID, et répond à la cible en envoyant un paquet RST à la cible.
(8) Il est aussi conseillé de tester plusieurs fois chaque port pour éviter les faux-positifs.

FIN, XMAS et NULL scans : options -sF, -sX et -sN Principe : envoi respectivement de paquet FIN, de paquet FIN| URG |PSH et de paquet sans aucun flag Tcp activé. Avantages, contournement de certains pare-feux. Inconvénient, ne fonctionne pas contre certains OS qui n'appliquent pas les normes à la lettre (comme Windows, IRIX, ...)

SCAN Udp : option -sU Principe : Envoi d'un paquet Udp vide sur chaque port. Les ports fermés retournent un paquet Icmp port unreachable. Avantage, permet d'avoir des informations sur NFS, TFtp et certaines backdoor. Inconvénient, très lent.

Scan RPC (Remote Procedure Call) : option -sR Principe : envoi de commandes SunRPC. Avantage, détermine s'il s'agit bel et bien de port RPC et si oui, de quel programme et/ou version il s'agit. Inconvénient, assez voyant.

ACK et Window scan : option -sA et sW principe : Envoie respectivement un paquet ACK avec un numéro de séquence aléatoire et un paquet ayant une taille de fenêtre non valide. Les ports qui ne répondent pas par un RST sont filtrés. Avantage, permet de vérifier si un port est filtré et s'il l'est avec une règle stateful. Inconvénient, Le Window scan ne fonctionne pas sur tous les systèmes d'exploitation.

Scans personnalisés : option --scanflags L'utilisateur spécifie les flags Tcp qu'il souhaite activer.

Scan de protocoles : option -sO Permet de déterminer quels sont les protocoles supportés par le système scanné, généralement un routeur.

Il n'est pas difficile de scanner dans l'anonymat :

Changer la vitesse du scan, grâce à l'option -T suivie des arguments Paranoïd, Sneaky, Polite, Normal, Aggressive or Insane. Nmap attend 5 minutes entre chaque paquet envoyé en mode Paranoïd et 15 secondes en mode Sneaky.

Utiliser des leurres (decoys, option -D) en envoyant d'autres paquets IP spoofés et semblant provenir d'une autre adresse. Sur un réseau local on peut spoofer (option -S) l'adresse source, et récupérer les réponses par sniffage en mode promiscuous. Sur la technique de l'IDLE scan.

L'auteur de Nmap, Fyodor, décrit sa technique de prise d'empreinte du système d'exploitation (fingerprinting) dans l'article « Détection d'OS distante par prise d'empreinte de pile Tcp/IP » traduit en français par ArHuman, et l'original en anglais « Remote OS detection via Tcp/IP Stack FingerPrinting ». Le principe repose sur le test de différentes particularités des piles Tcp/IP des différents systèmes d'exploitation, lesquelles sont :

Le type d'incrémentation du numéro de séquence initiale (ISN).

La présence ou non du flag IP Don't Fragment.

Des tests sur les tailles de fenêtres.

Le type de service (ToS).

Différents tests sur des paquets Tcp.

Différents tests au niveau Icmp, comme la limite de vitesse d'envoi de certains types de paquets Icmp d'erreurs.

Nmap utilise l'option -O pour effectuer une prise d'empreinte du système, et en général on associe l'option -v (Verbose) pour obtenir des informations supplémentaires comme les ports servant à effectuer les tests de la prise d'empreinte.

Il m'a semblé important de remarquer le fait que de scanner un pare-feu ou un système protégé par un pare-feu prend plus de temps qu'un système non protégé.

10.2.3 - HPING2.

HPING2 est différent de Nmap d'abord parce qu'il est beaucoup plus configurable. On peut facilement modifier n'importe quel octet de l'entête TcpIP. Cela permet d'être réellement créatif au niveau des techniques de balayage à des fins de reconnaissance. On peut bien sûr insérer des données malveillantes dans les paquets (buffer overflow, trojan, ...) et les utiliser pour pénétrer des réseaux.

HPING2 permet de :

1- Tester les règles de pare-feu.

2- De faire du scan sophistiqué.

3- De tester les performances d'un réseau utilisant différents protocoles, le ToS et la fragmentation.

4- De faire du firewalk.

5- De l'empreinte de système d'exploitation.

Actuellement, la version HPING3 est en train d'être développé par Salvatore SanFilippo, et d'autres volontaires. Selon son site Web, Hping3 sera nettement supérieur à l'actuelle version. Il y aura des améliorations d'installation, des outputs plus lisibles, et sera exploitable par script. Le statut actuel du projet peut être suivi .

Il existe aussi des outils d'évaluation de vulnérabilité :

Les payants : Retina (eEye) , NetRecon (Symantec), ISS Internet Scanner (ISS), Cybercop Scanner (Network Associates).

Les freewares : Nessus (Renaud Déraison).

10.2.4 NESSUS.

Nessus a été écrit par Renaud Deraison (depuis début 1998), un grand maître de Linux et de la sécurité. Nessus est devenu le Linux de l'évaluation de la vulnérabilité, il surpasse certains de ses concurrents commerciaux. Nessus emploie un modèle de plug-in extensible qui permet à la sécurité d'ajouter à la demande des modules d'exploration. Nessus utilise un langage de script NASL (Nessus Attack Script Language) pour écrire des tests de sécurité rapidement et facilement. Nessus est basé sur une architecture client-Serveur, le serveur réalise les attaques et tourne sur un système UNIX; les clients initialisent les attaques et existent sur différentes plates-formes X11, Win32 et un client Java. Le fait d'être open source et d'utiliser des plug-in permet à Nessus d'être mis à jour régulièrement au niveau de sa base de données d'attaques et d'être à la pointe de la technologie. Nessus compte à l'heure actuel plus de 500 contrôles de vulnérabilités, dont certains ne sont pas disponibles dans les scanners commerciaux.

10.2.5 Scanners en ligne.

Un autre moyen de sonder une cible sans passer par notre propre machine, donc sans se faire loguer ou presque, est d'utiliser les outils de balayage "online".

En effet, ce n'est plus la machine "pirate" qui envoie la requête vers la machine cible, mais c'est le site web proposant ce service qui va envoyer à notre place la requête de scan et qui nous remonte la la réponse via HTTP.

On est alors *presque* anonyme. Dans le sens où c'est l'outil en ligne qui peut nous logguer.

Voici des exemple de scanner en ligne :

- Le sanner TCP online de FrameIp qui permet de scanner une rangée de ports TCP.

- L'outil NQT (Network Query Tool) est aussi intéressant dans le mesure où il pratique plusieurs types de scan (Resolve/Reverse Lookup, enregistrement DNS, Whois, ping de port, traceroute,...).

-Nmap version web, le petit dernier, mais très intéressant aussi. Le puissant scanner online couplé avec une chaîne de Proxy peut être doté d'un bon niveau d'anonymat pour scanner une cible.

10.3 Configuration théorique des défenses.

La configuration d'un pare-feu est l'élément clef de son efficacité. Un pare-feu mal configuré peut être tout aussi efficace... qu'aucun pare-feu du tout. C'est la clef de son bon fonctionnement et de son efficacité.
Il existe deux politiques de configurations différentes en ce qui concerne la « base » du pare-feu :

Tout autoriser sauf ce qui est dangereux : cette méthode est beaucoup trop laxiste. En effet, cela laisse toute latitude à l'imagination des intrus de s'exprimer. Et à moins d'avoir tout prévu de façon exhaustive, on laissera forcément des portes ouvertes, des failles béantes dans notre système. A éviter absolument.

Tout interdire sauf ce dont on a besoin et ce en quoi on a confiance : cette politique est beaucoup plus sécuritaire. En effet, les services sont examinés avant d'être autorisés à passer le pare-feu, et sont donc tous soumis à un examen plus ou moins approfondi. Ainsi, pas de mauvaise surprise sur un service que l'on pensait ne pas avoir installé, plus d'oubli : tout service autorisé est explicitement déclaré dans le pare-feu. Cette politique s'accompagne de la création de deux zones : une zone interne et l'extérieur. On peut considérer que tout ce qui est dans notre réseau local est autorisé, sans prendre de trop gros risques : le pare-feu est là pour nous protéger des attaques extérieures, pas des attaques internes pour lesquelles il ne peut rien. Cette facette peut changer suivant la politique de l'entreprise (interdire l'accès à certains, jeux, etc.). La zone externe est par contre considérée comme « non sûre », et donc toute requête envoyée sur un service non explicitement déclaré comme accessible de l'extérieur sera interceptée et ignorée. La configuration de la DMZ est ici très importante, et sa gestion aussi. Cette politique s'accompagne de plusieurs points à noter :

Plus de services sont ouverts, plus vulnérable est le système. C'est logique, car plus le nombre de logiciels accessibles de l'extérieur est grand, plus le risque qu'un intrus exploite ces dits logiciels pour s'introduire dans le système est important. C'est ainsi que, par exemple, si on utilise un serveur Web qui interface déjà le serveur de base de donnée, il est inutile d'autoriser le trafic entrant vers le serveur de base de données... vu que le serveur Web joue le rôle d'interface.

Suivant la politique de l'entreprise, l'accès ou non à certains services peut être bloqué dans les deux sens. Cela peut servir, par exemple, à empêcher le jeu en ligne, ou autres activités que l'entreprise ne désire pas voir se dérouler sur ses propres infrastructures.

Certains protocoles sont assez difficiles à autoriser, notamment le Ftp. Le comportement du protocole Ftp est assez atypique et mérite que l'on s'y attarde. Le fonctionnement du Ftp prévoit que ce soit le serveur qui initie la connexion sur le client pour lui transmettre le fichier. Un exemple concret :

Le client demande le fichier index.txt

Le serveur envoie un message au client « accepte la connexion sur le port 2563 »

Le client attend une connexion sur ce port et renvoie un ACK au serveur

Le serveur initie la connexion et lance le transfert de données.

Ce comportement implique que le serveur, dans la zone « externe », initie une connexion sur un port choisi par lui-même sur le client. Or, nous avons explicitement interdit ce genre de manipulation via notre politique. Il y a donc deux solutions :

Interdire le Ftp.

Forcer le client à utiliser la commande PASV, qui indique que le serveur doit adopter un comportement passif, et accepter la connexion du client sur un port spécifié par ce dernier. C'est donc le client qui initiera la connexion, et donc, la connexion sera autorisée par le pare-feu. Avec la commande PASV, l'échange se passe donc ainsi :

        - Le client envoie la commande PASV
        - Le serveur répond avec l'adresse et le port auquel le client peut se connecter
        - Le client demande le fichier index.txt (RETR index.txt)
        - Le serveur envoie un reçu et attend la connexion du client
        - Le client se connecte et reçoit le fichier

La configuration efficace d'un pare-feu n'est pas chose évidente, et implique une grande rigueur, la moindre erreur ouvrant une brèche exploitable par les hackers.

10.4 Les réactions des pare-feu aux attaques classiques.

10.4.1 IP spoofing.

L'IP spoofing consiste à modifier les paquets IP afin de faire croire au pare-feu qu'ils proviennent d'une adresse IP considérée comme « de confiance ». Par exemple, une IP présente dans le réseau local de l'entreprise. Cela laissera donc toute latitude au hacker de passer outre les règles du pare-feu afin d'envoyer ses propres paquets dans le réseau de l'entreprise. Les derniers pare-feux peuvent offrir une protection contre ce type d'attaque, notamment en utilisant un protocole VPN, par exemple IPSec. Cela va crypter les entêtes des paquets, et ainsi rendre impossible leur modification par un intrus, et surtout, l'intrus ne pourra générer de paquets comme provenant de ce réseau local, ce dernier n'ayant pas la clé nécessaire au cryptage. Les algorithmes utilisés dans de tels protocoles sont de type RSA.

10.4.2 DOS et DDOS.

Le DOS, ou Denial Of Service attack, consiste à envoyer le plus de paquets possibles vers un serveur, générant beaucoup de trafic inutile, et bloquant ainsi l'accès aux utilisateurs normaux. Le DDOS, pour Distributed DOS, implique venir de différentes machines simultanées, cette action étant le plus souvent déclenchée par un virus : ce dernier va d'abord infecter nombre de machines, puis à une date donnée, va envoyer depuis chaque ordinateur infecté des paquets inutiles vers une cible donnée. On appelle aussi ce type d'attaque « flood ». Les pare-feux ici n'ont que peu d'utilité. En effet, une attaque DOS ou DDOS utilise le plus souvent des adresses sources différentes (le but n'est pas de récupérer une réponse ici) et souvent, impossible de distinguer ces paquets des autres... Certains pare-feux offrent une protection basique contre ce genre d'attaque, par exemple en droppant les paquets si une source devient trop gourmande, mais généralement, ces protections sont inutiles. Cette attaque brute reste un des gros problèmes actuels, car elle est très difficilement évitable.

10.4.3 Port scanning.

Ceci constitue en fait une « pré-attaque » (Etape de découverte). Elle consiste à déterminer quels ports sont ouverts afin de déterminer quelles sont les vulnérabilités du système. Le pare-feu va, dans quasiment tous les cas, pouvoir bloquer ces scans en annoncent le port comme « fermé ». Elles sont aussi aisément détectables car elles proviennent de la même source faisant les requêtes sur tous les ports de la machine. Il suffit donc au pare-feu de bloquer temporairement cette adresse afin de ne renvoyer aucun résultat au scanner.

10.4.4 Exploit.

Les exploits se font en exploitant les vulnérabilités des logiciels installés, par exemple un serveur Http, Ftp, etc. Le problème est que ce type d'attaque est très souvent considéré comme des requêtes tout a fait « valides » et que chaque attaque est différente d'une autre, vu que le bug passe souvent par reproduction de requêtes valides non prévues par le programmeur du logiciel. Autrement dit, il est quasiment impossible au pare-feu d'intercepter ces attaques, qui sont considérées comme des requêtes normales au système, mais exploitant un bug du serveur le plus souvent. La seule solution est la mise à jour périodique des logiciels utilisés afin de barrer cette voie d'accès au fur et à mesure qu'elles sont découvertes.

11. Conclusion.

Nous avons vu, dans cette publication, les différents types de pare-feux, les différentes attaques et parades. Il ne faut pas perdre de vue qu'aucun pare-feu n'est infaillible et que tout pare-feu n'est efficace que si bien configuré. De plus, un pare-feu n'apporte pas une sécurité maximale et n'est pas une fin en soi. Il n'est qu'un outil pour sécuriser et ne peut en aucun cas être le seul instrument de sécurisation d'un réseau. Un système comportant énormément de failles ne deviendra jamais ultra-sécurisé juste par l'installation d'un pare-feu.

Toutes ces technologies sont et seront en pleine évolution, car la base même de tout cela est de jouer au chat et à la souris entre les hackers et les programmeurs de pare-feu ainsi que les administrateurs. Une grande bataille d'imagination qui n'aura certainement jamais de fin.