A propos de "Block and Log All Unmatching Requests"

Bonjour,

Les jeux de règles prédéfinis (Web Browser, FTP Client, etc.) se terminent systématiquement par la règle “Block and Log All Unmatching Requests” (je cite de mémoire car je n’ai pas CIS sur mon poste actuel).

A quoi sert cette règle puisque, par définition, un pare-feu n’autorise que les requêtes conformes aux règles ?

Si elle est indispensable, comment l’insérer lorsqu’on définit soi-même les règles pour une application donnée ?

Merci d’avance pour vos réponses

Edit: “Block and Log All Unmatching Requests” et non “Block and Log All Unmatched Requests”

Bonjour,

Il faut simplement éviter de penser qu’un pare-feu à la base, cela bloque tout.
Un pare-feu sans règle, cela ne fait strictement rien hormis écouter le réseau.

Si l’on retirerait la règle de blocage, cela reviendrait à dire qu’on ne bloque jamais rien, ou plutôt qu’on ne fait rien dans tous les autres cas.

J’ai l’impression que nous ne sommes pas sur la même longueur d’onde…

Mais c’est peut-être parce que ma question (la première) était idiote. Car la réponse est simple, en réfléchissant un peu (je parle pour moi): la règle “Block and Log All Unmatched Requests” a pour conséquence le blocage de toute requête non conforme aux règles définies, au lieu de l’ouverture d’une fenêtre d’alerte (du moins en “Stratégie personnalisée”). Verrouiller le jeu de règles en quelque sorte. C’est bien ça ?

Pourtant j’ai bien vu qu’en assignant à FileZilla le jeu prédéfini “FTP Client”, il était impossible de vérifier la présence de mises à jour.

Du coup, je relance ma deuxième question: comment insérer soi-même cette règle-là ?

Block and Log All Unmatched Requests correspond a bloquer les connexions entrantes pour une applications.
c’est a dire l’application ne peu pas jouer le rôle d’un serveur en “écoutant” un port.

C’est bien ça votre question ?

En êtes-vous sûr ? Je dirais plutôt: bloquer et consigner toutes les requêtes qui ne sont pas conformes (qui ne “matchent” pas) aux règles qui ont été définies pour l’application. Je peux me tromper. Mais je ne vois pas comment “Block and Log All Unmatching Requests” pourrait signifier autre chose (“Unmatching” au lieu de “Unmatched” soit dit en passant - je viens de modifier le titre de mon post initial)

Pas vraiment. Cette règle me paraissait superflue et je voulais en avoir confirmation. D’où ma (première) question. Mais je me suis vite ravisé (voir ma réponse à Shaoran).

Si j’ai bien compris, cette règle est intéressante lorsqu’on estime avoir défini toutes les règles pour une application donnée et qu’on ne veut plus recevoir d’alerte de la part de CIS pour les requêtes non conformes à ces règles.

J’aimerais donc savoir comment je pourrais moi-même l’insérer (avec immédiatement en tête FileZilla auquel j’ai assigné des règles de type Client FTP et des règles autorisant la vérification de mises à jour).

Exactement, mais c’est aussi le cas pour tous les autres modes. Les alertes n’apparaissent que s’il est possible d’ajouter une règle. Si la règle demandant de bloquer tout ce qui ne colle pas aux autres est présente, toutes les possibilités sont donc déjà prise en compte et aucune alerte n’apparaitra pour cette application et ceux dans tous les modes.

Il faut que vous créiez un jeu de règles pour FileZilla uniquement.
Tout d’abord, allez dans les évènements du pare-feu et notez le port que FileZilla utilise sur le serveur distant, probablement un port 80 en tcp.
Dans stratégie de sécurité réseau, recherchez l’application FileZilla et faites modifier.

Passez en stratégie personnalisée et faite Copier depuis - stratégie de sécurité prédéfinie puis FTP Client.
Ensuite, ajoutez une règle autorisant les connexions sortantes depuis n’importe quel port vers le port utilisé par FileZilla pour ces mises à jours, comme le port tcp 80.
Attention toutefois à bien mettre la règle au dessus de la règle de blocage.

C’est exact, Symbian n’aura pas droit à son susucre ce soir ;D

Ces règles sont vraiment intéressantes lorsque l’on veut forcer des applications à ne faire que ce qu’elles sont censées faire, généralement pour des utilisations avancées de l’application.

+1. Et c’est plus clair et plus complet que moi.

En fait, j’ai déjà défini le jeu de règles permettant à FileZilla:

  1. de se comporter comme un client FTP,
  2. de vérifier les mises à jour.

Pour 1) j’ai procédé comme vous l’expliquez.

Mais pour 2), mon erreur a été de me dire que le plus simple était, non pas d’examiner le journal des événements, mais de lancer, sous FileZilla, la vérification de mises à jour, puis d’autoriser la demande dans la fenêtre d’alerte. Ça marche, de nouvelles règles viennent s’ajouter à celles qui sont déjà présentes. Mais auparavant, il m’a bien évidemment fallu supprimer la règle “Block and Log […]” (= règle de blocage ?).

Au fait, votre réponse laisse entendre que la seule manière d’ajouter cette règle de blocage est de la récupérer à partir d’un jeu de règles prédéfini.

+1

Le problème de cette méthode est qu’il crée une règle pour tout autoriser, c’est d’ailleurs une des critiques que je ferais à Comodo. Il serait préférable qu’il crée une règle pour le port concerné uniquement. Toutefois, ceci à moins que j’ai loupé un paramétrage qui le permette.

On peut aussi la recréer, il s’agit de bloquer tout les protocoles ip, entrant et sortant, venant de tout vers tout sur tout type d’ip. La seule différence sera le nom généré qui sera de la forme Block [and log] IP Out From IP Any to IP Any Where protocol is Any au lieu de Block [and log] All unmatching request. Nom toutefois personnalisable à l’aide de la description.

Hum… Pour les applications que j’ai testées, la règle créée par CIS ne porte que sur le/les port(s) concerné(s). Mais je n’en ai testé que trois (SpywareBlaster, WinDjView, Filezilla).

Re-Hum… Cela ne risque-t-il pas de tout bloquer, et non de ne bloquer que les requêtes qui ne collent pas aux règles déjà définies ?

Tout logiciel utilise une gamme de ports incluse à une zone déterminée.

Un exemple classique est fourni à Practically Networked (je suis désolé, c’est en langue anglaise):
http://www.practicallynetworked.com/sharing/app_port_list.htm

Le problème d’un client ou serveur FTP est à la fois plus simple et plus compliqué.

Dans ce dernier cas de figure, d’autres ports pourront être mis en cause si l’adresse ip est dynamique et si une redirection d’ip doit être utilisée (ex: 8245 pour No IP).

Mais même dans le cas d’un simple client FTP, Monsieur De La Palisse répondrait à la question que la réponse dépend du type de connexion au serveur qui, rappelons-le, peut être de 2 types, Passive (PASV) ou Active (PORT), et qui met en jeux différents ports comme fort bien expliqué ici, encore en anglais:
http://www.slacksite.com/other/ftp.html

Cette situation, relativement simple sur le plan théorique, se complique dans la pratique puisqu’il y a un aléa dans le calcul des ports, de sorte que l’on préfère parler de gamme de ports utiles, et File Zilla n’échappe pas à la règle, comme noté sur son wiki, toujours en anglais:
http://wiki.filezilla-project.org/FAQ

Maintenant, en effet, dès lors qu’il sera demandé à Comodo (ou tout autre firewall) d’autoriser une connexion FTP, il le fera, selon que cette connexion est PASV ou PORT, pour les seuls ports requis pour cette connexion spécifique.

La conclusion en est que l’utilisateur doit, quand il fermera sa connexion courante (et cela vaut d’ailleurs pour toutes les applications) se diriger vers la règle qui vient d’être établie pour un ou quelques ports particuliers, et l’élargir selon que le client FTP est paramétré en PORT ou PASV à la gamme de ports idoine telle que spécifiée par le wiki File Zilla.

Si vous le dites :slight_smile:

Euh… C’est le forum français ici… :wink: Plus sérieusement, merci pour votre éclairage. J’avoue que je peine à suivre… Mais je pense avoir compris que ce que vous dites concerne la définition de règles permettant à FileZilla d’agir en Client FTP, ce dans quoi je ne me hasarderai pas à me lancer.

Les échanges entre Shaoran et moi ne portent véritablement que sur les règles permettant à FileZilla de vérifier et de télécharge les mises à jour.

C’est curieux, j’ai pourtant refait quelques tests ce matin, il ne sait jamais créer autre chose que du tout sortant ou tout entrant.

Non, car il faut suivre cela dans l’ordre, pour Comodo, c’est de bas en haut.
D’abord on bloque tout, ensuite on autorise certaines demandes.

Je ne comprend pas sinon ce mini exposé sur ftp passif et ftp actif. Nostro_Uomo ayant mentionné que seule la mise à jour ne fonctionnait pas, il est inutile de chercher plus loin concernant le ftp.
Quelques vulgarisations seront sans doute nécessaires surtout sur certains points.

Si l’on devait résumer, on dirait qu’il existe deux types de connexion FTP, les connexions passives et actives.

Lors des connexions actives, une fois que le client à demander un accès au serveur, ce dernier va se connecter au client sur un port que le client aura spécifié. Il est donc actif, se connectant sur le client.
C’est un soucis pour les configurations du pare-feu car il faut autoriser certaines connexions entrantes, qui se font sur des ports aléatoires. C’est encore plus complexe pour les personnes se trouvant dernière des routeurs puisqu’il faut router les connexions entrantes.

Pour parer à ce soucis, on a crée la connexion passive où lorsque le client demande un accès, il se connecte sur le serveur sur un port spécifié par ce dernier. Autrement dit, l’inverse de la connexion active, le serveur FTP ne connecte jamais au client, il ne fait que recevoir, il est passif.
Cela résout le problème pour le client, le répercutant sur le serveur.

De nos jours, les serveurs FTP ne supportant pas les connexions passives sont très rare car une bonne partie des utilisateurs d’internet étant derrière un routeur, cela serait très problématique, surtout pour les néophytes. Il n’est donc pas nécessaire de s’en préoccuper.

Plus d’information : Wikipedia (en français …)

Mes considérations sur le protocole FTP ne sont pas si triviales que vous voulez bien le dire mais, certes, concerneront davantage la situation particulière de FTP de particulier à particulier chacun avec un serveur FTP en ip dynamique derrière un routeur que la simple utilisation d’un client FTP vers un serveur institutionnel.

J’y reviendrai si j’en ai le temps et si quelqu’un est intéressé, en tout cas probablement pas aujourd’hui.

Pour revenir à la discussion qui nous intéresse, je ne vois pas l’intérêt de procéder à une MAJ du logiciel “online”: on peut très bien le faire par téléchargement logiciel fermé ou, encore mieux, pas du tout.

Mais admettons qu’on le fasse, et j’en ai fait l’essai pour le plaisir de la discussion: le jeu de règles prédéfinies Comodo ne concerne qu’un client FTP classique vers les ports 20 et 21; Filezilla utilise pour ses MAJ une connexion sécurisée HTTPS, et donc le port 443: il suffit donc d’ajouter au jeu de règles (en amont bien sûr de “Block…”, auquel on n’aura pas touché), une règle d’autorisation TCP OUT vers le port 443, puis de définir Filezilla comme client FTP.

Je suis désolé de ma réaction tardive. Une semaine sur un forum de discussion c’est une éternité…

C’est sans doute parce que la règle créée par CIS dépend du paramètre “Fréquence d’alerte” dans “Stratégie de sécurité réseau”.

En le mettant sur “Haut”, CIS génère les deux règles suivantes:

  • TCP sortant sur le port 443 (pour la vérification de la présence de MAJ)
  • TCP sortant sur le port 80 (pour le téléchargement de la MAJ)

J’ai constaté que ce paramètre conditionne non seulement l’apparition de la fenêtre d’alerte mais également la règle créée par CIS.

Mais bon, je suis d’accord avec vous: mieux vaut créer la règle soi-même plutôt que de vérifier après coup si celle crée automatiquement est bien la bonne.

J’ajoute que je voulais surtout mieux connaître CIS au travers d’une application a priori inoffensive (FileZilla) même si on lui accordait plus de liberté que nécessaire.

Ok.

Merci. C’est promis, dès que les journées feront plus de 24 heures, je serai un spécialiste réseau. :slight_smile:

Disons que pour intéressant que soit votre premier post, il n’en a pas moins semé le trouble car ne portant pas sur les points discutés par Shaoran et moi.

Je vous rejoins totalement. Hormis Firefox, je n’autorise jamais un logiciel à vérifier la présence de MAJ, et encore moins à se mettre à jour en ligne.

Mais comme je viens de l’écrire dans mon post précédent, je voulais uniquement mieux connaître CIS au travers d’une application a priori inoffensive (FileZilla).