Il est vrai qu'il y des ports et des services qui se retrouvent généralement et dont le paramétrage peut tirer une généralité.
Je suis en train de travailler dessus pour faire un TUT sur la sécurité sur Kerio, mais j'ai pas fini, - parce que je teste mes différents paramétrages sur des réseaux wifi (comme météor) et dont quelquefois j'ai la surprise de voir qu'il faut ouvrir d'autres ports que le 53 pour naviguer avec les DNS, ou sinon j'ai droit à une lenteur d'escargot, et d'autres trucs comme ça.. -
alors je fais un copier/ coller des choses en l'état.. me tapez pas dessus trop fort 
PS, le principe s'appliquera pour les règles aussi à Sygate.. Comme je dois paramétrer bientôt un serveur avec sygate, jej'essairai de faire un tut du même genre..
***********
Introduction
J'ai récupéré et glané des informations à droite et à gauche sur différent forums. Ce tut est donc un résumé - Merci à ..Drachs..-
L'esprit de sécurité
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 ce qui est absolument nécessaire à bloquer dans tous les cas de figure, puis autoriser 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'esprit de sécurité à garder en mémoire.
La version 2.1.5
Pourquoi cette version:xxxxxxx liensxxxxxxxxx
Il n'y a plus de support pour cette version.
Les 2 failles du logiciel à corriger avant toute choses. Je fais un Copier coller d'un post qui résume bien -merci à celui qui l'a posté -
En attendant il y a deux failles de sécurité critiques qui ont été découvertes dans Kerio 2.1.5 et qui sont assez génantes, elles permettent à n'importe qui d'exécuter des commandes en tant qu'utilisateur SYSTEM (le seul à avoir plus de privilèges que l'administrateur local). Heureusement, elles ne tiennent pas au moteur du firewall, c'est l'essentiel. Ce sont des exploits locaux essentiellement, sauf si pour la première l'admin à distance est activée (je pense).
EXPLOIT 1 : La première tient à la façon dont Kerio charge les jeux de règles. Suffit d'aller dans l'interface d'administration, de cliquer sur le bouton "Load...", d'aller dans System32, de repérer "cmd.exe", de cliquer droit sur le fichier et de choisir "Ouvrir" dans le menu contextuel et non pas "Sélectionner". Oh, la console en ligne de commande s'ouvre. Un rapide whoami confirme que c'est NT AUTHORITY\SYSTEM qui exécute l'interpréteur.
REMEDE : protéger le module d'administration par un mot de passe connu du seul admin suffit, ce qui est de toutes manière l'attitude recommandée. Si l'administrateur ne protège pas son jeu de règles par un mot de passe, il n'a de toutes façons que ce qu'il mérite.
EXPLOIT 2 : La seconde est beaucoup plus grave et tient d'une part à la conception des fichiers d'aide HTML compilé (CHM) par Microsoft, l'autre au fait que l'icone dans la barre des tâches s'exécute aussi en tant que SYSTEM (puisqu'elle est rattachée au service du firewall). Ici, pas moyen de sécuriser quoi que ce soit par un mot de passe. Suffit de cliquer droit sur le bouclier, d'ouvrir l'aide en ligne (Help), puis de cliquer sur l'icône en haut à gauche en forme de point d'interrogation, de sélectionner "Aller à l'URL..." et de choisir le répertoire System32 comme destination (C: \WINDOWS\SYSTEM32 par exemple). Le contenu du dossier s'affiche dans la fenêtre de l'aide en ligne, suffit de trouver cmd.exe, et c'est parti comme vu plus haut.
REMEDE : renommer le fichier d'aide afin qu'il ne soit plus possible d'y accéder par ce biais.
EDIT : 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.
Les règles
C'est une possibilité de classement, mais je range les règles par catégorie
1. Les Catégories
Loopback
Pas nécessaire avec KPF, mais sur de nombreuses configurations, cette règle accélère les échanges.
Cette règle autorise les applications locales avec l'ordinateur sur le port 127.0.0.1.
Cette adresse est reliée au nom "localhost" qui désigne la machine locale, via un fichier de configuration dans le répertoire system32.
PRO
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
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 possible d'améliorer cette règle en plaçant un masque réseau 255.0.0.0 qui limiterait plus le risque puisqu'il n'y a pas de subnet spoofing (a prendre avec des pincettes, j'attends que des pro du réseaux confirment ou infirment.)
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:
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.
Je fais un copier/coller d'un post décrivant ces ports:
NETBIOS Name Service (NS port 137) : resolution de noms netbios = correspondance entre les noms d'hotes sur le reseau et les adresses IP
NETBIOS Datagram Service (DG port UDP 138) : ce port est essentiellement utilisé pour diffuser (broadcast) de l'information sur le réseau. En principe, seul le protocole UDP est utilisé sur ce port. Fonctionne en mode déconnecté.
NETBIOS Session Service (SS port TCP 139): c'est sur ce port que s'établissent les véritables connexions entre deux machines. C'est par exemple celui qui sera utilisé, lorsque tu veux accèder à une machine par le voisinage réseau, pour accéder à ses ressources (partages de fichiers et d'imprimantes).
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..
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 et 11, dans les 2 sens.
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
PRO
Rentrer 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
DNS
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.
PRO
Les pro rentrent les adresses IP des DNS bien sûr , ainsi que celui des « secours ».
LES APPLICATIONS
Navigateur, messagerie, FTP.. chacun utilisera un port spécifique. Si vous utilisez une appli pour la première fois, changez le cran en « me demander » et regardez sur quels ports l'appli tente de se connecter.
PRO utiliser la signature MD5 qui est une protection supplémentaire pour assurer l'authenticité sur les paquets de retour..
Conclusion
En théorie, on ne devrait rentrer que des règles pour les applications utilisées, puisque le reste est bloqué..
Mais en pratique, on s'aperçoit que de nombreux logiciels ont des failles : un exemple classique sont les active X de IE. Si vous en installez un , alors vous autorisez une porte ouverte pour qu'une application du serveur puisse s'exécuter sur votre navigateur (et donc votre ordinateur si celle-ci est maligne). C'est un peu comme un trojan (troyen), si vous en attrapez un par un mail, votre paramétrage ne servira à rien sauf si vous bloquez des ports sensibles ou utilisé par ce troyen AVANT toutes applications communicantes.
C'est pour çà qu'il faut un certain nombre de règle en plus et AVANT les applications communicantes..
*************
Message édité par serveur le 17-09-2004 à 16:46:40
![[:xice007]](https://forum-images.hardware.fr/images/perso/xice007.gif "[:xice007]")
