LnS Firewall Climenole’s rules set V. 3 - Introduction

Hi Gentle Readers

One of the most frequent question about rules set firewall is: “Where I put that rule in the list?” I’ll try to find a solution by adding to each rule name a code giving the relative position of the rule in the list.

The general syntax for the rule name will be easy to understand with this example of a rule for basic web browsing :

Name of the rule:

{R. 80,01}; [TCP] { HTTP }

Description of the rule:

[S/optional: else {S..0000000} or G]
[Hyper Text Transfer Protocol]
Firefox, Opera, IE

The “{R. 80,01}” means: a rule in the rules subset R , remote port 80, one remote port only.

The “; [TCP] { HTTP } ” means : a rule using TCP protocol (The “Transport layer of the TCP-IP protocols) and using the port related to the HTTP ( the “Application level layer” of the tcp-IP protocols).

The description: “[S/optional: else {S..0000000} or G]” means : this is a specific rule (one program must be included at least in this rule othewise the more general rule {S..0000000} will be used instead.

The “or G” means: you may leave it as a general rule anyway… [This will be more clear later...]

There is an other coded indication in the rule name:

{{ rule name }} means: packets authorised in and out for general rule
{ rule name } means : packets authorised in and out for specific rule
{{ rule name } means : packets authorised incoming only
{ rule name }} means: packets authorised outgoing only
{ * rule name } means: packets authorised in and out for a Server rule

<< rule name ! >> means: packets blocked in and out
<< rule name ! > means packets blocked incoming only
< rule name ! >> means : packets blocked outgoing only

In the rule description there is also some codes:

G = general rule or for any program

S = specific rule: at least one program must be listed in that rule
(this is mandatory for server rules and Udp rules …)[Exception: the DNS rule...]

S/C means Specific rule and must be configured: most of the time the port used in the rule must be configured also in the program like utorrent for example.

u+e = if needed, this rule must be unblocked (remove the red dot) and enable ( check the first column…)

experimental = self obvious. This rule was not fully tested and may require some fixes…

recommended: not a mandatory rule but it’s better to have it.

mandatory: you must have this rule!

optionnal: mostly for TCP applications.

Normally TCP application used the general rule “{S..0000000}; [TCP] {{ Common Internet Applications }}” and you don’t need more. Used these rules if you want it.

testing: some rules are created for testing or learning.

This is for “Geek” fun !!! Mostly about the TCP flags used in connections.

See rules {S. 0}; [TCP] {{ ACK }} to {S. 7}; [TCP] {{ RST }}.

Needed: rule for a server or for Udp protocol. The rule must be specific!!!

That’s all for now. The next articles will explained the rules for each rule’s subsets and give you some hints about the Internet packets filtering and the methodology used to create a “well built” rules set. In subsequents articles I will give you a more accurate details about routers and LAN configuration rules. Finally I will finished with an UNofficial Frequently Asked Questions for Look’n'Stop and firewalls in general …

Stay tuned !

Des règles climenole… et des fausses!

Bonjour à tous

J’ai complété tard aujourd’hui le dernier article de la série sur Look’n'Stop et j’en ai profité pour mettre les règles suggérées en téléchargement ici… et sur les réseaux P2P Gnutella et eDonkey. Je reproduit plus bas la partie de l’article concernant le téléchargement des ces règles suggérées avec les informations d’identification du fichier.
J’écrivais alors une mise en garde envers des “fakes” possibles. Je ne croyais pas si bien dire car immédiatement après avoir fait le “release” du jeu de règles climenole je me suis amusé à faire une recherche portant justement sur “règles climenole”… pour tomber sur des fichiers disponibles en téléchargements identifiés comme étant justement les “Règles climenole” ! Surprise et incrédulité !
J’ai alors téléchargé ces merveilles que voici:

Mon anti-virus n’a pas tardé à réagir et la douce voix de la Demoiselle d’Avast Anti-virus m’a sussuré à l’oreille: « Il y a un cheval de Troie sur votre ordinateur »…

L’extension des fichiers auraient dû me mettre la puce à l’oreille de même que la taille des machins. Combien d’internautes se sont fait prendre par ces fichiers avec cheval de Troie distribuée par de minables malveillants sous mon identité? Et depuis combien de temps?
Mais plutôt que de pester contre ces minus cela m’inspire pour une nouvelle série d’articles portant justement sur les “malwares”, les yahous dégénérés qui les fabriquent et les distribuent et, pourquoi pas, sur la psychologie profonde de ces tarés. Le vandalisme sur internet tout autant que celui qui défigure nos Cités, le piercing et le tatooing objectifs et subjectifs, la laideur à la mode et la bêtise rampante des vermines est un sujet du plus haut intérêt! (Si j’en attrape un je me promet bien de le conserver dans un bocal avec du formol ou, s’il est encore vivant, dans un Punkarium pour observer ses moeurs, ses modes d’alimentation et de reproduction et ses autres caractéristique (Sont-ils ovovivipares ou pas?).

« Il faut l’avouer, certains de ces êtres n’offrent pas un aspect bien esthétique: mais la connaissance du Plan de la Nature en eux réserve, à ceux qui savent voir le pourquoi des choses et qui aiment vraiment connaître, des plaisirs inexprimables. Il ne faut donc pas céder à une répugnance puérile et nous détourner de l’étude du moindre de ces animaux: en toutes les parties de la Nature, il y a à admirer. »

ARISTOTE, Les parties des animaux, I, 5, 644 b

———————————————————————————
Ceci étant dit revoici les informations sur le fichier authentiquement “Climenole”:

Jeu de Règles pour télécharger et importer dans Look’n'Stop

Voici quelques règles à télécharger. Vous pouvez les essayer telles quelles, les modifier ou vous en inspirer pour en créer de meilleures. Ces règles sont publiées sous une licence Creative Common. Merci de respecter les termes de cette licence.

Cette création est mise à disposition sous un contrat Creative Commons.

Règles Climenole version 1

Le nouveau jeu de règles “climenole version 3″ est disponible sur le forum officiel de Look’n’Stop:

Jeu de Règles Climenole Version 3 Français

The new climenoles rules set version 3 is available in the official Look’nStop forum:

Climenole’s Rules Set Version 3 English

Notes de version:

Disponibles sur le forum de Look’nStop

Règles pour Look ‘n’ Stop - partie 6

Comment créer des règles pour vos applications - troisième partie

1- Résumé de l’article précédent

Nous avons déjà vu dans l’article précédent qu’il est possible d’utiliser les entrées du journal pour déterminer les règles pour une application. Dans les cas les plus faciles cela peut se faire directement avec le journal tel qu’il se présente dans l’onglet “Journal” de Look’n'Stop sinon en utilisant le format brut du journal avec un chiffrier. Cette dernière méthode permet de choisir plus facilement les éléments à conserver, de trier les colonnes pour regrouper les données et obtenir un aperçu ordonné des traces laissées par une application au cours des connexions. Bref il faut:

1. Créer une règle temporaire sans restrictions pour l’application à surveiller
2. Placer cette règle immédiatement après la règle pivot
3. Utiliser le programme en essayant toutes ses fonctions
4. Utiliser un chiffrier pour ne conserver que les lignes de TEST et les trier
5. Créer un jeu de règles de test à partie des résultats de la “phase 1″ du test
6. Conserver la première règle TEST comme “garbage collector” durant la “phase 2″
7. Recommencer à partir de l’étape 3 et rafinez vos règles.

2- La méthode d’élaboration des règles et les applications P2P

La méthode est relativement facile à utiliser avec la plupart des applications. Dans le cas d’applications “purement” serveur, la règle de test devrait évidemment être placée avant la règle pivot. Toutefois il serait surprenant que cela soit nécessaire; les ports locaux utilisés par le serveur sont parmis les ports “bien connus”.

Un problème se pose par contre pour les applications P2P, celles-ci étant à la fois des applications clientes ET des applications serveur. Comment alors déterminer les règles “serveur” devant être placées avant la règle pivot et les règles “clientes” placées après?

Voici comment faire:

1. Créez une règle de Test “client” et positionnez-la comme nous l’avons déjà vu.
2. Créez une règle de Test “serveur” exactement identique mais cette fois-ci positionnez-la immédiatement avant la règle pivot.
3. Utilisez votre programme. Vous allez remarquer que seule la règle de Test “serveur” est utilisée, l’autre n’étant pas prise en compte…
4. Désactivez la règle de Test “serveur” vous allez constater que cette fois-ci seule la règle de Test “client” est prise en compte ET que vous avez des blocages signalés par la règle pivot. C’est exactement ce que nous voulions!

Les captures d’écran vont vous permettre de comprendre de quoi il s’agit.

Les deux règles de Test sont activées et le programme est mis à l’essai.

Ce qui nous donne ces entrées au journal:

puis la règle de Test “Serveur” est désactivée et cela occasionne des blocages.

Ce qui donne en fin de compte les données suivantes:

La partie A indiquée en mauve comprend toutes les entrées mais sans que nous sachions s’il s’agit de la partie cliente ou serveur. Par contre nous connaissons déjà les ports utilisés: 6346, 6347, 6348 puis des ports de la gamme 1024-5000, enfin des ports hors de cette gamme.

La partie B indiquée en bourgogne signale les blocages après avoir désactivée la règle Test “serveur”. Nous obtenons de cette façon ce que nous voulions savoir: quel est le port local utilisé par la partie serveur: 6346 en TCP. Notez que parmi les ports bloqués par la règle pivot, seuls ceux indiqués ici dans la partie A doivent être pris en compte. Des blocages sur les ports 135, 445 ou autre ne doivent pas être pris en comptes puisqu’ils ne sont pas reliées à ceux utilisés par l’application surveillée.

Les parties C en vert et D en marine nous donnent les ports utilisés par la partie cliente une fois le blocage activé: 6346 en TCP et UDP.

Nous avons donc obtenus rapidement toute une série d’indications sur les port utilisés en local et en distant, avec quels protocoles et s’il s’agit de la partie cliente ou serveur. Nous avons donc tous les éléments nécessaires pour élaborer un premier jeu de règles qui pourront par la suite être testées et rafinées sans trop de problèmes avec la méthode connue: d’abord des règles pas trop restrictives, puis une autre phase de test et enfin la rédaction des règles définitives.

3- En guise de conclusion temporaire…

Ainsi s’achève cette série d’articles sur Look’nStop. Si ces articles vous ont permis de mieux connaître les protocoles internets et les possibilités de filtrage et de surveillance de Look’n'Stop mon objectif principal sera atteint: vous permettre de maîtriser un des meilleurs pare-feu à règles pour Windows.

4- Jeu de Règles pour télécharger et importer dans Look’n'Stop

Voici quelques règles à télécharger. Vous pouvez les essayer telles quelles, les modifier ou vous en inspirer pour en créer de meilleures. Ces règles sont publiées sous une licence Creative Common. Merci de respecter les termes de cette licence.

Cette création est mise à disposition sous un contrat Creative Commons.

Jeu de règles “Climenole version 1 “règles climenole version 1 <<== (Enregistrez la cible du lien sous…)

Le nouveau jeu de règles “climenole version 3″ est disponible sur le forum officiel de Look’n’Stop:

Jeu de Règles Climenole Version 3 Français

MISE à JOUR 28 juin 07:

Jeu de Règles Climenole Version 3.01 Français

The new climenoles rules set version 3 is available in the official Look’nStop forum:

Climenole’s Rules Set Version 3 English

UPDATE June the 28th , 07:

Climenole’s Rules Set Version 3.01 English

Notes de version:

Disponibles sur le forum de Look’nStop

[Attention aux "fakes"... ]

Mise à jour 27 juin 2006 21:25 EST

Effectivement des fakes sont en circulation et identifiées à mes règles.

MISE EN GARDE IMPORTANTE

De Fausses “Règles Climenoles” en circulation sur les réseaux P2P

Des Règles Climenole … et des FAUSSES!

5- Autres ressources

La FAQ de Look’n'Stop
Le Forum de Look’n'Stop

A+

Règles pour Look ‘n’ Stop - partie 5

Comment créer des règles pour vos applications - deuxième partie

La façon la plus simple créer des règles spécifiques pour une application est de l’utiliser sans lui donner de restrictions pour obtenir les traces de son activité et ainsi avoir les éléments nécessaires pour l’élaboration des règles.

Il faut d’abord s’assurer que, dans les options avancées, l’option “Fichier journal au format brut” est coché. Par la suite il faut:

1- Que l’exécutable de l’application soit ajouté au filtrage logiciel sans lui mettre de restriction.

2- Ajouter une règle de test en TCP/UDP autorisant tous les ports locaux et distants de même que toutes les adresses locales et distantes.

3- Placer cette règle immédiatement après la règle pivot: blocage des paquets TCP entrants avec le flag SYN (dans le jeu de règles proposé { Q.999},[EB], SYN Entrant ).

4- Ajouter l’application surveillée dans cette règle TEST et utiliser cette application pendant un certain temps pour permettre d’avoir un bon échantillonage dans le journal.

5- Faire une copie du journal au format brut se trouvant dans C:\ProgramFiles\Soft4ever\looknstop\logs de .log en .txt

.

6- Importer le journal brut en .txt dans un chiffier tel que MS Excel ou OO Calc en tant que fichier avec champs séparés par des virgules.

.

.

7- Ne conserver du journal au format brut que les lignes concernant la règle TEST et faire un tri portant sur la dernière colonne correspondant au champ “Port de Destination” et supprimer les colonnes inutiles.

Le format des entrées du journal brut pour le filtrage internet des paquets TCP/UDP se présente comme ceci en commençant par le premier champs de gauche (colonne A):

• A- Date
• B- Heure en format UTC
• C- la mention UTC
• D- D = Download ou U = Upload
• E- 1 = autorisé ou 0 = bloqué
• F- Numéro de séquence de l’entrée au journal
• G,H,I- Identification de la règle: dans le cas du jeu de règle proposé si des virgules on été utilisées comme ceci: {R.00000.00}, [AA], TEST vous aurez trois colonnes correspondant à ces champs sinon une seule dans le cas {R.00000.00} [AA] TEST.
• J- Type Ethernet 800 = IPV4
• K- Taille des paquets
• L- IP Source
• M- IP Destination
• N- Numéro de Protocole: 6 = TCP, 17 = UDP
• O- Port Source
• P- Port Destination

Les colonnes minimales à conserver sont donc les colonnes D,L,M,N,O,P. À partir de ces informations il sera possible d’élaborer des règles spécifiques pour l’application. Il faut noter que les premières règles élaborées ne doivent pas être trop restrictives et devront la plupart du temps être corrigées.

Les nouvelles règles devront être elle-mêmes testées en les plaçant immédiatement après la règle de blocage des paquets TCP entrants avec le flag SYN comme à l’étape 3 ET imméditement suivies par la règle TEST pour “attraper” les paquets restants (ce qui permet de rafiner les règles en tenant compte de ces “restes”.).

En somme il est parfois nécessaire de s’y prendre à deux ou trois fois avant d’obtenir un jeu de règles spécifique à une application. Dans le cas des applications client+serveur, tel que les applications P2P, le problème se corse car la méthode mentionnée doit être modifiée pour accomoder les paquets TCP entrants avec le flag SYN correspondants à ceux de la partie serveur de l’application. Pour le moment nous nous limitons à des applications internets clientes uniquement.

La plupart de ces applications utilisent les ports locaux 1024 à 5000 pour se connecter au(x) port(s) distant(s) des serveurs et utilisent le protocole TCP mais il y a parfois des exceptions. Certaines d’entre-elles sont particulièrement corriaces et requièrent de la ténacité et de la débrouilllardise pour en venir à bout. Les traces du journal brut, la documentation lorsqu’elle est valable et des talents de détectives sont nos meilleurs atouts.

Dans l’exemple trivial donné ici, le navigateur Opera est utilisé pour l’accès à un site web, à une connection sécurisée et à un téléchargement en FTP. Les autres fonctions d’Opera n’ont pas été utilisées pour simplifier l’exemple au maximum.

Il est d’abord facile de voir que les ports utilisés en local sont bien dans la gamme 1024 à 5000 [colonne O], que les ports distants [colonne P] sont 21 (le port FTP-control), 80 (le port HTTP), 443 (le port HTTPS) de même qu’un port distant 57814 qui n’est ni un des ports “bien connus” (de 1 à 1023) ni dans la gamme 1024 à 5000 et qu’on peut facilement reconnaître ici comme étant le port utilisé en FTP mode passif. De plus la colonne N nous indique que le TCP est le seul protocole utilisé.

Ce qui nous donne donc les règles de tests “phase 2″ suivantes:

a) TCP ports locaux de 1024 à 5000 et ports distants égale ou 80, 443

b) TCP ports locaux 1024 à 5000 et port distant Égal 21

c) TCP ports locaux 1024 à 5000 et ports distants Entre A-B 1024 à 65535

d) TCP/UDP tous les ports locaux et distants (notre règle Test du début qui devient en quelque sorte un “garbage collector” au cas ou quelque chose nous aurait échappé…)

Par la suite, au cours de la “phase 2″ on pourra utiliser d’autres fonctions d’Opera qui utiliseront soit les 2 premières règles soit la troisième ou quatrième. Notez que l’adresse IP de votre ordinateur, adresse IP en source ou destination est un bon point de repère pour s’orienter et comprendre qui fait quoi.

Il suffit alors de recommencer la procédure à nouveau pour affiner les règles.

2 Remarques pour cet exemple particulier :

1- Pour éviter de multiplier les phases de test (et même en simplifier la deuxième) il est évidemment préférable d’utiliser toutes les fonctions du programmes pour faire ressortir dès la première phase quels sont les ports distants utilisés ou les gammes de ports, avec quel(s) protocole(s), et ainsi de suite.

2- De même, il serait préférable de ne pas utiliser la 3 ième règle, parce que trop générale, et de se fier uniquement à la 4 ième pour les paquets restants c’est à dire correspondants à des ports distants “bien connus” pour rafiner nos règles de la “phase 1″. Dans l’exemple donné, s’il n’y avait pas d’autres fonctions dans Opera (courrier, IRC, etc) nous aurions déjà dès la première phase toutes les règles dont nous avons besoin. Les données récoltées ici correspondant dès le premier coup d’oeil à celles que nous avons déjà vu dans l’article “Règles pour Look’n'Stop - partie 4″, 4- Règles pour les applications les plus courantes…

La meilleure façon de se faire la main avec cette méthode est d’utiliser d’abord un programme tel qu’un navigateur dont on connait d’avance les fonctions et les règles de façon à s’orienter plus facilement avec le format brut du journal et son traitement avec un chiffrier. Par la suite il sera plus facile de s’attaquer à de plus gros morceaux. C’est ce que nous verrons dans le prochain article portant sur Look’n'Stop.

À bientôt.

Règles pour Look ‘n’ Stop - partie 4

COMMENT CRÉER DES RÈGLES POUR VOS APPLICATIONS - première partie

1- Les programmes internets et l’assignation des ports

L’attribution des ports pour les services et applications est du ressort de l’I.A.N.A. Les 65535 ports logiques sont divisées entre les ports “bien connus” de 0 à 1023, “enregistrés” de 1024 à 49151 et “dynamiques” de 49152 à 65535. Certains d’entre eux sont assignés, d’autres non, sans compter les ports “officieusement” assignées et l’utilisation anarchique de n’importe quel ports assignées ou non par certaines applications internets ce qui n’est pas sans causer des conflits, des ports étant utilisés par des application différentes.

Références:

I.A.N.A.
Assignation des ports, officielle ou non

Pour la plupart des applications courantes les ports utilisés correspondent bien à ceux assignés par l’I.A.N.A. mais un bon nombre parmis les applications tel que la VoIP, les messageries instantanées et les applications “multimédia” ont des normes plutôt “flottantes” ou ne tiennent aucun compte de l’assignation des ports.

2- Les programmes, les connexions et la documentation

La plupart des applications internets se connectent aux serveurs en utilisant le premier port local disponible dans la gamme 1024 à 5000. La connection d’un navigateur à un serveur web en est un bon exemple. Lorsque l’URL est entré dans le champ d’adresse du navigateur, le système d’exploitation vérifie la présence ou non de l’URL dans le fichier HOSTS. Si l’URL n’y est pas une requête Domain Name Service est lancée en UDP vers le port 53 du serveur DNS, l’URL est traduite en adresse IP et la connexion est initiée par le navigateur par un paquet TCP sans donnée et avec le flag SYN activé. Le premier port disponible dans la gamme 1024 à 5000 est utilisé et la connection se déroule entre ce port et le port 80 du serveur web tout au long de cette connexion. Rien de plus simple alors de créer une règle pour une telle application.

Si toutes les applications était ainsi faites, l’élaboration de règles serait presqu’un jeu d’enfant: il suffirait d’indiquer au pare-feu le ou les ports distants officiellement assignées pour l’application. Mais ce n’est pas le cas: les ports locaux utilisés pour initier la connection peuvent être différents de la gamme 1024-5000, utiliser plus d’un port local dans le déroulement de la connexion ou encore, obliger l’utilisation d’une gamme de ports distants étendue et aléatoires. Le cas le plus ancien est le protocole FTP qui a l’honneur de figurer en tête de la liste des protocoles à “contenu sale”.

Enfin, pour épicer le tout, un très grand nombre d’application n’ont pas de documentation ou une documentation déficiente, incomplète ou incorrecte. Aussi incroyable que cela puisse paraître il semble de toute évidence que les derniers à connaître le comportement exact d’un programme lors des connections internets en soient trop souvent les auteurs.

3- L’exemple des navigateurs et l’utilisation des ports

Rien de plus simple semble-t-il que les règles pour les navigateurs: la gamme de ports locaux de 1024 à 5000 est utilisée pour initier les connections vers les serveurs web en Http vers le port 80 ou en Https vers le port 443. On note au passage l’existence du port 8080, un port Http alternatif utilisé par quelques sites. Cependant plusieurs navigateurs ajoutent aux fonctions de navigation d’autres fonctions: courrier, messagerie, Nntp, etc.

Cela suppose donc que les règles tiennent compte de toutes ces fonctions ET que ces règles soient activée chaque fois que le programme est lancé, que ces fonctions soient utilisées ou non. C’est le résultat de la tendance à transformer les outils simples en “canif suisse”, “couteau de survie Rambo”, “suite logicielle” ou, pour parler vulgairement, d’usine à gaz [flatuliciel © climenole]. L’empiètement d’un programme sur les fonctions des autres et le je-m’en-foutisme dans l’utilisation des ports est AMHA le résultat de l’exemple déplorable donné par Microsoft ™ tant avec l’Omniprésent et l’Indécrottable InterNUT Expl’horreur [© climenole] intégré à Windows ™ à la façon d’une tumeur inopérable que par le laxisme incroyable de la même bande présentant une demi-barrière de broches à poules comme étant un pare-feu. Tel maître, tels valets.

4- Règles pour les applications les plus courantes

Navigateurs (HTTP / HTTPS)

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000
• Destination Adresse(s) IP: Toutes
• Destination Port(s): Égale ou 80 HTTP, 443 HTTPS
• Application(s): exécutables du navigateur
• En supplément:
• Destination Port(s): Alt-HTTP 8080
• Autres: FTP via l’HTTP et d’autres fonctions optionnelles.

Courrielleurs (SMTP/POP3 ou SMTP/IMAP4 ou SSL/TLS)

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000
• Destination Adresse(s) IP: Toutes
• Destination Ports(s): Égale ou 25 SMTP, 110 POP3
• Destination Ports(s): Égale ou 25 SMTP, 143 IMAP4
• Destination Ports(s): Égale ou 995 POP3S, 587 TLS *
• En supplément:
• Destination Ports(s) 80 HTTP affichage HTML et les mises à jour.
• Destination Ports(s) 11371 HKP accès aux serveurs de clés publiques OpenPGP
• * le port SMTP TLS varie selon le courrielleur utilisé. Voir l’aide de GMail…

Clients IRC

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000
• Destination Adresse(s) IP: Toutes
• Destination Port(s): Entre 6667-6669
• En supplément:
• Source Port: IDENT 113 en tant que serveur!

Clients NNTP

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000
• Destination Adresse(s) IP: Toutes
• Destination Port(s): Égale 119
• En supplément: parfois aussi utilisé comme client de courrier

Clients Jabber

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000 (connexions)
• Source Port: 5222 (communications)
• Destination Adresse(s) IP: Toutes
• Destination Port(s): 5222 *(ou 5223 pour l’accès à Gtalk avec un autre client)
• Destination Port: 8010 (échanges de fichiers)
• Commentaire: dans le cas de Gtalk HTTP + HTTPS pour le “login”

Notez que la plupart des applications locales ont parfois besoin d’une connection en HTTP pour accéder au site web de l’éditeur du programme, pour une aide en ligne ou pour les mises à jour du produit. Dans ce dernier cas les mises à jour sont lancées depuis le programme lui-même ou par un programme spécifique. D’autres applications ne posent pas non plus de problème car les accès sont en général documentés correctement (VNC et ses variantes par exemple). À part quelques exceptions faciles à gérer les programmes internets mentionnés sont plutôt faciles en comparaison de ceux qui vont suivre.

5- Les protocoles à “contenu sale”, à “n’importe quoi” et à “géométrie variables”

À part le cas du FTP et du serveur IDENT, il n’est pas question de donner une énumération à dormir debout de toutes les règles possibles pour les applications multimédias, les messageries instantanées, les clients VoIP, les Jeux, P2P, etc.

Une méthode pour créer des règles sur mesure est plus pratique puisqu’elle est universelle: valable pour toutes les applications peu importe qu’elle soit ou non documentée. C’est cette méthode que nous allons voir au point 6

Le protocole applicatif FTP et ses modes ou le “contenu sale”

Dans le cas du mode actif le client se connecte au port 21 du serveur FTP et les données sont transférées sur l’un des ports locaux prédéterminés par le client à partir du port 20 du serveur FTP. Ce mode implique qu’une nouvelle connexion soit initiée par le serveur FTP vers le client pour la transmission des données.

Dans ce cas il faut 2 règles pour l’utilisation du FTP en mode actif:

une règle pour la connexion du client vers le port 21 du serveur FTP et une règle pour la nouvelle connexion initiée depuis le port 20 du serveur FTP vers le client sur l’un des ports d’une gamme prédéterminée. Cela constitue donc une connexion de type serveur puisque le client doit accepter une connexion entrante en provenance du serveur FTP vers son propre système (Paquet TCP + flag SYN).

Il y a donc dans le protocole applicatif FTP des échanges de ports et d’adresses IP ne devant normalement se dérouler qu’au niveau des protocoles de transport (TCP/UDP).

De plus l’utilisation du FTP en mode actif initie une deuxième connexion de type serveur sur le client lui-même comme nous venons de le voir.

Enfin dans les deux modes les ports utilisés pour les transferts sont imprévisibles et obligent la mise à la disposition des applications utilisant le FTP une large de ports. On peut parler ici de “protocoles à larges culottes”…

Dans le cas du mode passif le client se connecte au port 21 du serveur FTP et les données sont transférées au client depuis n’importe quel port du serveur FTP vers l’un des ports du client au cours de la même connexion (initiée par le client). Ce dernier mode est plus sécuritaire puisqu’il se déroule à l’intérieur d’une connexion unique initiée par le client.

Clients FTP (et fonctions FTP du navigateur) en mode passif

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000
• Destination Adresse(s) IP: Toutes
• Destination Port: 21 FTP-control [première règle]
• Destination Port(s): 49153 à 65535 (parfois 1024 à 65535) [deuxième règle]
• Références: Protocoles réseau à contenu sale
• Commentaires:
• le FTP utilisé via un client FTP tel que Filezilla ne pose pas de problèmes particuliers à part ceux mentionnés dans la référence donnée pour ce protocole. Cependant, en tant que fonction du navigateur cela oblige à chaque fois que celui-ci est lancé à laisser la possibilité d’ouvir l’accès sur une gamme de ports distants étendue tout à fait inutile pour les besoins normaux de navigation.
• De plus cela semble causer quelques ennuis à Look’n'Stop si une autre application utilisant elle aussi une gamme de ports étendue est lancée en même temps. Le pare-feu tend à mélanger les pinceaux au moins au niveau de la journalisation: des accès de MSN Messenger ou d’ITunes pour l’écoute en stream étant journalisés comme des accès FTP.
• Ceci est un exemple d’une limitation de Look’n'Stop: pare-feu à état mais pas pare-feu d’applications proprement dit; il n’y a pas de vérification ni de différence faites entre des paquets FTP ou HTTP par exemple. Un un mot, L’n'S reconnaît bien les paquets du niveau Transport (TCP, UDP, ICMP, etc.) mais ne distingue pas les échanges au niveau applicatif (HTTP, FTP, SIP, etc.). Ces différences sont indirectement (et imparfaitement) contrôlées avec les règles limitant l’accès à des ports distants correspondants au protocoles du niveau 5 des couches TCP-IP. Dans le cas de protocoles “à larges culottes” un méli-mélo semble s’installer au niveau de la détection des sockets…
• Les limitations, les “bugs” et les améliorations souhaitables de Look’n'Stop sortent du cadre de cet article et seront examinés dans de prochains articles.

Client FTP en mode actif

• Serveur: placer obligatoirement entre la règle { G.07} et la règle { Q.999}
• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000 (ou une autre gamme déterminée par le client FTP)
• Destination Adresse(s) IP: Toutes (ou adresses IP des serveurs FTP)
• Destination Port: 20
• Commentaire: ambigüité de source et destination. Dans le cas d’un échange de paquets en entrée et sortie la source et la destination varient. Le terme plus exact serait local [L] plutôt que “source” et distant [D] plutôt que “destination”. C’est d’ailleurs ainsi que les indications doivent être comprises. Dans le cas de l’édition des règles de L’n'S, “source” désigne les champs d’adresses et de ports à gauche, tandis que “destination” désigne les champs à droite.
• 
  

Le protocole IDENT ou le “n’importe quoi”

• Serveur: placer obligatoirement entre la règle { G.07} et la règle { Q.999}
• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Source Adresse(s) IP: @IP
• Source Port(s): 113
• Destination Adresse(s) IP: Toutes
• Destination Ports(s): tous
• Application(s): option du client IRC ou WinIdent
• Références: Ident

Le protocole IDENT serait, paraît-il, important pour les serveurs IRC afin identifier l’accès aux serveurs IRC depuis un système multi-utilisateur afin d’identifier et d’éventuellement bannir cet utilisateur en cas d’abus plutôt que de bannir le système multi-utilisateur à partir duquel il s’est connecté. En cas d’absence de réponse à la requête IDENT le nom de l’utilisateur connecté est alors préfixé avec un tilde [ ~ ] indicant qu’il n’y a pas de nom d’utilisateur obtenu par l’IDENT et que celui-ci pourrait être un “fake”…

Il peut même arriver qu’un serveur IRC bloque l’accès à toute tentative de connection de donnant pas de réponse à la requête IDENT. Une mini-polémique a d’alleurs opposée MM. Erik Fair et Russell Nelson au sujet de ce protocole.Le premier soutenant que ce protocole est sans pertinence et possiblement dangereux, l’autre retournant l’argument cul par dessus tête en soutenant que ce protocole serait des plus utile aux administrateurs de système pour identifier les utilisateurs abusifs (de serveurs IRC…).

Erik Fair: identd (identification protocol) is pointless and potentially dangerous
Russell Nelson: ident is not of use to servers

Pour vous faire une idée vous même je vous invite à consulter le RFC 1413 et en particulier cet extrait (c’est moi qui souligne…):

RFC 1413

«
6- Security Considerations

The information returned by this protocol is at most as trustworthy as the host providing it OR the organization operating the host. For example, a PC in an open lab has few if any controls on it to prevent a user from having this protocol return any identifier the user wants. Likewise, if the host has been compromised the information returned may be completely erroneous and misleading.

The Identification Protocol is not intended as an authorization or access control protocol. At best, it provides some additional auditing information with respect to TCP connections. At worst, it can provide misleading, incorrect, or maliciously incorrect information.

The use of the information returned by this protocol for other than auditing is strongly discouraged. Specifically, using Identification Protocol information to make access control decisions - either as the primary method (i.e., no other checks) or as an adjunct to other methods may result in a weakening of normal host security.

An Identification server may reveal information about users, entities, objects or processes which might normally be considered private. An Identification server provides service which is a rough analog of the CallerID services provided by some phone companies and many of the same privacy considerations and arguments that apply to the CallerID service apply to Identification. If you wouldn’t run a “finger” server due to privacy considerations you may not want to run this protocol.

»

Pour ma part je soutiens que ce protocole est insignifiant, sans pertinence et utilisé par certains serveurs IRC encroûtés à la façon d’une mauvaise habitude. Il n’aide personne, ni les administrateurs de ces serveurs, ni les utilisateurs, ni les administrateurs de systèmes multi-utilisateurs: personne (même pas les Script Kiddies!). Plus amusant encore il même très facile de donner à la requête IDENT une réponse fantaisiste et gobée telle quelle par les serveurs IRC. Il suffit par exemple d’utiliser le programme WinIdent Server plutôt que l’option de réponse IDENT du client IRC.

Voici une capture d’écran de la connexion d’une machine sous Windows XP se présentant chez Dalnet en tant que BSD Unix à l’aide de WinIdent:

En somme un truc totalement inutile qui nécessite l’installation d’un serveur dont la valeur est douteuse sauf évidemment pour faire une blague ou un clin d’oeil aux serveurs IRC ou autrement de ne pas l’utiliser.
Vous pouvez trouver le programme WinIdent server sur le site de l’auteur (inaccessible?): http://www.rndware.info ou via les réseaux P2P en format zip.

Checksum:

sha1:QKHRVMK6MIEKPVJZ7TZMUJQH3G3FXPY2 md5:4b1e263c071db6ecc50e49bc7f2232ac

Les autres “n’importe quoi” ou protocles fantaisistes

Dans le cas des Messageries et de la VoIP, les fonctions de connexion utilisent le HTTP et le HTTPS mais toutes les autres fonctionnalités: présence, communications vocales et vidéo, échanges de fichiers et autres utilisent un protocole propriétaire, des ports locaux et distants variants selon le service de messagerie utilisée et obligent la plupart du temps à autoriser une gamme très large de ports. Les règles doivent en conséquence être adaptées chaque fois pour accomoder le protocole propriétaire de tel ou tel service de messagerie. Ce sont aussi des “protocoles à larges culottes” nécessaires pour y installer confortablement leur gros derrières flasques.

On note cependant que Jabber permet l’utilisation de d’autres protocoles via les “transports” ce qui permet évidemment de simplifier les règles du pare-feu. Cependant les transports faisant office de passerelles vers d’autres services de messageries sont dépendants de protocles fermés et ne permettent pas en général d’accéder à toutes les fonctions disponibles en utilisant le client de messagerie dédié à ce protocole.

Il en va de même des applications multimédia: les fonctions de “stream” pour l’écoute des radios en lignes par exemple utilisent une multitude de ports distants: aucune norme n’étant prévue pour ces applications. Pour les jeux en lignes: chacun établissant ses propres normes il n’est pas possible d’avoir une règle générale permettant de tous les utiliser.

Enfin les applications de serveurs et de P2P sont relativement bien documentées mais dans le cas des applications P2P l’implantation de règles correctes est plus ardue puisqu’il s’agit à la fois d’application clientes ET d’application serveur.

Le protocole BitTorrent ou à “géométrie variable”

Dans le cas particulier de BitTorrent le port d’accès de la partie serveur est “officiellement” le port TCP 6881. Cependant il est recommandé de ne pas l’utiliser à cause du filtrage de ce port par de nombreux serveurs. Il est suggéré d’utiliser un des ports non assignés par l’I.A.N.A,. tel que, par exemple, 46881. On voit tout de suite le problème: chaque client BT permet le choix de n’importe quel port de serveur. Ce n’est pas tout: le protocole BitTorrent utilise plusieurs port différents pour l’annonce des torrents: les ports 6969 en HTTP ou 7000 en HTTPS sont utilisés mais ce n’est pas toujours le cas et l’annonce peut être faite sur n’importe quel autre. Enfin certains clients BT tel qu’Azureus utilisent aussi le Distributed Hash Table en UDP.

Tout cela ne pose pas vraiment de problèmes pour établir des règles mais oblige encore une fois à permettre l’utilisation d’une gamme importante de ports locaux et distants puisqu’il est impossible de prévoir lequels parmi cette gamme seront utilisés. (Dans le cas d’Azureus on notera aussi l’envoi amusant d’un paquet IGMP vers l’adresse IP 224.0.0.22 au lancement et à la fermeture du programme… Pourquoi? En attendant les commentaires des auteurs on peut demander à Google ou au hacker d’à côté en échange d’une pointe de pizza.)

On peut parler ici de flexibilité de l’implantation du protocole ou insister sur les pirouettes nécessaires pour intégrer ce protocole aux règles d’un pare-feu bien ordonné. Sur ce point je préfère le prendre tel quel et me débrouiller pour trouver les meilleures règles possibles compte tenu des circonstances.

À SUIVRE (?!)

Je vous avais promis de publier dans cette quatrième partie la méthode pour créer des règles à partir du format brut du journal et d’un chiffrier de même que le jeu de règles à télécharger. Mais la dimension de l’article ayant été plus importante que ce que j’avais prévu, la suite fera l’objet d’un cinquième et dernier article. Je vous remercie à l’avance pour votre patience et votre compréhension.

à bientôt.