Gestion des applications

Discussion in 'LnS French Forum' started by renArD, Jan 12, 2008.

Thread Status:
Not open for further replies.
  1. renArD

    renArD Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    29
    Bonjour,

    après un certain temps d'utilisation, si je lance une application (typiquement, Firefox ou la Connexion au bureau distant), celle-ci apparait promptement dans la liste des applications de LnS (filtrage logiciel) puis disparait. Ces applications ne peuvent alors pas se connecter à internet.
    Quand on observe du côté du filtrage internet, les règles associées à ces logiciels se valident et dévalident immédiatement (ce qui est cohérant avec la détection furtive de l'application par LnS).
    Au niveau du journal, rien n'est signalé (aucun bloquage, bien que tous soient avec demande de log '!') dans le cas de firefox, ou bien se sont les règles bloquantes qui suivaient les règles d'autorisation (qui auraient dues être validées sur application) qui s'appliquent.

    Configuration :
    WXPP, SP2, LnS 2.06p2

    Merci

    Renard

    PS : j'espère ne pas être un redondant avec un autre post, il semble que non.
    PS : auriez vous un lien vers un totoriel sur l'édition de règles en mode brut ?

    Edit : il pourrait y avoir un lien avec Azureus car une fois arrêté ça semble ne plus se produire. Je ne connais hélas pas de stimuli pour provoquer l'erreur et avancer.
     
    Last edited: Jan 12, 2008
  2. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    Bonjour,

    Je vois 2 causes possibles:
    - le TCP SPI a trop de connexion ouvertes (à cause du P2P), et ne peut en accepter une de plus => est-ce que cette option est activée dans les options avancées ?
    - la plage des ports locaux 1024-5000 dans les règles standards n'est pas suffisante, à cause du P2P vous commencez à taper au delà de 5000

    Dans les 2 cas, il devrait y avoir des alertes dans le journal. Etes-vous sûr que toutes les règles qui bloquent dans le filtrage internet ont l'attribut "!" ?
    Y a t'il quand même de temps en temps des alertes qui s'inscrivent dans le journal ?

    Frédéric
     
  3. renArD

    renArD Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    29
    Bonjour,

    le SPI est bel et bien activé (dailleurs, quelques règles l'emploient, cf. votre post sur la version 2.06p2).

    J'ai retiré la règle "Autorise les services internet standards" car j'ai spécialisé les règles aux applications, selon les seuls ports autorisés. Par exemple, les ports 80 et 443 ne s'ouvrent qu'avec Firefox. Le problème ici, c'est que LnS active la règle et la désactive juste après. Pour le bureau distant, il y a aussi une règle spécialisée (port, ip, et application spécifiés).

    Bien que la configuration d'Azureus soit une galère (justement pour pas qu'il arose sur trop de ports), ce logiciel a lui aussi droit à des règles dédiées. Il n'utilise donc pas une règle commune du style "Autorise les services internet standard". Donc, les ports 1024 à 5000 ne sont peut-être pas saturés.

    L'attribut '!' est appliqué à toutes les règles qui ont le signe interdit (enfin, le temps des tests, car sinon je soulage). Dans le cas du bureau distant, il y a des alertes qui sont signalées puisque la règle qui devait autoriser les paquets (active sur application, alors que l'application disparait instantanément) est inactive.

    Je me demande donc s'il s'agit d'une surcharge de ports ou du driver. Il semble en effet que ce soit la détection de l'application qui pose problème. Mais cela est peut-être lié.

    J'espère avoir été clair. Merci.

    Renard
    PS : auriez vous un lien vers un totoriel sur l'édition de règles en mode brut ?
     
  4. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    Bonjour,

    Merci pour ces précisions.

    Si vous voyez bien la règle s'activer puis se désactiver immédiatement, la détection de l'application qui se connecte marche donc bien, et le blocage doit se faire à cause d'une autre règle.

    Les nouvelles règles SPF, notamment celles pour le DNS autorisent les ports locaux via le critere "PORT_LOCAL_IN" et donc par défaut 1024-5000.
    Donc il est bien possible (comme vous utilisez ces règles, et le problème serait identique avec la règle de base UDP des jeux de règles standards).
    Pour confirmer le problème, le plus simple serait de créer une règle UDP DNS normale qui ne fait que logger (en désactivant l'attribut "stopper l'examen du jeu de règles quand la règle s'appliquie" => la flèche jaune vers le bas), par défaut vous désacivez la règle pour ne pas surcharger le log, et dès que le problème survient vous l'activez, comme cela on verra exactement quels ports sont utilisés lors du problème.

    Une solution plus radicale (mais sans essayer de comprendre) est de modifier la plage 1024-5000 dans la base des registres:
    [HKEY_CURRENT_USER\Software\Soft4Ever\looknstop\options] => LocalPortEnd à augmenter.
    Look 'n' Stop doit être arrêté pour faire ce changement (sinon les valeurs sont à nouveau écrasée quand Look 'n' Stop se quitte).

    Malheureusement il n'existe pas de vrai tutorial pour les règles au format brut, il y a cependant le post suivant qui est utile:
    https://www.wilderssecurity.com/showpost.php?p=506705&postcount=33
    complété pat celui-ci:
    https://www.wilderssecurity.com/showpost.php?p=1156264&postcount=14

    Ensuite c'est surtout une connaissance des protocoles réseaux (quelle information dans quel niveau de protocole et à quel offset je souhaite vérifier) qui permet de créer ce type de règles.
    Pour les règles SPF il y a la page suivante (que vous avez déjà du lire):
    http://looknstop.soft4ever.com/Beta/2.06p2/Plugins/SPF-Info.HTM

    Cordialement,

    Frédéric
     
  5. renArD

    renArD Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    29
    Je précise que du côté filtrage logiciel, dans la liste des applications actives, l'application apparait et disparait aussitôt aussi. En fait, je penses avoir mal compris votre réponse : pourquoi l'application disparait-elle alors qu'elle est toujours lancée ? Ceci provoque la non validation de la règle qui ouvrait les ports nécessaires au logiciels, et donc la règle bloquante qui suit agit (et est dans le journal, tout naturellement... enfin pour le bureau distant. Arg, je ferais mieux de séparer les problèmes pour gagner en clarté. Disons qu'on ne parle que du bureau distant puisque Firefox a le même problème et en cumulerait peut-être un autre (!)).

    Erratum, les règles DNS SPF sont les seules parmis les proposées que je n'utilise pas car un autre logiciel (skype ou xlite, j'ai oublié mais je peux vérifier si nécessaire) demandait un nombre de requetes different du nombre de réponses (... bref les SPF bloquant les requètes sans connexion associée, le logiciel ne fonctionnait pas).
    J'ai donc remis la règle UDP DNS standard, en la spécialisant à mes deux serveurs DNS (Free) et à mon adresse locale.

    Hum, ce test est-il encore d'actualité (même question pour le changement dans la BdR) ? J'ai une question très basique au passage : sans la flèche jaune, la règle ne fait-elle qu'observer (look) ou bien elle autorise (respectivement, elle bloque, selon la présence du sens interdit) ?

    Merci (aussi pour votre patience).

    Renard

    PS : merci pour l'édition de règles en mode brut, il y a matière à réflexion :)
     
  6. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    L'application disparait de la liste parce qu'elle se déconnecte immédiatement.
    Au début Look 'n' Stop détecte la tentative de connection, l'application est ajoutée dans la liste et la règle s'active coté du filtrage internet. Ensuite le paquet arrive dans le filtrage internet, quelque chose bloque et le paquet est rejeté, l'application récupère ce refus et se déconnecte, Look 'n' Stop détecte la déconnexion dans le filtrage logiciel et enlève l'application de la liste et désactive la règle.

    C'est curieux cela, vous ne devez normalement pas recevoir de paquets sur le port DNS s'ils n'ont pas été demandés. Et bizarre que ce soit lié à une application en particulier. Enfin, on ne va pas tout mélanger, on verra cela plus tard, quand le 1er problème sera déjà résolu.
    Quels sont les ports locaux de la règle UDP DNS standard ?
    Egalement pour la règle qui autorise le port 80 (en remplacement de la règle standard) avez-vous précisé les ports locaux ?

    Oui, le test reste d'actualité si l'une de vos règles continue à utiliser les ports locaux 1024-5000.
    Oui, quand on enlève la flèche jaune, le paquet n'est qu'observé, et la suite du jeu de règles est examinée pour savoir ce qu'il faut faire du paquet. Une telle règle d'observation/sniff doit être en général placée en tête de liste.

    Frédéric
     
  7. renArD

    renArD Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    29
    Merci pour la rapidité de vos réponses.

    Merci pour l'explication quand à la désactivation instantannée des applications.
    Je déduis - peut-être trop vite - que la règle qui bloque l'application est avant la règle qui lui ouvrait le port (et qui n'est active qu'en présence de l'application).

    Les règles pour le DNS et le port 80 n'ont pas de port local spécifié (c'est vrai que j'aurais pu mettre 1024-5000, sauf pour le fameux DNS aux requetes supplémentaires m'en demandait en dehors de cette plage... mais nous verrons ça plus tard :) )
    Mais au fait, pourquoi nous interessons-nous tant au DNS dans ce blocage d'applications ? Simplement parceque c'est une règle liée à la plage 1024-5000, laquelle serait saturée, ou bien le protocole DNS a un lien ?

    J'ai "relu" toutes mes règles, aucune ne spécifie la plage de ports 1024-5000. Sauf peut-être (je l'ignore), les règles SPF DHCP,NTP,Ping. Je ne vois donc pas quelle règle étendre.

    Merci pour l'explication de la flèche jaune.

    Renard
    PS : dans une édition brute, retrouve-t-on stritement toutes les informations de l'édition standard ?!
     
  8. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    Ok, donc vous étiez déjà tombé sur le problème d'une ulisation d'un port au delà de 5000 et ceci ne doit donc pas être la cause du problème.
    On s'intéresse à cela, car un port au delà de 5000 est une raison suffisante et commune pour laquelle une connexion Web standard n'arrive plus à se faire.
    Ok, si aucune règle n'utilise cette plage le problème est alors ailleurs.
    Peut être au niveau du TCP SPI qui est saturé au niveau du nombre d'entrées.
    N'y a t'il vraiment aucune alert SPI dans le journal quand le problème arrive ?
    Quand vous constatez le problème, pourriez-vous ouvrir la console (dans les options) et demander les logs du driver, ça pourra peut être donner une piste. J'aimerais aussi avoir une copie d'écran du journal, juste après le constat d'échec d'une connexion Web.

    Oui, mais bien sûr. D'ailleurs, il possible d'éditer une règle standard avec le plugin des règles brute, cette conversion est possible dans tous les cas, et ça permet de voir/comprendre comment est traduite une règle standard en règle brute (quels sont les champs vérifiés, les offsets...).
    La conversion inverse n'est pas contre la plupart du temps jamais possible, car une règle brute permet de faire beaucoup plus de chose, et une règle brute est justement utilisée dès lors que l'édition de règle standard n'est pas suffisante.

    Frédéric
     
  9. renArD

    renArD Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    29
    Bonsoir,

    il n'y a, à priori, pas d'alerte SPI lors des blocages mais j'aimerais pouvoir le confirmer. Hélas je ne sais pas comment stimuler à coup sûr l'erreur donc j'attends...

    Dès que j'ai le problème, je copie le journal et la console. D'un côté j'espère que ce sera bientôt afin de clore le sujet.

    Je vous tiens donc au courant, désolé si ce sera long.

    Renard



    Deuxième partie du message : quelle ironie !

    Alors que je clique sur la prévisualisation des lignes ci dessus, voilà que ça ne fonctionne plus. Comme quoi, il suffisait de demander :)
    Firefox étant déjà lancé, les symptomes sont légèrement différents : Firefox est encore dans la liste des logiciels et les règles qui s'activent avec Firefox sont encore activées.
    J'arrete alors firefox, le relance, et là j'ai le symptome "habituel" (disparition immédiate). Idem pour le bureau distant. Ci joint les screenshots des journaux pour les deux applications, et le fichier log (que j'épure des messages uplink et downlink excessifs).

    Voilà :)

    Renard
     

    Attached Files:

  10. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    Merci pour les copies d'écran et le fichier console.
    Tout a l'air correct, aucune erreur dans les logs du driver du filtrage internet.

    Je n'ai plus trop d'idées :doubt:

    Pour que ça Firefox remarche que faites vous ? (arrêt azureus, arrêt/redémarrage de l'ordi, ou de Look 'n' Stop ?)

    Même si c'était l'activation de la règle du filtrage internet qui se passait mal, il y aurait une alerte dans le journal avec la règle qui a bloqué le paquet.
    Mais bon, peut être essayer quand même de ne plus associer la règle à firefox, pour voir ou confirmer que ça ne vient pas de là.

    Est-ce que dans le filtrage logiciel il y a des ports indiqués pour firefox ?
    Un truc à essayer, mettez l'attribut !! sur l'appli firefox (quand le problème se pose uniquement) pour voir ce qui se passe exactement pour la connexion qui ne s'établit pas.
    Un truc qu'il faudrait déterminer: est-ce que la résolution DNS du site à afficher dans firefox se fait quand même bien ou alors non ?
    Faites un "ping nom_du_site" dans une boite de commande pour voir si la résolution DNS se passe bien.

    Frédéric
     
  11. renArD

    renArD Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    29
    Bonsoir,

    pour pouvoir utiliser Firefox (et poster à nouveau...), il faut que j'arrete Azureus, ce qui m'occupe le processeur à 100% pendant quelques minutes (à vrai dire, c'est le processus "system" lancé par "system" qui prend tout). Apparrement ce processus lance un peu tout le monde au démarrage de l'ordinateur, mais je ne pense pas qu'il y ait de lien. Toujours est-il qu'une fois que j'ai récupéré la main, le fonctionnement est normal.
    Edit : il semblerait que la fermeture d'Azureus sans qu'il y ait eu ces bugs soit rapide (normale). Donc il y a peut-être un lien finalement :)

    Si je désactive LnS pour le réactiver, le problème persiste et en plus les règles activées par Azureus - ou autres logiciels connectés qui ont été lancés avant LnS - ne sont plus activables sans redemarrer les logiciels en questions.

    Je me souviens avoir jadis dupliqué les règles de validation du port 80, en retirant l'activation par application mais cela ne changeait rien. A confirmer (prochainement !).
    Edit : en parlant de port 80, je me rends compte qu'Azureus l'utilise aussi (je ne comprends dailleurs pas pourquoi et je n'ai pas trouvé où retirer ça). Il se pourrait donc que ce port 80 soit saturé par Azureus. Mais cela n'expliquerait que Firefox et pas le bureau distant.

    Je constate après coup que le journal relatif au lancement du bureau distant me fait mentir sur des affirmations précedentes (pourtant constatées !) : il n'y a pas la règle suivante (blocage) qui s'applique.

    Le filtrage logiciel ne spécifie pas de ports ou adresses pour firefox. Pour le bureau distant oui, donc je retire cette contrainte pour le prochain test (le test des '!!').

    Et dans la foulée des tests, je tenterai la résolution DNS. Cependant, étant donné ce qui s'est anecdoctiquement passé alors que je voulais prévisualiser mon message précédent, je pense que l'entrée dns du forum était déjà présente, donc rien à résoudre cette fois là.

    A bientôt pour de nouvelles aventures :)

    Renard
     
    Last edited: Jan 13, 2008
  12. renArD

    renArD Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    29
    Bonjour !

    voilà, les tests sont faits.
    J'ai dupliqué les règles d'ouverture du port 80 pour firefox, et j'ai levé leur activation par logiciel. Ca ne venait pas de là.

    J'ai retiré la contrainte de ports et adresse pour le bureau distant (il n'y en a pas pour firefox), ça ne venait pas de là.

    Dans le filtrage logiciel (note : deux entrées de firefox, une avec chemin raccourci ms-dos, l'autre avec chemin complet, tout dépend d'où je lance le logiciel) j'ai mis le '!!', ce qui produit les fichiers joints (rien de probant hélas).

    Quant au DNS, je confirme que j'arrive à pinger une entrée déjà présente dans la table, mais pas une nouvelle (donc la résolution dns pour le ping semble aussi bloquée). Le ping vers les sites connus fonctionne.

    Une idée ? :)

    Renard
     

    Attached Files:

  13. renArD

    renArD Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    29
    Bonjour,

    voici les derniers tests effectués : arreter look'n'stop ! J'ai le regret de dire que ça ne corrige pas le problème. Je puis pourtant vous assurer (mais si :oops: ) que dans le cas du bureau distant, la règle suivante s'appliquait. Hélas je n'ai pas su reproduire ce symptôme là. Même si je l'avais reproduit, il n'est pas dit que LnS put être reconnu fautif.

    Bref, j'aurais du faire ce test basique bien plus tôt, je vous prie de m'en excuser. J'essaie de me justifier par le fait que les symptomes laissaient quand même croire que le parefeu était responsable.

    J'ai fait un autre test, qui consiste à "réparer" la connection (wifi). Ceci permet - au coût de la déconnection de tous les logiciels connectés ! - de contourner le problème. Mais combien de temps cela oudra bien tenir ...?

    Pour conclure, Azureus fini par bloquer les nouvelles connections au bout d'un certain temps et je n'ai pas trouvé de solution. Bien que ça sorte du cadre de ce forum, je suis interessé par vos opinions.

    Merci beaucoup pour votre disponibilité et votre patience. Bravo pour le logiciel. J'espère que mes prochaines interventions seront justifiées :doubt:

    Renard
     
  14. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    Bonjour,

    Pas de problème, il est parfois difficile de faire la part des choses.

    Il est possible que dans le cas du bureau distant il y ait bien un vrai blocage dans le firewall.

    Oui, le précédent post montrait que les applications ne cherchaient même pas à se connecter vers le site distant (car normalement avec le !! on voit plus de chose). La seule alerte qu'on voit c'est au tout début de la connexion, avant d'avoir résolu l'adresse IP du distant.
    Et effectivement si même un ping vers un site distant ne marchait pas, le problème est autre.

    2 choses quand même: je constate que le numéro d'alerte dans le journal est très élevé (37700) => peut-être faudrait-il limiter les logs (je suppose que ce ne sont pas les manips que je vous ai demandées qui provoquent cela). Avec tant que ça d'alertes, ça peut ralentir le PC. De plus, pour chaque alerte, Look 'n' Stop fait une demande DNS pour afficher le nom du site distant en clair, ce qui génère aussi du traffic. Il est possible que le problème soit une saturation générale de l'ordi, et il faut juste que le P2P ralentisse un peu pour que ça se remette à marcher.
    Ce que vous pouvez essayer: ne plus faire afficher les alertes ICMP, et désactiver la résolution DNS dans les options, pour charger moins l'ordi.

    Cordialement,

    Frédéric
     
  15. renArD

    renArD Registered Member

    Joined:
    Jan 11, 2008
    Posts:
    29
    Bonjour,

    vos suggestions semblent porter du fruit ! J'ai désactivé la résolution de noms dans LnS, réduit le nombre de connexions d'Azureus, et levé les logs superflus.

    Il restait la question des paquets DNS reçus alors qu'ils n'étaient pas solicités, mais si nécessaire je relancerai ça dans un autre post.

    A bientôt donc, au moins pour la gestion de plusieurs interfaces ;)

    Renard
     
Thread Status:
Not open for further replies.