Ce topic a reçu le label R+ dans le méta-topic des topics uniques.  
 
-----------------------------------------------------------------------------------------------
Dernière mise à jour: Mercredi 23 Mars 9h00
-----------------------------------------------------------------------------------------------
 

• Le site officiel: http://www.kerio.com
• Où trouver encore la version 2.1.5: http://kerio215.free.fr/kerio-pf-2.1.5-en-win.exe
• Où trouver encore le patch pour qu'il soit en français: http://veekee.free.fr/petzouille/kpf_fr.exe
• Le forum pour la version 2.1.5: http://forums.kerio.com/

-----------------------------------------------------------------------------------------------
 
Je vais peut-être en décevoir quelques-uns en leur cassant le mythe et leur rappeler que leur sécurité est bien relative. Les informations ont été glanées à droite et à gauche sur différent forums. Merci à 'Drachs' et à d'autres qui se reconnaîtront
 
Ce 'tutoriel' est donc un résumé, et s'adresse plutôt aux néophytes voulant débuter. Les pros n'y trouveront probablement rien. J'ajoute que je ne sais pas tout, et que j'espère que chacun et particulièrement les super-pros du firewall viendront amener leur pierre à l'édifice pour l'intérêt de tous...
 
-----------------------------------------------------------------------------------------------
 
Structure du topic:

- 2eme Partie du TUT - LA FIN D'UN MYTHE  
Structure de la deuxieme Partie:

 
-----------------------------------------------------------------------------------------------
 
0. Introduction
 
Pourquoi cette version est préférée encore par de nombreuses personnes à la version 4, sachant qu'il n'y a plus de support pour cette version ?
Cela vient du fait que nombreux trouvent encore beaucoup de bugs à la version 4 avec en plus des conflits de paramétrages internes, des problèmes de logs, etc..
Pour savoir utiliser Kerio 2.1.5 (menus, fonctions, etc..), l'aide (fichier Help) de Kerio est à lire (et je vous conseille de le lire avant d'aller plus loin). Il en existe une version en ligne à http://securis.info/securis/ker/
 
Lorsque vous allez commencer à établir vos règles, celles-ci sont enregistrés dans un fichier ".conf".
Il m'est arrivé une fois de par le passé (et pas qu'a moi) que ce fichier perde les règles. La manière de s'affranchir de ce problème est de faire un enregistrement de ce fichier via l'onglet 'divers > enregistrer' dans un répertoire différent du 'C' - bref pas sur votre DD system, juste comme ça en cas de restauration -. Depuis, le problème n'est jamais réapparu, et quand bien même ce serait le cas, il vous suffit de faire "charger" dans la même fenêtre!

 
-----------------------------------------------------------------------------------------------
 
1. Comprendre le principe général
Kerio a été conçu pour être un pare-feu (firewall) qui agit au dessous du niveau de la pile TCP/IP dans le system-Kernel en utilisant la methode "stateful inspection". C'est un système de filtrage dynamique de paquets de CheckPoint Software Technologies qui est basé sur l'inspection des couches 3 et 4 du modèle OSI permettant d'effectuer un suivi des transactions entre le client et le serveur, puis compile cette information 'de suivi' pour les paquets suivants, dans une table au niveau du noyau.  
La couche 3 du modèle OSI est la couche réseau , "les paquets", du modèle. Elle regroupe tous les protocoles réseaux et adresses correspondantes (TCP/IP, NetBeui, IPX/SPX...).  
La couche 4 est la partie transport qui lie de bout en bout le message et qui recouvre la connexion entre émetteur et récepteur. On y trouve des informations telles que les ports d'attaque de commandes ( TCP / UDP ) pour gérer la connexion -
 
 
Si une application sur votre PC souhaite établir une connexion avec un serveur (ou un autre PC) pour effectuer un transfert de données (prenons ici l'exemple d'un transfert de données a faire sur un serveur FTP, via un logiciel). Elle va utiliser un protocole pour effectuer ce transfert.  
Les données sont divisées en petites parties appelées packets à l'intérieur de chaque protocole.  
 
l'IP (Internet Protocol) est une suite d'octets qui transporte dans sa structure, tous les autres protocol packets, avec entre autres dans le "header" (l'entête) du paquet IP, l'IP source, l'adresse IP de destination, la fragmentation (DF,MF, Offset) - je les cite ici, vous allez comprendre après pourquoi -. La structure du paquet IP se constitue ainsi:
 
[version][taille (ou longueur) du header][service][Taille totale du paquet][n° de paquet][Flag][n° de fragment][Time To Live][Protocole][CRC][adresse source(IP)][adresse destinataire(IP)][Options][Bour.]["Message" TCP,UDP,ICMP..]
 
Kerio analysera chaque IP 'packet'
 
Cette application va donc demander à votre PC d'ouvrir un port de connexion (local) et effectuer une requête à l'adresse du serveur ou du PC concerné. De nombreux services initient une connexion sur un port statique, mais ouvrent dynamiquement (de manière aléatoire) un port afin d'établir une session entre la machine faisant office de serveur et la machine cliente. La règle "sortante" de Kerio va donc autoriser cette application a sortir ses 'packets'. Le serveur (destinataire) a normalement un ou plusieurs ports ouverts qui sont à l'écoute, prêt à recevoir ce type de requêtes ainsi que les 'packets' de données. Le serveur ayant reçu la requête, retourne un accord ou un refus à cette requête, puis établit la connexion en fonction.
 

 
Le tout est de s'assurer que les paquets qui reviennent via ce canal "virtuel" de connexion (comme dans le cas du TCP) vers votre PC, provient bien du destinataire initial, et qu'ils sont à l'intention de l'application concerné. S'il viennent par un autre canal, un autre protocole, ou par un autre chemin (un autre port ou autre), Kerio nécessitera une règle "entrante" pour vérifier qu'ils ont le droit d'entrer vers l'application concerné. Le reste doit être bloqué.
 
 
1.1 Le principe du paramétrage
 
C'est de faire en sorte que Kerio (2.1.5) verifie:

• Que l'application ou le service est autorisé à effectuer (ou recevoir) une connexion.
• Que cette application ou service correspond bien à la signature MD5 qui lui est attribuée.
• Qu'elle communique bien sur le(s) port(s) autorisé(s).
• Qu'elle communique sur un protocole qui lui est permis
• Vers et en retour, d'une destination autorisé (en exemple ci-dessus l'adresse IP du serveur)

On créée donc une liste de règles autorisant les applications ou les services souhaitées, à communiquer.
Le reste sera bloqué!! C'est à dire que tout packet qui ne correspondra pas aux règles établies, sera bloqué. Le principe est que Kerio applique les règles en commençant par la première règle vers la dernière... cependant il ne faut pas paramétrer en mettant du moins restrictif au plus restrictif.
Il faut au contraire garder à l'esprit de commencer par bloquer TOUT et n'autoriser qu'au cas par cas.
 
Voilà pourquoi le paramétrage correct commence par un positionnement du cran sur « refuser tout » qui, comme l'explique Kerio, bloquera tout ce qui ne correspondra pas aux règles établies... C'est là l'esprit de sécurité à garder en mémoire.
 
1.2 Ce que ne fera PAS Kerio 2.1.5
 
Bon, c'est ici que les déceptions vont commencer ...
 

• Ce n'est  pas un firewall de contenu

Il n'analyse donc pas le "data" contenu dans les trames. Kerio 2.1.5 ne vous dira pas si le contenu que vous rapatriez du serveur FTP est un virus ou non. Il ne dira pas non plus si votre collègue infecté avec qui vous avez un dossier partagé, vous transfere un fichier vérolé. Ce n'est pas un anti-virus !!
 

• Ce n'est pas un firewall applicatif, en ce sens qu'il ne "comprend" pas comment fonctionne les applications et ne peut effectuer un filtrage au niveau de la couche applicative (couche 7 du modèle OSI) si celle-ci possède une faille. Le filtrage applicatif suppose donc une connaissance de l'application, et notamment de la manière de laquelle elle structure les données échangées et requiert une grande puissance de calcul (se traduit donc souvent par un ralentissement des communications).. Par exemple, le protocole HTTP fonctionne sur la couche de niveau 7 de l'OSI, et par conséquent Kerio n'est pas en mesure de détecter dans le "Header" un objet genre "set-cookie", et vous ne pourrez pas le filtrer.

 D'autre part, si vous lancer un 'troyen'.exe (genre 'jesuisunesuperrousse.exe' que votre collègue vous a refilé) et que ce troyen 'spoof' un service windows et communique a travers le "svchost" que vous avez autorisé, Kerio 2.1.5 ne sera pas en mesure de vous dire que cette application agit comme troyen. Ce n'est pas un troyen-killer, ni un anti-spyware!
 CEPENDANT, Cette version possède un système de vérification basé sur une signature MD5 de l'application communicante, et poura avertir s'il y a substitution du '.exe'. Il ne pourra pas empêcher la substitution, mais il empêchera le '.exe' intrus de communiquer et le signalera. Cependant cette partie est désormais faillible (voir la deuxième partie du tutoriel "la fin d'un mythe" ).
Cette signature fonctionne aussi pour les services de windows. L'avantage serait normalement de signer ses services AVANT la toute première connexion, ce qui doit garantir leur authenticité par la suite.
 
Nota: Une signature MD est un checksum de l'exécutable d'une application. La première fois qu'une application est lancée (ou lorsque l'application essaie pour le première fois de communiquer via le réseau) Kerio crée une signature MD5 pour cette application. Cette signature est contrôlée à chaque tentative de communication suivante de la-dite application avec le réseau. Si l'exécutable de l'application a été modifié (par exemple s'il est infecté par un virus ou a été remplacé par un autre programme) Kerio 2.1.5 refuse la communication à cette application, présente un avertissement et demande si le changement doit être accepté ou non (par exemple en cas d' upgrade de l'application).
 

• On ne peut contrôler les protocoles d'applications à l'intérieur des protocoles de transport...

(voir Une passoire avec un autre protocole ? dans failles et limites ci-dessous)
 
 
1.3 Les failles et les limites
 
Les 2 failles du logiciel à corriger avant toute choses ( Copier/coller d'un post qui résume bien -merci à celui qui l'a posté )
 

 
Nota : bien sûr on peut exécuter n'importe quoi en lieu et place de cmd. La console compmgmt.msc par exemple pour rajouter des utilisateurs, changer les mots de passe existants, enfin, tout, quoi.
 
D'autres failles pour lesquels il n'existe pas de patchs ont été relevées par le site de Secunia (merci minipouss).  http://secunia.com/product/1493/#s [...] riticality
dont voici le résumé:
 

• Faille n°SA12468: (peu critique)

Concerne un "bypass" sur le système de protection de démarrage d'applications définis dans Kerio. Cette faille a été vérifiée pour la version 4, mais pourrait exister sur les précédentes versions.

Pour exploiter cette faille, il faut le privilège administrateur. bref, un attaquant doit d'abord convaincre l'utilisateur d'executer un programme malicieux en tant qu'administrateur!!! (genre l'admin qui clique sur "superrousse.exe"    )
pour en savoir plus: http://www.security.org.sg/vuln/kerio4016.html
 

• Faille n°SA10746: (peu critique)

Elle concerne la version 2.1.5 mais a été indiquée plus haut avec la soluce! ( Elle concerne la manière dont Kerio charge le jeu de règle en nécessitant le privilège "system" ).  
Conseil supplémentaire: En plus du mot de passe, ne pas prêter son ordinateur a des utilisateurs peu digne de confiance (généralement une grosse faille dans la sécurité).
 

• Faille n°SA8682: (très critique)

Ne concerne que la version 2.1.4 et antérieure.. donc on n'est pas concerné! Cependant, pour expliquer brièvement, il s'agissait d'une faille lié à la fonction d'administration à distance de Kerio. Il fallait se connecter à l'interface de contrôle a distance ( c'était faisable à condition d'être en mesure de "monitorer" les paquets entre l'admin et le firewall afin de pouvoir executer un "replay" de ces paquets et il fallait le monitorer à une session où l'admin désactive ses règles!! (bref dans les semaines de 4 jeudis ) . La soluce consiste à désactiver l'admin à distance de Kerio pour ces versions.
 

• Faille n°SA8663 : (pas critique)

N'est pas considéré comme critique par sécunia, mais perso, je la trouve gênante pour plusieurs raisons:
- la première est qu'elle concerne notre version 2.1.5 puisque toute les versions avant la 4.1.0 sont concernés et que le fix (patch) n'a été que pour cette version 4 et les versions suivantes.
- Qu'on apprend qu'il serait possible à une personne malveillante de "spoofer" le port 53    pour communiquer avec des services 'systèmes' en écoute sur le protocole UDP (nécessite quand même de faire un scan des ports, mais la règle par défaut de Kerio permettait TOUT traffic UDP entrant sur le port 53)  - nota : d'où à priori l'importance de ne pas mettre "toute application" dans les règles pour les DNS -
Le fix de la société a été d'appliquer un "stateful inspection" (analyse dynamique) sur les paquets UDP et d'autres protocoles IP, pour corriger le problème!  
> D'où tout a coup un doute m'assaille pour notre version 2.1.5, car dans le fichier help, il est juste écrit que la méthode principale est le "stateful inspection", mais ne précise pas sur quels paquets s'effectue l'analyse dynamique. Si cela s'averrait qu'ils n'ont implémenté l'analyse dynamique (c'est à dire d'effectuer un suivi des trames)  sur l'UDP qu'a partir de la 4.1, alors cela pourrait constituer une faiblesse accrue comme par exemple sur des paquets 'forgés'..(?)  
 
 
Une passoire avec un autre protocole ?
 
Il faut beaucoup relativiser, et ne pas se croire invulnérable. Kerio 2.1.5 ne permet pas de paramétrer sur les protocoles d'applications à l'intérieur des protocoles de transport.
 
Prenons un exemple (grâce un article tiré des jeudi de l'informatique) avec un protocole moins connu comme le protocole SNMP. Celui-ci permet d'agir sur des cartes réseaux à travers des datagrams (UDP) via une station de management - en général, le protocole SNMP se sert du protocole UDP pour ses transmissions -. Un admin peut donc arrêter une connexion sur l'une de ses interfaces réseaux, via le protocole SNMP. Or le protocole UDP n'étant déjà pas un protocole sûr puisqu'il ne crée pas de tunnel virtuel ( toutes les "data" sont transférées via messages individuels appelés datagrams), il existe des outils de hack avec linux permettant de scanner et de récupérer des infos sur ces datagrams (ce qui est plus discret qu'un scan sur TCP/IP). L'UDP peut donc 'renseigner' des informations intéressantes sur votre réseau. Après reflexion, Kerio n'a pas de fonction permettant de sélectionner ou filtrer un protocole (FTP, HTTP, SNMP..) à l'intérieur du protocole de transport - comme ici l'UDP - dans le cas ou ce protocole (UDP) est 'permis' sur une plage IP et ports spécifiques...
 
Cela ne veut pas dire qu'il n'effectue pas ce filtre automatiquement en fonction de l'application (par exemple avec une application FTP, il ne filtrerait que le protocole FTP) et encore A CONDITION je suppose, que cette application soit précisé dans les règles - à la place d'un paramétrage "tous programmes" -, mais ce n'est pas sûr puisqu'une application comme un navigateur IE6 peut travailler sur le protocole HTTP, mais aussi effectuer un transfert FTP ! Kerio ne filtre t'il qu'en fonction de la demande de protocole faite par l'application, ou bien permet-il à plusieurs protocoles de passer pour cette application?
N'ayant pas plus de précisions sur le moteur de Kerio 2.1.5, il est permis de penser qu'il existe là une limite du fait de cet abscence de paramétrage sur le firewall qu'il faut prendre en compte.
 
Une passoire avec les paquets fragmentés
 
Voir deuxième partie du TUT : "La fin d'un mythe".
 
-----------------------------------------------------------------------------------------------
 
2. Les règles
 
C'est une possibilité de classement, mais je range les règles par catégorie
 
1. Les Catégories
 

• Loopback

Je pensais qu'elle n'était pas nécessaire avec Kerio, mais cette règle accélère effectivement les échanges, c'est à dire par exemple dans le cas de l'application du browser, la vitesse d'affichage des pages passant de 5 à 10 secondes sur ma configuration à une vitesse instantanée!! Cependant il faut préciser que cela peut dépendre de la configuration.
Cette règle autorise les applications locales avec l'ordinateur sur le port 127.0.0.1. (je dois faire quelques test pour montrer dans quel intérêt il y a ce loopback par les applis)
Cette adresse est reliée au nom "localhost" qui désigne la machine locale, via un fichier de configuration dans le répertoire system32.  
 
Cependant, elle peut constituer une faille dans les cas d'un IP spoofing du localhost (exemple d'un messenger spam : UDP(fake) sur 127.0.0.1:1234 -> votre IP:1026 ).
 
Une manière de prévenir ce spoofing est d'établir une règle uniquement « sortante » sur le loopback  avec les applications communicantes.  
Mais il existe certaines applications qui ne ré-utilisent pas le même port et nécessitent une règle « entrante », ce qui oblige de faire du cas par cas sur les applications
 
Pour les paranos, il vaut mieux donc paramétrer cette règle avec les applications qui peuvent s'en servir:
exemple pour le cache IE :UDP sortante(Tous)  ieAppli -> 127.0.0.1(Tous)
Mais cela nécessite de le faire pour chaque application communicante. Devient nécessaire lorsque l'on utilise un soft proxy.
 
Il apparaîtrait qu'il n'y a pas de subnet spoofing (a prendre avec des pincettes, j'attends que des pro du réseaux confirment ou infirment..), il dvrait être possible d'établir une règle avec un masque. Mais sur certains forums, la règle apparaît comme étant avec un masque 255.0.0.0 ce qui est faux, car en faisant le test (avec désactivation des connexions, etc..), cela ralentit avec un temps d'affichage de 5 à 10 secondes par page.. ce qui fait que si on la désactive ou l'active avec ce submask, on ne voit pas de différence entre activer cette règle loopback et la déactiver. C'est donc avec un autre masque peut-être (je dois faire quelques essais). POu l'instant je ne mets pas de submask:

 

• NetBios

(Net Basic Input/Output System)
 
C'est une API qui peut être utilisé par des  programmes sur un réseau local. NetBios fournit un jeu de commande aux programmes permettant d'accéder aux ressources bas niveau !! Cette API est nécessaire à la gestion des noms, au déroulement d'une session, à l'échange de datagrammes entre les noeuds d'un réseau.
Exemple d'une commande qui utilise cette API:
Nbtstat
Cette commande de diagnostic affiche les statistiques de protocole et les connexions TCP/IP en cours utilisant NBT (NetBIOS sur TCP/IP). Cette commande est disponible uniquement si le protocole TCP/IP est installé.
nbtstat [-a nom_distant] [-A adresse IP] [-c] [-n] [-R] [-r] [-S] [-s] [intervalle]
Paramètres

• a nom_distant: Affiche la table des noms de l'ordinateur distant en utilisant le nom.
• A adresse IP: Affiche la table des noms de l'ordinateur distant en utilisant son adresse IP.
• c: Affiche le contenu du cache de noms NetBIOS en donnant l'adresse IP de chaque nom.
• n: Affiche les noms NetBIOS locaux. La mention Registered indique que le nom est enregistré par diffusion (Bnode) ou par WINS (autres types de noeuds).
• R: Recharge le fichier Lmhosts après avoir purgé tous les noms du cache de noms NetBIOS.
• r: Affiche les statistiques de résolution de noms pour la résolution de noms en réseau Windows. Sur un système Windows 2000 configuré pour utiliser WINS, cette option renvoie le nombre de noms résolus et enregistrés par diffusion ou par WINS.
• S: Affiche les sessions client et serveur, en répertoriant les ordinateurs distants par adresse IP uniquement.
• s: Affiche les sessions client et serveur. Ce commutateur tente de convertir l'adresse IP de l'ordinateur distant en un nom à l'aide du fichier Hosts.

Si vous désactivez NetBIOS sur TCP/IP, vous risquez de ne plus pouvoir vous connecter aux ordinateurs exécutant des systèmes d'exploitation différents de Windows.  
Normalement,  netbios n'est pas utilisé pour la communication Internet (c'est le nom d'hote qui est propre au protocole TCP/IP), mais depuis Win2K, le nom netbios et le nom d'hote sont les même.
C'est donc sur les ports NetBios que s'effectue de nombreuses attaques externes.
 
Voici un copier/coller d'un post décrivant ces ports:
 

 
En théorie, si on a positionné sur « refuser tout », cette règle n'est pas nécessaire, mais en pratique -voir pourquoi plus bas- on créée une règle qui bloque tout.  
 
Sauf évidemment, si vous êtes dans un LAN qui utilise le système de réseau Microsoft et que vous utilisez le partage de dossiers, il faudra alors rentrer une règle pour rentrer les IP autorisés des ordinateurs du LAN avec qui vous communiquerez via ces ports... En espérant que vous avez une bonne confiance dans vos « collègues »..  
Je n'ai pas fait de test pour savoir si on peut s'en affranchir en utilisant le protocole IPX/SX à la place du TCP/IP..
 
Même si vous avez désolidarisé NetBIOS du protocole TCP/IP, elles vous permettront de savoir s'il y a une tentative d'intrusion en cochant la case "journaliser si..".  
 
Si vous êtes sur un LAN, il peut être nécessaire d'autoriser le NetBIOS pour les PC de votre réseau local, en créant une régle (voir règle 1 dans l'image ci-dessous) d'autorisation sur une plage d'adresse ou un masque de reseau avant les règles 2 et 3 (ci-dessous en case décoché):  
La règle s'établirait ainsi:

 
 

• ICMP

 
l'ICMP est un protocole particulier, pas vraiment nécessaire pour une utilisation normale, mais indispensable dès qu'on aime faire des pings ou des traceroutes, soit les types 0, 3,8,11. Dans la fenêtre de règles de Kerio, il vous est proposé une liste de chiffres correspondant à l'ICMP demandé (Exemple le 8= Echo request).
 
La liste est la suivante:
http://www.erg.abdn.ac.uk/users/go [...] -code.html
 
En règle générale, beaucoup mettent en règle sortante :"l'echo request"
En règle entrante: "l'echo reply", "destination unreachable" et "time exceeded for a datagram".
 
La règle s'établirait ainsi:

 

• DHCP

Si vous passez par un serveur DHCP pour obtenir votre adresse IP, il faut créer une règle pour permettre la communication avec ce serveur. L'échange se fait  normalement par le protocole UDP sur le port 68 en local et 67 en distant
Les Pros Rentreront l'adresse IP du serveur DHCP (et le masque réseau si applicable)dans la règle. On peut obtenir l'adresse IP du serveur avec ipconfig par ligne de commande pour les systèmes NT et winipcfg avec 98/Me . Dans certains cas (comme par exemple sur différent réseaux wifi), on ne peut connaître à l'avance l'adresse IP du serveur DHCP, ce qui oblige soit à établir une régle générale pour tout IP distant, ou bien de modifier la règle et de se reconnecter derrière (pas pratique tout de même). Si vous avez une configuration avec IP fixe, cette règle ne vous concerne pas. Si vous avez un portable qui va sur différents réseaux, il est utile de créer autant de règles pour chacun des serveurs DHCP connus (IP connue) auxquels vous vous connecterez (en activant la bonne règle à chaque fois.. voir "applications" plus loin), sinon, il vous faudra vous servir d'une règle générale. Le service de Windows qui établit la communication avec le seveur est le "services.exe" dans le "sytem32" du repertoire windows.
 
La règle s'établirait ainsi:

 

• DNS

D'une manière générale, la requête DNS est un processus en deux parties :
 
1ere partie: La résolution locale
Une requête de nom est formulée au niveau d'un ordinateur client et transmise à un solveur, le service Client DNS, en vue d'être résolue.  
Lorsque la requête ne peut pas être résolue localement, des serveurs DNS extérieurs sont nécessaires pour résoudre le nom.
Dans les premières étapes du processus de requête, un nom de domaine DNS est utilisé dans un programme de l'ordinateur local. La requête est ensuite transmise au service Client DNS afin d'être résolue à l'aide des informations mises localement en cache. Si la requête de nom peut être résolue, une réponse est donnée à la requête et le processus se termine.
Le cache de résolution local peut inclure des informations de nom issues de deux sources :
Si un fichier Hosts est configuré localement, tout mappage nom d'hôte-adresse contenu dans ce fichier est préchargé dans le cache au démarrage du service Client DNS.  
Les enregistrements de ressources obtenus en réponse à de précédentes requêtes DNS sont ajoutés au cache et conservés pendant un certain temps.  
Si le requête ne correspond à aucune entrée du cache, le processus de résolution se poursuit et le client interroge un serveur DNS pour résoudre le nom.
 
2ème partie : interrogation d'un serveur DNS
Le client interroge un serveur DNS par défaut. Le serveur utilisé dans la première partie du processus (requête client/serveur) est sélectionné dans une liste générale. À réception de la requête, le serveur DNS commence par vérifier s'il peut y répondre en faisant autorité à partir des informations d'enregistrement de ressource présentes dans une zone configurée localement sur le serveur. Si la requête de nom correspond à un enregistrement de ressource dans les informations de la zone locale, le serveur répond en faisant autorité et utilise ces informations pour résoudre la requête de nom.
Si la zone locale ne contient aucune information pour le nom faisant l'objet de la requête, le serveur vérifie s'il peut résoudre ce nom en utilisant les informations mises localement en cache à partir de requêtes antérieures. Si une correspondance est trouvée, le serveur envoie ces informations en réponse. Si le serveur par défaut peut envoyer une réponse positive à la requête du client à partir des informations de son cache, la requête prend fin.
Si aucune réponse à la requête de nom n'est trouvée sur le serveur par défaut - dans son cache ou ses informations de zone - le processus de requête se poursuit et la récursivité est utilisée pour résoudre complètement le nom. Ce processus implique l'assistance d'autres serveurs DNS. Par défaut, le service Client DNS demande au serveur d'utiliser un processus de récursivité pour résoudre complètement les noms pour le compte du client avant de renvoyer une réponse. Cela peut remonter jusqu'au "TOP LEVEL DNS" qui eux contiennent tous les domaines du réseau des réseaux.
NOTA: Si la réponse d'une requête est trop longue pour être envoyée et résolue dans un seul paquet de message UDP, le serveur DNS peut lancer une réponse de basculement sur le port TCP 53 pour répondre complètement au client dans une session TCP.  
 
Le serveur DNS fournit les adresses IP aux noms de domaines que vous avez rentré en requête dans votre navigateur. Vous passez par les DNS de votre FAI généralement
Il vous faut créer autant de règles que votre FAI utilise de serveur DNS.  
A priori il ne semble pas y avoir d'attaques connu sur le port 53 , donc on pourrait laisser toute communication sur le port 53 et hop, on ne s'embêterait pas à rechanger les adresses IP des DNS si ceux des FAI changent. Mais les pros rentrent les adresses IP des DNS bien sûr , ainsi que celui des « secours »... On peut établir aussi une règle qui bloquera toute autre packet sur ce port juste derrière 'par sécurité' (voir sur l'image ci-dessous les flèches rouge).
 
le service windows qui s'occupe de ça est : c:\winnt\system32\services.exe
 
La règle s'établirait ainsi:

 
-----------------------------------------------------------------------------------------------

3. Les applications
Navigateur, messagerie, client-FTP.. chaque application utilisera un port spécifique, un protocole spécifique...  
Pour savoir comment créer une règle pour votre application, vous pouvez soit changez le cran en « me demander » et  regardez sur quels ports l'appli tente de se connecter, soit regarder dans le firewall status et les logs (voir application pratique). Ne pas oublier de définir la signature MD5 qui est une protection supplémentaire pour assurer l'authenticité sur les paquets de retour (onglet signature des applications) ! En voici quelques-uns des plus courant:
 
Par exemple pour un client FTP (filezilla,..)
La règle s'établirait ainsi:

nota: vous remarquerez que je n'ai pas mis l'adresse IP du serveur FTP destinataire.. si vous la connaissez ce serait effectivement mieux de le faire.
 
Pour un client HTTP (IE, Firefox..)
La règle s'établirait ainsi:

nota: vous remarquerez que seule la règle sortante est cochée "autorisé". Cela est suffisant pour surfer, puisque les navigateurs n'utilisent en règle générale que le TCP, il n'est pas nécessaire d'appliquer une règle entrante.. cependant, une règle entrante peut s'avérer également nécessaire dans des cas de connexions particuliers.. (comme par exemple sur des ports autres que ceux définis).
 
Pour un client POP3, SMTP (Outlook, Foxmail,...)
La règle s'établirait ainsi:

nota: vous remarquerez que seule une règle sortante est nécessaire, et ce pour l'envoi, comme pour la réception de courrier. Cela est possible puisque l'on définit dans la règle sortante au moins deux ports sur le serveur destinataire (un destiné a recevoir le courrier, l'autre pour le retrait du courrier) dans le même "canal virtuel".
 
-----------------------------------------------------------------------------------------------
 
Un exemple de liste de règles

C'est la mienne a l'heure actuelle. Elle me permet de surfer sans aucun patchs contre blaster et Co. sur le web.. C'est pas très bien de dire ça, mais c'est juste pour expliquer que c'est faisable. Toutefois, je la mets ici seulement à titre d'exemple.. C'est à vous de paramétrer Kerio en fonction de ce que vous faites de votre ordinateur, de vos applications, et des réseaux sur lesquels vous allez. Le but de "l'application pratique" de ce tutoriel est justement de vous montrer comment y parvenir..
 
Le fichier .conf à télécharger est ici:
http://serveur.levillage.org/KerioConf.conf
 
Ce paramétrage est adapté pour un portable plutôt "traveller" et lorsque je change de réseau, je coche et décoche en fonction (par exemple ici, sur l'image dessus, si je décide de surfer sur un réseau wifi, j'ai coché les règles qui sont cadrés en rouge). Evidemment, vous allez dire que ce n'est pas pratique, mais il s'agit d'un portable, et peut-être que chez vous, vous n'aurez pas besoin d'activer et désactiver les règles.  
 
Vos applications
Cette partie s'incrémentera de screenshots de la règle de vos applications comme suit :
Application,  
Protocole Règle entrante (s'il y a lieu) et sortante
Ports locaux, adresse
ports distants, adresse
 
 
 
-----------------------------------------------------------------------------------------------
 
4. APPLICATION PRATIQUE
 
 
Là aussi, on va garder son calme et voir que ce qui est bloqué, ne veut pas dire qu'on essaie de vous hacker!  
Le but de cette application pratique est  de vous montrer comment paramétrer vos règles dans le firewall en fonction de l'observation du log et des connexions de ports dans la fenêtre "firewall status" ainsi que le journal (n'oublions pas que celui-ci ne listera que les connexions des règles où vous avez cochez l'option 'journaliser') et nous allons regarder un peu ce qui se passe.

 
 

• Surfer Wi-fi sur le réseau Meteor en conservant son firewall.

En utilisant les règles de la liste au-dessus, les pages mettent un peu plus de temps à s'afficher du fait que l'on accepte que que les retours DNS du "services.exe". Si vous acceptez les retour DNS avec "no owner" (c'est a dire d'autres appli du serveur), le surf est 10 fois plus rapide.. là je ne sais pas quelle attitude adopter et j'attends le super pro pour mieux expliquer.
Dans les propriétés TCP/IP de notre connexion réseau Wifi, on coche "obtenir DHCP et DNS automatiquement".
Activons la connexion réseau de notre carte wifi ainsi que les ondes radios, et sélectionnons le réseau Meteor (Le reseau Meteor est celui qui est disponible dans les gares et les fastfoods, ce qui veut dire que vous êtes près d'une borne de ce réseau)

 
(Nota: Par habitude, je garde toujours mes connexions désactivés et mon firewall 'non démarré' pour gagner des ressources en 'mode workstation', c'est pour ça que dans mes icônes en bas (si je décide de me connecter), j'ai de la gauche vers la droite, le firewall, le firewall admin (pour cocher ou décocher certaines règles), puis la connection, puis les applis.. )
 
Ouvrons le navigateur, on peut voir qu'on est connecté (après acceptation des règles):

 
Dans le journal:

On voit que la connexion s'établit d'abord avec le serveur DHCP en lancant une requête 'Broadcast' (255.255.255.255) sur tout le réseau afin de toucher le serveur DHCP en écoute sur le port 67 - voir n° 1,2,3,4 de l'image ci-dessous-. Celui-ci nous retourne une réponse avec son adresse IP -192.168.101.1 (nota: il m'a attribué l'adresse IP 192.168.101.9). Le service de Windows ayant obtenu les infos du DHCP -dont l'adresse IP du DNS-, se connecte ensuite au serveur DNS, qui est le même au vu de l'adresse IP!
On va aller sur le forum HFR avec notre application (navigateur IE) qui envoie alors une requête vers le serveur DNS  et reçoit une réponse indiquant où se situe la page web cherchée et pour lequel il va se connecter au serveur Web hebergeant cette page (je n'ai pas journalisé la règle du navigateur ici, donc on ne voit pas ces échanges..).
En 7 et 8 on voit que le firewall a bloqué une communication sortante de IE vers les serveurs de Verisign sur un protocole TCP (règle n° 1 et 2 dans ma liste de règles (cela vient d'une remarque sur un forum concernant l'utilisation abusive de la corporation Verisign sur des protocoles internet et de ses serveurs sur le Net).  
En 10, on note ce fameux retour de packet DNS "no owner" qui si on l'accepte permet de surfer rapidement. Je mets des flèches pour montrer où regarder des indications utiles pour paramétrer vos règles.  
 

On peut voir que IE ouvre de nombreux ports de communication locaux, en fonction des indications du serveur web, des scripts, des images ou des URL pointant sur d'autres serveurs web (comme ici "Village06.cyberbrain.." qui est le serveur hebergeant les images d'un topic sur HFR), etc..  
 
 
De même pour une une application Mail sur lequel on a effectué un envoi et une reception:

On voit dessus l'adresse du serveur, les ports, etc.. Si vous remarquez que l'adresse IP est toujours la même ou sur une plage spécifique, vous serez en mesure de la rentrer dans votre règle d'application mail  
 
Toutes ces indications vous permettront d'analyser les connexions, les adresses des serveurs, d'établir des règles, de faire des tests.. et de ne pas voir partout des attaques.
 
 
 
 
-----------------------------------------------------------------------------------------------
Pour terminer...
 
 
En théorie, on ne devrait rentrer que des règles pour les applications utilisées, et le reste est bloqué...
 
Mais en pratique, on s'aperçoit que de nombreux logiciels ainsi que l'OS ont des failles: un exemple classique sont les actives X de IE. Si vous autorisez un à s'installer pour pouvoir lire la page web ou executer un script, alors vous autorisez l'ouverture d'une porte à une application du serveur qui s'exécutera sur votre navigateur (et votre ordinateur, si celle-ci est maligne et qu'il n'existe pas de patch).. A cause de certaines de ces failles il faut un certain nombre de règles en plus et AVANT les applications communicantes.. Votre bon sens reste le dernier rempart.
 
Une chose est sûre, vous n'êtes pas en sécurité derrière votre firewall, mais Kerio 2.1.5 a quand même le mérite d'être suffisamment efficace pour vous permettre de surfer à ce jour sans patchs contre blaster, sasser et compagnie, en plus d'être gratuit..
 
-----------------------------------------------------------------------------------------------
 
serveur & sanpellegrino

- 2eme Partie du TUT -
 
////////////////////// LA FIN D'UN MYTHE /////////////////////////
 
Structure de la deuxieme Partie:

 
-----------------------------------------------------------------------------------------------
 
1.Notions et rappels
 
Fragmentation et ré-assemblage IP
Jusqu'à aujourd'hui, l'une des méthode du hack reposait (ou repose encore) sur la nécessité des paquets à se ré-assembler après leur trajets sur le réseau. La méthode consiste à ré-écrire et ré-agencer une séquence de paquets dans un ordre déterminé, à le faire passer à travers le firewall pour obtenir une session, une authentification, ou même activer un code. On a vu plus haut que les données étaient séparés en paquets pour transiter entre les routeurs et ceux-ci peuvent être encore fragmentés suivant certains routeurs avec un paramétrage MTU bas qui obligent certains paquets à se fragmenter (flag MF: More fragment = 1).
Lorsque les paquets fragmentés, éparpillés suivant les différents tronçons empruntés, parviennent à destination, ceux-ci sont en attente du premier fragment, afin d'être ré-assemblés en fonction de leur identification et de leurs morceaux (Offset 2,3..) afin de reconstituer le paquet IP. C'est cette phase que le hacker en général utilise à son profit pour générer SA séquence, en "forgeant" les paquets malicieux. Les méthodes d'attaques ou de surveillance varient suivant le protocole utilisé (TCP,UDP..).  
 
Le Protocole TCP
Le paquet TCP est constitué de [source port][destination port][n° de séquence unique 'TH SEQ'][n° d'acquittement 'TH ACK'][offset][Flags'URG,ACK,PSH,RST,SYN,FIN'][fenêtre][checksum][Pointeur Urg.][options][Data]
 
En prenant la valeur =1, les Flags TCP permettent d'indiquer le "type" de paquet TCP
- URG : Urgent. (l'explication va de soi)
- ACK : Acquittement d'un paquet (Acknowledgement)
- PSH : Interdire le stockage temporaire
- RST : Réinitialiser (ou terminer) une session
- FIN : Fin d'une session
- SYN : Synchronisation (début) d'une session
 
Exemple: U=0, A=1, P=0, R=0, S=1, F=0 => paquet TCP "SYN/ACK"
 
Une session TCP se traduit normalement par un flux client-serveur dans cet ordre: SYN (vers serveur), SYN/ACK (vers client), ACK(vers serveur), <Data>(echange client-serveur), FIN/ACK(vers serveur), ACK(vers client), FIN/ACK(vers client), ACK(vers serveur).
 
 
Les paquets Forgés
On peut utiliser des utilitaires comme Rafale X pour forger des paquets. Le but étant souvent de ré-écrire une partie du "header" TCP, UDP.. afin d'accéder à des ports normalement bloqués par un firewall, mais qui se ferait duper (voir plus loin pour l'explication). On peut alors, faire des écoutes, des scans, des deni-os, etc.. en étudiant les réponses du serveur visé.
 
exemple: copier-coller pris sur http://babin.nelly.free.fr/scan.htm

 
Les paquets Fragmentés
Avec un IP_MF=1 et une valeur offset, le paquet fragmenté doit trouver sa place au sein de la reconstruction du paquet IP. Mais ces paquets lorsqu'ils sont forgés avec des valeurs de taille, d'ordre offset, ou d'un header TCP remanié, peuvent duper les firewalls..  
C'était le cas par exemple du firewall IPchains de Linux avant qu'un patch ne soit mis sur la version 2.2.10. Si le fragment était trop petit pour contenir le Header complet, et une valeur offset =O, le moteur l'interprétait comme un offset >0  
(source: http://linuxtoday.com/news_story.p [...] -021-10-SC ). Regardons comment un hacker s'y prends.
 
2.Un vrai Hack
 
J'aurais pu le titrer un vrai 'ACK'    .  
Les cibles privilégiés d'un hacker quand il s'agit d'un particulier lambda sont rare! Les cibles étant plutôt des cadres genre "Elf" et autres corporates, des journalistes.., voire votre "ex" , mais pas le lambda du coin.
 
Je choisis cet exemple qui est tiré de "How Mitnick hacked Tsutomu Shimomura with an IP sequence attack System: TCP/IP" (Source: tsutomu@ariel.sdsc.edu (Tsutomu Shimomura), comp.security.misc) dont j'ai pris un extrait ici: http://files.arenhack.com/redirect [...] le=181&id=  parcequ'il est très représentatif de la méthode, et aussi parceque cela devrait relativiser vos craintes de subir une attaque de ce genre..
 
Mitnik (d'après Tsutomu) aurait utilisé pour commencer:
 
 un IP spoofing> en Root sur toad.com, avec une utilisation de sondes pour vérifier une relation de confiance, un envoi de  TCP "SYNs" sur le port 513. Un packet SYN est le premier packet envoyé lors d'une connexion TCP. Normalement "Le but d'un SYN scan est de déterminer si l'hôte répond sur ce port sans devoir initier une connexion complète". Mais ici Tsutomu précise que le but était de remplir une file d'attente sur le port 513 de connexions "half open" (état d'un port à moitié fermé, c'est à dire que le serveur laisse un délai avant de fermer la connexion physique au cas il y a une relance derrière)  pour empêcher le serveur de répondre par un TCP RST's à une autre connexion innoportune qui aurait généré un SYN-ACK. Puis Mitnik utilise ce port dés lors "réservé de force", pour s'en servir comme point de départ en tant que source IP (le port 513 était un port spécial:server.login).
 
 Ensuite une Séquence TCP généré> Utilisation de paquets forgés "SYN-ACK" pour tester le comportement du générateur de séquence TCP du serveur, puis forgeage d'un "ACK" ayant la bonne séquence par rapport au "SYN-ACK". Une connexion TCP unilatérale est alors créée et ne sera maintenu qu'à condition de renvoyer à chaque fois un "ACK" ayant la bonne séquence TCP généré. Temps depuis l'attaque : moins de 16 secondes    . Puis Recompilation d'un module et enfin login sur le serveur.
 
3. "RIP" 2.1.5
 
Bon, c'est ici que la version 2.1.5 peut partir à la retraite et reposer en paix. C'est basé sur 3 remarques différentes (dont une de Minipouss).
 
1/ La première tiré d'http://groups-beta.google.com/grou [...] lr=&rnum=1,  
Kerio 2.1.5 se laisse abuser par des paquets fragmentés sur des protocoles UDP et ICMP. On pourrait penser que l'utilisateur a mal paramétré son firewall, mais en fait c'est confirmé même sur des paquets TCP fragmentés sur ce topic ( http://forums.kerio.com/index.php? [...] 110c4f8643 ), d'où 2eme remarque, je vais retraduire une partie:
 
2/
L'utilisateur a d'abord fait un test sur grc shieldsUP et est confirmé comme "stealth" , puis il établi deux règles simples qu'il place TOUT EN HAUT des règles:  

• 1- BLOQUE TOUT traffic TCP entrant et sortant!  
• 2- Bloque tout traffic ICMP ! avec Log et alert..

Puis il utilise TYPsoft FTP server pour ouvrir un port 21 sur la machine un XPpro (en SP2!) faisant tourner Kerio 2.1.5. ..A partir d'une machine Linux, il envoie des pacquets
 

• a) Lorsqu'il envoie un SYN sur un port ouvert ou fermé, Kerio réagit bien et ne répond pas, bloque le traffic et affiche l'alerte. Ce sera le seul bon point.

• b) Lorsqu'il envoie un FIN, ACK, RST sur un port ouvert ou fermé, il n'y a pas de réponses, mais Kerio laisse passer le traffic (!) et ne 'log' pas. Si encore c'est compréhensible qu'il ne log pas, il n'aurait pas du laisser passer le traffic.

• c) Lorsqu'il envoie un PUSH, URG sur un port ouvert ou fermé, il reçoit un RST/ACK en réponse (!), et laisse passer le traffic, et ne "log" pas.. Déjà a partir d'ici, on oublie le "stealth"!!

• d) lorsqu'il envoie un SYN avec La valeur du bit du FRAGMENT à destination d'un port fermé, il a obtenu un RST/ACK (port fermé) en retour, avec le traffic permis (flèche verte).. Aïe!

• e) Lorqu'il envoie un SYN (qui je le rappelle est un début d'ouverture de connexion) sur un PORT OUVERT, il reçut un SYN/ACK (connexion accepté) en retour, la flèche verte indiquant le passage du traffic, pas de log, et le ServerFTP enregistre la connexion et répond par une demande de UserName!!!. Il fit le même essai avec NetCat (permet de connaître les versions logiciels) en écoute sur le port 21, et NetCat retourna un SYN/ACK!!!!

A partir de là c'est fini! Cela veut dire que la version ne gère pas les paquets avec une valeur sur le "fragment bit".
 
3/Il faut y ajouter un autre problème que Minipouss a trouvé ( http://ferruh.mavituna.com/article/?769 )
qui montre un script vbs qui effectue un bypass et incruste une nouvelle signature MD5 parmi les applis autorisés..  j'ai testé sur mon portable en lancant les différents .vbs .. notamment Kerio.vbs et le test firewall.  
( test sans et avec firewall).
Il faut déjà que le le Windows Script Host soit activé, afin que tout windows script puisse s'executer ..(ce qui veut dire que déjà si un poste client désactive l'execution de script, cela ne peut fonctionner, mais bon en règle général, ce sont des failles IE qui sont exploitées, ou bien , c'est simplement l'execution d'actives X)
 
Sans firewall, le .vbs se connecte bien au serveur "malintentionné" , et j'ai bien un retour des "headers" des paquets IP... donc passons au test avec kerio actif avec les règles du topic..
 
Concernant kerio.vbs il me fait 5 bip, mais ne passe pas le firewall, quant au "test firewall.vbs" , il ne se connecte plus, et ne passe pas le firewall, idem pour "bypassSendkey".vbs dont une fenêtre s'ouvre et indique "que le nom de serveur n'a pu être résolu".
 
Bref ces scripts , bien qu'étant installé coté client (c'est à dire que j'ai fait comme si j'avais installé le trojan), ne passe plus une fois  Kerio 2.1.5 éxecuté avec les règles du topic, et ce même si Kerio est activé après.  
 
La seule chose que je remarque effectivement, c'est qu'une application "C:\winnt\system32\wscript.exe" possède une signature MD5 dans l'onglet des signature des applications de Kerio.  
 
En clair, on peut estimer qu'il y  a un danger potentiel du fait que l'exe se retrouve bien dans les signatures MD5, et donc qu'un trojan perfectionné peut exploiter cette faille pour communiquer. Mais faut il encore que les règles établies le lui permettent (dans le sens où il faut qu'il n'y ait pas une règle bloquante, même pour l'exe ..)
 
Bref, ce que la personne indique c'est qu'il y a un danger effectivement exploitable par un bon programmeur.
 
A titre indicatif, je mets un exemple du genre d'attaque qu'utiliserait cette faille :
 
http://computercops.biz/article3654.html.  
 
A priori d'autres firewalls perso (outpost, look'nstop, ZA, etc semble être affectés.. mais des patchs sont peut-être sorti depuis pour ces firwalls.  

Bravo Messieurs

interessant sur les failles.
sinon, utilisateur de kerio 2.1.5 depuis 1 an, entierement satisfait

niveau failles, d'après Secunia il y en a 4 non patchées (3 annonces de vulnérabilités concernant 4 failles)
 
http://secunia.com/product/1493/

je vais les rajouter..  

ok

Beau boulot   !

drapal

Beau travail, fort instructif: bravo.
 
Quelques remarques:
1. Kério 2.1.5 existe aussi en français via un patch (dont je ne me souviens plus de l'adresse)
2. Kério ne filtre pas les IP
3. Il ne passe pas le test du ping si le mode passerelle est activé sur un site de test (plus le nom en tête)
4. Il manque les explications lors de l'utilisation de Kério sur une passerelle.

http://perso.wanadoo.fr/veekee/petzouille/kpf_fr.exe pour le patch de francisation
 
edit (2 fois) : plutot mettre ce lien là http://veekee.free.fr/?p=list-105 il a dû changer de FAI
 
dispo aussi par clubic http://drivers.clubic.com/telechar [...] ewall.html

1/ exact pour le patch,j'y ai pensé ce matin, je vais essayer de retrouver le lien, au pire j'uploaderai le mien..
2/ je veux bien que tu précises un peu.. tu parles des adresses IP, ou bien du filtrage IP (protocole IP )?
3/ et 4/ heureusement San pellegrino a réservé un post en 3eme position pour la suite..
 
en fait il me reste encore à rajouter dans la partie application une procédure pas a pas un prenant une appli, un test sur l'inbound HTTP wifi, un autre test sur le 'no owner' dns pour la rapidité, et la traduction des failles non patchés précisé par minipouss..
d'ici la fin de semaine j'espère  
 
[edit] Merci à minipouss pour le lien..

je me suis gouré
 
http://veekee.free.fr/?p=list-105 pour la page et http://veekee.free.fr/redirect.php?id=105 pour le lien direct

 
Bikerman, merci pour les compliments, cela nous va droit au coeur.  
 
Ta remarque m'interesse pour les IP, mais j'ai pas tout a fait compris  
- Si c'est au niveau des adresses IP, Kerio effectue bien un filtrage (simple, plage, etc..) qui fonctionne effectivement (on le voit sur la partie 'appli pratique' lors d'un paquet rejeté sur les adresses de verisign
- Si c'est au niveau de 'l'Internet Protocole', Kerio effectue normalement bien le filtrage à ce niveau sinon, je ne vois pas sur quel niveau il pourrait faire l'analyse des headers et des autres protocoles (Bien que non explicitement dit, la doc l'indique ici : http://securis.info/securis/ker/ch03s02.html )
- Si c'est au niveau d'un paramétrage des protocoles à l'intérieur de l'internet Protocole, cela me parait exact ( je l'ai fait figuré dans ma remarque dans Failles et limites "Une passoire avec un autre protocole ?" )  
Ou alors il y a un truc qui m'a échappé ou que je n'ai pas compris

En fait je viens de découvrir que certains firewall comme zone alarm pouvaient bloquer certaines adresses IP qu'on lui fournissait et ce pour toutes les applications.
Il n'est donc plus quetion d'un filtrage sur les applications mais sur les adresses IP.
 
D'autres outils permettent ce genre de blocage, je pense à protowall, p2phazard, peerguardian nottament.
 
L'utilité de ces blocages est peut-être discutable mais c'est une fonction présente sur certains firewall et absente sur Kério.

si je ne me trompe pas, on peut bien faire une règle pour tous les protocoles, toutes les applis et spécifier une IP distante qui sera seule concernée par cette règle non

Absolument vrai pour 1 IP distante.
 
Mais si tu en a beaucoup beaucoup plus et qui ne se suivent pas forcement, tu ne vas pas créer une règle pour chaque.
D'autant plus que ces adresses peuvent être alimentée par des logiciels tiers et qui n'interfacent pas avec Kério.

y a "groupe personnalisé" qui existe pour mettre plusieurs IP distantes mais je ne sais pas m'en servir (jamais regardé ça)
 
pour le reste je ne m'y connais pas donc je te crois

Bikerman> Ok, merci pour la remarque concernant les "blacklist" IP, je vais l'intégrer.
Cependant, comme le dit Minipouss,  Kerio gère les groupes personnalisé ("custom address group" ). Il suffit d'aller dans l'onglet 'divers' du panneau de configuration, et il y a une fenêtre marqué "groupe d'adressage personnalisé". On peut ajouter des adresses IP, des plages, des réseaux qui seront pris en compte si on choisit ensuite dans la règle au niveau de la liste IP : groupe personnalisé.
Cependant, il n'y a qu'une seule liste (qui servira de blacklist ou de liste autorisée).. Kerio 2.1.5 n'en gère pas plusieurs..  
 
Il ne faut pas oublier que cette liste n'est pas nécessaire dans le cas où l'on connaît l'adresse de destination du serveur concerné puisque TOUTE autre adresse est bloquée. C'est déjà bien qu'il l'ait intégré pour le cas des serveurs "généraux" c'est à dire ceux dont on ne précise pas l'adresse IP destinataire par commodité à cause des changements fréquents.
 
Pour ce qui est des applis qui génèrent les adresses IP, effectivement je n'en connais pas qui s'interface avec Kerio 2.1.5, mais cela rentre dans le domaine très professionnel, et là je ne connais pas. Il ne faut pas oublier que cette version est juste une version à usage personnel..
 
Mais je vais le noter et le mettre dans les applis pratique  

>serveur et encore bravo à toi  

[Mode Dark_Vador=ON]
 
...ffhhhhhh.......Impressionnant!....ffhhhhhh
 
[Mode Dark_Vador=OFF]
 
 

Up,
 
et merci pour ce topic !

'lut,
 
Super TAF, merci

beau travail !
 
pourkoi le topic est pas dans la partie securité ?

Quelques questions:
 
-@Serveur: pourquoi fais-tu souvent deux règles distinctes, une en entrée et l'autre en sortie au lieu de faire un both?? Y a une raison?
 
- Perso j'ai pas vu l'utilité du loopback. Il y a quelque demandes parfois sur l'IP 127.0.0.1  mais il semble que les refuser ne cause pas de problème et n'empêche aucun fonctionnement.
 
- Et question de noobs: le DHCP n'est utilisé que sur un réseau local? Aucune FAI n'a de serveur DHCP pour distribuer ses IP?

 Van Lock.. c'est une erreur, je vais le mettre dedans..
 
@ramkin : C'est pas une obligation, j'utilise deux règles entrée-sortante dans certains cas comme pour les navigateurs, ou l'entrante n'est nécessaire que dans des cas particuliers.
Dans d'autres cas, c'est pour les logs et l'analyse dont je n'aurais besoin que sur les entrants et non les sortants ou pour faire des tests.. Dans d'autres cas (et surtout dans ces cas là), c'est parce que les ports entrée-sortie sont différents. Mais tu peux parfaitement dans les cas appropriés regrouper sous une seule règle..  en ce moment, je dois regarder un peu plus au niveau des transactions avec les serveurs DNS que je trouve être un facteur important dans la rapidité de surf (avec certains serveurs, le ralentissement est considérable).
Mes règles actuelles ralentissent pas mal l'affichage des pages, et je sais qu'une des raisons vient de ces transactions.. j'ai encore pas mal de tests a faire pour accèlerer ça..
oups .. je dois retourner au boulot , je continuerai plus tard.. Il y a encore beaucoup a mette à jour sur ce topic.. une partie sera faite ce week-end..

Ok. Il me semblait bien aussi. C'est vrai que dans un premier temps, il vaut mieux distinguer chaque connexion pour bien voir ce qui se passe.

Si vous n'avez ni réseau local, ni Wifi mais juste  votre ordi et une connexion ADSL comme moi et que vous ne faites pas de LAN, les règles peuvent se résumer à ça:
 

 
Et losque je veux savoir, je mets en Ask me first en décochant la dernière règle "Bloque tout, gars!"
 
DNS:
Pour le DNS 1 et le DNS 2, il faut, comme disait serveur récupérer la ou les IP serveur de votre FAI (en tappant ipconfig /all dans une console DOS)
Pour moi (tele2) les IPs sont donc:
130.244.127.161 et 212.151.136.254
Les règles DNS 3 et 4 me sont un peu obscures... J'ai juste noté que le services.exe voulait se connecter très souvent sur ces deux addresses et que refuser cette connexion entrainait parfois des problèmes de navigation. Donc je les ai rajoutées. Vu qu'elles ressemblent aux Ip serveurs de ma FAI (juste le dernier nombre qui change), je ne crois pas qu'il y ait danger, mais je ne sais pas pourquoi cette connection.    
 
Le loopback
Comme vous voyez il est désactivé. Je laisse cette règle pour l'instant en vue d'analyse plus précise. Pour l'instant je regarde et je refuse systématiquement. Ca n'empêche pas la navigation.
J'ai noté qu'en fait seul Firefox demandait une connexion sortante sur l'adresse 127.0.0.1 en TCP. Je sais pas pourquoi, je refuse, et ça navihue. A suivre.
 
Messagerie et navigateur
Confère serveur. Tout est bien expliqué.
 
Le DHCP
Ici aussi c'est désactivé. J'ai noté que seul le services.exe demandait une connexion sortante en UDP sur le port local 68 et le remote 255.255.255.255: [67]. (assez souvent quand même...) Donc je refuse (ça n'empêche pas la navigation) en attendant d'en savoir plus.
 
 

Pour une gestion fine des ports, j'ai trouvé une excellente page qui liste les ports ouverts par différents programmes :
http://www.practicallynetworked.co [...] t_list.htm
 
Au cas où elle disparaissait un jour, j'en fais un copier/coller ici :
 
Messaging & Conferencing
 
Active Worlds
(Watch Out! Opens a wide port range!)
IN      TCP     3000
IN      TCP     5670
IN      TCP     7777
IN      TCP     7000-7100
 
[0000]
Type=TCP
Translation=NORMAL
Port=5670
 
[0001]
Type=TCP
Translation=NORMAL
Port=7777
 
[0002]
Type=TCP
Translation=NORMAL
Port=7000-7100
 
[0003]
Type=TCP
Translation=NORMAL
Port=3000
 
AIM Talk
OUT     TCP   4099
IN      TCP     5190
 
Battlecom
(Watch Out! Opens a wide port range!)
IN      UDP  2300 - 2400
IN      TCP  2300 - 2400
IN      UDP  47624
IN      TCP  47624
 
Buddy Phone
(only communication. No FTP)
IN      UDP  700 - 701
 
Calista IP phone
OUT     TCP     5190
IN        UDP     3000
 
CuSeeMe
(Watch Out! Opens a wide port range!)
OUT   UDP   24032
IN       UDP    1414  [use H.323 protocol if available]
IN       UDP    1424 [use H.323 protocol if available]
IN       TCP     1503
IN       TCP     1720 [use H.323 protocol if available]
IN       UDP     1812   1813  
IN       TCP      7640
IN       TCP      7642
IN       UDP      7648
IN       TCP       7648
IN       TCP       7649 7649
IN       UDP       24032
IN       UDP       56800
OUT    UDP       1414 [use H.323 protocol if available]
OUT    UDP     1424 [use H.323 protocol if available]
OUT    TCP      1503
OUT    TCP      1720 [use H.323 protocol if available]
OUT    UDP     1812 1813
OUT    TCP      7640  
OUT    TCP      7642
OUT    UDP      7648
OUT    TCP      7648
OUT    TCP      7649
OUT    UDP      56800
 
Delta Three PC to Phone
(Watch Out! Opens a wide port range!)
IN       TCP 12053 [use CuSeeMe protocol if available]
IN       TCP 12083
IN       UDP 12080
IN       UDP 12120
IN       UDP 12122
IN       UDP  24150 - 24179
 
Dialpad
OUT     TCP     7175
IN         UDP     51200   51201
IN         TCP     51210
IN         TCP     1584    1585
OUT     TCP     8680    8686
 
Dwyco Video Conferencing
(Watch Out! Opens a wide port range!)
IN         UDP     12000 - 16090
IN         TCP     1024 - 5000
IN         TCP     6700 - 6702
IN         TCP     6880
 
Go2Call
IN         UDP     2090  2091
IN         TCP     2090
 
H.323 compliant video player,  
NetMeeting 2.0, 3.0, Intel Video Phone
(Watch Out! Opens a wide port range!)
(Incoming calls are not possible  
due to NetMeeting assigning ports dynamically.)
OUT     TCP     1720
IN      UDP     1024    65534 [use H.323 protocol if available]
OUT     UDP     1024    65534 [use H.323 protocol if available]
IN      TCP     1024    1502 [use H.323 protocol if available]
OUT     TCP     1024    1502 [use H.323 protocol if available]
IN      TCP     1504    1730 [use H.323 protocol if available]
OUT     TCP     1504    1730 [use H.323 protocol if available]
IN      TCP     1732    65534 [use H.323 protocol if available]
OUT     TCP     1732    65534 [use H.323 protocol if available]
OUT     TCP     1503    1503  
OUT     TCP     1731    1731  
IN      TCP     1503    1503  
IN      TCP     1731    1731
 
Hotline Server
IN         TCP   5500 - 5503  
IN         UDP  5499
The TCP Ports enabled are 5500 - 5503 (This is for the standard 5500
Hotline port)
 
If you change the default port, then you must enable the 3 ports after
it (so if you choose 4000 then you must enable 4000 - 4003)
 
The UDP port enabled 5499 is required only if you want to list your
server on a tracker (the data stream is only outgoing so if you want to
disable in bound on a firewall it would work fine)
 
ICQ
In ICQ under "Preferences & security", "Preferences" and Connections, click on "I am behind a firewall or proxy" then click on "Firewall Settings". Then select "I don't have a SOCKS Proxy server on my firewall" or "I am using another Proxy server". Click Next.  Click "Use the following TCP listen ports for incoming event" and set the TCP ports for 20000 to 20019 for the first user, 20020 to 20039 for the second user,  20040 to 20059 for the third user, etc.
 
OUT   UDP     4000
IN    TCP     20000   20019 for one user
OR
IN    TCP     20000   20039 for two users
OR
IN    TCP     20000   20059 for three users, etc.
 
ICUII Client
(Watch Out! Opens a wide port range!)
OUT     TCP     2019
IN      TCP     2000 2038
IN      TCP     2050 2051
IN      TCP     2069
IN      TCP     2085
IN      TCP     3010 3030
OUT     TCP     2000 2038
OUT     TCP     2050 2051
OUT     TCP     2069
OUT     TCP     2085
OUT     TCP     3010 3030
 
ICUII Client (Version 4.xx)
(Watch Out! Opens a wide port range!)
IN      TCP     1024 - 5000
IN      TCP     2000 - 2038
IN      TCP     2050 - 2051
IN      TCP     2069
IN      TCP     2085
IN      TCP     3010 - 3030
IN      TCP     6700 - 6702
IN      TCP     6880
IN      UDP   12000 - 16090
 
Internet Phone
OUT     UDP     22555
 
Ivisit
IN  UDP     9943
IN  UDP     56768
 
LIVvE
(For pager file send only)
IN  UDP     8999
 
mIRC DCC / IRC DCC
[mIRC Proxy/Firewall Help page]
(Watch Out! Opens a wide port range!)
IN  TCP     1024 - 5000
 
mIRC Chat
(The IRC port is usually 6667)
IN  TCP     6660 - 6669
 
mIRC IDENT
IN      UDP 113
 
MSN Messenger
(Watch Out! Opens a wide port range!)
NOTE: Shut off any personal firewall programs such as BlackIce, ZoneAlarm, etc.  
Ports 6891-6900 enable File send,  
Port 6901 is for voice communications
Allows Voice, PC to Phone, Messages, and Full File transfer capabilities.
Thnx to Brad King & Bill Finch Jr.
IN         TCP     6891 - 6900
IN         TCP     1863
IN         UDP    1863
IN         UDP    5190
IN         UDP    6901
IN         TCP    6901
 
Net2Phone  
OUT     UDP     6801
IN        UDP  6801
One additional UDP and one TCP port in the range of 1 to 30000
must be mapped.  Ports 6802 and 6803 are suggested.  These  
ports must be mapped in your firewall, then set in the Net2Phone client
as follows:
     1) Click on Net2Phone's "Menu" button.
     2) Select "Preferences".
     3) Click on the "Network" tab.
     4) Enter 6802 for the Client TCP Port.
     5) Enter 6803 for the Client UDP Port.
 
Pal Talk [support page]
(Watch Out! Opens a wide port range!)
IN       UDP 2090 [voice]
IN       UDP 2091 [control stream]
IN       TCP 2090  [file transfer]
IN       TCP 2091  [video listening]
IN       TCP 2095   [file transfer- older versions]
OUT   TCP 5001 - 50015 [text messaging]
OUT   TCP 8200 - 8700 [Firewall / network mode group voice]
OUT   UDP 8200 - 8700 [Firewall / network mode group voice]
OUT   UDP 1025 - 2500 [outbound voice & control stream (user configurable)]
 
The last 2 UDP outbound ports are usually set in pairs. 1024 - 1025, 1026 - 1027, etc... Most users never have to set these lower two ports. They are dynamically assigned if you leave the lower two boxes set to 0's on the 'paltalk port settings' tab.  
Outbound ports are usually not an issue but are listed here for network users who may need to manually configure for a proxy or NAT server or other hardware device.
 
PhoneFree
(Watch Out! Opens a wide port range!)
IN         UDP     1034 - 1035
IN         UDP     9900 - 9901
IN         TCP     1034 - 1035
IN         TCP     2644
IN         TCP     8000
This Mapping is needed to hear the audio from the incoming party, outgoing audio would work without it.  
** According to phonefree the ports you need open are:
   8000 TCP For Server access
   1034 UDP Voice in/out
   1035 TCP Voice in/out
   2644 TCP Personal Communication Center
I found that port range 9900-9901 UDP is also needed but not mentioned at phonefree support.
Also shut off any other firewall programs you may have running.  
 
To make PC-TO-PHONE calls, it seems only UDP port 9900 must be opened (the fewer ports open, the better!).  
 
Polycom ViaVideo H.323
IN         TCP     3230 - 3235
IN         UDP     3230 - 3235
NOTE: I needed to set these ports to dial out.
Also enable on ViaVideo (under H.323 QoS) 'Use Fixed Ports' 3230-3235 TCP & UDP
 
Roger Wilco [support page]
IN         TCP  3782
IN         UDP  3782
IN         UDP  3783  [only needed for RW Base station]
 
Speak Freely
IN         UDP     2074 - 2076
 
Yahoo Messenger Chat
IN         TCP     5000 - 5001
 
Yahoo Messenger Phone
IN         UDP     5055
 
 
Audio & Video
 
Audiogalaxy Satellite [updated 12/13/00]
(Watch Out! Opens a wide port range!)
IN      TCP     41000 - 50000
IN      TCP     1117-5190
 
Camerades
IN      TCP     2047 2048
IN      UDP     2047 2048
 
GNUtella
IN      TCP     6346
IN      UDP     6346
 
IStreamVideo2HP
IN      TCP     8076 - 8077
IN      UDP     8076 - 8077
 
KaZaA
IN      TCP     1214
 
Napster
OUT     TCP     6699
IN      TCP     6699
 
QuickTime 4 Server
IN    TCP     6970
IN    UDP     6970  -  7000
 
QuickTime 4 Client & RealAudio on Port 554
(Watch Out! Opens a wide port range!)
OUT     TCP     554
IN      UDP     6970  -  32000
 
RealAudio on Port 7070
OUT     TCP     7070
IN      UDP     6970  -  7170
 
ShoutCast Server
IN      TCP     8000 - 8005
Games
 
Games
 
Aliens vs. Predator
(Watch Out! Opens a wide port range!)
IN    UDP  80
IN    UDP  2300 - 2400
IN    UDP  8000 - 8999
 
Anarchy Online (BETA)
IN    TCP 7013
IN    TCP 7500 - 7501
IN    UDP 7013
IN    UDP 7500 - 7501
 
Asheron's Call [support page] [mapping info]
OUT    UDP  9000, 9004, 9008, 9012
IN    UDP  9000, 9001, 9004, 9005, 9012, 9013
NOTE! You may also need to open the MSN Game Zone and DX ports  
 
Black and White
IN    TCP     2611 - 2612
IN    TCP     6667
IN    UDP    6500
IN    UDP    27900
 
Blizzard Battlenet
This allows for -1- machine on the network to take advantage of Blizzard's BattleNet system for playing online games such as Diablo II and StarCraft. The 6112 port is needed in both TCP and UDP for StarCraft and Diablo II, and the 4000 port is needed for Diablo II. No other settings should be needed.
IN    TCP     4000
IN    TCP     6112
IN    UDP    6112
 
Bungie.net, Myth, Myth II Server
IN    TCP     3453
 
Dark Reign 2
IN    TCP     26214
IN    UDP     26214
 
Delta Force (Client and Server)
OUT     UDP     3568
IN      TCP     3100    3999
OUT     TCP     3100    3999
IN      UDP     3100    3999
OUT     UDP     3100    3999
 
Delta Force 2
IN      UDP  3568
IN      UDP  3569
 
Elite Force
IN    UDP     26000
IN    UDP     27500
IN    UDP     27910
IN    UDP     27960
NOTE: If the server is behind the same router/firewall as other clients, then all of the clients will have to add "+set net_port 27961," "27962," etc. to their shortcut command lines.  Otherwise, they will not be able to use the in-game internet game browser. This is due to the fact that EF uses the same port (27960) for both the client and the server.
 
Everquest
(Watch Out! Opens a wide port range!)
See this Everquest page for more info
IN   TCP   1024  7000
IN   UDP  1024  6000
Note: May have to open this last UDP range even wider
 
F-16, Mig 29
IN    UDP    3862
IN    UDP    3863
 
F-22 Lightning 3
(Watch Out! Opens a wide port range!)
IN    UDP     3875
IN    UDP     4533
IN    UDP     4534
IN    UDP     4660 - 4670 (for VON)
 
F-22 Raptor
IN    UDP    3874, 3875
 
Fighter Ace II
(Watch Out! Opens a wide port range!)
IN    TCP     50000 - 50100
IN    UDP    50000 - 50100
 
for DX play also open these ports:
IN    TCP     47624
IN    TCP     2300 - 2400
IN    UDP     2300 - 2400
 
Half Life
IN    UDP  6003
IN    UDP  7002
IN    UDP  27010
IN    UDP  27015
IN    UDP  27025
 
Half Life Server
IN    UDP  27015
 
Heretic II Server
IN    TCP     28910
 
Hexen II
Each computer hosting Hexen II must use a different port number, starting at 26900 and incrementing by 1.
 
IN    UDP     26900 (for first player)
 
KALI
Each computer using KALI must use a different port number, starting at 2213 and incrementing by 1.
 
IN    UDP     2213 (for first player)
IN    UDP     6666
 
Kohan Immortal Sovereigns
This allows you to host a Kohan game and have it show
up on Gamespy, otherwise no one will be able to see your
game outside of your lan. Only the ICS server can host  
games and have them show up however.
IN    UDP     3855
IN    UDP     17437
IN    TCP      3855
IN    TCP      17437
 
Motorhead server
IN    UDP     16000
IN    TCP      16000
IN    TCP      16010 - 16030
IN    UDP     16010 - 16030
 
The ports 16010-16030 are ports I specified in the MotorHead dedicated server client ports section. You need to specify client ports so that Motorhead does not assign client ports randomly.
 
MSN Game Zone [support page] [DX support page]
(Watch Out! Opens a wide port range!)
IN    TCP     6667
IN    TCP     28800 - 29000
 
for DX play also open these ports:
IN    TCP     47624
IN    TCP     2300 - 2400
IN    UDP     2300 - 2400
 
Need for Speed - Porche
IN    UDP     9442
 
Need for Speed 3- Hot Pursuit
IN    TCP  1030
 
Operation FlashPoint
 
TCP 47624 ~ 47624
TCP 2234 ~ 2234
BOTH 6073 ~ 6073
 
Outlaws
IN    UDP     5310
IN    TCP      5310
 
Quake2  (Client and Server)
IN    UDP     27910
 
QuakeIII  
Each computer playing QuakeIII must use a different port number, starting at 27660 and incrementing by 1. You'll also need to do the following:
 
1. Right click on the QIII icon  
2. Choose "Properties"  
3. In the Target field you'll see a line like "C:\Program Files\Quake III Arena\quake3.exe"  
4. Add the Quake III net_port command to specify a unique communication port for each system. The complete field should look like this: "C:\Program Files\Quake III Arena\quake3.exe" +set net_port 27660  
5. Click OK.  
6. Repeat for each system behind the NAT, adding one to the net_port selected (27660,27661,27662)
 
IN    UDP     27660  (for first player)
 
Rainbow Six (Client and Server)
OUT     TCP     2346
IN      TCP     2346
 
Rogue Spear
OUT     TCP     2346
IN      TCP     2346
 
Soldier of Fortune
IN   UDP   28910 - 28915
 
Starcraft
IN   UDP   6112
 
Starfleet Command
(Watch Out! Opens a wide port range!)
IN   TCP  2300 - 2400
IN   TCP  47624
IN   UDP 2300 - 2400
IN   UDP 47624
 
SWAT3
IN   TCP 16639
IN   UDP 16638
 
Ultima
IN   TCP   5001-5010 Game
IN   TCP   7775-7777 Login  
IN   TCP   8888 Patch  
IN   TCP   8800-8900 UO Messenger  
IN   TCP   9999 Patch
IN   TCP   7875 UOMonitor
 
Port 7875 is not used by the game, but by UOMonitor, which many players use to monitor server status.
 
Unreal  Tournament server
IN    UDP 7777 (default gameplay port)
IN    UDP 7778 (server query port
IN    UDP 7779+ (UDP 7779+ are allocated dynamically for each
                        helper UdpLink objects, including UdpServerUplin
                        objects. Try starting with 7779-7781 and add
                        ports if needed.))
IN    UDP 27900 (server query, if master server uplink is enabled.
                         Some master servers use other ports, like 27500)
IN    TCP 8080  
(Port 8080 is for UT Server Admin. In the [UWeb.WebServer] section of the server.ini file, set the ListenPort to 8080 (to match the mapped port above) and ServerName to the IP assigned to the router from your ISP.)
 
Westwood Online - C&C Tiberian Sun & Dune 2000
Note: Westwood Online supports only one user per public IP address at any given time. Apprule courtesy of Quantus' World
OUT     TCP     4000
IN      TCP     4000
IN      UDP     1140    1234
IN      TCP     1140    1234
OUT     UDP     1140    1234
OUT     TCP     1140    1234  
 
ZNES
IN    UDP  7845 [Use Quake Translation if you can set it]
Common Servers
 
Services
 
FTP Server on your LAN
IN    TCP     21  
 
POP3 Mail Server on your LAN
IN    TCP     110  
 
SMTP Mail server" on your LAN
IN    TCP     25
 
TELNET Server on your LAN
IN    TCP     23  
 
WEB Server on your LAN
IN    TCP     80
 
Other
BAYVPN
OUT     UDP     500
 
CITRIX Metaframe / ICA client
(Watch Out! Opens a wide port range!)
IN     TCP   1494
IN     UDP  1604
IN     TCP   1023 - 5000 (NOTE: Depending on the number of clients/sessions, you can try decreasing this range, or you may need to increase it.)
 
CarbonCopy32  host on your LAN
(Watch Out! Opens a wide port range!)
IN    TCP     1680
IN    UDP     1023-1679
 
Deerfield MDaemon Email Server
IN    TCP     3000
IN    TCP     3001
 
Direct Connect
(Watch Out! Opens a wide port range!)
IN  TCP 375 - 425
 
FW1VPN
OUT     UDP     259
 
Laplink Host
IN    TCP     1547
 
Lotus Notes Server
IN    TCP     1352
 
NTP (Network Time Protocol)
OUT     UDP     123
IN      UDP     123  
 
pcANYHWERE host on your LAN
IN    TCP     5631
IN    UDP     5632
 
RAdmin (Fama Tech)
IN    TCP     4899
 
Remote Anything
FAQ page
IN    TCP      3999 - 4000
IN    UDP     3996 - 3998
 
Remotely AnyWhere
IN    TCP      2000
 
Remotely Possible Server
IN    TCP      799
 
Shiva VPN
(set the mobile option in the Shiva VPN client software to be your public IP address)
OUT   UDP     2233
IN    UDP     2233
 
Timbuktu Pro
IN    TCP      407
IN    TCP 1417 - 1420
IN    UDP   407
IN    UDP  1417 - 1420
 
Virtual Network Computing (VNC)
IN    TCP     5500
IN    TCP     5800
IN    TCP     5900
 
Windows 2000 Terminal Server
(probably also works for NT Terminal services)
IN    TCP      3389
IN    UDP     3389[b][/b]

c'est une manie de polluer les topics (Thunderbird et ici)

   
C'est pas de la pollution, ça concerne directement la création des règles sous Kerio.

il y a des tonnes de sites où les ports sont listés, pas la peine de faire une liste monstrueuse et illisible sur ce topic, surtout sans demander aux auteurs

Ah, ben ça serait pas mal de les indiquer, parce qu'ils ne sont pas faciles à trouver.

de plus c'est si difficile que ça de mettre Kerio en "Ask me first" pour configurer un logiciel ou un jeu ?

par exemple http://keir.net/portlist.html a l'air costaud
 
edit : et ça http://www.iana.org/assignments/port-numbers

même MS a fait un petit truc là-dessus  
 
http://support.microsoft.com/default.aspx?kbid=842242
 
ou alors http://kbserver.netgear.com/kb_web_files/n100495.asp
 
mais je répète qu'il suffit de se mettre en mode apprentissage et hop tout roule

Oui mais non, il ouvre le port nécessaire pour l'appli à un instant donné, mais ce n'est pas très précis. C'est quand même mieux de lui indiquer exactement ce dont l'appli a besoin.