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.

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

Présentation commentée d'un jeu de règles.

« Ce qui a forme et contours peut être observé par chacun dans l'Empire [...] Tout cela est soumis à des formes se dominant mutuellement. Celui qui excelle aux formes refuse de les imiter. Car il sait que la grandeur du Tao réside dans ce qu'il n'a pas de forme. Sans-forme il ne peut être ni dominé, ni mesuré, ni trompé, ni même deviné. »

Extrait du "Houai-Nan Tse", commentaire de l'Art de la Guerre de Sun Tzu.

1- Résumé des deux articles précédents

Dans le premier article nous avons vu les points importants dont il faut tenir compte dans l'élaboration de notre jeu de règles: les adresses IP, l' Internet Control Messages Protocol, l'User Datagram Protocol et le Transmission Control Protocol.

Dans le second article de cette série nous avons abordé l'édition des règles pour les filtrages logiciel et internet.

Les éléments déjà vu dans les articles précédents nous fournissent donc les matériaux et les moyens pour monter un jeu de règles permettant à votre système d'être furtif, sans fuite et informatif.

Furtif:

Votre ordinateur ne répond à aucune sollicitation en provenance d'internet tel que des balayages par ICMP, l'envoi de datagrammes UDP ou des tentatives sollicitation de votre système en tant que serveur avec des paquets TCP qui ne vous sont pas normalement destinées ou mal formés.

Parmis ces paquets un bon mombre proviennent de restes de connexions précédentes destinées à l'adresse IP dynamique que vous venez d'obtenir, de routeurs mal configurés, de paquets en provenance de "Zombies" et plus rarement de balayages dirigés vers votre adresse IP utilisés pour détecter si cette adresse IP correspond à une machine en opération et en cas de réponse d'un système non-furtif quelles sont les réponses obtenues.

Ces "scans" permettent de déterminer les ports ouverts, fermés, la présence d'un service en écoute et même le type de système d'exploitation en analysant la signature des réponses. Dans d'autres cas des envois massifs de paquets anormaux sont utilisés pour exploiter des faiblesses connues ou possibles de tel ou tel système d'exploitation.

Look'n'Stop est un pare-feu à état (Stateful): les paquets sont analysés en eux-mêmes et selon qu'ils font partie d'une connexion que vous avez initiée, établie entre votre PC et un serveur et faisant partie de la séquence des paquets échangés pour cette connexion.

Un point important à préciser: les "attaques" et les tentatives d'intrusion dirigées contre des ordinateurs personnels sont rares: les "attaques" étant surtout le fait de "Script_kiddies" et les tentatives d'intrusion résultant le plus souvent d'une infection de l'ordinateur par des programmes malveillants d'où l'importance de préserver votre système de toute infection par ces programmes malveillants et l'importance pour le pare-feu d'empêcher tout fuite vers l'extérieur de la part de ces "malwares".

Votre système étant furtif, vu de l'extérieur, votre adresse Ip ne révèle rien, ni les ports ouverts ou fermés, ni le type de système ni même la présence ou non d'une machine en activité correspondant à cette adresse.

Sans fuites:

Seuls les programmes autorisés peuvent se connecter à internet ou lancer d'autres programmes qui s'y connectent. Le pare-feu identifie la signature du programme, en demande l'autorisation à l'utilisateur, filtre les connexions selon les règles pré-établies et bloque le reste.

À première vue cela ne devrait pas poser de problème et le filtrage de l'intérieur vers l'extérieur est plus une question d'ordre et d'information qu'autre chose. Mais le système n'est pas clos: il est ouvert sur l'extérieur et les connexions établies sur internet échangent des données au cours des connexions via les applications, les mises à jours et les installations de nouveaux programmes.

Les filtrages du pare-feu concernent la couche TCP-IP de liaison, la couche réseau, la couche transport et la couche application. Cependant la protection de look'n'Stop ne s'étend pas jusqu'aux détails des échanges tels que ceux du navigateur avec un site web. Par exemple, le pare-feu autorise le navigateur à se connecter au site en TCP, sur le port distant 80 (HTTP) mais les données et les codes échangés entre ceux-si sont du ressort des paramètres de sécurité du navigateur (cookies, Javascript, redirections, etc.).

Les tests de fuite révèlent les méthodes les plus courantes utilisées par les programmes malveillants pour passer outre au couches de protection: substitution, lancement indirect, accès direct aux couches réseau, injection par DLL, injection de processus, attaque par multiplication d'identificateur de processus, requêtes récursive, etc.

Le filtrage de Look'n'Stop est l'une des couches de protection intérieure de votre système. Le maintient à jour du système d'exploitation, des pilotes et des applications, une configuration correcte des services, un anti-virus à jour et en protection résidente ("On Access"), des protections anti-spywares, des applications dont les paramètres de sécurité sont correctement réglés et possiblement un protecteur d'intégrité tel que System Safety Monitor font aussi parties de ce système de protection par couches.

Il est indispensable de noter que la plupart des problèmes de fuites dépendent de la façon dont les systèmes MS Windows ™ sont conçus: "interdépendances" des programmes, niveaux de permissions, privilèges d'exécution, etc. Ce n'est pas le rôle d'un pare-feu de servir de béquille aux méthodes boiteuses d'un système d'exploitation à moins de vouloir transformer les fonctions d'un pare-feu en redresseur de système d'exploitation tordu.

Mais le facteur le plus important est l'utilisateur en tant qu'administrateur de son système. C'est la pratique du Safe-Hex qui assure le bon dosage de sécurité et de fonctionnalité. Être informé est à la base de la pratique du Safe-Hex et les notifications et les journaux du pare-feu vous en procurent une bonne partie.

Sans négliger l'importance d'avoir de bon outils il est bon de rappeler à la suite de Bruce Schneier que la sécurité n'est pas [d'abord]un produit mais [principalement]un processus.

« Security is not a product, it's a process »

Informatif:

Le pare-feu doit enfin vous donner les informations nécessaire pour que vous restiez le "maître à bord". La journalisation et les notification en temps réel doivent vous permettre de décider en connaissance de cause de la validité ou non d'une application se connectant à internet. Ces notifications, combinées à d'autres outils tels que Process Explorer ou Packetyzer, vous permetrent un contrôle raisonnable sur les échanges entre votre système et internet.

Il importe toutefois de trouver un juste dosage entre les notifications et la journalisation. Les notifications immédiates ne doivent pas vous alerter inutilement et la journalisation doit être suffisamment complète pour être utilisable. Le point majeur étant la pertinence de ces informations.

Les notifications de Look'n'Stop lors du lancement d'une nouvelle application, la notification lors d'un changement de signature d'un programme sont nécessaires par contre des alertes à tout bout de champs pour les moindres blocages sont aussi ennuyantes qu'inutiles.

Quant à la journalisation elle doit vous permettre des vérifications occasionnelles, retracer les activités du système et l'élaboration de règles d'applications plus précises. Il est évident que passer toutes les entrées en revue ou d'archiver les journaux pour de trop longues périodes seraient aussi fastidieux qu'inutile. Il existe aussi des moyens pour traiter les journaux avec des programmes tiers tels que OO Calc ou MS Excel pour en faire la synthèse permettant d'en faire ressortir les points pertinents.

2- Modèles possibles de jeu de règles

Compte tenu des possibilitées offertes par look'n'Stop par les filtrages logiciel et internet quel peut être la bonne combinaison entre les restrictions et la fonctionnalité du système? Il est possible par exemple de déterminer précisément pour chaque programme reconnu les ports, les adresses ou gammes d'adresses tout en inscrivant au journal l'ensemble des activitées de ceux-ci. Il est possible aussi de n'y mettre aucune contrainte du moment que le programme est approuvé. Quant au filtrage internet on peut établir une gamme de possibilités de filtrage allant d'une seule règle générale permettant à toutes les applications de se connecter à internet jusqu'à un jeu de règles pour chaque application.

Je propose le dosage suivant pour le filtrage logiciel: les programmes susceptible d'être détournés par des programmes malveillants doivent être restreints tant pour les ports, les adresses et la possibilité ou non soit de se connecter à internet ou de lancer d'autres applications susceptibles de le faire. Pour les autres programmes, les contraintes seront minimales au niveau du filtrage logiciel.

Programmes bloqués: pas d'accès internet et pas de lancement de programmes tiers, mention dans le journal en cas d'exécution: wscript.exe et cscript.exe, mshta.exe, schtasks.exe et son jumeau at.exe, rundll32.exe, cmd.exe, wmiprvse.exe.

Sans oublier la nouvelle initiative anti-piratage de Microsoft d'un goût douteux: wgatray.exe.

Programmes bloquées en accès direct avec autorisation de lancer d'autre application internet et notifications au journal: winlogon.exe, smss,exe, services.exe, explorer.exe.

Programmes restreints d'accès par ports et adresses IP avec notification au journal: svchost.exe et msiexec.exe. Les détails sont indiquées plus loin.

Et finalement celui-ci:

Une des sources les plus importantes d'infections, traînant depuis des lunes des failles jamais corrigées, cible rêvée de tous les vandales de la Toile, IE est aussi l'intermédiaire de choix utilisé par un bon nombre de programmes malveillants pour passer outre les couches de protection de votre système. Utilisation fortement déconseillée. Ce machin inqualifiable est bloqué. Il faut cependant être conscient du fait que cela n'est pas une garantie absolue et que le blocage logiciel ne constitue pas une panacée.

En ce qui concerne le filtrage internet pour les programmes y ayant accès, je propose d'établir une règle par type d'application en tenant compte de la couche application du protocole TCP-Ip (Http, Https, Ftp, Nntp, Ntp, etc.). Puisqu'il faut un ordre je propose que les règles pour les programmes internet soient listés par le dernier port distant utilisé par la couche application à savoir 21 pour les programmes ou fonctions de programmes Ftp, 80 pour le Http et ainsi de suite. Certains protocoles pourront être regroupés tels que le Pop3 et le Smtp et des exceptions sont prévues pour certains cas. Voyons d'abord le jeu de règles générales (avec les restrictions déjà mentionnées précédemment: pas de réseau, connexion internet PPPoE sans routeur ou DHCP) [3] puis quelques règles pour les applications internet courantes et quelques autres qui pourraient vous intéresser [4].

3- Exemple d'un jeu de règles simple

Tout d'abord un mot sur la numérotation des règles. Le problème à résoudre était d'identifier chaque règle ET d'indiquer en même temps la position relative de chacune d'elles en tenant compte de la possibilité d'une expansion future de celles-ci. J'ai constaté que le positionnement correct des nouvelles règles est souvent mal compris. Les règles sont examinées à partir du début de la liste et dès que tous les critères d'une règle correspondent, cette règle est appliqué et les suivantes ne sont pas prises en compte. De plus le modèle utilisé doit permettre d'ajouter facilement et dans le bon positionnement de nouvelles règles reflétant des modifications à la configuration (ajout d'un routeur, installation d'un réseau local ou d'un serveur, nouvelles applications internet, etc.)

Le modèle de numérotation que je propose n'est évidemment pas parfait mais peut vous inspirer pour en trouver un meilleur. Les règles sont classées par catégories au moyen d'un capitale romaine de A à Z: A est réservée pour une expansion future des règles, B pour les règles des gammes d'adresse IP, C pour le protocole ICMP, D pour les règles communes au TCP et à l'UDP, E pour les règles UDP, F est en réserve, G pour les règles en TCP, H à P en réserves pour le réseau local et les serveurs, Q est utilisé pour la règle unique de blocage des sollicitation de connexions serveur (paquets TCP SYN en entrée), R est prévu pour les règles des programmes internet, S en réserve , T à Y utilisés pour les verrouillages des protocoles et enfin, Z utilisé pour la règle finale et obligatoire qui clos la liste des règles: le blocage de tout le reste.

{ A.00}, [AA], identifiant

Entre accolades: la catégorie en capitale romaine, point, numéro de règle, virgule

Entre crochet: l'identifiant de direction des paquets AA autorisé en entrée/sortie, XX interdit en entrée / sortie, EA pour entrée autorisée, SA pour sortie autorisée, EB pour entrée bloquées, SB pour sortie bloquée, suivi d'une virgule.

Enfin le nom de la règle.

L'utilisation des virgules est prévue pour la séparation des champs dans le format brut du journal. (Tout cela est évidemment optionnel: cela vous en indique la possibilité.)

I - Règles { B.01} à { B.09} concernent le blocage en entrée de paquets de n'importe quel protocole en provenance d'adresses IP ne devant pas se retrouver sur internet: adresse IP se terminant par 0 ou 255, adresses réservées pour les réseaux locaux ou le bouclage sur "localhost" et enfin les adresses réservées par L'I.A.N.A pour usage futur.

{ B.01}, [EB], IP Invalides *0

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: Tous
• Frag. Offset: n/a
• Frag. Flag: n/a
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Masque 0.0.0.0 / 0.0.0.255
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP (mon adresse IP)
• Destination Ports(s): Tous
• Application(s): Toutes

{ B.02}, [EB], IP Invalides *255

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: Tous
• Frag. Offset: n/a
• Frag. Flag: n/a
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Masque 0.0.0.0 / 0.0.0.0
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ B.03}, [EB], IP Locales 10*

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: Tous
• Frag. Offset: n/a
• Frag. Flag: n/a
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Entre A-B 10.0.0.0- 10.255.255.255
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ B.04}, [EB], IP Locales 127*

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: Tous
• Frag. Offset: n/a
• Frag. Flag: n/a
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Entre A-B 127.0.0.0 - 127.255.255.255
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ B.05}, [EB], IP Locales 169*

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: Tous
• Frag. Offset: n/a
• Frag. Flag: n/a
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Entre A-B 169.254.0.0 - 169.254.255.255
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ B.06}, [EB], IP Locales 172*

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: Tous
• Frag. Offset: n/a
• Frag. Flag: n/a
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Entre A-B 172.16.0.0 - 172.31.255.255
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ B.07}, [EB], IP Locales 192*

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: Tous
• Frag. Offset: n/a
• Frag. Flag: n/a
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Entre A-B 192.168.0.0 - 192.168.255.255
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ B.08}, [EB], IP Multipoints

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: Tous
• Frag. Offset: n/a
• Frag. Flag: n/a
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Entre A-B 224.0.0.0 - 239.255.255.255
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ B.09}, [EB], IP Réservées

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: Tous
• Frag. Offset n/a
• Frag. Flag: n/a
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Entre A-B 240.0.0.0 - 255.255.255.255
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

II- Règles { C.01} à { C.05} concernent le protocole ICMP. Elles comprennent d'abord deux règles de blocages visant la fragementation et trois règles autorisant l'utilisation légitime de ce protocole par votre système. Une règle de blocage finale est prévue à la fin du jeu de règles.

{ C.01}, [EB], Fragmentés

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: ICMP
• Frag. Offset: Different 0
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: Tous
• type: Tous
• Source Adresse(s) IP: Toutes
• Source Port(s): n/a
• Destination Adresse(s) IP: @IP
• Destination Ports(s): n/a
• Application(s): Toutes

{ C.02}, [EB], + Fragments

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: ICMP
• Frag. Offset: Tous
• Frag. Flag: MF
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: Tous
• type: Tous
• Source Adresse(s) IP: Toutes
• Source Port(s): n/a
• Destination Adresse(s) IP: @IP
• Destination Ports(s): n/a
• Application(s): Toutes

{ C.03}, [SA], Requête

AUTORISÉ

• Type Ethernet: IP
• Direction(s): Sortante
• Protocole IP: ICMP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: 0
• type: 8
• Source Adresse(s) IP: @IP
• Source Port(s): n/a
• Destination Adresse(s) IP: Toutes
• Destination Ports(s): n/a
• Application(s): Toutes

{ C.04}, [EA], Réponse

AUTORISÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: ICMP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN; n/a
• code: 0
• type: 0
• Source Adresse(s) IP: Toutes
• Source Port(s): n/a
• Destination Adresse(s) IP: @IP
• Destination Ports(s): n/a
• Application(s): Toutes

{ C.05}, [EA], Dépassement de temps

AUTORISÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: ICMP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: 0
• type: 11
• Source Adresse(s) IP: Toutes
• Source Port(s): n/a
• Destination Adresse(s) IP: @IP
• Destination Ports(s): n/a
• Application(s): Toutes

III- Règles { D.01} à { D.04} concernent les règles de blocages communes aux protocoles TCP et UDP: paquets en provenance ou en direction du port 0 et paquets fragmentés.

{ D.01}, [EB], Src Port 0 Invalide

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: TCP/UDP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): 0
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ D.02}, [EB], Dst Port 0 Invalide

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: TCP/UDP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP:@IP
• Destination Ports(s): 0
• Application(s): Toutes

{ D.03}, [EB], Fragmentés

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrantes
• Protocole IP: TCP/UDP
• Frag. Offset: Différent 0
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ D.04}, [EB], + Fragments

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: TCP/UDP
• Frag. Offset: Tous
• Frag. Flag: MF
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

IV- Règles { E.01} à { E.99} concernent l'autorisation des requêtes DNS, mettent des numéros de règles en réserve pour le DHCP et les NetBios en UDP pour un réseau local et se terminent par le blocage des datagrammes NetBios et NetSend Messenger en provenance d'internet.

{ E.01}, [AA], DNS - Résolution des noms

AUTORISÉ

• Type Ethernet: IP
• Direction(s): Entrantes et Sortantes
• Protocole IP: UDP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-5000
• Destination Adresse(s) IP: Ip des serveurs DNS
• Destination Ports(s): 53
• Application(s): Toutes

Commentaire: l'adresse IP des serveurs DNS est celles indiquées par la commande Ipconfig /all

{ E.98}, [EB], NetBios name/datagram

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: UDP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): 137-138
• Application(s): Toutes

Commentaire: la règle ne bloque pas les paquets NetBios sortants. Le jeu de règles présenté suppose que le NetBios n'est pas utilisé (pas de réseau local) et que votre système est correctement configuré (paramètres de la connexion réseau et les services NetBios et associés arrêtés et mis en mode manuel ou désactivé.) Les règles ne sont pas une béquille pour une mauvaise configuration …

{ E.99}, [EB], Net send messenger

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: UDP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): 1024-1055
• Application(s): Toutes

Commentaire: cette règle concerne les datagrammes UDP du service d'affichage des messages détournées par les "spammeurs" (principalement originaires du "Pacific Ring" ou des pays d'Europe de l'est.). Si votre système est à jour et correctement configuré vous ne devriez pas être ennuyés par ces messages. Toutefois j'ai inclu cette règle afin de différencier le blocage du Net Send Messenger des autres blocages UDP. Cette règle est optionnelle mais pratique pour des raisons de débogage des applications utilisant l'UDP et pour une journalisation plus précise.

V- Règles { G.01} à { G.07} concernent les règles de blocage pour le TCP; le bouclage sur l'adresse Ip de votre système [l'exploit "Land Attack"] et le blocage des paquets TCP avec des flags anormaux.

{ G.01}. [XX]. Src & Dst = @IP

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: @IP
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ G.02}, [EB], Null

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: TCP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP:
• Masque: URG ACK PSH RST SYN FIN
• Actif : Aucun flag activé
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ G.03}, [EB], Full

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: TCP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP:
• Masque: URG ACK PSH RST SYN FIN
• Actif : Tous les flags activés
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

{ G.04}, [EB], Fin & variantes

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: TCP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP:
• Masque: ACK FIN
• Actif : FIN
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

Commentaire: cette règle permet un filtrage des paquets TCP anormaux avec les 14 variantes suivantes: FIN, FIN-SYN, FIN-RST, FIN-PSH, FIN-URG, FIN-SYN-RST, FIN-SYN-PSH, FIN-SYN-URG, FIN-RST-PSH, FIN-RST-URG, FIN-PSH-URG, FIN-SYN-RST-PSH, FIN-SYN-RST-URG, FIN-SYN-RST-PSH-URG.

{ G.05}, [EB], Syn Rst & variantes

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: TCP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP:
• Masque: ACK RST SYN FIN
• Actif : RST SYN
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

Commentaire: cette règle permet un filtrage des paquets TCP anormaux avec les 4 variantes suivantes: SYN-RST, SYN-RST-PSH, SYN-RST-URG, SYN-RST-PSH-URG.

{ G.06}, [EB], Syn Psh & variantes

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: TCP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP:
• Masque: ACK PSH RST SYN FIN
• Actif : PSH SYN
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

Commentaire: cette règle permet le filtrage des paquets TCP anormaux suivants: SYN-PSH, SYN-PSH-URG.

{ G.07}, [EB], Syn Urg

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: TCP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP:
• Masque: URG ACK SYN FIN
• Actif : URG SYN
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

VI- Règle { Q.999} concerne le blocage des paquets TCP avec le flag SYN en provenance d'internet. Cette règle est la règle pivot du jeu de règles. Elle permet de bloquer toute tentative de solliciter votre système en tant que serveur. Si vous installez un serveur sur votre PC, les règles concernant le serveur devront se placer obligatoirement entre la règle { G.07} et la règle { Q.999}. Toutes les règles concernant les programmmes internets doivent être à la suite de cette règle et précéder les règles finales de verrouillage.

{ Q.999}, [EB], SYN Entrant

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante
• Protocole IP: TCP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: Option "bloquer les connexions réseau" cochée
• Masque: URG ACK PSH RST SYN FIN
• Actif : SYN
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: @IP
• Destination Ports(s): Tous
• Application(s): Toutes

VII- Règles {R.00000.00} à {R.99999.99} sont réservées pour les règles des programmes devant normalement se connecter à internet. Les identifiants { S.00} sont gardés en réserve pour des utilisations de déboguage ou autre.

{R.00000.00}, [AA], Programmes internet

AUTORISÉ

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP/UDP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: @IP
• Source Port(s): 1024-65535
• Destination Adresse(s) IP: Toutes
• Destination Ports(s): Toutes
• Application(s): Au moins une des applications listées dans le filtrage logiciel.

Commentaire: cette règle très peu restrictive permet d'utiliser à peu près n'importe quelle application internet; navigateur, courrielleur, messagerie instatanée, etc. Cependant elle doit être combinée à l'option de journalisation du filtrage logiciel à défaut de quoi la trace de "qu'est-ce ce qui fait quoi" se perd assez vite. Est-il besoin de préciser que cette règle ne doit pas être utilisée sans inclure au moins une application pour la règle. De plus le nombre d'applications maximales par règle étant de 10, ses limites se recontrent assez rapidement. Dans le prochain article de cette série nous verrons une façon plus ordonnée de procéder. Il est à noter qu'une règle sans restriction pourra être utilisée de façon temporaire pour suivre l'exécution à la trace d'un programe afin d'en déterminer les règles précises.

VIII- Règles { T.00} à { Y.9999} sont utilisées pour le verrouillage final des différents protocoles. Sans être obligatoires ces règles permettent d'identifier facilement le blocages par protocole.

{ T.99999}, [XX], Verrouillage TCP

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: TCP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: Tous
• Destination Ports(s): Tous
• Application(s): Toutes

{ U.99999}, [XX], Verrouillage UDP

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante et sortante
• Protocole IP: UDP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP: n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: Toutes
• Destination Ports(s): Tous
• Application(s): Toutes

{ V.99999}, [XX], Verrouillage ICMP

BLOQUÉ

• Type Ethernet: IP
• Direction(s): Entrante et Sortante
• Protocole IP: ICMP
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: Tous
• type: Tous
• Source Adresse(s) IP: Toutes
• Source Port(s) n/a
• Destination Adresse(s) IP: Toutes
• Destination Ports(s): n/a
• Application(s): Toutes

IX- Règle {Z.99999.99} est la règle finale et obligatoire pour clore le jeu de règles afin d'interdire et de bloquer tout ce qui n'est pas soumis à une règle placée avant. Elle est absolument nécessaire pour assurer la validité de votre jeu de règles.

{ Z.9999999}, [XX], VERROUILLAGE FINAL

BLOQUÉ

• Type Ethernet: Tous
• Direction(s): Entrantes et Sortantes
• Protocole IP: Tous
• Frag. Offset: Tous
• Frag. Flag: Tous
• Flag TCP n/a
• Masque: URG ACK PSH RST SYN FIN: n/a
• Actif : URG ACK PSH RST SYN FIN: n/a
• code: n/a
• type: n/a
• Source Adresse(s) IP: Toutes
• Source Port(s): Tous
• Destination Adresse(s) IP: Toutes
• Destination Ports(s): Tous
• Application(s): Toutes

4- Règles pour les programmes internets

Le jeu de règles tel que présenté jusqu'ici permet de bloquer les paquets anormaux en provenance d'internet, d'utiliser n'importe quel programme internet et de verrouiller correctement le jeu de règles.

Toutefois la règle unique autorisant les programmes internets est trop permissive et suppose soit que le filtrage logiciel précise les ports ou les adresses IP autorisées pour les applications soit que les programmes internets soient contrôlés par des règles spécifiques du filtrage internet.

Dans le prochain article de cette série nous verrons comment combiner les possibilités du filtrage logiciel et du filtrage internet pour les programmes les plus courants de façon à n'autoriser explicitement les programmes qu'avec des règles de filtrage internet.

L'avantage de cette méthode de filtrage est de réduire les possibilités de fuites et d'avoir les traces explicites des activités, programme par programme, dans les journaux. Cela permet aussi de simplifier la gestion de votre pare-feu en regroupant les réglages du côté du filtrage internet plutôt qu'en les dispersant dans le filtrage logiciel.

Les règles présentées ici seront dans le prochain article en format téléchargeable prêtes à l'importation dans Look'n'Stop pour vous permettre de les essayer, de les adapter à votre système et de les améliorer. La méthode pour créer de nouvelles règles à partir du format brut des journaux avec un chiffrier sera aussi expliquée.

À bientôt.