5.1 Points de rendez-vous dans Tor

Les étapes suivantes sont réalisées au nom d'Alice et de Bob par leurs OP locaux ; l'intégration des applications est décrite plus en détail ci-dessous.

• Bob génère une paire de clés publiques à long terme pour identifier son service.
• Bob choisit quelques points d'introduction et les annonce sur le service de recherche, en signant l'annonce avec sa clé publique. Il peut en ajouter d'autres ultérieurement.
• Bob construit un circuit vers chacun de ses points d'introduction et leur demande d'attendre les demandes.
• Alice apprend l'existence du service de Bob par la bande (peut-être que Bob le lui a dit, ou qu'elle l'a trouvé sur un site web). Elle récupère les détails du service de Bob auprès du service de recherche. Si Alice souhaite accéder au service de Bob de manière anonyme, elle doit se connecter au service de recherche via Tor.
• Alice choisit un OU comme point de rendez-vous (PR) pour sa connexion au service de Bob. Elle construit un circuit vers le point de rendez-vous et lui donne un "cookie de rendez-vous" choisi au hasard pour reconnaître Bob.
• Alice ouvre un flux anonyme vers l'un des points d'introduction de Bob et lui transmet un message (chiffré à l'aide de la clé publique de Bob) dans lequel elle se présente, indique son RP et son cookie de rendez-vous, ainsi que le début d'une poignée de main DH. Le point d'introduction envoie le message à Bob.
• Si Bob veut parler à Alice, il établit un circuit vers le RP d'Alice et envoie le cookie de rendez-vous, la seconde moitié de la poignée de main DH et un hachage de la clé de session qu'ils partagent désormais. Selon le même raisonnement que dans la section 4.2, Alice sait qu'elle ne partage la clé qu'avec Bob.
• Le RP relie le circuit d'Alice à celui de Bob. Notez que le RP ne peut reconnaître ni Alice, ni Bob, ni les données qu'ils transmettent.
• Alice envoie une cellule relais begin le long du circuit. Elle arrive au PO de Bob, qui se connecte au serveur web de Bob.
• Un flux anonyme a été établi et Alice et Bob communiquent normalement.

Lors de l'établissement d'un point d'introduction, Bob fournit au routeur en oignon la clé publique identifiant son service. Bob signe ses messages, de sorte que d'autres ne puissent pas usurper son point d'introduction à l'avenir. Il utilise la même clé publique pour établir les autres points d'introduction de son service et actualise périodiquement son entrée dans le service de recherche.
Le message qu'Alice transmet au point d'introduction comprend un hachage de la clé publique de Bob et un jeton d'autorisation initial facultatif (le point d'introduction peut effectuer une présélection, par exemple pour bloquer les rediffusions). Le message qu'elle envoie à Bob peut inclure un jeton d'autorisation de bout en bout afin que Bob puisse choisir de répondre ou non. Les jetons d'autorisation peuvent être utilisés pour fournir un accès sélectif : les utilisateurs importants peuvent bénéficier d'un accès ininterrompu. Dans des situations normales, le service de Bob peut simplement être offert directement par les miroirs, tandis que Bob distribue des jetons aux utilisateurs prioritaires. Si les miroirs sont détruits, ces utilisateurs peuvent accéder au service de Bob via le système de rendez-vous Tor.

Les points d'introduction de Bob sont eux-mêmes sujets à des attaques par déni de service - il doit ouvrir de nombreux points d'introduction pour ne pas risquer une telle attaque. Il peut fournir à des utilisateurs sélectionnés une liste actuelle ou un calendrier futur des points d'introduction non annoncés ; cette solution est plus pratique s'il existe un groupe stable et important de points d'introduction. Bob peut également fournir des clés publiques secrètes pour la consultation du service de recherche. Toutes ces approches limitent l'exposition, même lorsque certains utilisateurs sélectionnés sont de connivence avec le service de recherche.

Le service d’informations sur le réseau vous permet de vous informer gratuitement sur le lieu et le type de pose de câbles de Swisscom. Ce service est mis à disposition principalement pour les entreprises de construction, les services publics, les bureaux d’architecture et bureaux d’ingénieurs, mais peut également être utile pour les personnes privées. Afin d’éviter l’endommagement de conduites, la demande d'un plan de notre réseau pour un projet de construction est donc indispensable.

En saisissant des critères de recherche comme des adresses, des coordonnées ou des parcelles, vous trouvez les informations utiles du réseau dans la zone sélectionnée. Celles-ci peuvent en outre être générées et imprimées au format PDF ou DXF.

tuto ajour de règles de firewall

Interfaces

Le USG/ATP dispose de port physique rj45. Ils sont associé à un VLAN et à un sous réseau.

Configuration > Network > Interface  => onglet port | onglet Ethernet 

Je peux associer les ports (ex: LAN1, WAN1 et DMZ) à des IP, ou des range d'ip ou des écoute DHCP.

Zones

La zone est un conteneur d'interfaces.
Ça peut être pratique de regrouper plusieurs interface sous la même dénomination pour appliquer d'un coup la même politique.

Par exemple la zone "WAN" regroupe les interfaces: "wan1, wan2, wan1_ppp"

Objets

Les objets sont des "alias" de nom de port et/ou protocoles. C'est une manière simplifiée plus explicite de désigner un groupe d'adresse ou un groupe de protocole.

Il y a déjà des objets créé pour désigner des protocoles courants. (ça évite de connaitre par coeur le numéro du port) On les trouve ici:

Configuration > Object > Service

On a par exemple: "HTTPS" => "TCP=443"

Politiques de sécurité / Règles Firewall

Il est temps d'ajouter des règles. C'est ici:

Configuration > Security Policy > Policy Control

Il y a déjà des règles par défaut.

La liste des règles se lit de haut en bas. C'est ainsi qu'elle sont traitée.

WAN = Wide Area Network => l'extérieur
LAN = Local Area Network => l'intérieur, mon réseau local
DMZ = Zone Démilitarisée => ma zone "interne" de service qui doivent être visible de l'extérieur: web, mail, etc..

Les colonnes:

• Priorité : Ordre de la règle Firewall - les règles de pare-feu s'exécutent de haut en bas, dans cet ordre spécifique
• Statut : indique si la règle est active - le jaune est allumé, le gris est éteint
• Nom : Nom de la règle de pare-feu
• De : Désigne la zone d'où provient le trafic
• Vers : fait référence à la zone vers laquelle le trafic sera acheminé
• Source IPv4 : fait référence à un objet d'adresse, facilite l'ajustement des règles de pare-feu à des sources IPv4 spécifiques
• Destination IPv4 : fait référence à un objet d'adresse, facilite l'ajustement des règles de pare-feu à des destinations IPv4 spécifiques
• Service : fait référence à un objet de service, permet de créer une règle qui ne s'applique qu'à un seul port/protocole ou à un groupe de ports/protocoles
• Utilisateur : permet d'affiner la règle de pare-feu pour qu'elle ne s'applique qu'aux objets/groupes d'utilisateurs
• Calendrier : Cela permet de configurer le pare-feu pour qu'il ne devienne actif que pendant un horaire spécifique (utile pour le contrôle parental, les applications scolaires, etc.)
• Action : définit si le trafic correspondant à tous les paramètres ci-dessus est autorisé à passer ou est refusé
• Journal : ici, vous pouvez définir si vous souhaitez une entrée de journal au cas où le trafic correspondant passerait par le pare-feu
• Profil : dans ce segment, vous pouvez ajouter des services UTM et leurs profils respectifs (par exemple, des profils de filtrage de contenu, etc.)

Ajouter une règle

+add

Donner un nom, une description.
Configurer: de, à .... avec les objets déjà là ou "creer un nouvel objet" (peu visible, mais possible)

Définir l'action:

• deny => ignore silencieusement la demande
• reject => renvoie les raisons du rejet.

On utilise généralement un "deny" (block) pour ne pas donner d'info à un pirate.

Il est possible d'activer des log:

Monitor > Log