LnS - Les 7 étapes et le Journal

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.