Re: Nouvelle version beta: 2.06b2 Petite suggestion, simple à implémenter, vraiment importante ! En utilisation quotidienne, LnS travaille très bien tout seul de son côté (comprendre : en arrière-plan, silencieux). Alors sauf Alerte, demandant une autorisation pour se connecter, de tel ou tel logiciel, je ne consulte que le Journal. Normal donc Mais dans tous les détails du journal, celui qui est fondamental pour une compréhension et un traitement du message d'alerte c'est la date ! En effet : pour savoir qui a fait quoi, c'est mieux de se baser sur quand. ^^ Car comme on peut le voir ici : http://img249.imageshack.us/img249/9035/nomapplicationhb2.th.jpg Il n'y a jamais le nom de l'application (ver. 2.05 comme 2.0.6) Or ma Barre des tâches Windows est masquée automatiquement (bien utile ! Gain de place ). Donc ce que je suggère c'est de placer dans cette fenêtre du Journal, un p'tit champ avec l'horloge/heure système. En bas à gauche par exemple. Merci d'avoir lu
Re: Nouvelle version beta: 2.06b2 Salut zisworg Je te suggère de poster sur un nouveau fil plutôt que sur celui-ci... Je pense qu'il y a deux ou trois petits trucs que tu n'as pas encore saisi ce qui est tout à fait normal avec un nouveau programme. D'après les captures d'écran qu je vois ici il y aura certains correctifs à apporter et des explications aussi... A+ (sur un nouveau fil de discussion...)
Re: Nouvelle version beta: 2.06b2 Euh, ben d'accord. (pas tout compris des corrections) Sinon, oui ça ne fait pas longtemps. :s Il est quand même très technique ce Look'n'Stop.
Re: Nouvelle version beta: 2.06b2 Salut zisworg Il n'y a pas le nom de l'application car pour cela il faut soit activer une entrée au journal pour l'application dans le filtrage logiciel: un ! = entrée au journal si appl. bloquée deux !! - entrée au journal si appl. autorisée ou bloquée rien... = aucune entrée OU Créer une règle spécifique pour cette application ou au groupe d'application tel que, par exemple, une règle { HTTP / HTTPS } pour les ports 80 et 443 pour les applications: internet explorer, firefox et opera et ajouter sur la ligne de cette règle, un point d'exclamation pour avoir une entrée au journal quand la règle est appliquée... Note aussi que les options du journal peuvent donner des informations supplémentaires qui signalent de quelle application il s'agit... (voir onglet options...) Voir par exemple dans la capture de mon journal avec les options activées(et quelques bidouilles de mon cru...) A, C - Une connexion à un serveurs de News en mode TLS B, D - Une requête DNS ...pour la résolution des noms (URL <--> IP....) E - Une connexion à Gmail pour récupérer le courrier... F- un paquet UDP bloqué sur le port 1026 et en provenance d'Asie ( 221.202.208.98 ) : il s'agit de "spam" utilisant Net Send Messenger... G- Une tentative de connection en TCP avec le flag SYn sur le port 135: le ver blaster? ou Sasser ? Qu'importe: LNS a bloqué cette merde... Etc. Je crois que tu as encore beaucoup de choses à découvrir avec LNS. Tes questions sont toujours les bienvenues.
Re: Nouvelle version beta: 2.06b2 D'accord, merci bien Climenole. Je vais donc m'essayer au paramètrage plus fin de mes logiciels. Frederic > vous penser quoi de ma suggestion ?
La date et l'heure sont bien affichées dans le journal. Je n'ai pas compris la première suggestion. Pour les noms des applications ceci n'est possible que venant du filtrage logiciel et en sélectionnant le ! ou le !! comme l'a indiqué Climenole. Pour les paquets filtrés par le filtrage internet et affiché dans le journal, il n'y a pas d'application associée à un paquet donc il n'est pas possible d'afficher cette information. Réafficher l'heure courante dans la page du journal: hmm, c'est assez spécifique On évite en général de surcharger Look 'n' Stop. Frédéric
Oui en fait, vous avez tout à fait raison. En fait je sais pas vraiment pourquoi j'ai fait un bloquage su l'heure... Désolé. Il y a toujours l'heure Windows.
Bonjour tout le monde, Je m'éttais fait la même remarque que zisworg pour le nom de l'application. Je comprend bien votre réponse, vous lui proposez d'afficher les noms des applications dans le journal en configurant les règles pour qu'elle le fassent. Mais serait-il possible que look'n'stop affiche par défaut tout les programmes depuis lesquels les paquets ont été envoyés ou quels programmes s'apprétait à les recevoirs ou les a reçus ? Pas mal de pare-feu le font apparament, et je pense que ça peut être bien pratique. Sinon, autre question à pars : comment appelle-t-on les pare-feu qui demandent si on autorise ou pas une application à accéder à internet, et si on répond "autoriser tout" qui se débrouillent pour ouvrir dynamiquement les ports utilisés par l'application ? Je sais que ça a un nom spécifique, mais je ne souviens plus lequel. Merci. Pierre. PS : tant qu'on y est dans les suggestions, au niveau du journal de look'n'stop, apparament, il garde dans la ram toute les entrées, et même si ça ne le fait pas vite, ça fait apparament augmenter la ram utilisé par lns, alors qu'on pourait mettre une option pour ne garder que x entrées en mémoire. Si on en veut plus, il y a toujours la possibilité de regarder le journal exporté par lns dans le fichier journal. Je me trompe ou c'est bien ce qui se passe ? Merci, et à +
Comme indiqué plus haut ceci n'est pas possible dans le filtrage internet car Look 'n' Stop bloque les paquets au plus proche de l'interface physique (niveau NDIS) et à ce niveau aucune application n'est associée à un paquet. Typiquement un paquet qui arrive n'a pas d'application associée. Il faut que le paquet soit transmis à certaines couches de Windows pour que Windows décide quelle application pourrait le traiter, mais Look 'n' Stop bloque le paquet avant pour une plus grande protection. Les firewalls qui affichent les applications et les paquets bloquent les paquets à un autre niveau (TDI) où l'application est connue. La contre partie est que les paquets ont déjà traversés pas mal de couches pour arriver là et donc le risque qu'ils fassent des "dégats" est plus grand. Cordialement, Frédéric
Ok pour les paquets entrants, on ne pourait donc que pour les paquets sortants, ça pourait peut être aider déjà dans quelques cas. A la prochaine. Pierre.
Il n'en reste pas moins qu'au niveau NDIS un paquet sortant n'est pas non plus associé à une application. Il faudrait corréler les 2 niveaux de filtrage (logiciel et internet) pour avoir l'information, pas prévu dans l'immédiat Pour l'instant, il faut voir le filtrage internet comme un filtrage de paquet tel que l'on peut trouver dans un routeur ou hardware dédié. Frédéric
Salut Pierre4012 Ma réponse est qu'il s'agit d'une des possibilités... LNS étant un pare-feu à règles, c'est justement un de ses avantages... Plusieurs possibilités. Il ne vous reste qu'à les découvrir. Les règles de filtrage concernent principalement le niveau des paquets de la couche 4 (Transport layer) des protocoles TCP-IP (TCP, UDP, ICMP). LNS est un pare-feu "Stateful": les paquets ne sont pas seulement examinés les uns indépendamment des autres mais aussi en fonction des connexions existantes (en TCP). Les paquets ne faisant pas d'une connexion existante sont rejetés... Pour en revenir à votre idée d'indications par programmes permettez-moi de vous signaler que les informations pertinentes sont bel et bien disponibles: le journal indique la date, l'heure, la direction des paquets, l'autorisation ou le blocage, l'adresse IP et l'Url des connexions, le protocole utilisé de même que les ports source et destinations qui sont une indication claire du type de programme en utilisation... De plus, il est possible, si vous le jugez nécessaire, de raffiner le filtrage jusqu'à créer les règles qui vous sont nécessaires pour chaque programme. Ce que vous mentionnez existe bel et bien avec LNS !!! La règle générale "autoriser les services internet standards" du jeu de règles évoluées de LNS fait EXACTEMENT cela. En passant: les ports sont ouverts dynamiquement par le système d'exploitation pas par le pare-feu. Le pare-feu autorise ou non telle ou telle gamme de ports. Au niveau de l'O.S. tel que W xp la gamme de ports à ouvrir localement est déterminée par cette clé de registre: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters MaxUserPort La plus récente version (beta mais stable) de LNS a l'option "Dans local" permettant d'utiliser cette gamme et est valable autant pour XP (1024 à 5000) que pour Vista (49152-65535)... Des règles spécifiques doivent être créés si: - l'application est un serveur - l'application utilise l' UDP - l'application utilise des ports locaux "non-standards" Le nom dont vous ne vous souvenez plus n'est-il pas: pare-feu authentifiant? OR, cela ne concerne nullement ce dont vous parlez mais bien autre chose. Il s'agit de pares-feu d'entreprises qui filtrent selon l'identification de l'utilisateur du réseau... L'un des grand avantages de LNS est d'être un pare-feu à règles. Vous réclamez de LNS qu'il ne le soit pas. LNS n'est pas ZA (Jaune à Larmes)... Voici un exemple de ma connexion avec Firefox sur ce forum: Comprend les requêtes DNS et quelques uns des paquets échangés examinés par une règle spécifique {R. 80,01}; [TCP] { HTTP } (j'aurais pu la nommer :Firefox...):
Ok, merci pour ces réponces ... "Des règles spécifiques doivent être créés si: - l'application est un serveur" Ce que je voulais dire justement c'est qu'avec Outpost par exemple, je viens d'essayer avec le serveur FTP Filezilla, quand il nous demande ce qu'il doit faire, on lui séléctionne "autoriser tout", et le serveur marche directement, alors qu'avec LNS, il faut ouvrir le port 21 + les ports utilisés par le passif. Quand les plages de ports à ouvrir sont clairement identifiées, ça va, mais ce qui m'a trop soulé, c'est pour eMule, j'ai essayé pas mal de choses, mais il utilise une très grand plage de port aléatoirement, donc à pars lui dire de laisser tout passer pour cet application du port 1 au 65 mille et quelques je n'avais pas trouvé d'autres solutions. N'arrivant pas à configurer look'n'stop correctement je suis passé à un autre, je repasserais surement à LNS quand j'aurais plus de temps. A+, Pierre.
