1. Préliminaires▲
La sécurité des hôtes sur un réseau, et donc sur le Net, est un vaste problème.
L'objectif de ce document n'est certes pas d'être une référence à l'usage des spécialistes, mais plutôt un exposé des connaissances de base qui permettent d'entrevoir les dangers encourus par un utilisateur tel qu'un internaute câblé ou « ADSLisé ».
1-1. Mais que risque-t-on ?▲
Malheureusement beaucoup. TCP/IP n'est pas un modèle de sécurité et de nombreux spécialistes ont mis à jour des trous qui permettent de s'introduire frauduleusement dans les machines des autres. Comme le monde virtuel n'est pas bien différent du monde réel, nous y trouverons aussi des cambrioleurs, des voyeurs, des casseurs, etc. avec toutes les nuisances que ça laisse supposer. Il est donc nécessaire de se protéger de ces agresseurs.
1-2. Firewall, c'est quoi ça ?▲
Traduit plus ou moins harmonieusement par « mur pare-feu », les « firewalls » sont normalement des systèmes dédiés à la sécurité d'un réseau.
Dans l'absolu, un firewall devrait être un dispositif informatique qui s'intercale entre le réseau privé et la connexion Internet. Comme c'est lui qui va prendre les coups, il vaut mieux qu'il soit solide et qu'il soit dédié à cette tâche.
Malheureusement, les choses ne sont pas toujours aussi simples et de nombreuses entorses à cette règle basique sont souvent nécessaires.
- Le coût : installer selon cette règle un firewall pour protéger une machine unique augmente l'investissement dans des proportions considérables (encore qu'un vieux PC type P75, 16 Mo de RAM, DD de 500 Mo et une installation de GNU/Linux bien configurée, ça peut se faire pour pas très cher).
- Les services : on a souvent besoin d'installer des services qui doivent communiquer directement avec le Net (DNS, SMTP, FTP, HTTP) et dans ces cas-là , un firewall pur et dur devient un vrai casse-tête. On parle alors de DMZ (Zone démilitarisée), sorte de purgatoire un peu protégé dans lequel les serveurs publics jouissent d'une relative sécurité derrière un barrage filtrant, mais non protégés par un firewall plus strict, dont le rôle reste de protéger la partie privée du réseau.
D'autres compromis sont possibles. Le firewall pourra être une machine exposée, donc protégée par des logiciels appropriés, mais elle servira également à d'autres tâches. C'est le cas d'un poste isolé, seulement connecté au Net. C'est aussi le cas de ma configuration où la machine exposée sert également de passerelle pour le réseau privé, de DNS et de relais SMTP.
Finalement, le firewall apparaît plutôt comme un ensemble de règles de sécurité pour la configuration de la machine, avec un logiciel de filtrage de paquets, un logiciel de surveillance (snort, par exemple sous GNU/Linux), voire un logiciel capable de construire une protection particulière lorsqu'il détecte les prémices d'une intrusion.
D'autres logiciels qui cumulent ces fonctions existent dans le monde Windows. Leur principe reste cependant plus ou moins le même, chaque paquet entrant est vérifié et, s'il correspond à certains critères, est bloqué, tracé, accepté, etc.
2. Les attaques▲
2-1. Hasard ou nécessité ?▲
La bonne question à se poser, concernant les problèmes de sécurité n'est pas :
« Est-ce que j'ai des chances (grandes ou petites) de subir une attaque un jour ? »
Mais :
« Quand vais-je être la cible d'une attaque ? »
Et la seule réponse pertinente à cette question est :
« À tout moment. Peut-être justement pendant que tu lis ces lignes :- ) »
Mon propos n'est certes pas d'affoler le lecteur, mais d'essayer de lui faire comprendre que les arguments du type :
« Oh, moi, je n'ai rien d'intéressant sur ma machine et je ne vois pas pourquoi un pirate s'ennuierait à essayer d'y pénétrer… »
Sont du même ordre que de croire que les accidents de voiture sont toujours pour les autres et jamais pour soi.
2-2. Les attaques possibles▲
Une machine informatique est par défaut, d'une grande vulnérabilité, tout simplement, parce que l'informatique est passée des mains d'une poignée de spécialistes à une foule d'utilisateurs et qu'une certaine éthique de l'informaticien y a laissé ses plumes.
Les environnements informatiques n'ont pas été prévus pour être manipulés par des personnes sans scrupules qui cherchent à en exploiter tous les effets pervers.
Je classerai les malfaisants dans trois catégories (c'est une opinion toute personnelle) :
- les amateurs de génocides. Ils utilisent des virus pour produire le plus de dégâts possible sans se soucier de savoir quelles sont les cibles qui seront touchées. Ce qui leur importe est la masse atteinte. Les meilleurs écrivent eux-mêmes leurs virus, ce qui fait au moins la preuve de leur compétence technique, les pires exploitent des virus faits par d'autres, sans même savoir comment ils fonctionnent ;
- les voyous du Net. Bien connus sous le nom de « script kiddies », ceux-là cherchent à pénétrer, le plus souvent pour faire de la casse, des hôtes connectés au Net en utilisant des recettes de cuisine élaborées par d'autres. Nous verrons plus loin de quoi il retourne. Peu leur importe la cible, leur amusement consiste à utiliser des méthodes toutes faites pour ennuyer leur monde. Ils s'attaquent à la première machine sur laquelle ils trouvent une faille, juste pour le plaisir. Mes logs sont pleins de petits comiques de ce genre, qui cherchent au hasard du Net, une machine qui serait infectée par un cheval de Troie, juste, sans doute, parce qu'ils ont trouvé quelque part le client qui sait s'y connecter ;
- les Hackers. Les vrais, ceux qui ont des connaissances très étendues dans les systèmes et pour qui le jeu consiste à rechercher toujours de nouvelles failles. Notez bien que ce ne sont pas forcément des pirates. Ceux-là sont de véritables techniciens et, même s'ils font parfois des dégâts (lorsqu'ils sombrent du mauvais côté de la force), inspirent plus ou moins le respect par leurs grandes connaissances. Ce sont leurs découvertes qui, la plupart du temps, sont exploitées par les script kiddies et autres utilisateurs de virus. Ce sont également leurs découvertes qui contribuent à créer des systèmes de plus en plus solides et fiables. Leur objectif premier n'est pas de détruire, mais de comprendre.
2-2-1. Les attaques virales et assimilées▲
2-2-1-1. Les virus dans les exécutables▲
Un virus est un bout de programme glissé volontairement dans une application dans le but de nuire. Il est possible d'attraper un virus avec n'importe quelle application que l'on a installée et que l'on exécute, ce n'est pas un problème typique d'une connexion permanente. Un virus ne peut être introduit dans sa machine que si l'on exécute une application infectée, application récupérée sur l'Internet ou sur n'importe quel autre support informatique : disquette, CD-ROM, clé USB, etc.
2-2-1-2. Les macrovirus dans les données▲
Une autre infection, assez semblable, consiste à exploiter les possibilités qu'ont certaines applications d'installer des macrocommandes dans les fichiers de données. La suite Microsoft Office qui propose des possibilités, par ailleurs intéressantes, de placer des macros dans les documents Word, Excel et même PowerPoint est une cible de choix. Ces macros sont maintenant écrites en VBA (Visual Basic for Applications) qui est un langage suffisamment puissant pour arriver à faire beaucoup de dégâts avec. Dans un tel cas, il suffit d'ouvrir un document infecté pour mettre le macrovirus en activité. Autrement dit, même des fichiers de données peuvent être dangereux. Notez que Microsoft a modifié les applications de MS Office de manière à ce qu'elles puissent vous avertir de la présence de macros dans les documents, vous laissant la possibilité de les activer ou non. OpenOffice n'est pas plus à l'abri de ce genre d'infection.
2-2-1-3. Les scripts et applets dans le HTML▲
Malheureusement, d'autres moyens existent, typiquement venus de l'Internet, dans les pages HTML. En effet, pour rendre les pages HTML plus vivantes, il devient possible d'y insérer des composants actifs. Parmi ceux-ci nous trouvons :
- les scripts (JavaScript, VBScript) : ce ne sont pas les plus dangereux parce que les langages de scripts offrent rarement des fonctions pouvant être utilisées à des fins vraiment destructrices. Ils disposent cependant de la possibilité de lancer des exécutables locaux, c'est en cela qu'ils peuvent devenir dangereux ;
- les applets Java ou les composants ActiveX : plus puissants, ils sont introduits dans les pages HTML sous la forme de composants compilés (ou précompilés). Leur contenu n'est pas visible et les outils qui permettent de les construire (Java ou Visual Basic) offrent des fonctions permettant de réaliser des opérations extrêmement dangereuses. La grande mode consiste en un mélange des deux. Un message malicieux en HTML pour exécuter un script qui exécute un applet ou un ActiveX, le résultat étant par exemple que votre carnet d'adresses sera utilisé à votre insu pour « spammer » à toutes vos connaissances le même message malicieux ou mieux encore, un autre message, mais contenant le même ver ;
- les « plug-in » qui sont des extensions ajoutées aux navigateurs pour permettre la visualisation de fichiers multimédias peuvent également être corrompus.
2-2-2. Parades▲
Toutes ces attaques sont plus ou moins prises en charge par des applications antivirus, les meilleures précautions à prendre sont :
- installer un « bon » antivirus et effectuer une mise à jour fréquente de la base de données de cet outil. Mais attention, un antivirus, si efficace soit-il ne saura jamais détecter 100 % des attaques ;
- ne pas faire une confiance aveugle à son antivirus, sous prétexte qu'il est « bon et à jour » ;
- rester très prudent sur les sources des documents ou applications que l'on rapatrie sur la machine ;
- paramétrer son navigateur pour ne pas laisser exécuter n'importe quel script ou applet dont l'origine n'est pas sûre ;
- éventuellement, prier.
2-2-3. Les intrusions▲
Décrire dans le détail les méthodes employées serait long, voire fastidieux. Ceux qui sont avides de détails sur la question ont intérêt à se procurer le très instructif « Hacking interdit » édité en français chez Eyrolles. Cet ouvrage traite en quelque 1250 pages des diverses techniques de piratage, ainsi que les parades possibles. Voyons tout de même en résumé les principaux risques.
2-2-3-1. Les ports à l'écoute▲
Lorsqu'un port est ouvert à l'écoute sur un service serveur, c'est une porte ouverte par laquelle un intrus peut entrer. Sur un serveur, on peut entrer avec des outils comme Telnet et exploiter des failles de ces logiciels
Je vous entends me dire Oui, mais ma machine Windows xx n'est pas un serveur, il n'y a donc pas de ports à l'écoute… En êtes-vous si sûr ?
Vous avez déjà les ports 137, 138 et 139 qui sont ouverts pour que NetBIOS fonctionne (la partie la plus visible étant le voisinage réseau). Surtout, si vous avez le partage des fichiers et des imprimantes activé. Dans ce cas-là , vous êtes bel et bien un serveur.
Si vous avez installé IIS (Internet Information Services), nécessaire pour travailler efficacement avec FrontPage, vous avez également le port 80 qui est ouvert (et vous êtes particulièrement en danger).
Vous êtes donc peut-être beaucoup plus serveur que vous ne le pensez…
2-2-3-2. Les « backdoors », « trojans » et assimilés▲
Une porte dérobée n'est pas à proprement parler un virus, dans la mesure où elle ne se multiplie pas. Elle peut cependant s'attraper sensiblement de la même manière, par un cheval de Troie. Un cheval de Troie est une application, d'apparence inoffensive qui installe discrètement une porte dérobée. Elle peut également être inoculée par un pirate qui a réussi une opération de « spoofing », un débordement de pile ou de prise de contrôle à distance sur votre poste, comme nous le verrons plus loin.
Une porte dérobée est en gros un logiciel de contrôle à distance. Il fonctionne comme un serveur, sur un port connu de celui qui a conçu le piège. Un simple scan d'adresses IP sur ce port permet alors de repérer les machines infectées actuellement en ligne. Le mal intentionné peut s'y connecter et faire plus ou moins ce qu'il veut sur la machine distante. Très dangereux, ce genre de saleté peut heureusement être repéré relativement simplement, en prenant la précaution de vérifier périodiquement les ports ouverts sur sa machine. Malheureusement, l'utilisateur a souvent autre chose à faire que de surveiller continuellement les ports ouverts.
Une variante est le « spyware » très à la mode actuellement. Ce n'est pas dangereux à proprement parler, mais ça envoie des informations diverses sur le contenu de votre machine, vos habitudes sur l'internet, etc. à un serveur qui les récupère. Les « spywares » sont souvent implantés dans des logiciels en démonstration ou des « sharewares », de la même manière qu'une porte dérobée. Certains logiciels commerciaux, hélas, s'adonnent également à ce genre de pratiques.
2-2-3-2-1. Exemple marrant d'un spyware▲
Un « keylogger » est un membre de cette famille, dont la spécialité est d'intercepter au plus bas niveau du système toutes les activités du clavier. En bon français, tout ce que vous tapez, il l'enregistre à la source.
Dangereux ?
Vous êtes dans une transaction commerciale. Vous devez envoyer votre numéro de carte bancaire au site marchand. Vous avez bien pris les précautions d'usage :
- vous êtes en HTTPS (HTTP sécurisé), donc connexion chiffrée ;
- vérification du certificat du serveur, le serveur est bien celui qu'il prétend être.
(Comment, vous n'avez même pas vérifié tout ça ?)
Mais si bien sûr, vous avez vérifié :-).
Oui, mais…
Le « keylogger » il s'en fout un peu du HTTPS, puisqu'il récupère les informations à la source, bien avant la couche application. De même, il s'en fout un peu du serveur dûment authentifié, puisqu'il va envoyer les informations recueillies à un serveur pas du tout authentifié, et contrôlé par une association de malfaiteurs.
Vous entrevoyez les risques ?
2-2-3-3. Parades▲
- Contrôler périodiquement les ports ouverts à l'écoute.
- Certains antivirus savent détecter les trojans, backdoors et autres spywares connus.
2-2-4. Les défauts logiciels▲
Il est également possible d'exploiter des failles de sécurité sur des applications serveur « officielles » pour les utiliser comme porte d'entrée, en général par débordement de pile. Il arrive aussi que certains logiciels serveur comportent des « bogues » ou soient mal configurés et permettent de prendre la main sur une machine, les serveurs FTP mal configurés sont un danger immédiat , mais tout type de serveur peut présenter des failles de sécurité pouvant déboucher sur une prise de contrôle. Le pirate qui réussit l'opération peut alors installer une porte dérobée pour la suite des opérations.
2-2-4-1. Parades▲
- Ne pas installer de serveur inutile.
- Mettre en place toutes les sécurités proposées par les serveurs que l'on a installés et vérifier périodiquement sur les sites des constructeurs de ces logiciels l'apparition de mises à jour de sécurité.
- Filtrer efficacement les accès sur les ports que l'on souhaite laisser ouverts.
- D'une manière générale, se tenir au courant des patchs, service packs et autres correctifs qui sortent et les installer systématiquement.
2-2-5. Les « spoofing », « hijacking » et autres « SYN Flood »▲
Le jeu consiste à se faire passer pour un autre au cours d'une connexion TCP. Le principe est assez compliqué, mais redoutable s'il réussit. En général, le pirate utilise ces méthodes pour placer une porte dérobée qu'il utilisera par la suite. Vous serez sans doute tout à fait rassurés de savoir qu'il traîne sur l'Internet des programmes spécialement conçus pour ce genre d'intrusions.
Il est très délicat de se protéger de ces d'attaques.
2-2-5-1. Parades▲
Pas à ma connaissance, sauf si le pirate utilise un « SYN Flood » et que le logiciel firewall sait le détecter. Ici, il faut être préventif et curatif. Comme un spoofing ne s'improvise pas, le malintentionné a déjà certainement pas mal tourné autour de votre machine. Prise d'empreinte de la pile TCP/IP, scan des ports ouverts et c'est à ce niveau qu'il faut le débusquer et le coincer. Par ailleurs, il se contentera dans cette phase d'installer une porte dérobée ou de créer un compte d'administrateur, choses qui sont détectables si l'on y prend garde en vérifiant périodiquement l'état de son système.
2-2-6. Les blocages▲
Ce n'est pas à proprement parler une intrusion. C'est assez facile à faire, ce n'est pas forcément dangereux, mais la machine ciblée se bloque, forçant parfois un« « reset » » sauvage, on appelle ça un«  « denial of Service ». »
Pour ce genre d'attaque, le «  méchant » utilise des failles dans le NOS pour bloquer le système distant. Le «  ping de la mort » en est un bon exemple. Le jeu consiste à envoyer un « echo request » avec une trame anormalement longue. Certains systèmes y sont sensibles et se bloquent. Le « méchant » n'y gagne rien, il a juste la joie de vous avoir obligé à faire un reset.
2-2-6-1. Parades▲
Un firewall bien configuré arrive généralement à éviter ce genre de problèmes.
2-3. ICMP, le protocole qui fait peur▲
Rappelons ici que le protocole ICMP est avant tout destiné au transport d'informations sur le fonctionnement du réseau. Il travaille au même niveau qu'IP. Vous trouverez ici des détails sur ce protocole.
ICMP couvre tous les besoins de signalisation des équipements de réseau. Il est clair que l'utilisateur final n'a pas besoin de tous les signaux possibles, c'est cependant une erreur de croire que l'on peut tous les bloquer sans problèmes. Voici quelques éléments de réponse à l'épineuse question : ICPM oui ou non ?
2-3-1. Le PING▲
Le ping peut éventuellement être une source de désagréments :
- il contribue à révéler votre présence sur le Net ;
- il peut servir à obtenir un déni de service (blocage de la machine).
Vous pouvez bloquer les ping request (signal 8) à l'entrée de votre machine, ça ne prête pas à conséquences.
2-3-2. Hôte inaccessible▲
C'est le signal 3. Il sert à indiquer que l'hôte que l'on cherche à joindre ne répond pas. C'est certainement le signal le plus utile pour les clients du Net.
Il ne faut pas bloquer ce signal, du moins en entrée, faute de quoi les couches supérieures du protocole ne pourront pas être informées et ne réagiront pas en conséquence.
Par ailleurs, ce signal intervient dans la découverte du MTU (Maximum Transfert Unit). C'est la taille la plus grosse qu'un paquet peut prendre avant de devoir subir une fragmentation. Si ce processus est mis en œuvre et que le signal 3 est bloqué, les paquets envoyés risquent d'être systématiquement trop grands et donc systématiquement fragmentés (voire rejetés parfois). Dans ce cas, les performances de la connexion risquent de devenir déplorables.
Ce signal est-il par ailleurs dangereux ? Pas à ma connaissance.
2-3-3. Horodatage▲
Ce signal peut donner des indications sur le fuseau horaire sur lequel vous vous trouvez. Son utilisation est assez similaire au ping. Comme vous ne voulez pas forcément donner ce genre d'information à un éventuel pirate, bloquez-le (signal 13). A priori, ça ne devrait pas perturber le bon fonctionnement de votre connexion.
2-3-4. TTL expiré▲
Information aussi intéressante que « hôte inaccessible ». Ce signal (signal 11) est utilisé dans la commande traceroute.
Il n'est pas utile, voire néfaste de bloquer ce signal.
2-3-5. Redirection nécessaire▲
Ce signal n'est en principe utile que pour les routeurs. Il peut servir à manipuler à distance la table des routes (commande route print sous Windows, ou route sous GNU/Linux).
Du fait de ces risques, il vaut mieux le bloquer.
En ce qui concerne les autres signaux, je n'ai trouvé aucune information indiquant s'il valait mieux les bloquer ou non. À mon sens, le signal 17 (requête de masque de réseau) ne perd rien à être bloqué. À essayer pour voir.
3. Analyse de cas « classiques »▲
Commençons par voir ce qu'il se passe sur une machine « propre », c'est-à -dire non infectée par des chevaux de Troie, ou toute application destinée à en prendre le contrôle à distance.
3-1. Un poste « classique » sous Windows 98▲
L'expérience est tentée sur deux postes Windows 98, l'un avec le partage de fichiers activé et l'autre non. Nous faisons un scan de ports TCP et UDP avec nmap depuis un poste Linux situé sur le réseau.
3-1-1. Ports TCP▲
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on michele.maison.mrs (192.168.0.2):
(The 1522 ports scanned but not shown below are in state: closed)
Port State Service
139/tcp open netbios-ssn
TCP Sequence Prediction: Class=trivial time dependency
Difficulty=2 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98
Nmap run completed -- 1 IP address (1 host up) scanned in 1 second3-1-2. Ports UDP▲
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Warning: No TCP ports found open on this machine,
OS detection will be MUCH less reliable
Interesting ports on michele.maison.mrs (192.168.0.2):
(The 1446 ports scanned but not shown below are in state: closed)
Port State Service
137/udp open netbios-ns
138/udp open netbios-dgm
Too many fingerprints match this host for me to give an accurate OS guess
Nmap run completed -- 1 IP address (1 host up) scanned in 8 secondsCe qu'il est intéressant de constater au premier abord, c'est que les mêmes ports sont ouverts, que l'on ait activé le partage des fichiers ou non. La seule chose qui diffère, c'est que le poste sur lequel le partage n'a pas été activé n'est pas visible dans le voisinage réseau.
Les seuls ports ouverts sont ceux utilisés par NetBIOS.
3-2. Un poste de travail Windows 2000▲
Prenons un autre exemple un peu plus compliqué, mon poste de travail sous Windows 2000. (Je vous rappelle qu'il n'est pas directement connecté à l'Internet, j'ai une passerelle Linux entre les deux :-)
Ce poste est considéré comme une station de travail et en aucun cas comme un serveur. Il ne doit donc théoriquement pas y avoir de ports à l'écoute sur l'Internet.
Sur ce poste, j'utilise Frontpage 2000, j'ai donc un serveur web personnel (proposé par Windows 2000). Voici ce que donne un scan de ports TCP avec Nmap depuis ma passerelle Linux :
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on chris.maison.mrs (192.168.0.10):
(The 1517 ports scanned but not shown below are in state: closed)
Port State Service
80/tcp open http
135/tcp open loc-srv
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
TCP Sequence Prediction: Class=random positive increments
Difficulty=14803 (Worthy challenge)
Remote operating system guess: Windows 2000 RC1 through final release
Nmap run completed -- 1 IP address (1 host up) scanned in 1 secondComme vous le constatez, il y a 5 ports ouverts en écoute sur cette machine. Parmi ceux-ci, il y en a un bon nombre qui présentent des dangers.
3-2-1. Le port 80▲
C'est normal, PWS est actif (Personal Web Server). Ce serveur HTTP est utile pour la composition de sites avec Frontpage, pour la mise à disposition de documents sur le réseau privé, en revanche, il pourrait être dangereux de le laisser visible sur l'Internet…
3-2-2. Le port 135▲
Celui-ci doit présenter quelques dangers…
C'est le serveur RPC (Remote Procedure Call), c'est-à -dire le mécanisme qui permet à distance de déclencher l'exécution de procédures sur ma machine (par un administrateur uniquement). Il est clair que ce port ne doit pas être accessible depuis l'Internet.
3-2-3. Le port 139▲
Ah, celui-là est bien connu. C'est un des mécanismes de service de noms NetBIOS (le voisinage réseau). Absolument rien à faire sur l'Internet…
3-2-4. Le port 443▲
HTTP « sécurisé » (HTTPS). Ouvert également par PWS.
3-2-5. Le port 445▲
Celui-ci, c'est une originalité de Windows 2000. Pour le service de noms, Microsoft a toujours utilisé son système WINS, basé sur NetBIOS. Depuis Windows 2000, il existe également un service de noms basé sur un DNS dynamique, qui n'utilise pas NetBIOS. Ce port est ouvert pour ce nouveau service et ne devrait se rencontrer que sur les machines Windows 2000 et suivants.
Passons maintenant à un scan de ports UDP :
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Warning: No TCP ports found open on this machine,
OS detection will be MUCH less reliable
Interesting ports on chris.maison.mrs (192.168.0.10):
(The 1442 ports scanned but not shown below are in state: closed)
Port State Service
135/udp open loc-srv
137/udp open netbios-ns
138/udp open netbios-dgm
445/udp open microsoft-ds
500/udp open isakmp
3456/udp open vat
Too many fingerprints match this host for me to give an accurate OS guess
Nmap run completed -- 1 IP address (1 host up) scanned in 9 secondsNous avons déjà vu le port 135. Les ports 137 et 138 sont des services NetBIOS toujours pour la résolution des noms et les ouvertures de sessions. Nous avons également déjà rencontré le port 445, spécifique à Windows 2000.
Le port 500 est utilisé par HTTPS, pour la négociation de clés de cryptage. Encore un port ouvert par PWS.
3-3. Un poste de travail Windows XP SP3▲
3-3-1. Pare-feu désactivé▲
IIS n'est pas installé. Un scan TCP :
Starting Nmap 4.53 ( http://insecure.org ) at 2008-05-26 09:30 CEST
Initiating ARP Ping Scan at 09:30
Scanning 172.16.129.250 [1 port]
Completed ARP Ping Scan at 09:30, 0.01s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 09:30
Completed Parallel DNS resolution of 1 host. at 09:30, 0.00s elapsed
Initiating SYN Stealth Scan at 09:30
Scanning 172.16.129.250 [1714 ports]
Discovered open port 3389/tcp on 172.16.129.250
Discovered open port 135/tcp on 172.16.129.250
Discovered open port 139/tcp on 172.16.129.250
Discovered open port 445/tcp on 172.16.129.250
Completed SYN Stealth Scan at 09:30, 1.29s elapsed (1714 total ports)
Initiating Service scan at 09:30
Scanning 4 services on 172.16.129.250
Completed Service scan at 09:30, 6.00s elapsed (4 services on 1 host)
Initiating OS detection (try #1) against 172.16.129.250
Retrying OS detection (try #2) against 172.16.129.250
Retrying OS detection (try #3) against 172.16.129.250
Retrying OS detection (try #4) against 172.16.129.250
Retrying OS detection (try #5) against 172.16.129.250
SCRIPT ENGINE: Initiating script scanning.
SCRIPT ENGINE: rpcinfo.nse is not a file.
SCRIPT ENGINE: Aborting script scan.
Host 172.16.129.250 appears to be up … good.
Interesting ports on 172.16.129.250:
Not shown: 1710 closed ports
PORT STATE SERVICE VERSION
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
3389/tcp open microsoft-rdp Microsoft Terminal Service
MAC Address: 00:11:2F:41:C7:57 (Asustek Computer)
No exact OS matches for host (If you know what OS is running on it, see http://insecure.org/nmap/submit/ ).
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=258 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: OS: Windows
Read data files from: /usr/share/nmap
OS and Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 17.615 seconds
Raw packets sent: 1938 (88.840KB) | Rcvd: 1800 (85.270KB)Avec le pare-feu actif, en autorisant les exceptions suivantes :
- bureau à distance ;
- partage de fichiers et d'imprimantes.
Starting Nmap 4.53 ( http://insecure.org ) at 2008-05-26 09:36 CEST
Initiating ARP Ping Scan at 09:36
Scanning 172.16.129.250 [1 port]
Completed ARP Ping Scan at 09:36, 0.01s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 09:36
Completed Parallel DNS resolution of 1 host. at 09:36, 0.00s elapsed
Initiating SYN Stealth Scan at 09:36
Scanning 172.16.129.250 [1714 ports]
Discovered open port 3389/tcp on 172.16.129.250
Discovered open port 135/tcp on 172.16.129.250
Discovered open port 139/tcp on 172.16.129.250
Discovered open port 445/tcp on 172.16.129.250
Completed SYN Stealth Scan at 09:36, 8.66s elapsed (1714 total ports)
Initiating Service scan at 09:36
Scanning 4 services on 172.16.129.250
Completed Service scan at 09:36, 6.00s elapsed (4 services on 1 host)
Initiating OS detection (try #1) against 172.16.129.250
Retrying OS detection (try #2) against 172.16.129.250
SCRIPT ENGINE: Initiating script scanning.
SCRIPT ENGINE: rpcinfo.nse is not a file.
SCRIPT ENGINE: Aborting script scan.
Host 172.16.129.250 appears to be up … good.
Interesting ports on 172.16.129.250:
Not shown: 1710 filtered ports
PORT STATE SERVICE VERSION
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
3389/tcp open microsoft-rdp Microsoft Terminal Service
MAC Address: 00:11:2F:41:C7:57 (Asustek Computer)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|authentication server
Running (JUST GUESSING)Â : Microsoft Windows XP|2000|2003 (98%), Juniper Windows 2000 (90%)
Aggressive OS guesses: Microsoft Windows XP SP2 (98%), Microsoft Windows 2000 SP4 or Windows XP SP2 (93%),
Microsoft Windows 2003 Small Business Server (93%), Microsoft Windows XP Professional SP2 (93%),
Microsoft Windows Server 2003 SP0 or Windows XP SP2 (93%), Microsoft Windows Server 2003 SP1 or SP2 (91%),
Microsoft Windows XP SP 2 (91%), Microsoft Windows XP SP2 (firewall disabled) (91%),
Microsoft Windows XP Professional SP2 (firewall enabled) (91%), Microsoft Windows Server 2003 SP2 (90%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=260 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: OS: Windows
Read data files from: /usr/share/nmap
OS and Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 19.020 seconds
Raw packets sent: 3493 (157.302KB) | Rcvd: 31 (2132B)Pas grand-chose de changé ici.
Voyons maintenant avec le pare-feu actif, sans aucune exception :
Starting Nmap 4.53 ( http://insecure.org ) at 2008-05-26 09:45 CEST
Initiating ARP Ping Scan at 09:45
Scanning 172.16.129.250 [1 port]
Completed ARP Ping Scan at 09:45, 0.02s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 09:45
Completed Parallel DNS resolution of 1 host. at 09:45, 0.00s elapsed
Initiating SYN Stealth Scan at 09:45
Scanning 172.16.129.250 [1714 ports]
Completed SYN Stealth Scan at 09:45, 36.54s elapsed (1714 total ports)
Initiating Service scan at 09:45
Initiating OS detection (try #1) against 172.16.129.250
Retrying OS detection (try #2) against 172.16.129.250
SCRIPT ENGINE: Initiating script scanning.
SCRIPT ENGINE: rpcinfo.nse is not a file.
SCRIPT ENGINE: Aborting script scan.
Host 172.16.129.250 appears to be up … good.
All 1714 scanned ports on 172.16.129.250 are filtered
MAC Address: 00:11:2F:41:C7:57 (Asustek Computer)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop
Read data files from: /usr/share/nmap
OS and Service detection performed. Please report any incorrect results at http://insecure.org/nmap/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 39.523 seconds
Raw packets sent: 3477 (157.546KB) | Rcvd: 18 (936B)La moralité de l'histoire, c'est que dans ce cas, plus aucun port n'est accessible, ce qui est plutôt une bonne nouvelle si votre machine est directement connectée à l'Internet.
3-4. Conclusions▲
Il est clair qu'il y a toujours quelques ports ouverts sur un hôte, sauf dans le cas de Windows XP (SP3 ici), avec le pare-feu actif sans aucune exception. Si les ports UDP ne présentent pas trop de dangers encore que…), les ports TCP sont plus inquiétants.
Par ailleurs, certaines machines de marque comme Compaq ou Hewlett Packard installent des dispositifs d'administration distante qui ouvrent également des ports à l'écoute et l'utilisateur ne le sait pas forcément.
Il importe donc de savoir avec le plus de précision possible ce qui est installé sur sa machine, volontairement ou involontairement.
4. Contrôles possibles▲
4-1. Vérifications « à la main »▲
Il existe un certain nombre de commandes en ligne qui permettent de vérifier l'état de votre machine vis-à -vis du réseau. Nous allons essayer d'en voir quelques-unes et ce que l'on peut en tirer comme informations.
4-1-1. Rappel sur la configuration de test▲
Pour mieux comprendre la suite, rappelons la configuration avec laquelle ces tests vont être effectués :
Le poste de travail est sous Windows 2000, il s'appelle « pchris ». Il est connecté à la passerelle Linux via eth1.
La passerelle GNU/Linux est connectée à l'Internet via eth0, elle s'appelle « gateway1 ». Cette passerelle fait tourner un serveur SAMBA, qui permet d'ajouter les composants NetBIOS pour pouvoir partager des partitions Linux sur un réseau Microsoft. Ce n'est pas une solution exempte de dangers pour la sécurité de la passerelle, mais il est simple de filtrer les ports 137 à 139. Par ailleurs, SAMBA permet de définir la plage d'adresses autorisées à accéder aux ressources, ainsi que les interfaces réseau à utiliser. Ce sont des protections supplémentaires à ne pas négliger.
4-1-2. La commande « netstat »▲
La commande « netstat » est bien instructive, même si elle n'est pas toujours très lisible. Elle affiche les statistiques de protocole et les connexions réseau TCP/IP en cours.
E:\>netstat
Connexions actives
Proto Adresse locale Adresse distante Etat
TCP pchris:1031 gateway1.maison.mrs:netbios-ssn ESTABLISHED**Tout à fait normal. C'est la session réseau NetBIOS qui est à l'œuvre. En effet, dans mon voisinage réseau, je vois la passerelle.
Une variante de la commande :
E:\>netstat -n
Connexions actives
Proto Adresse locale Adresse distante Etat
TCP 192.168.0.10:1031 192.168.0.250:139 ESTABLISHED**Elle donne les mêmes informations, mais sans résoudre ni les adresses IP ni les ports.
Si j'arrête le serveur SAMBA sur la passerelle, cette connexion va disparaître, mais je ne verrai plus gateway1 dans mon voisinage réseau.
Attention, la liste était simple parce que je ne faisais rien de spécial sur l'Internet. Voici la liste si j'ouvre Internet Explorer sur http://www.altavista.fr :
E\:>netstat
Connexions actives
Proto Adresse locale Adresse distante Etat
TCP pchris:1031 gateway1.maison.mrs:netbios-ssn ESTABLISHED
TCP pchris:1296 gateway1.maison.mrs:5901 ESTABLISHED
TCP pchris:1304 212.187.226.53:http TIME_WAIT
TCP pchris:1311 195.154.216.235:http TIME_WAIT
TCP pchris:1318 195.154.216.235:http TIME_WAIT
TCP pchris:1327 212.187.226.53:http TIME_WAIT
TCP pchris:1331 195.154.216.235:http TIME_WAIT
TCP pchris:1333 a213-56-194-51.deploy.akamaitechnologies.com:http ESTABLISHED
TCP pchris:1334 a213-56-194-51.deploy.akamaitechnologies.com:http ESTABLISHED
TCP pchris:1335 212.187.226.41:http ESTABLISHED
TCP pchris:1338 195.154.216.235:http TIME_WAITIl convient donc d'être prudent dans l'interprétation des résultats de cette commande qui liste toutes les connexions existant à un instant donné. Pour détecter des « connexions indélicates », il faut être certain que votre poste n'a aucune activité « normale » sur l'Internet (pas de navigateur ouvert, pas de client de messagerie, etc.).
La commande « netstat » dispose de quelques options, voici pour ceux qui voudraient un peu s'amuser avec la documentation extraite de Windows 2000 (je ne garantis pas qu'elle soit entièrement compatible avec Windows 98).
Netstat
Affiche les statistiques de protocole et les connexions réseau TCP/IP en cours. Cette commande est disponible uniquement si le protocole TCP/IP est installé.
| netstat [-a] [-e] [-n] [-s] [-p protocole] [-r] [intervalle] | |
| Paramètres | |
| -a | Affiche toutes les connexions et les ports d'écoute. Les connexions serveur ne sont en principe pas affichées. |
| -e | Affiche des statistiques relatives à Ethernet. Ce paramètre peut être combiné avec l'option -s. |
| -n | Affiche les adresses et numéros de ports sous la forme numérique (au lieu de tenter des recherches par nom). |
| -s | Affiche les statistiques des protocoles respectifs. Par défaut, les statistiques de TCP, UDP, ICMP et IP sont affichées. L'option -p peut être utilisée pour spécifier un sous-ensemble des protocoles par défaut. |
| -p protocole | Affiche les connexions du protocole spécifié par le paramètre protocole ; ce paramètre peut avoir pour valeur tcp ou udp. Quand il est utilisé avec l'option -s pour afficher des statistiques par protocole, protocol peut prendre la valeur tcp, udp, icmp ou ip. |
| -r | Affiche le contenu de la table de routage. |
| intervalle | Affiche les statistiques sélectionnées de manière répétée avec un intervalle (en secondes) entre chaque occurrence. Appuyez sur CTRL+C pour interrompre l'affichage des statistiques. Si ce paramètre est omis, netstat n'imprime qu'une seule fois les informations de configuration. |
4-1-3. La commande « arp »▲
Affiche et modifie les tables de conversion des adresses physiques IP employées par le protocole ARP (Address Resolution Protocol). Il s'agit ici d'une conversion au niveau du sous-réseau. Le protocole ARP permet, dans un sous-réseau, d'établir une relation entre adresse IP et adresse MAC, celle qui est employée par la couche d'accès réseau pour acheminer les données.
Autrement dit, si quelqu'un tente de se connecter sur votre machine alors qu'il est dans le même sous-réseau que vous (un autre abonné câble de votre branche), vous le verrez. Mais si la tentative vient d'un autre réseau, vous ne verrez qu'une connexion à la passerelle.
4-1-3-1. Un exemple▲
Test de la commande « arp » sur le poste de travail :
E:\>arp -a
Interface : 192.168.0.10 on Interface 0x1000003
Adresse Internet Adresse physique Type
192.168.0.250 00-20-18-61-90-e3 dynamique**192.168.0.250, c'est l'adresse de ma passerelle sur eth1.
Même commande sur la passerelle Linux (pour une fois que l'on a les mêmes outils dans les deux environnements) :
[root@gateway1 chris]# arp -a
ca-ol-marseille-9-1.abo.wanadoo.fr (213.56.56.1) at 00:D0:79:72:5C:00 [ether] on eth0
chris.maison.mrs (192.168.0.10) at 00:20:18:B9:49:37 [ether] on eth1**J'ai deux connexions :
- la première sur 213.56.56.1 par eth0, c'est normal, c'est la passerelle par défaut que le client DHCP a récupéré ;
- la seconde sur 192.168.0.10 par eth1, c'est encore normal, c'est mon poste de travail.
Il est possible que la commande vous réponde :
E:\>arp -a
Aucune entrée ARP trouvéeCe n'est pas alarmant, si vous n'avez pas utilisé la connexion depuis un certain temps, la table ARP s'est vidée. Ce qui éventuellement peut-être plus dérangeant, c'est lorsque votre table ARP indique des connexions multiples et pas forcément faciles à justifier :
il vous faudra alors essayer d'identifier ces connexions en fonction de ce que vous êtes en train de faire sur votre machine.
Voici les diverses options de la commande « arp » :
| Arp : affiche et modifie les tables de conversion des adresses physiques IP (Ethernet ou anneau à jeton) employées par le protocole ARP (Address Resolution Protocol). Cette commande est disponible uniquement si le protocole TCP/IP est installé. arp -a [adr_inet] [-N [adr_si]] arp -d adr_inet [adr_si] arp -s adr_inet adr_ether [adr_si] |
|
| Paramètres | |
| -a | Affiche les entrées ARP en cours en interrogeant TCP/IP. Si adr_inet est spécifié, seules les adresses physiques et IP du système spécifié apparaissent. |
| -g | Identique à -a. |
| adr_inet | Spécifie une adresse IP en notation décimale pointée. |
| -N | Affiche les entrées ARP pour l'interface réseau spécifiée par adr_si. |
| adr_si | Spécifie, le cas échéant, l'adresse IP de l'interface dont la table de conversion des adresses doit être modifiée. Si elle n'est pas spécifiée, la modification est appliquée à la première interface rencontrée. |
| -d | Supprime l'entrée spécifiée par adr_inet. |
| -s | Ajoute une entrée dans la mémoire cache ARP pour associer l'adresse IP adr_inet à l'adresse physique adr_ether. L'adresse physique se compose de six octets hexadécimaux séparés par des tirets. L'adresse IP est spécifiée en notation décimale pointée. L'entrée est permanente, c'est-à -dire qu'elle est automatiquement supprimée du cache à l'expiration de la temporisation. |
| adr_ether | Spécifie une adresse physique. |
4-2. Les outils d'audit▲
Sous Linux, il existe une foule d'outils permettant de tracer le trafic réseau. En général, ces outils sont capables d'afficher ou d'enregistrer (ou les deux) tout ce qui est visible sur une interface réseau, concernant les protocoles TCP, UDP, ICMP et même ARP.
Brutalement, ça ressemble un peu à un « sniffer », à part que les trames sont identifiées, mais pas visualisées en entier et que, normalement, seules les trames destinées à l'hôte sont analysées (pas de mode « promiscuité »).
Ces outils nécessitent la mise en place de règles de filtrage, sans quoi, ils enregistrent absolument tout ce qui entre depuis le réseau concerné.
Ce ne sont pas à proprement parler des outils de protection, mais ils permettent de contrôler le trafic et constituent un excellent moyen d'apprentissage. Bien configurés, ils peuvent servir d'alarme en cas d'activité jugée suspecte.
Parmi les plus connus sous Linux, il y a ippl (qui ne semble plus évoluer), iptraf et bien sûr Snort, TCPDump, Tshark, Fail2ban, etc.
L'audit ne se résume cependant pas aux traces générées par ce genre d'outils. Les systèmes d'exploitation « sérieux » construisent des journaux d'audit du système qui permettent de savoir qui s'est connecté sur la machine, quel service a été démarré, utilisé, arrêté… Autant d'informations qu'il ne faut pas négliger de consulter régulièrement.
5. Protections▲
5-1. Savoir ce qui est installé▲
La première règle est bien entendu de savoir exactement quels sont les services installés sur sa machine et de n'y laisser que ce qui est strictement nécessaire. Cette méthode, surtout dans le cas d'un réseau local connecté à l'Internet par une passerelle est toutefois assez pénalisante. On peut souhaiter disposer de quelques services sur l'hôte qui sert de passerelle.
Bien entendu, la solution la plus sûre consiste à installer une passerelle qui ne fera que son travail de passerelle et de firewall et d'installer par ailleurs sur le réseau privé un serveur pour les divers services souhaités. Ceci augmente tout de même le nombre de machines et la facture EDF. Ça ne résoudra pas non plus certains problèmes pour les entreprises qui souhaitent accéder à certaines de leurs ressources depuis l'extérieur, mais le cas de figure dépasse largement le propos de cet exposé.
5-2. Construire une barrière▲
5-2-1. État des lieux▲
Une solution de protection consiste à interdire l'accès aux ports inutiles côté Internet. L'étude qui suit date un peu, mais malgré l'obsolescence du système utilisé, elle n'en est pas moins toujours pertinente.
Sur Linux Mandrake 7.x (plus généralement avec un noyau 2.2.x bien compilé), ceci peut se faire avec IPChains. Les noyaux 2.4.x et supérieurs, bien que supportant IPChains, gagneront à exploiter plutôt IPTables, nettement plus évolué.
Pour fixer les esprits, donnons un exemple.
Soit une machine Linux servant de passerelle sur l'Internet. Comme on aime bien jouer avec les diverses applications fournies, on y a installé :
- SAMBA, pour communiquer avec le réseau Microsoft ;
- APACHE, pour tester ses pages web sur un serveur classique de l'Internet ;
- WU-FTPD, serveur FTP pour pouvoir charger ses pages HTML avec les outils de FrontPage ;
- BIND, pour avoir son propre DNSÂ ;
- POSTFIX, pour avoir son propre serveur SMTPÂ ;
- VNC SERVER pour ouvrir des sessions X depuis les postes Microsoft du réseau privé ;
- et j'en passe…
Et comme on ne veut pas s'embêter, la règle par défaut sur INPUT est ACCEPT.
Croyez-vous que ce soit prudent ? Pas du tout bien entendu. Sur une machine exposée à l'Internet, moins on installe de serveurs, mieux ça vaut. Examinons ce que verrait un pirate qui ferait un « scan » de cette machine avec l'un des meilleurs outils dans le genre nmap (inclus dans toutes les bonnes distributions GNU/Linux).
5-2-2. Démonstration▲
De quoi vraiment donner envie de s'y intéresser de plus près !
- 21, c'est WU-FTPD.
- 23, Telnet, ah ! nous verrons ça…
- 25, c'est Postfix, faudra voir si ce ne serait pas un « open relay » :-).
- 53, tiens, il y a un DNS, intéressant.
- 80, sans doute Apache.
- 139, ce monsieur a installé SAMBA. Bon, ça suffit comme ça pour l'instant. Exploitons un peu le sujet…
Telnet, c'est intéressant :
Welcome to gateway2.maison.mrs
Linux Mandrake release 7.1 (helium)
Kernel 2.2.16-9mdk on an i586
login:Voilà , une Mandrake 7.1 avec un kernel 2.2.16-9 et la machine s'appelle gateway2.maison.mrs. Ça, c'est intéressant. Allons faire un tour sur le DNS du monsieur…
E:\>nslookup
Serveur par défaut : <peu importe>
Address: <peu importe>
> server 62.161.100.113
Serveur par défaut : ca-ol-marseille-5-113.abo.wanadoo.fr
Address: 62.161.100.113
> set q=any
> ls maison.mrs
[ca-ol-marseille-5-113.abo.wanadoo.fr]
maison.mrs. NS server = gateway2.maison.mrs
gateway2 A 192.168.0.253
remi A 192.168.0.12
michele A 192.168.0.2
chris A 192.168.0.10
gateway1 NS server = 192.168.0.250
daniel A 192.168.0.11
gateway2 NS server = 192.168.0.253**Et hop ! On sait tout du réseau de ce monsieur :-) et même, si vous avez bien suivi, que ce monsieur dispose sans doute d'une seconde machine du même genre qui s'appelle gateway1.
Il faut dire que c'est quand même très mal, de laisser libre le transfert de zone sur un DNS. Mais j'ai trouvé cette gravissime lacune sur des sites très « professionnels ».
Reprenons le scénario, mais avec BIND correctement configuré. Ça donne ceci :
E:\>nslookup
Serveur par défaut : gateway1.maison.mrs
Address: 192.168.0.250
> server 62.161.100.113
Serveur par défaut : ca-ol-marseille-5-113.abo.wanadoo.fr
Address: 62.161.100.113
> set q=any
> ls maison.mrs.
ls: connect: No error
*** Impossible de fournir la liste du domaine maison.mrs.: Unspecified error
> pchris.maison.mrs
Serveur : ca-ol-marseille-5-113.abo.wanadoo.fr
Address: 62.161.100.113
*** ca-ol-marseille-5-113.abo.wanadoo.fr ne parvient pas à trouver pchris.maison.mrs :
No response from serverC'est déjà mieux, au moins le DNS ne répond plus aux requêtes venant de l'Internet. Comment il faut faire ? Dans /etc/named.conf, il faut utiliser les directives « allow-transfert », « allow-query » et même « listen-on » (cf. la doc. de BIND).
Cet exemple est juste donné pour bien montrer que la sécurité passe d'abord par une configuration correcte des serveurs installés…
Mais continuons l'investigation. Voyons le serveur FTP, un petit coup de Telnet sur le port 21Â :
220 gateway2.maison.mrs FTP server (Version wu-2.6.0(1) Wed Jun 28 23:51:34
EDT2000) ready.Oui, c'est bien un wu-ftp, version 2.6.0. Faudra voir ce qu'il y a comme « exploits » là -dessus. On va s'arrêter là , mais il y a pas mal d'investigations à faire sur un serveur FTP.
Allez, encore un Telnet sur le port 25
220 gateway2.maison.mrs ESMTP Postfix (Postfix-19991231) (Linux-Mandrake)C'est bien Postfix. (Là aussi, il y aurait encore beaucoup à faire.)
Convaincu ? En très peu de temps, le pirate accumule une quantité intéressante d'informations sur votre équipement, autant d'informations qu'il pourra exploiter pour essayer de « casser » votre matériel.
Comme l'objectif de cet exposé n'est pas de faire un cours sur l'intrusion (encore que ce soit le meilleur moyen pour apprendre à mettre en place des parades), on va s'arrêter là .
La situation exposée est d'autant plus absurde, qu'avec IPTables, on peut déjà compliquer passablement le travail de l'indélicat.
Que les utilisateurs de Windows n'abandonnent pas la lecture de ce qui suit. La démonstration se fait avec IPtables, mais le principe reste vrai, quel que soit l'OS. Nous verrons plus loin les solutions proposées aux utilisateurs de produits Microsoft.
5-2-3. Construction de barrières▲
Disons d'abord ce que l'on veut faire en français. D'abord une simple passerelle avec masquage d'adresses du réseau privé :
- en entrée, on accepte tout par défaut (comme c'était dans l'exemple précédent) ;
- en sortie, on laisse tout passer aussi ;
- au travers de la passerelle (le routage entre le Net et le réseau privé), on n'accepte rien, mais on va faire du masquage d'adresse pour tout ce qui vient du réseau privé et va vers le Net.
Ensuite, pour tout ce qui vient du Net, nous bloquerons en UDP comme en TCP les ports :
- 21 tcp, qui est le port de commande FTPÂ ;
- 23 tcp, qui est le port Telnet ;
- 25 tcp, qui est le port SMTPÂ ;
- 110 tcp, qui est le port POP3Â ;
- 111 tcp/udp qui est le port des « Remote Procedure Call » ;
- 135 à 139 tcp/udp, des ports utilisés par NetBIOS,
- 143 tcp, le port IMAPÂ ;
- 6000 à 6009 tcp, les ports utilisés pour le serveur graphique.
iptables -P INPUT ACCEPT
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/255.255.255.0 -o ppp0 -j MASQUERADE
iptables -A INPUT -p tcp --dport 21 -i ppp0 -j REJECT
iptables -A INPUT -p tcp --dport 23 -i ppp0 -j REJECT
iptables -A INPUT -p tcp --dport 25 -i ppp0 -j REJECT
iptables -A INPUT -p tcp --dport 110 -i ppp0 -j REJECT
iptables -A INPUT -p tcp --dport 111 -i ppp0 -j REJECT
iptables -A INPUT -p udp --dport 111 -i ppp0 -j REJECT
iptables -A INPUT -p tcp --dport 135:139 -i ppp0 -j REJECT
iptables -A INPUT -p udp --dport 135:139 -i ppp0 -j REJECT
iptables -A INPUT -p tcp --dport 143 -i ppp0 -j REJECT
iptables -A INPUT -p tcp --dport 6000:6009 -i ppp0 -j REJECTTraduit en français, ça veut dire que l'on jette (REJECT) les paquets qui viennent de n'importe où pour aller n'importe où, s'ils ont le malheur de rentrer par ppp0 sur les ports 21, 23, 25, 110, 111, 139, 143 et de 6000 à 6009. C'est bien ce que nous voulions. Refaisons un scan :
Starting nmap V. 2.30BETA17 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Interesting ports on ca-ol-marseille-5-113.abo.wanadoo.fr (62.161.100.113):
(Ports scanned but not shown below are in state: filtered)
Port State Service Owner
1/tcp unfiltered tcpmux
2/tcp unfiltered compressnet
3/tcp unfiltered compressnet
…
80/tcp open http nobody
…
113/tcp open auth nobody
…
515/tcp open printer root
…
…
3306/tcp open mysql mysql
…
TCP Sequence Prediction: Class=random positive increments
Difficulty=4917615 (Good luck!)
Remote operating system guess: Linux 2.1.122 - 2.2.14**
Nmap run completed -- 1 IP address (1 host up) scanned in 220 secondsnmap ne s'y trompe pas, il constate qu'il y a des règles de filtrage sur cette machine et essaye de trouver les ports non filtrés. Il va en trouver beaucoup, mais ça ne veut pas dire qu'ils sont ouverts. Ceux qu'il trouve ouverts sont ceux que l'on n'a pas filtrés.
Il est clair que l'on a déjà limité les problèmes. Mais on pourrait encore faire beaucoup mieux. L'objectif ici n'était que de montrer comment l'on peut établir des règles de filtrage de paquets, mais d'expliquer comment un port peut être bloqué par un firewall.
Dans la pratique, il sera probablement plus judicieux de tout interdire, puis de n'ouvrir que ce qui est nécessaire. Voyez à ce propos le chapitre « NetFilter et IPtables ».
5-3. Conclusion▲
Ce type de protection passive offre déjà un bon niveau de sécurité, si l'on a convenablement analysé la configuration de sa machine et placé les bonnes règles. Il y aurait encore à faire sur cette machine, car si l'on a à peu près filtré les ports TCP, qui sont les plus dangereux parce qu'ils permettent un mode connecté, on n'a encore rien fait ni sur UDP, ni sur ICMP. Ces deux protocoles peuvent cependant créer des nuisances parce qu'ils peuvent être utilisés pour bloquer la machine.
Cependant, il est intéressant de placer en plus quelques systèmes qui vont épier le trafic et prévenir, voire réagir, en cas d'activité suspecte avec les « loggers » et les firewalls actifs.
IPtables sait déjà « logger » les événements qui satisfont aux critères des chaînes, mais il est peut-être plus intéressant d'utiliser des outils spécifiques.
5-4. Les miradors du Net▲
La plupart des attaques commencent par un scan des ports ouverts sur la cible. Des outils particuliers permettent de détecter ce scan, d'en identifier la source par son adresse IP et certains permettent même de monter un firewall « sur mesure » pour bloquer l'intrus. Le scanner n'aura même pas le temps de finir son travail et aura l'impression que la cible a disparu.
5-4-1. Les « loggers »▲
J'en ai plus ou moins testé trois sous Linux, il en existe beaucoup d'autres, chacun dispose, à mon sens, d'avantages et d'inconvénients. Bien qu'ils n'aient plus beaucoup évolué depuis pas mal de temps, ils sont toujours distribués dans Debian Etch.
5-4-1-1. IPTRAF▲
C'est peut-être le plus « convivial », mais pas forcément le plus paramétrable. Il fonctionne bien en mode texte, mais présente quelques bogues d'affichage dans une console sous X, suivant la taille de la fenêtre.
Les « anciens » de MS DOS retrouveront avec nostalgie les menus arborescents en mode caractère…
Ici, il est possible de choisir les protocoles à tracer.
Malheureusement, s'il est possible de définir des filtres personnalisés pour UDP, l'option n'existe pas pour les autres protocoles.
Il est également possible de choisir l'interface que l'on souhaite tracer
Voici un exemple de trace. Si les connexions TCP sont affichées de manière très lisible, il n'en va malheureusement pas de même pour les autres protocoles
5-4-1-2. IPPL▲
Celui-ci fonctionne de manière différente. Son but principal étant d'enregistrer la trace dans des fichiers, bien qu'il soit possible de diriger ses traces sur une console. Lui aussi se trouve encore dans la Debian Etch, bien que sa dernière version (1.4.14) remonte à septembre 2001.
Sa configuration se fait par le fichier /etc/ippl.conf, je n'ai malheureusement pas trouvé le moyen de limiter son activité à l'interface choisie autrement qu'en donnant son adresse IP, ce qui n'est guère pratique lorsque l'on dispose d'une adresse dynamique.
5-4-2. Snort▲
Il s'agit d'un outil de détection et de prévention d'intrusions. Disposant d'un langage de définition de règles, il travaille un peu comme un antivirus heuristique, en combinant des recherches de signatures et des analyses comportementales. Probablement l'outil le plus utilisé dans le monde, mais pas facile à maîtriser.
5-4-3. Conclusions▲
Un outil de log comme iplog est un bon moyen pour contrôler le trafic. Il ne sait cependant tracer que ce qu'il lui est demandé (ce que vous lui demandez) et uniquement ce qu'il lui est demandé. Ça veut dire deux choses importantes :
- il tracera des événements qui n'en valent peut-être pas la peine. Si vous lui demandez de tracer tout trafic sur une interface, il le fera. Les logs de la journée risqueront peut-être de peser plusieurs Mo et seront inexploitables, autrement que par des filtres qu'il vous faudra écrire ;
- il ne tracera peut-être pas des événements qu'il aurait été important de ne pas rater.
Vous apprendrez certainement beaucoup de choses en passant du temps à essayer de maîtriser ce genre d'outils.
5-5. Les coupe-feux actifs▲
Un coupe-feu actif, en plus de surveiller les connexions entrantes est capable de détecter une activité réputée frauduleuse et y parer de manière dynamique. Il existe sous Linux au moins une application de ce type : « Portsentry ».
5-5-1. Portsentry, le pompier du Net▲
Portsentry est capable de détecter un « scan » de ports TCP et UDP. La détection peut déclencher plusieurs types de parades :
- un simple « log » via syslogd. Dans ce cas, Portsentry agit comme un simple « loggeur », un peu léger toutefois, puisqu'il ne sait pas traiter les activités ICMP ;
- une inscription du scanner dans « hosts.deny », pour qu'il soit pris en compte par le « TCP Wrapper » ;
- l'ajout d'une règle dans la chaîne « input » d'IPtables pour bloquer l'intrus ;
- la modification de la route par défaut dans un « black hole » de manière à ce qu'une éventuelle réponse à l'intrus soit dirigée vers nulle part ;
- le déclenchement d'une commande externe pouvant être, par exemple, la désactivation pure et simple de l'interface réseau.
Bien entendu, ces parades sont configurables.
Portsentry ne semble plus évoluer depuis sa version 1.2 de 2003, mais est toujours disponible sur Debian Etch.
5-5-1-1. Juste un exemple▲
- Dans le rôle de l'intrus : 213.56.228.199. Une machine Linux équipée du scanner « nmap ».
- Dans le rôle du défenseur, une autre machine Linux, équipée de portsentry. La configuration est à peu de choses près celle qui est donnée par défaut dans le paquetage rpm pour Mandrake. En cas de détection de scan, portsentry va réagir de la manière suivante :
- inscription de l'intrus dans « /etc/hosts.deny » ;
- Écriture d'une règle de blocage dans IPChains (fonctionne aussi avec IPTables).
5-5-1-2. Avant l'attaque▲
Voyons un peu l'allure de la chaîne INPUT (IPtables) :
Chain INPUT (policy ACCEPT)
target prot opt source destination
REJECT tcp -- anywhere anywhere tcp dpt:telnet reject-with icmp-port-unreachable
REJECT tcp -- anywhere anywhere tcp dpt:smtp reject-with icmp-port-unreachableLes protections sont très simplistes, seuls Telnet et smtp sont filtrés.
Portsentry est démarré avec la commande « portsentry -atcp » (entamer ici une étude détaillée de portsentry nous mènerait trop loin).
Le démarrage de portsentry ajoute ces lignes au fichier /var/log/messages :
adminalert: Psionic PortSentry is starting.
adminalert: Advanced mode will monitor first 1023 ports
adminalert: Advanced mode will manually exclude port: 113
adminalert: Advanced mode will manually exclude port: 139
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 21
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 23
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 25
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 53
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 80
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 110
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 111
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 113
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 139
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 143
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 515
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 820
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 901
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 113
adminalert: Advanced Stealth scan detection mode activated. Ignored TCP port: 139
adminalert: PortSentry is now active and listening.5-5-1-3. L'attaque a lieu…▲
Le scan est démarré avec nmap sur l'hôte « pirate ». Portsentry s'en rend compte et effectue les opérations suivantes :
- les lignes qui suivent sont ajoutées au journal /var/log/messages
attackalert: SYN/Normal scan from host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 to TCP port:52
attackalert: Host 213.56.228.199 has been blocked via wrappers with string: « ALL: 213.56.228.199 »
attackalert: Host 213.56.228.199 has been blocked via dropped route
using command: « /sbin/ipchains -I input -s 213.56.228.199 -j DENY »
attackalert: SYN/Normal scan from host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 to TCP port:175
attackalert: Host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 is already blocked Ignoring
attackalert: SYN/Normal scan from host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 to TCP port:32
attackalert: Host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 is already blocked Ignoring
attackalert: SYN/Normal scan from host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 to TCP port:621
attackalert: Host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 is already blocked Ignoring
attackalert: SYN/Normal scan from host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 to TCP port:312
attackalert: Host: ca-ol-marseille-21-199.abo.wanadoo.fr/213.56.228.199 is already blocked Ignoring- la règle suivante est ajoutée dans la chaîne INPUT d'IPchains :
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all -- 213.56.228.199 anywhere
*** //L'attaquant est bloqué sur tous les ports, sur tous les protocoles,
*** quelle que soit la destination//**//
REJECT tcp -- anywhere anywhere tcp dpt:telnet reject-with icmp-port-unreachable
REJECT tcp -- anywhere anywhere tcp dpt:smtp reject-with icmp-port-unreachable- le fichier /etc/hosts.deny est modifié de la manière suivante :
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!
#
ALL: 213.56.228.1995-5-1-4. Bilan▲
L'attaquant n'aura même pas le temps de finir son scan. il aura l'impression que la cible n'existe plus, tout simplement.
N'est-ce pas joli ? Attention toutefois, si la modification de /etc/hosts.deny n'est pas volatile (écriture dans le fichier), il n'en va pas de même pour IPChains. Sans précautions particulières, si la machine est arrêtée, la règle sera perdue. Il existe cependant une parade grâce, par exemple, à la possibilité d'exécuter une commande externe en cas de détection d'attaque. Il suffit de sauvegarder la règle INPUT pour pouvoir la recharger au prochain démarrage. Ceci dit, les attaques venant le plus souvent d'adresses dynamiques, il n'est pas forcément nécessaire de rendre la règle définitive. Par ailleurs, si l'on agit sur IPChains, il n'est pas nécessaire de conserver l'option de modification de /etc/hosts.deny.
Notez tout de même que nous n'avons pas couvert les risques émanant :
- d'un scan UDP. C'est généralement moins dangereux, mais pas à négliger tout de même. Portsentry peut également être démarré pour surveiller les ports UDP, mais le fonctionnement est plus délicat et peut provoquer des réactions parasites ;
- d'une attaque ICMP. Portsentry ne sait rien faire contre ça. Il ne vous reste de ce côté qu'à écrire des règles correctes ;
- d'une attaque sans qu'il y ait de scan préalable.
Portsentry n'est donc, hélas pas, un outil miraculeux, il n'en existe d'ailleurs pas.
5-5-2. Fail2ban▲
Fail2ban lit des fichiers de log comme /var/log/pwdfail ou /var/log/apache/error_log et bannit les adresses IP qui ont obtenu un trop grand nombre d'échecs lors de l'authentification. Il met à jour les règles du pare-feu pour rejeter cette adresse IP. Ces règles peuvent être définies par l'utilisateur.
Il ne s'agit pas ici de détecter des « scans », mais des tentatives de « loggin ». Lorsque le logiciel détecte un nombre déterminé de loggins ratés dans un temps également déterminé, il peut déclencher un certain nombre d'actions :
- écriture d'une règle IPtables pour bloquer la source, pendant une durée paramétrable ;
- envoi d'un message d'alerte à l'administrateur.
Il peut surveiller plusieurs serveurs susceptibles de réclamer un loggin comme Openssh, Apache, Postfix, Proftpd, vsftpd,wuftpd, etc.
Voici un exemple de message reçu en cas de détection :
Hi,
The IP 62.38.244.99 has just been banned by Fail2Ban after
5 attempts against SSH.
Here are more information about 62.38.244.99:
% This is the RIPE Whois query server #2.
% The objects are in RPSL format.
…
## Suivent les informations recueillies par "hois"
Regards,On ne devrait pas pouvoir se passer de Fail2ban :-)
6. Les firewalls▲
Dans la page précédente, nous avons fait du « firewalling » sans le savoir. Pour donner quelques indications de plus, il est nécessaire de se pencher d'un peu plus près sur les diverses méthodes de construction d'un « firewall ».
6-1. D'abord, c'est quoi, un « firewall » ?▲
Typiquement, une installation complète contient :
- un réseau privé, dont on considère (souvent à tort) qu'il ne sera pas utilisé pour attaquer notre système informatique. Dans cette zone, il n'y a que des clients du réseau et des serveurs qui sont inaccessibles depuis l'Internet. Normalement, aucune connexion, au sens TCP du terme, aucun échange, au sens UDP du terme, ne peuvent être initiés depuis le Net vers cette zone ;
- une « DMZ » (Zone DéMilitarisée), qui contient des serveurs accessibles depuis le Net et depuis le réseau privé. Comme ils sont accessibles depuis le Net, ils risquent des attaques. Ceci induit deux conséquences :
- il faut étroitement contrôler ce que l'on peut faire dessus depuis le Net, pour éviter qu'ils se fassent « casser » trop facilement,
- il faut s'assurer qu'ils ne peuvent pas accéder aux serveurs de la zone privée, de manière à ce que si un pirate arrivait à en prendre possession, il ne puisse directement accéder au reste du réseau.
Les trois types de communications marquées 1, 2 et 3 sur l'illustration seront donc soumis à des règles de passage différentes. Le dispositif qui va permettre d'établir ces règles de passage s'appelle un firewall. Techniquement, ce pourra être un logiciel de contrôle installé sur un routeur.
Nous aurons, par exemple :
- le réseau privé dans une classe d'adresses IP privées, comme 192.168.0.0 ;
- la DMZ dans une autre classe privée comme 192.168.1.0 ou, si l'on a les moyens, dans un morceau de classe publique, de manière à pouvoir accéder à ces machines depuis le Net sans translation d'adresse ;
- une adresse publique attribuée au routeur sur le Net par le FAI. (Fixe ou dynamique. Dans ce type d'installation, il vaut mieux qu'elle soit fixe.)
Le routeur cumule ici deux fonctions :
- le routage proprement dit, pour permettre aux paquets de passer d'une zone à l'autre alors que ces zones ne sont pas situées dans le même réseau IP ;
- le filtrage du trafic entre les diverses zones, c'est la fonction de firewall.
Bien entendu, qui peut le plus peut le moins, il peut ne pas y avoir de DMZ, si l'on n'a pas besoin d'exposer de serveurs sur le Net.
Sur des petites structures, la DMZ peut être implantée sur le routeur lui-même. En effet, un routeur peut très bien n'être rien d'autre qu'un serveur avec plusieurs interfaces réseau et un logiciel de routage. Ce n'est bien entendu pas une solution très « propre » au sens de la sécurité.
6-2. Les trois passages▲
Revenons à notre schéma initial.
6-2-1. Entre le réseau privé et le Net▲
Toujours typiquement, ce sont les clients du réseau (les utilisateurs) à qui l'on va donner des possibilités d'accéder au Net comme le surf ou la messagerie. Toutes les requêtes partent du réseau privé vers le Net. Seules les réponses à ces requêtes doivent entrer dans cette zone. Les accès peuvent être complètement bridés (les clients du réseau privé n'ont aucun droit d'accès vers le Net, ça nuit à leur productivité. Seul le patron y a droit). Ou alors, les utilisateurs ne pourront consulter qu'un nombre de sites limités, dans le cadre de leurs activités professionnelles exclusivement. Très généralement, cette zone est construite sur une classe d'adresses privées et nécessite donc une translation d'adresse pour accéder au Net. C'est le routeur qui se chargera de cette translation.
6-2-2. Entre la DMZ et le Net▲
Ici, nous avons des serveurs qui doivent être accessibles depuis le Net. Un serveur Web, un serveur de messagerie, un FTP… Il faudra donc permettre de laisser passer des connexions initiées depuis l'extérieur. Bien entendu, ça présente des dangers, il faudra surveiller étroitement et ne laisser passer que le strict nécessaire.
Si l'on dispose d'adresses IP publiques, le routeur fera un simple routage. Si l'on n'en dispose pas, il devra faire du « port forwarding » pour permettre, avec la seule IP publique dont on dispose, d'accéder aux autres serveurs de la DMZ. Cette technique fonctionne bien sur un petit nombre de serveurs, mais devient très vite un casse-tête si, par exemple, plusieurs serveurs HTTP sont présents dans la DMZ.
6-2-3. Entre le réseau privé et la DMZ▲
Les accès devraient être à peu près du même type qu'entre la zone privée et le Net, avec un peu plus de souplesse. En effet, il faudra
- mettre à jour les serveurs web ;
- envoyer et recevoir les messages, puisque le SMTP est dedans ;
- mettre à jour le contenu du FTP (droits en écriture).
En revanche, depuis la DMZ, il ne devrait y avoir aucune raison pour qu'une connexion soit initiée vers la zone privée.
6-3. Les divers types de firewall▲
Bien. Maintenant que nous savons à peu près ce que l'on peut et ce que l'on ne peut pas faire entre les diverses zones, voyons comment construire ce firewall.
Il y a déjà deux moyens différents de s'y prendre. Soit l'on travaille au niveau TCP et UDP en s'intéressant aux adresses IP des sources et des cibles, ainsi qu'aux ports employés, nous ferons du filtrage de paquets, soit l'on travaille au niveau de l'application (HTTP, SMTP, FTP). Nous ferons alors du « proxying ».
Rien d'ailleurs n'interdit de faire les deux.
Si l'on travaille au niveau des paquets, il y a encore deux méthodes, l'une triviale et l'autre plus fine. Pour comprendre la différence entre les deux, ce n'est pas facile. Disons qu'une connexion entre un client et un serveur peut engendrer plusieurs connexions sur des ports différents.
Sans aller très loin, une simple consultation de page web suffit à expliquer ce qu'il se passe. Si le client envoie bien la requête toujours sur le port 80 du serveur, il attend en revanche la réponse sur un port qu'il va choisir aléatoirement, généralement en dessus de 1024. Comme le port de réponse est aléatoire, ça va être difficile de laisser passer les réponses sans ouvrir tous les ports au-dessus de 1024 en entrée vers la zone privée.
Pour être efficace, il faut être capable d'assurer un suivi de la connexion, en analysant la requête initiale pour découvrir le port sur lequel le client recevra la réponse et agir dynamiquement en fonction. C'est ce que l'on appelle le suivi de connexion (« conntrack » en jargon informaticoanglo-saxon).
6-3-1. Le firewall par filtrage simple de paquets (« stateless »)▲
C'est donc le plus trivial. Il ne sait que vérifier si les « sockets » (couple adresse IP : port) source et destination sont conformes ou non à des autorisations de passage. Dans la pratique, si la machine cliente d'IP 217.146.35.25 doit pouvoir accéder au serveur web 124.8.3.251 et, bien entendu, recevoir ses réponses, nous dirons en français :
- les paquets venant de 217.146.35.25 vers 124.8.3.251, port 80 passent ;
- les paquets venant de 124.8.3.251, port 80 vers 217.146.35.25, ports >=1024 passent.
Si nous voulons étendre à tous les serveurs web possibles, nous ne pourrons plus tenir compte de l'IP des serveurs, ça aura pour conséquence que tout le Net pourra accéder à 217.146.35.25 sur tous les ports au-dessus de 1024.
Si nous voulons que toute la zone privée puisse accéder à tous les serveurs web du Net, alors, tout le réseau privé sera accessible sur les ports au-dessus de 1024.
L'exemple est minimaliste, les IP des clients sont des IP publiques, il n'y a pas de translation d'adresse mise en œuvre, ce qui rend les risques maximums. Dans la pratique, le cas est rarissime. Il ne sert ici qu'à montrer les limites de ce filtrage simple. Notez qu'avec de tels systèmes, la translation d'adresse est de toute manière rendue impossible. Pour faire de la translation d'adresse, il faut être capable de suivre les connexions.
6-3-2. Le firewall par suivi de connexion (« statefull »)▲
Ici, nous mettons en œuvre le suivi des connexions. Par un procédé que nous conserverons obscur pour le moment, le firewall va savoir si une connexion est :
- NEW : c'est-à -dire qu'elle est créée. Par exemple, un client envoie sa première requête vers un serveur web ;
- ESTABLISHE : cette connexion a déjà été initiée. Elle suit dans les faits une connexion NEW que l'on a déjà vu passer ;
- RELATED : ce peut être une nouvelle connexion, mais elle présente un rapport direct avec une connexion déjà connue ;
- INVALID : un paquet qui a une sale tête, un paquet qui n'a rien à faire là -dedans, un paquet qui sent l'ail.
Là , ça va devenir plus facile. Nous dirons en français :
- toutes les connexions NEW qui viennent du réseau privé et qui vont sur le NET port 80 sont acceptées. Tous les clients du réseau privé peuvent interroger tous les serveurs web du Net ;
- toutes les connexions RELATED et ESTABLISHED qui viennent du Net port 80 sont autorisées à rentrer. Les serveurs peuvent répondre ;
- toutes les connexions RELATED et ESTABLISHED qui sortent du réseau privé vers le Net sont autorisées à sortir. Les connexions peuvent se poursuivre, même si elles ouvrent de nouvelles connexions ;
- toutes les connexions INVALID, d'où qu'elles viennent sont jetées à la poubelle, on n'aime pas l'odeur de l'ail.
Certains suivis de connexions ne sont pas simples à faire et nécessitent des algorithmes spécifiques, comme principalement le FTP.
Netfilter, avec son interface IPTables, dans les noyaux 2.4 de Linux savent très bien travailler de cette manière.
6-3-3. Les firewalls applicatifs▲
Ici, on ne travaille plus au niveau du transport, mais au niveau de l'application, c'est-à -dire au niveau du protocole applicatif, comme HTTP, FTP ou autre. Un tel « firewall » est en réalité un serveur « Proxy », c'est-à -dire que le client s'adressera toujours à lui, quelle que soit la cible finale et n'acceptera de réponse que de sa part. Le proxy reformule la requête pour son propre compte vers le Net et, lorsqu'il reçoit la réponse, la transmet au client comme si c'était lui qui répondait directement.
En gros, ça veut dire que le proxy est le seul à accéder au Net et qu'il est donc le seul à risquer de subir des attaques.
Cette méthode, si elle est simple à mettre en œuvre avec des clients HTTP ou FTP, qui sont pratiquement tous prévus pour fonctionner dans ce cadre, peut poser des problèmes avec des applications qui ne le prévoient pas, comme c'est souvent le cas pour les clients de messagerie.
6-4. Avantages et inconvénients▲
Reprenons à l'envers.
6-4-1. Le proxy▲
Ça pourrait apparaître comme la solution ultime, puisqu'il y a effectivement une barrière entre le Net et la zone protégée. Sauf que ces logiciels sont complexes et qu'ils peuvent contenir des bogues que les pirates, tôt ou tard, découvriront et exploiteront pour passer quand même. De plus, ils consomment pas mal de ressources et nécessitent des machines relativement musclées.
6-4-2. Le firewall « StateFull »▲
C'est pas mal, c'est souple à paramétrer, ça consomme peu de ressources, mais le suivi de connexion est délicat et, s'il y a un bogue dans le système, ça ouvre des portes aux pirates. Les premières versions de Netfilter en ont présenté beaucoup, surtout sur les protocoles délicats comme FTP.
6-4-3. Le firewall « StateLess »▲
C'est très simple, ça consomme très peu de ressources, il n'y a quasiment aucun risque de bogue, mais ça ouvre trop de portes pour qu'un protocole applicatif ne risque pas de rester planté à un moment ou à un autre.
Vous le voyez, il n'y a pas de solution miracle.
6-5. Et avec, ça va mieux ?▲
Oui, bien sûr, un firewall est indispensable. Pour autant, se croire à l'abri parce que son firewall a passé les tests de sécurité classiques relève de la plus pure utopie. Pourquoi ?
Il n'existe pas de firewall inviolable, tout simplement. Pour plusieurs raisons :
- nous l'avons vu, les systèmes puissants comme un firewall statefull ou un proxy renferment des logiciels complexes qui ne peuvent pas être totalement exempts de failles. Il suffit au pirate d'en trouver une ;
- les règles de filtrage placées sur ces outils sont obligatoirement un compromis entre la sécurité maximale et une certaine liberté d'usage de l'Internet. Là où il y a compromis, il y a aussi faiblesse ;
- les proxys travaillent sur les couches hautes, on peut les percer en passant sur les couches basses ;
- les filtres de paquets travaillent sur les couches basses, on peut les percer en exploitant les failles des couches hautes.
Nous pouvons multiplier les barrages en les diversifiant, mais ça ne procure pas une protection absolument certaine. Pour obtenir une sécurité maximale (mais jamais absolue), il faut travailler à tous les niveaux :
- configurer ses serveurs avec le plus grand soin, en éliminant tous les risques connus à leur niveau ;
- s'assurer que l'on n'a pas dans un coin un serveur qui tourne sans qu'on le sache. Ne riez pas, le cas est assez fréquent ;
- protéger le tout avec un système de filtrage efficace, bien adapté à ses besoins ;
- surveiller avec le plus grand soin tout ce qu'il se passe, aussi bien sur les serveurs que sur les filtres, pour détecter le plus rapidement possible toute activité anormale ;
- avoir perpétuellement à l'esprit qu'il y a forcément quelque part une faille que l'on ne connaît pas, et qu'un pirate peut trouver.
Vous le voyez, la sécurité informatique oblige à devenir complètement paranoïaque. Mais réfléchissez bien… Dans la vie, c'est pareil. Si vous voulez vivre avec un risque zéro, vous aurez les mêmes problèmes :)
6-6. Sueurs froides▲
- Votre réseau est bien à l'abri, derrière tous les murs pare-feu de la création, avec une surveillance de tous les instants sur les points d'accès au Net. Mais dans votre réseau, il y a des utilisateurs qui se servent de portables. Lorsqu'ils rentrent chez eux, ils connectent leur portable au Net sans aucune sécurité et se gavent de virus, de backdoors et autres spywares. Le lendemain, ils reviennent se connecter sur votre beau réseau tout propre.
- Un proxy travaille dans les couches hautes. On peut le casser en passant par les couches basses ou en exploitant des failles logicielles. Donc, on ajoute aussi un filtre de paquets. Mais le filtrage de paquets peut plus ou moins être contourné, si l'on arrive à installer dessus une autre pile IP, parallèle à celle qui est utilisée par le filtre. Une sorte de super backdoor qui permettra de construire un routeur pirate à côté du vôtre, très étroitement surveillé, et qui ne s'apercevra de rien.
7. Et les bons vieux Windows…▲
Revenons à une situation plus commune, celle de l'internaute privé, qui ne dispose pas d'un réseau de type entreprise chez lui. Tout au plus, il faut distinguer deux cas qui n'ont pas beaucoup de rapports :
- ceux qui utilisent les services d'un petit routeur NAT du commerce, on en trouve maintenant à moins de 100 €. En général, ce type d'équipement propose déjà pas mal de fonctions de filtrage de paquets ;
- ceux qui utilisent une machine connectée directement au Net et qui peut éventuellement partager la connexion avec un ou deux autres postes. Les dernières versions de Windows (Me, 2000 et XP) proposent un moyen simple de le faire, Mac OS X également. Dans ces cas, il est clair que la machine exposée devra disposer d'un minimum de protections. Si Mac OS X propose un filtre de paquets performant, hérité de ses origines BSD, les diverses versions Windows ne sont pas très performantes dans ce domaine, bien qu'au moins 2000 et XP proposent un filtrage de paquets.
7-1. Windows NT, 2000, XP, etc.▲
N'en déplaise aux détracteurs de ces produits, ce ne sont pas forcément des passoires, à la condition tout de même de faire attention à plusieurs choses. Suivant la version, la configuration par défaut peut être plus ou moins dangereuse. Microsoft a tout de même fait quelques progrès sur ce point, au fil des « Service-Packs » et des versions.
- Ne laissez pas le compte d'administrateur par défaut avec un mot de passe vide :-) (C'est évident, mais combien l'ont fait ?).
- Windows 2000 et Windows XP permettent de changer le nom de l'administrateur. Dans leur version française, l'administrateur s'appelle « Administrateur » (comme root sur Linux). Changez ce nom.
- Adoptez pour ce compte (et ceux d'éventuels autres administrateurs) un mot de passe « fort » :
- huit caractères minimum ; 14, c'est mieux,
- utilisez une combinaison de caractères sans signification (pour éviter les recherches par dictionnaire), avec des majuscules, des minuscules, des caractères de ponctuation et même éventuellement des caractères non imprimables.
- Désactivez NetBIOS sur TCP/IP sur l'interface connectée au Net.
- N'installez pas de serveur inutile. IIS est dangereux, l'agent SMTP de l'option pack aussi, le DNS également.
- Proscrivez dans la mesure du possible tout logiciel de prise de contrôle à distance.
- Bloquez les ports 135 à 139 aussi bien en UDP qu'en TCP, ça peut se faire sur NT, 2000 et XP sans logiciel supplémentaire, dans la configuration de la pile IP ou avec le firewall fourni sur XP depuis le SP1.
- Installez les derniers Service Packs.
- Vérifiez régulièrement chez Microsoft l'apparition de nouveaux patchs de sécurité.
- Vérifiez fréquemment que vous n'avez pas installé un « backorifice » ou un « netbus » par inadvertance. (Ctrl+Alt+Suppr permet de visualiser les tâches et processus en cours. Ce n'est pas toujours très compréhensible, mais on y gagne beaucoup à analyser la liste des processus en cours).
- Installez un antivirus sérieux, même s'il ne faut pas en attendre de miracles.
- Enfin, prenez l'habitude de travailler systématiquement avec un compte d'utilisateur sans pouvoir d'administration. Cette pratique, naturelle sur les systèmes Unix ne l'est malheureusement pas sous Windows, au point que vous rencontrerez peut-être des problèmes avec certaines applications, même prétendues « professionnelles ».
Avec ces précautions, vous devriez déjà être relativement à l'abri, mais tout ceci ne vous évitera pas forcément l'installation malveillante d'un programme malicieux.
7-2. Les logiciels de surveillance▲
Il en existe un grand nombre, plus ou moins efficaces, plus ou moins simples à configurer, plus ou moins gratuits.
Actuellement, les « antivirus » sont en réalité des logiciels plus larges, capables de faire plus que de la simple détection de virus. Ils sont souvent grands consommateurs de ressources, mais il s'agit d'un mal nécessaire sur certains systèmes d'exploitation, plus particulièrement ciblés par les malveillants.
7-3. Conclusions▲
Je tiens à m'excuser auprès des possesseurs de Mac. (Apple), je n'ai aucune compétence dans ce domaine. Mais des outils analogues doivent exister.
La protection d'une machine connectée à l'Internet sous Windows (comme sous n'importe quel OS d'ailleurs) passe d'abord par des principes de prudence et de sécurité de bon sens, encore faut-il être suffisamment averti des problèmes potentiels et des règles élémentaires d'hygiène en matière de réseaux et j'espère que cet exposé vous aura aidé à y voir un peu plus clair dans ce domaine.
En plus de cela, l'usage d'un outil de surveillance reste tout de même conseillé, mais afin de ne pas sombrer dans la paranoïa, il convient de se renseigner sur les risques, les mécanismes des réseaux pour pouvoir faire le tri dans les alertes, entre celles qui sont réellement dangereuses et celles qui ne le sont pas.
8. Remerciements Developpez▲
Vous pouvez retrouver l'article original ici : L'Internet Rapide et Permanent. Christian Caleca a aimablement autorisé l'équipe « Réseaux » de Developpez.com à reprendre son article. Retrouvez tous les articles de Christian Caleca sur cette page.
Nos remerciements à ClaudeLELOUP pour sa relecture orthographique.
N'hésitez pas à commenter cet article ! Commentez 