Un profil de configuration du pare-feu est composé d'une ou plusieurs règles dont chacune reprend les principes de configuration d'un service personnalisé du pare-feu de Kwartz.
Vous pouvez alors ajouter (bouton Ajouter), modifier ou supprimer (après avoir sélectionné la ou les règles concernées) vos règles.
Les règles vous permettent d'autoriser ou interdire certains trafics depuis ou vers l'extérieur du serveur Kwartz.
Les règles définies dans un profil sont prioritaires à toutes les règles de pare-feu définies dans KWARTZ~Control. Ainsi il vous est possible de créer une règle d'interdiction qui ne pourra pas être outrepassée par l'administrateur du serveur Kwartz.
Dans l'exemple ci-dessus, l'extranet Kwartz (port 8080 en entrée) sera toujours bloqué indépendamment de sa configuration sur le serveur lui-même.
Les règles sont ordonnées selon leur nom et appliquées dans cet ordre. Ainsi, toujours dans notre exemple, l'extranet sera également fermé pour l'adresse 109.190.128.65 contrairement à ce qui est paramétré par la deuxième règle.
Dans la configuration des règles d'un profil pare-feu vous pouvez définir:
Un service en entrée est fourni par le serveur KWARTZ. S'il est ouvert, il peut être accédé depuis internet en utilisant l'adresse IP publique de votre connexion. Par exemple, KWARTZ~Control est ouvert par défaut en entrée, ce qui permet d'administrer votre serveur à distance.
Un service en sortie est fourni par l'extérieur. Ils peuvent être ouverts pour le serveur ou pour les postes du réseau. S'il est fermé, le pare-feu interdit d'y accéder.
Afin de limiter les risques d'attaque, il est conseillé de limiter le nombre des services ouverts en entrée. Pour cela, les règles des profils pare-feu de la Konsole permettent de bloquer les services, empêchant l'administrateur local d'ouvrir des ports critiques ou sensibles. Notez toutefois que, par défaut, la quasi totalité des ports ne sont pas ouverts sur un serveur Kwartz.
Dans la définition des règles, il peut être nécessaire d'entrer une adresse. Selon le champ d'application (adresse interne ou externe), vous avez les possibilités suivantes:
Cela permet de construire des règles génériques applicables sur plusieurs serveurs dont les interfaces réseau n'ont pas la même adresse, pour peu que les plans d'adressage soient cohérents.
Par exemple, dans le cas d'un vlan ayant pour id 14 et pour adresse 10.11.14.0/24 sur un serveur 1 et 10.22.14.0/24 sur un serveur 2, la syntaxe ${eth0.14}0.0.0.250 sera résolue en 10.11.14.250 sur le serveur 1 et 10.22.14.250 sur le serveur 2
Vous avez la possibilité de définir la façon dans les règles vont être appliquées:
La définition des adresses est décrite ci-dessus.
De plus, pour chaque cas, vous pouvez: