________________________________________________________________ ____ __ __ / ___________________________________________________________ ____ __ _ / ` \ / \[13]/ + ,\_____ ___/ . ` |\/ , \__/ . \____ /:/=[ Sécurité sur IRC ] =\:\ _____/ ` x || , . " :X \_______________________________ ____ ____ / , ` ` || + , () . x , . ` ' ` \_ \ ,\\_ +\_ \ 'M ` | . || ` | ` , ` , + , ` ,--, + . \\_ \_ \ , \\_ K -+- / |+ -+- . , ` , ,',/ ,'. \_ \ . \\_ \_ \ - | ` / . | ; + + . ` | : . :`` ,_): ' ` \\_ \_ \ \\_` 1 , / ` . . x , .-=+=- `. ,. ,' ` , \_ \ + \\_` \_ \ 1 /\_____ x ' , . . X | ` `--' ` ` \\_ \_ \ , \\_ 1 + \\_ \___________________ , . . ` , + ' , , ; x ._\ \___\\___\ \ . \_ \ \__________________________________/ \ ` , \\_ /:/=[ Aka: spa pcq c'est pas leet qui faut être stupide ]=\:\ \ \__\__________________________________________ ______________________________ \` \__\ /__/ \\_ /:/=[ Ninja ]=\:\ _// \__\________________________/__/ Securité sur IRC Résumé Petit text qui réflète les méthodes que j'utilisent afin de me "protéger" sur les serveurs IRC. Je ne suggère pas que mes méthodes sont parfaites ni efficaces, mais disons qu'elles ont faites leurs preuvent jusqu'à maintenant. Cetainnes de ces méthodes doivent modifier le comportement du client IRC utilisé, j'ai donc fourni, lorsque nécessaire, un exemple du code à utiliser. Table des matières 1. Introduction 2. Pourquoi 3. Comment 3.1 Rendre anonyme notre client 3.2 Auto-Get, Auto-Send, Auto-Chat 3.3 Securiser ses scripts 3.4 Trojans, virus, vers 3.5 Proxy, Wingate, Bouncer 3.6 La commande 'mode +x' 3.7 Serveur IRC sécuritaire (encryption SSL) 3.8 Règles de base 4. Conclusion 1. Introduction Imaginons la situation suivante: votre système est vulnérable. Une personne malveillante peut donc avoir un accès complet à votre ordinateur. Celà veut dire qu'il peut faire ce qu'il lui plait: Accèder à vos fichiers, scanner pour d'autre système à attaquer, faire des attaque de denis de service (DoS) sur d'autre système, effacer vos fichiers, etc. Même si vous n'avez aucuns fichiers qui vaut la peine d'être protégé, les systèmes vulnérables sont souvant utilisés pour lancer des attaques sur d'autre système, vous fesant parraitre comme l'auteur de ces attaques et vous expose aux actions criminel et civil. De nos jours, les attaques à grande échelle sont fondées sur un réseaux de systèmes vulnérable, car les systèmes des utilisateurs moyen sont presque toujours mal protégés. En prenant le temps de sécuriser votre système contre les intrusions, et en réagissant rapidement et correctement au cas où votre système soit compromis, vous vous prévenez de devenir un participant non-solicité pour ces attaques. 2. Pourquoi Je suis sure que vous comprenez l'importance de sécuriser votre système contre toutes formes d'intrusions. Mais peut-être vous ne voyez pas vraiment l'utilité de la sécurité sur IRC, ou vous vous demandez peut-être en quoi consiste la sécurité sur IRC. Laissez moi vous expliquer pourquoi, selon moi, il est important de tenir compte de la sécurité lors de vos session de bavardages sur les réseaux IRC. Supposons que vous avez passé des heures à configurer votre système et ces différents programmes afin que votre système soit protégé. Vous vous êtes arrangé pour qu'aucune informations sensibles, qui puissent amener votre système à être vulnérable, ne puissent être obtenu par une personne malveillante. Ces informations peuvent être le type de système d'exploitation que vous utilisé et son numéro de version, les différents services web (httpd, ftpd, sshd, etc.) ainsi que leur numéro de version, etc. Mais vous utilisé un vulgère client IRC qui vous semble tout à fait inoffensif et vous ne vous en préoccupez pas. Eh bien!, tout vos efforts ont été pratiquement fait en vain, puisque ce client est susceptible de donner certainnes des informations que vous avez pris la peines de cacher. De plus, il est possible que ce vulgère client est une faille de sécurité qui permette à une personne d'exécuter du code arbitraire, et ainsi prendre contrôle de votre ordinateur. 3. Comment 3.1 Rendre anonyme notre client Malgré le fait que le protocol définie dans le RFC-1459 ne fait aucunement allusion au CTCP (Client To Client Protocol), la majorité des client IRC on une implémentation de ce dernier. Même si ce protocol n'a jamais été officiellement standardisé, un effort collectif de différents auteurs de client IRC on permits au protocol de survivre au temps et de coller à un standard officieux. Il est très facile de determiner quel client vous utilisez, ainsi que sa version et le système d'exploitation que vous utilisez. On peut donc trouver aisément une faille de securité soit pour le client, soit pour le système d'exploitation. Il est entendu que d'autres méthodes peuvent être utilise pour trouver quel client et/ou système d'exploitation vous utilisez, mais elles ne sont pas dans "scope" de ce texte. Nous devons donc empêcher le client de divulger des informations qui pourraient compromette votre securité ou fausser ces dernières afin de brouiller vos traces. L'attaqueur devra donc redoubler d'effort afin d'obtenir ces informations. Voici les differentes commandes CTCP que le standard officieux recommande au client d'implementer: VERSION, Cette requête va donner à l'initiateur des informations particuliaires à propos du client utilisé par le récepteur. Une requête valide ne possèdera pas d'argument. Elle régnérera une réponse dans la forme générale ci-dessous, avec trois champ dans la réponse: Champ1: Nom du client et sa version Champ2: Nom du système d'exploitation et sa version Champ3: Contact de l'individu/organisation responsable du client Les champs doivent être combiné comme suit: VERSION Ex.: mIRC mIRC32 v5.91 K.Mardam-Bey mIRC v6.02 Khaled Mardam-Bey mIRC v6.03 Khaled Mardam-Bey mIRC v6.11 Khaled Mardam-Bey mIRC v6.12 Khaled Mardam-Bey mIRC v6.14 Khaled Mardam-Bey mIRC v6.16 Khaled Mardam-Bey x-chat xchat 1.8.9 Linux 2.6.4-ALIZEE [i686/251MHz] xchat 2.4.1 Windows 5.1 [i1586/2,79GHz] xchat 2.4.1 Linux 2.6.8-1-386 [i686/908.62MHz] BitchX BitchX-1.0c19+ by panasync - Linux 2.4.20 : Keep it to yourself! KVIrc KVIrc 3.0.1 'System Virtue' - 2004.03.24 - build Sun Jan 16 04:20:59 UTC 2005 - i686-cefikoprstAGST IRSSI irssi v0.8.9 - running on Linux i686 irssi v0.8.9 - running on NetBSD i386 Eggdrop eggdrop v1.4.4 eggdrop v1.6.16 PING, Cette requête à comme but de déterminer le délai du voyage que prendra un message de l'initiateur au destinataire et de nouveau à l'initiateur. Le destinataire est requis de renvoyer une reproduction exact de l'argument reçu, sans modification. Chaque client définira son propre format pour l'argument de 16 octets. Les requêtes avec des arguments plus long que 16 caractères devraient être silencieusement ignorés. La réponse sera du format suivant: PONG ACTION, Cette requête est utlisé afin de fournir une méthode alternative de communiquer avec un autre utilisateur ou un canal. Le texte devrait être traite de façon similaire à celui d'une requête PRIVMSG tel que défini dans le RFC1459. Aucune réponse n'est généré suite a cette requête. Les commandes CTCP suivante ne sont plus supporté par la majorité, sinon la totalité, des clients IRC actuel même si il sont "require" selon le protocol officieux: CLIENTINFO, (seul BitchX semble encore supporter cette commande) Cette requête est utilisé pour connaître les capacités du client utilisé par le récepteur. La réponse sera une liste de commandes valide, reconnu par le client, séparré par des espaces. L'implémentation courrante de cette commande permet de passer en argument une commande supporté par le client pour obtenir de l'informations supplémentaire sur cette dernière. La seul commande CTCP qui nous intéresse dans ce cas ci est VERSION, qui nous permet d'obtenir des informations en rapport avec le client utilisé et le système d'exploitation. Notez aussi que certains scripts disponible pour certains clients modifient la réponse du CTCP VERSION, souvant en votre faveur, mais certains donne encore plus d'informations que ce que le client aurait fourni. Comme X-Chat et BitchX permettent de modifier les requête CTCP VERSION et autres de façon relativement simple, enfin je crois, je ne fournirai pas de script pour ces derniers. Voici donc, un script écrit pour mIRC afin de fausser la réponse suite à un CTCP VERSION. =--------------------CUT HERE-------------------= ; Puisque mIRC à son CTCP VERSION reply hardcoded, nous ne pouvons pas ; simplement utiliser le code suivant: ; ctcp &*:VERSION:*:/ctcpreply $nick VERSION BlaBla | /halt ; Alors nous devons faire un petit "hack" pour arriver a notre fin. ; ; Premièrment, lors de la connexion, nous allons créer une fenêtre debug ; qui ne serait qu'accesible par la "windows list" de mIRC à partir du ; menu "Windows" (l'option -h). Cette fenêtre aura comme nom ; @Debug, donc aucun conflit si vous êtes connecté ; sur plus d'un server à la fois. on *:connect:{ .window -h $+(@Debug,$cid) ; Ensuite nous ordonnons à mIRC d'appler la fonction Parse_Debug, à chaque ; message que le serveur lui envois et vise versa, avec comme argument le ; message "raw", donc dans le format spécifier par le RFC1459. Le résultat ; retourné par la fontion Parse_Debug serait affiché dans nos fenêtres ; debug. En fait, la fontion ne retournera rien. .debug -i $+(@Debug,$cid) Parse_Debug ; Ensuite nous ignorons les requête ctcp venant de n'importe qui seulement ; pour la connection courante. .ignore -t *!*@* } ; Voici l'alias Parse_Debug qui va nous permettre de voir lorsque des ; requête CTCP VERSION nous sont envoyé, et générer notre propre réponse. ; Voici à quoi ressemblera un requête CTCP VERSION format "raw": ; <- :Ninja|tux!~ufmow@66.201.225.99 PRIVMSG Ninja|code :VERSION ; Veillez noter que le '<-' est rajouter par mIRC pour qu'il soit plus ; claire si le message arrive du serveur ou si c'est un message que nous ; envoyons au serveur. Les deux caractères bizzard entourant le mot ; VERSION sont en fait des délimiteurs, le code ASCII de ce caratère est: ; DECIMAL | OCTAL | HEXA | CARATÈRE | DESCRIPTION ; 1 1 01 SOH Start of header alias Debug_Parse { tokenize 58 $1- if ($gettok($3,1,1) == VERSION) { var %my_nickreply $gettok($2,1,33) var %my_ctcpecho $+($chr(91),[ [ %my_nickreply ] ],$chr(32),VERSION,$chr(93)) echo $color(Ctcp text) -a %my_ctcpecho .ctcpreply %my_nickreply VERSION Why you need to know? } } ; Simple question de sanité, pour éviter les risques de multiplication de ; fenêtres @Debug, losque vous perdez la connection avec le serveur ; nous arrêtons le debug et fermons la fenêtre. Et puis pour ne pas ; remplir inutilement la ignore list ou risquer de foutre le bordel dans ; votre "ignore list", nous y enlèverons notre entrée. on *:disconnect:{ .debug -c off .ignore -tr *!*@* } on *:exit:{ ; pas besoin d'arrêter le debug puisque nous quittons, mIRC s'en occupe ; automatiquement. ; Comme nous quittons TOUS les serveurs, nous enlevons TOUS les entrées ; que nous avons créé (-w) .ignore -twr *!*@* } =--------------------CUT HERE-------------------= 3.2 Auto-Get, Auto-Send, Auto-Chat Certains client IRC offrent des options qui permettent l'envoie et la reception de fichiers automatiquement, ou de démarrer des sessions de bavardage (chat) automatiquement. Si ces options sont activées, elles permettent a n'importe qui d'obtenir votre adresse ip. De plus, il se peut qu'un client soit vulnérable à un type d'attaque relier à l'envoie et à la réception de fichier ou de session de bavardage, et l'automatisation des ces dispositifs vous rend un cible idéale. Il est préférable d'utiliser des "trigger" qui vont former un pseudo-mechanisme d'identification pour ensuite initier l'envoie/reception de fichiers ou de démarrer une session de bavardage (chat). Une sorte de vérification sanitaire afin d'éviter certains type d'attaques. Ces "trigger" peuvent être simplement une requête (ou suite de requêtes) CTCP, un PRIVMSG, un NOTICE, etc. Voici un exemple simple, en PERL, écrit pour X-Chat. Le trigger consiste en une simple requête CTCP. =--------------------CUT HERE-------------------= #!/usr/bin/perl use strict; use warnings; # Variables my $PKG = __PACKAGE__; my $NAME = "DCC Trigger Protection"; my $VERSION = "1.0"; my $H_MSG = "PRIVMSG"; my $TRIGGER = "DCCTRIGGER"; my $DESC = "pseudo-mechanisme d'identification pour initier les DCC."; # On doit absoluement enregistrer notre script auprès de xchat avant de # faire quoi que ce soit. Xchat::register($NAME, $VERSION, $DESC, "${PKG}::callback"); # On 'hook' le message $H_MSG Xchat::hook_server($H_MSG, "${PKG}::parseTrigger"); Xchat::print("\02$NAME $VERSION\02 by Ninja"); # On ignore toutes les requêtes de connexions DCC Xchat::command('IGNORE *!*@* DCC NOSAVE QUIET'); sub parseTrigger { my ($rawuserhost, $cmd, $nick, @rawdata) = @{$_[0]}; my (undef, $userhost) = split(':',$rawuserhost); my ($snick, undef) = split('!',$userhost); my (undef, $data) = split(':',(@rawdata)[0]); if ($data eq $TRIGGER) { # On ajoute l'instigateur à la liste d'exception Xchat::command( 'IGNORE '. $userhost. ' DCC NOSAVE QUIET UNIGNORE' ); # On laisse 5 minutes pour initier une requête DCC Xchat::command( 'QUOTE PRIVMSG '. $snick. ' :Vous avez 5 minutes pour initier votre requête DCC.' ); Xchat::command( 'TIMER 300 UNIGNORE '. $userhost. ' QUIET' ); return Xchat::EAT_ALL; } return Xchat::EAT_NONE; } sub callback { Xchat::command('UNIGNORE *!*@* DCC UNIGNORE'); } 1; =--------------------CUT HERE-------------------= 3.3 Securiser ses scripts Ne jamais utiliser des mecanisme d'autentification basé uniquement sur des nicknames et/ou hostnames. Meme si il sagit de host unique (offert par different network) parce qu'il son suceptible d'être utilisé/voler par une personne malveillante. Vous pouvez utiliser le nick et le host dans des mechanisme d'autentification seulement si ils servent de support a un autre méchanisme d'autentifiaction. N'utilisez pas de scripts qui vous permettent de vous auto-identifier auprès d'un service ou d'un bot puisqu'il requière que le mot de pass et le nom d'utilisateur soient conservés en quelque part (généralement un fichier). Il est donc possible, si votre système est compromis, que quelqu'un accède à ce fichier et vole les informations qu'il contien. Il est possible aussi qu'une personne ce soit emparré du nick d'un bot auprès duquel vous vous identifiez, obtenant ainsi votre nom d'utilisateur et votre mot-de-passe lors de votre tentative d'authetification. Vérifiez la validité du service ou bot et identifiez vous manuellement auprès de ces derniers. Utilisez des mots de passe sécuritaire. Ce que j'entend par mot de passe sécuritaire c'est qu'il doit être long, que le mot n'apparaise pas dans le dictionnaire, qu'il soit constitué de combinaison de caractère alpha-numerique (chiffres et lettres) et si le système d'identification est 'case sensitive', profitez en. Très, très important, changer vos mots de passe régulièrement (une fois par mois n'est pas exagéré). Essayez aussi différentes combinaisons chaque mois. Aussi très important, ne JAMAIS garder une liste de vos mots de passe sur votre ordinateur, il est plus sécuritaire de les écrire sur papier ou dans un livret gardé dans un endroit sécure et/ou secret. 3.4 Trojan, virus, vers Certains scripts/addons changent complètement le fonctionnement habituel de certains client IRC. Il est bien important de prendre conscience que certains de ses scripts/addons peuvent contenir des backdoor, des virus ou des vers. Ils peuvent donc permettrent, sans que vous en soiyez conscient, un access à votre ordinateur ou lancer des attaques. Il est primordiale que celui qui utilise un script/addon qui n'est pas de sa conception, connaisse ce que chaque ligne de code fait exactement. Voici une liste de chose que vous devez ou ne devez pas faire afin de vous assurez de n'être "jamais" infecté par un Trojan, virus, vers, etc.: - Ne jamais cliquer sur les liens qui sont publiés sous IRC en provenance de quelqu'un que vous ne connaissez pas. - Ne jamais accepter des fichiers de quelqu'un que vous ne connaissez pas. (voir la section 3.2 pour plus de détails) - Garder votre système à jour. Avec plus de 200 nouveaux virus reportés par mois, demain n'est pas le temps de mettre à jour votre système mais aujourd'hui. Installez toutes les patches de sécurité de votre système d'exploitation, de votre navigateur web (si par malheure vous cliquez sur un mauvais lien) et de votre logiciel de courriel nécessaires. 3.5 Proxy, Wingate, Bouncer La façon la plus simple de cacher son adresse IP lors de vos sessions IRC est en passant par un/des Proxys/Socks ou Wingates/Sygates/TelGates. Il n'est pas très difficile de trouver des proxys fonctionnels, une simple recherche sur google avec les terme "proxy" et "list" vous retourne des centaines de sites. Bien entendu, ce n'est pas tout les proxys qui vont vous authoriser à les utiliser, alors parcourrez les différentes listes et testez ceux que vous pouvez utiliser pour vous 'bouncer' sur IRC. Une autre façon de trouver des proxys est en scannant des segments d'ip à là recherche des ports 8080, 3128, 81 et 80 ou pour des serveurs socks en scannant pour le port 1080. Encore une fois, testez si ces serveurs vous permettent de vous 'bouncer' sur IRC. Prenez garde, la pluparts des serveurs proxy gardent des 'logs' des connections faites. Donc il est possible, si l'effort y est mis, de vous retracer grace à ces 'logs'. Malheureusement, il est maintenant rare de pouvoir se connecter sur des serveurs IRC par l'intermédiaire de proxy, puisse que la majorité vérifie lors de la connection si vous tentez de vous connecter par un serveur proxy/socks et si c'est le cas, la connection est interrompu. La vérification que font la plupars des serveur IRC n'est pas incontournable, ils scan simplement l'adresse par laquel vous tentez de vous connecter pour les 'well known' ports de proxy. Mais si le proxy oblige un nom d'utilisateur et/ou mot de passe effectuer la connection, les serveur IRC ne couperont pas votre connexion. En ce qui concerne les WinGates/SyGates/TelGates, le fonctionnement peut-être un peu plus complexe qu'un proxy (dépends des type de wingates/sygates et de leurs configurations). Les WinGates permettent au gens de partager une connection sortante et la plupars sont simplement mal configuré, et permettent ainsi les connections venant de n'importe où. De nos jours, les WinGates opérationnels sont très dure à trouver et ne fonctionneront pas longtemps, éventuellement quelqu'un va se rendre compte qu'il à été mal configuré et va ou va faire fixer le problème. Encore une fois, googler les mots suivant: "wingate" et "lists". Il est aussi possible d'utiliser des scanner de wingates pour les trouver vous même. Il y a beaucoup de scanner de disponible, faite une recherche, ça ne devrait pas être très dur à trouver. Une autre façon de cacher son ip est de passer par un 'bouncer'. Il y a plusieurs 'bouncer' *nix et certains on été porté pour windows (plus sur ce sujet plus loin). Ils sont conçus uniquement pour les session IRC et fonction comme des proxy IRC. Pour utiliser un 'bouncer' il faut premièrement un compte 'shell', autement dit, un accès à une machine *nix qui permet les processus en arrière-plan et les connexions sortantes. Mais la plupars des fournisseur de compte 'shell' gratuit ne les autorises pas, alors vous devez vous en payer un, sinon bonne chance dans votre recherche. La p lupars des fournisseur de 'shell' on aussi ce qu'on appel des vhost, nom de domaine vituel, qui vous permettent de changer votre 'hostname' et de choisir parmis une liste. Un exemple: Connecter sur un serveur IRC directement, votre 'hostname' ressemble a ceci: dsl-154-13.aei.ca ou 200-161-141-54.dsl.telesp.net.br Connecter sur un serveur IRC par l'intermédaire d'un 'bouncer' avec support vhost, votre 'hostname' ressemble a ceci: hahaha.undernetsucks.info ou PLZ.Dont.Ddos.My.56K.vid3otron.biz ou vive.les.femmes.enchaleur.biz Les vhost varies entre les différent fournisseurs de 'shell' et la façon de les assigné aussi. Vous vous rapplez surement que j'ai mentionné les version windows de certains 'bouncer'. Je ne vous les recommande pas! Premièrement il est pratiquement impossible de trouver un fournisseur de 'bouncer' qui fonctionne sous windows, votre seul alternative est de demander à un ami d'en installer un sur son ordinateur. De plus, côté stabilité, les plateforme *nix n'ont plus à faire leurs preuves. On ne peut pas en dire autant pour windows. 3.6 La commande 'mode +x' Certains réseaux IRC offrent la possibilité de caché votre adresse ip ou 'hostname', soit partiellement ou complètement. Il suffit de taper la commande suivante dans votre client après vous être connecter au serveur: /mode +x Prenez note que le résultat de cette commande diffère d'un réseaux à l'autre. De plus, le mode peut changer selon le réseaux. Par exemple, sur LinkNet, 'mode +h' doit être utilisé. Voici comment fonctionne 'mode +x' (et 'alike') sur les 4 plus gros réseaux: QuakeNet (~218 000): Pour pouvoir utiliser le mode +x sur QuakeNet, vous devez vous enregistrer auprès du service Q. Ensuite, vous vous identifiez à Q comme suit: /msg Q@CServe.quakenet.org AUTH Ensuite vous mettez le mode +x comme décrit plus haut. Il est important de noter que le mode +x ne fonctionne SEULEMENT lorsque vous êtes identifier aupres de Q. Très important d'utiliser Q@CServe.quakenet.org avec la commande login, il est possible que quelqu'un prenne le nick de Q lorsque ce dernier est en netsplit. IRCnet (~128 000): Ce réseaux ne supporte pas le mode +x ou autres méthodes pour masquer un hostname. En fait, IRCnet ne possède aucun service. Undernet (~121 000): Pour pouvoir utiliser le mode +x sur Undernet, vous devez vous enregistrer auprès de CService (http://cservice.undernet.org/live/) puis vous identifiez auprès du robot de service (X) comme suit: /msg X@channels.undernet.org login Ensuite vous mettez le mode +x comme décrit plus haut. Il est important de noter que le mode +x ne fonctionne SEULEMENT lorsque vous êtes identifier aupres de X. Très important d'utiliser X@channels.undernet.org avec la commande login, il est possible que quelqu'un prenne le nick de X lorsque ce dernier est en netsplit. EFnet (~106 000): Ce réseaux ne supporte pas le mode +x ou autres méthodes pour masquer un hostname. Si vous utiliser le méchanime fournis par le réseaux pour cacher votre adresse au reste du monde, il est préférable de le faire avant de joindre un canal. Je ne crois pas avoir besoin de vous expliquer le pourquoi. Mais malgré cela, il est possible pour quelqu'un d'obtenir votre adresse avant que vous n'aillez join un salon et ce, simplement en connaissant votre nick habituel. Donc la façon idéale est de prendre un nick aléatoire avant de se connecter, ensuite utiliser la mode +x ou son équivalant, puis prendre votre nick habituel et finalement joindre vos salons préférés. 3.7 Serveur IRC sécuritaire (encryption SSL) Ce qu'on appel 'Secure IRC', serveur IRC supportant les connexions SSL sécuritaire, est encore relativement rare et les clients IRC qui le supportent nativement sont peu nombreux. J'ai eu ouie-dire que xchat avait le support le plus mature et complet à ce sujet. Mais si vous préférez un client console, irssi à aussi un excellent support. Plus sur les différents clients en fin de ce texte. 'Secure IRC' est un élément intéressant pour tous les maniaques de la sécurité ou pour les fervant défenceur du droit à la vie privée. Les connections sécuritaires permettent de protéger l'intimité des messages envoyé aux autres utilisateurs et robots de services, ainsi que de protéger la communication dans n'importe quel salon de bavardage privé. Parcontre, il faut bien comprendre qu'un serveur qui permet les connexions normal et sécuritaire ne protège plus à 100% les communications entre utilisateurs et sur les salons de bavardage. Voici un explication plus visuel pour permettre de mieux saisir cet inconvéniant: Prenons l'exemple d'un serveur qui n'autorise que les connexions sécuritaire. Un client, C1, à établie une connextion sécuritaire avec un serveur, S1. +----+ Connexion sécure +----+ | C1 |<------------------>| S1 | +----+ +----+ Un autre client, C2, se connect sur le même serveur, toujours de façon sécuritaire. +----+ Connexion sécure +----+ Connexion sécure +----+ | C1 |<------------------>| S1 |<------------------>| C2 | +----+ +----+ +----+ Si C1 envoie un message privé à C2, le message en question sera protégé durant tout le voyage, puisque les deux client utilise une connexion sécure. Mais si le serveur acceptait aussi les connexions non sécuritaire, et que C2 établie une connexion non sécuritaire avec le serveur, ce même message ne serait maintenant plus sécuritaire durant tout le voyage: +----+ Connexion sécure +----+ Connexion non-sécuritaire +----+ | C1 |<------------------>| S1 |<--------------------------->| C2 | +----+ +----+ I1 +----+ Il serait maintenant possible d'intercepter, en I1, le message en provenance de C1 destiné à C2, puisque ce dernier utilise une connexion non protégé. Les serveurs supportant les deux mode de connexion n'offre pas une protection complète de vos messages privé. Et les serveur exclusivement 'Secure IRC' ne vous offre pas nécessairement une protection absolue: Si les serveurs d'un réseaux ne sont pas liée ensemble par des connexion sécuritaires, votre message va un jour ou l'autre être exposé. De façon général, on peut dire que les connexion sécuritaire avec les serveurs ne sont utile que sur les réseaux publique, suceptible d'être espionné. Petite note pour les clients qui ne supporte pas le 'Secure IRC', il est possible d'utilisé des tunnels sécuritaire. Il s'agit d'un programme que vous installez sur votre ordinateur, qui joue le rôle d'intermédiaire entre vous et le serveur. Il suffit de se connecté localement, avec votre client, sur le programme en question et ce dernier établie une connexion sécuritaire avec le serveur. stunnel - encrypt arbitrary TCP connections inside SSL http://www.stunnel.org/ 3.8 Règles de base - Activez le mode personnel invisible (+i). Il sera plus difficile de vous trouver. Faite simplement /mode votre_nick +i. Vous ne serai pas complètement invisible, les utilisateurs sur le même salon que vous pourrons vous v oir. Vous serez, parcontre, invisible aux utilisateurs qui utilisent les commande /who et /names. La commande /whois va cependant donner vos informations et les salons sur lesquels vous vous trouvez. - Ne donner aucune informations personnelles: nom, numero de téléphone, adresse civil, etc. - Utilisez un nick de nature general, qui ne donne pas d'information sur l'age que vous pourriez avoir ni votre sexe. - Ne téléchargez aucuns fichiers sauf si vous faite entièrement confiance au "sender" et que vous savez qu'est-ce que le fichier contien. - N'allez pas sur les sites qui sont publiés sur les salon par des personnes ou des bots. Ils peuvent contenir du code malveillant qui peut être téléchargé sur votre ordinateur. - Ne taper aucune commande dont vous ne connaissez pas son utilité et le résultat escompté. Ne jamais faire ce qu'un utilisateur vous demande de faire si ce qu'il vous demande semble étrange ou que vous ne connaissez pas le résultat. - N'activé pas l'option 'Auto join on invite'. Certains utilisateurs malveillants pourraient vous faire joindre plusieurs salons lourdement fréquenté et ainsi forcer le serveur à vous déconnecter pour ne pas vous flooder. Vous devez comprendre que lorsque l'on join un salon, le client envoie la commande NAMES au serveur pour que ce dernier vous envoie la liste des utilisateurs qui sont présent sur le salon que vous venez de joindre. Plus il y a d'utilisateurs sur le salon, plus la liste est longue. De plus, certains clients, en plus d'envoyer la commande NAMES, envoient la commande WHO pour obtenir les hostnames des clients présent sur le salon. Le serveur doit donc vous envoyer une quantité d'informations importantes, et la plupars des servers, pour vous protéger, vont vous déconnecter si il y a trop d'informations à envoyer. - N'activé pas l'option 'Whois on query'. Quelqu'un pourrais simplement lancer un simple flood de privmsg avec un botnet suffisament populeux pour que le serveur vous déconnect pour 'Excess Flood'. 4. Conclusion Voilà, c'est ce qui termine mon exposé sur la sécurité sous IRC. J'espère que certaines des infos seront utiles pour les néophites ou pour les freaks de la sécurité.