TCP/IP & sécurité. [ Accueil ] [ Attaques ] [ Etude de cas ] [ Contrôles possibles ] [ Protections ] [ Les Firewalls ] [ Client Windows ] 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é". 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. 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 500Mo et une installation de 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 (IPChains ou, plus récemment IPTables sous Linux), un logiciel de surveillance (iplog ou snort, par exemple sous Linux), voire un logiciel capable de construire une protection particulière lorsqu'il détecte les prémices d'une intrusion (portsentry, toujours sous Linux). D'autres logiciels qui cumulent ces fonctions existent dans le monde Windows, nous parlerons un peu de ZoneAlarm et de Look 'n Stop, mais il en existe beaucoup d'autres. 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. Plan du chapitre. [ Attaques ] [ Etude de cas ] [ Contrôles possibles ] [ Protections ] [ Les Firewalls ] [ Client Windows ]
Attaques. [ Accueil ] [ Attaques ] [ Etude de cas ] [ Contrôles possibles ] [ Protections ] [ Les Firewalls ] [ Client Windows ] Hasard ou nécessité? La bonne question à se poser, concernant les problèmes de sécurité n'est pas: Mais: "Est-ce que j'ai des chances (grandes ou petites) de subir une attaque un jour?" "Quand vais-je être la cible d'une attaque?" Et la seule réponse pertinente à cette question est: "A 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 pour les autres, jamais pour soi. 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): 1. 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. 2. Les voyous du Net Bien connus sous le nom de "script kiddies", ceux là cherchent à pénétrer, le plus souvent pour
3. 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. Ceux là sont de véritables techniciens et, même s'ils font parfois des dégâts, forcent plus ou moins le respect par leur 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. A priori, ce ne sont pas des pirates et leur objectif premier n'est pas de détruire, mais de comprendre. Les attaques virales et assimilées. 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é 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 etc. Les macro virus dans les données. Une autre infection, assez semblable, consiste à exploiter les possibilités qu'ont certaines applications d'installer des macro commandes 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 "macro virus" 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. 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élande 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'adresse 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 peuvent également être corrompus. Parades: Toutes ces attaques sont plus ou moins prises en charge par des applications anti-virus, 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 est efficace si le fichier exécutable (ou le fichier de données pour les macro virus) est au préalable enregistré sur le disque, pas s'il est lancé (ou ouvert) directement depuis le serveur... 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. Eventuellement, prier. 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 "Halte aux Hackers" édité en français chez Eyrolles. Cet ouvrage traite en quelques 600 pages des diverses techniques de piratage, ainsi que les parades possibles. Voyons tout de même en résumé les principaux risques. 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 entend 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é PWS (Personal Web Server), 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... 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. parades: Contrôler périodiquement les ports ouverts à l'écoute. Certains antivirus savent détecter les "trojans", "backdoors" et "spywares" connus 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 serveurs comportent des "bugs" 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. 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é 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. 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. 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 mal intentionné 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. Les blocages. Ce n'est pas à proprement parler une intrusion. C'est assez facile à faire, c'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. Parades: Un firewall bien configuré arrive généralement à éviter ce genre de problèmes.
ICMP, le proto 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 des détails sur ce protocole ici 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?" 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. 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 oeuvre 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 même 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. 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.
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. 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 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. A mon sens, le signal 17 (requête de masque de réseau) ne perd rien à être bloqué. A essayer pour voir. [ Accueil ] [ Suivante ]
Etude de cas. [ Accueil ] [ Attaques ] [ Etude de cas ] [ Contrôles possibles ] [ Protections ] [ Les Firewalls ] [ Client Windows ] 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. 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: 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 second 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 seconds Ce 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.
Mon 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 second Comme vous le constatez, il y a 6 ports ouverts en écoute sur cette machine. Parmi ceux-ci, il y en a un bon nombre qui présentent des dangers. 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... 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. 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...
Le port 443. HTTP "sécurisé" (HTTPS). Ouvert également par PWS. 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 seconds Nous 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. Conclusions. Il est clair qu'il y a toujours quelques ports ouverts sur un hôte. 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 qu'est ce qui est installé sur sa machine, volontairement ou involontairement. [ Précédente ] [ Accueil ] [ Suivante ]
Contrôles possibles. [ Accueil ] [ Attaques ] [ Etude de cas ] [ Contrôles possibles ] [ Protections ] [ Les Firewalls ] [ Client Windows ] 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. 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 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. 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_WAIT Il 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 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. 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. 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. Note: Il est possible que la commande vous réponde : E:\>arp -a Aucune entrée ARP trouvée Ce 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.
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, iplog, iptraf et bien sûr Snort et TCPDump. 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" (Windows NT, Windows 2000, Linux...) 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. [ Précédente ] [ Accueil ] [ Suivante ]
Protections. [ Accueil ] [ Attaques ] [ Etude de cas ] [ Contrôles possibles ] [ Protections ] [ Les Firewalls ] [ Client Windows ] 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. Ca augmente tout de même le nombre de machines et la facture EDF. Ca 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é. Construire une barrière. Etat des lieux. Une solution de protection consiste à interdire l'accès aux ports inutiles côté Internet. 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, 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 les distributions Mandrake ). 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. Ca 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 :-) (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 "officiels". Reprenons le scénario, mais avec BIND correctement configuré. Ca 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 server C'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 du pirate. 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.