Citation :
Pour ma part, je vais vous parler ici des protocoles TCP, UDP et ICMP qui sont les trois principaux protocoles dont vous verrez mention dans la configuration d?un firewall.
Un rappel s?impose : on parle toujours du protocole TCP/IP. Cette simple formulation est erronée, car elle devrait être au pluriel. En effet, l?acronyme TCP/IP désigne une "suite" de nombreux protocoles dont les 4 cités précédemment. Vous pouvez encore y ajouter DNS, NNTP, SMTP et POP3 par exemple, qui gèrent respectivement les relations entre noms de domaine et adresses IP, les newsgroups, l?envoi de mail, et la réception de mail. Il y en a bien d?autres mais je m?arrêterai là de peur de vous gaver sur le sujet 
TCP est un protocole permettant l?échange d?informations entre un client et un serveur. Typiquement, le client établit une connexion TCP en utilisant un canal (port) de communication vers un serveur pour lui demander une information, et le serveur répondra à cette demande. A la fin, la communication est fermée. Il y a ceci de particulier dans TCP que lorsque l?une des parties envoie une information, elle attendra une confirmation de réception.
Vous pouvez comparer la communication via TCP avec l?envoi d?un recommandé par la poste : vous saurez au bout d?un délai spécifié si le destinataire a bien reçu où non l?information qui lui était destinée. En informatique, le dépassement de délai est aussi appelé timeout. Et si ce timeout se produit, l?application responsable de la communication en sera avertie, et devra traiter ce problème en conséquence.
Exemple de communication TCP : un navigateur établit une connexion TCP vers un serveur web en s?adressant au port 80 du serveur. Le serveur répondra en renvoyant la page web, l?image, ou autre contenu, demandé par le navigateur. Si le serveur n?a pas répondu dans un délai donné, une erreur sera affichée à l?intention de l?utilisateur (comme la fameuse petite croix rouge qui indique qu?une image n?a pu être rapatriée).
Maaaaaaaaaais me direz vous, un navigateur, ça cause en HTTP ? Oui bien sûr, vous répondrai-je. Mais en réalité, HTTP s?appuie lui-même sur TCP. Vous pouvez voir TCP comme un support de communication, et HTTP comme un langage. Il en va de même pour NNTP, SMTP, POP3 et bien d?autres. Ils s?appuient tous sur TCP. Simplement, il y a différentes "couches" de protocoles qui s?empilent les unes sur les autres, et donc les protocoles s?appuient éventuellement les uns sur les autres.
Et UDP maintenant ? Et bien en UDP, ce n?est pas pareil. On n?établit pas de communication. On se contente d?envoyer une information qui arrivera sur un port précis de la machine distante, et c?est tout. On n?attend pas de confirmation de réception, on ne sait donc pas implicitement que l?information a bien été reçue par son destinataire. Un envoi postal classique en somme.
UDP et TCP ont donc un point commun : ils communiquent en utilisant des ports de communication. Typiquement, le client prend le premier port disponible dans un intervalle compris entre 1024 et 65535, car il y a toujours un port utilisé pour la source, et un port pour la destination.
Le port de destination est prédéfini, et pour les protocoles séculaires de l?internet, se situera en dessous de 1024. Un serveur web écoute généralement sur le port 80, alors qu?un FTP écoutera sur le port 21 et un serveur de mail POP3 sur le 110.
Le partage de fichiers et le protocole NetBIOS utilisés par Windows utilisent les ports 137 à 139, tant en TCP qu?en UDP.
Le port DNS est le 53. Le DHCP/BOOTP qui permet d?obtenir une adresse IP sur les connexions haut-début passe par les 67 et 68.
Un serveur IRC (protocole qui s?appuie sur TCP et né au début des années 90) utilise en général le port 6667, un serveur de news le port 119.
Tout ceci n?est bien évidemment pas exhaustif mais déjà largement suffisant pour toute configuration usuelle.
Maintenant, au niveau sécurité. La règle générale : c?est le client qui initie une connexion TCP vers un serveur. Ce serveur se contentera toujours de répondre via le canal de communication établi. Les choses sont donc claires.
Il y a toutefois une exception : en FTP, le serveur répond parfois en lançant une communication via son port 20 vers votre PC. A ce moment, votre client FTP doit donc être capable de recevoir une communication sur n?importe quel port (car celui-ci est déterminé par le client FTP au moment de l?établissement de la communication), du moment que le port source (du serveur) est le 20.
En UDP, n?importe qui peut envoyer une information n?importe où. A charge de l?utilisateur et/ou de l?administrateur de savoir quoi en faire, laisser passer ou non.
ICMP : c?est un protocole qui permet d?échanger des informations d?ordre système, notamment pour aider à la régulation du trafic. Par exemple, lorsque vous utilisez la commande PING pour savoir quel est le temps de réponse d?une machine distante, ou lorsque vous faites un TRACERT pour connaître le chemin parcouru par vos paquets vers une machine distance, c?est ICMP qui s?en charge. ICMP passe par le port 0 qui lui est réservé quasi exclusivement, et dispose de différents types de messages qui sont identifiés numériquement. Pour le ping, on utilise les types de message 0 (echo reply) et 8 (echo request). Votre firewall vous énumérera éventuellement les différents types de messages texto (c?est le cas de Tiny par exemple, que j?utilise).
Après avoir décrit brièvement ces protocoles, voyons maintenant comment construire la sécurité d?un firewall.
Prenons le cas d?un navigateur. Un navigateur ne connait que le protocole TCP. C?est sur lui que s?appuie non seulement le protocole du web HTTP mais aussi HTTPS et FTP, également utilisés par le navigateur.
Le navigateur demande des pages webs, des images, des animations Flash et tutti quanti, et a besoin d?obtenir une réponse du serveur web. La situation est en fait la même pour votre client e-mail : il demande au serveur de récupérer les derniers e-mails arrivés sur votre compte, et le serveur répondra en satisfaisant la demande.
Dans ce cas, il suffit d?établir dans votre firewall une règle qui limite la communication en sortie (outgoing) et en TCP uniquement. Pour le navigateur, le port ou l?adresse de destination importe peu. Tout serveur web n?utilise pas forcément le port 80. Si vous êtes du genre parano, vous pouvez spécifier que votre navigateur n?accède que les serveurs web sur le port 80, en spécifiant dans votre règle que le port de destination est 80. Dans la règle, je spécifie que les communications se font en sortie uniquement. Cela veut en fait dire que le navigateur à le droit d?initier une connexion, durant laquelle des informations circuleront dans les deux sens. Mais en aucun cas il n?aura le droit de recevoir une communication initiée par une machine distante. De plus, nous spécifions que le navigateur ne peut utiliser que TCP.
Pourquoi limiter les protocoles autorisés puisqu?un navigateur ne parle que TCP ? Pour votre information, sachez que diverses applications "internet-aware" ont un port UDP ouvert. C?est à dire qu?elles écoutent sur un port de type UDP, et par conséquent, sont prêtes à recevoir des informations par ce biais. Comme il n?existe pas de documentation à ce sujet (du moins en suis-je persuadé), j?appelle ça un trou de sécurité. Ma règle, telle que décrite ici, m?évitera donc les désagréments liés à cette inconnue.
Ah oui, j?oubliais une chose : dans tout bon firewall actuel, gratuit ou non, il est possible d?assigner une règle à une application spécifiquement. Par exemple, la règle que j?ai définie doit être assignée à mon navigateur. Si j?en utilise d?autres, il me faudra redéfinir la même règle pour ces autres navigateurs. Pourquoi associer une application à une règle ? Pour limiter les risques d?infection par un trojan. Les trojans ont la sale habitude de se mettre à la place d?une application, ou pire, de la modifier, et de s?en servir pour se répandre sur votre PC et sur le net. Le firewall qui permet d?assigner une application à une règle, a également la bonne idée d?identifier ladite application en établissant une signature correspondant à celle-ci. Si l?application a été modifiée ou remplacée, le firewall s?en apercevra et ignorera l?application, c?est à dire que toutes les tentatives de communication de ou avec l?application seront bloquées.
Enfin, on définit l?ordre d?application des règles de sécurité. En effet, certaines sont plus importantes que d?autres, et doivent être traitées en priorité. Tout dépend comment vous pensez la sécurité de votre ordinateur.
L?interface liée à cet aspect de priorités dépend du firewall que vous utilisez. Dans Conseal PC Firewall, chaque règle recevait un niveau de priorité entre 1 et 200. Un niveau 1 équivaut au niveau le plus important, alors que le 200 est le moins important. Avec Tiny, c?est l?ordre des règles à l?écran qui prime. Elles sont appliquées de haut en bas.
Reste une inconnue. Que faire si un paquet passant par le firewall ne correspond à aucune règle ? Le firewall vous proposera une option par défaut: laisser passer ou bloquer ce qui n?est pas spécifé dans les règles. Autrefois, on laissait passer. La tendance actuelle serait de bloquer.
Enfin, vous pouvez logger les paquets correspondant à une règle, il suffit de le préciser pendant l?édition de la règle. Vous pouvez donc faire en sorte de voir tout ce qui a été bloqué et par quelle règle.
|
FORUM HardWare.fr
![[:spamafote]](https://forum-images.hardware.fr/images/perso/spamafote.gif "[:spamafote]")
![[:draculax]](https://forum-images.hardware.fr/images/perso/draculax.gif "[:draculax]")
on est toujours là pour toi ![[:zoubi]](https://forum-images.hardware.fr/images/perso/zoubi.gif "[:zoubi]")
, il me reste plus qu'a formater ? 
(enfin d apres moi)
) car il rebootait avant que win ne boot 
![[:drapo]](https://forum-images.hardware.fr/images/perso/drapo.gif "[:drapo]")