Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Requete entre deux machines sur le même sous réseau

    Scheduled Pinned Locked Moved Français
    4 Posts 2 Posters 1.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      hielleelle
      last edited by

      Bonjour à tous,

      je viens vers vous pour vous poser une question, le portail captif de pfsense fonctionne très bien mais je me demandai quelque chose.

      Prenons un cas simple avec une architecture comme celle-ci : INTERNET -> PORTAIL CAPTIF PFSENSE -> SWITCH -> RESEAU LAN

      Actuellement, dans le cas où le portail captif est activé ainsi que le dhcp, un utilisateur qui se connecte au réseau LAN va donc recevoir une adresse IP délivré par le DHCP de pfSense.
      Quand celui-ci va s'authentifier, il aura donc accès à Internet. Jusque là, pas de problèmes…
      La seule chose qui me gêne c'est le cas ou un utilisateur se connecte, obtient son adresse IP mais ne s'authentifie pas. J'ai vu que même sans s'authentifier, rien n'empêche de pinger d'autre machine du réseau ou de faire du ssh dessus.
      Donc en gros, si je me connecte sur le LAN et que je prends le contrôle à distance d'une autre machine qui elle, est déjà connecté, je vais donc pouvoir surfer sans problèmes...

      Y a t-il un moyen de bloquer toutes les requêtes vers d'autres machines du même sous-réseau, du moment que l'on est pas authentifié ?
      Je pense que dans ce cas, les règles du pare-feu ne suffisent pas vu que les deux machines se trouvent dans le même réseau...

      Merci d'avance.

      1 Reply Last reply Reply Quote 0
      • C
        ccnet
        last edited by

        Je pense que dans ce cas, les règles du pare-feu ne suffisent pas vu que les deux machines se trouvent dans le même réseau…

        Absolument puisque le trafic ne transite pas par le firewall mais est échangé directement entre les deux machines.

        Y a t-il un moyen de bloquer toutes les requêtes vers d'autres machines du même sous-réseau, du moment que l'on est pas authentifié ?

        Je pense que c'est un problème mal posé. Soit on considère que les machines qui ne doivent pas être accédées sont configurées pour ne pas l'être ou via une authentification gérée sur la machine cible, ou bien on considère que sans authentification pas d'accès au réseau. Ceci étant entendu que l'on parle d’accès réseau au niveau liaison de données. Le problème est mal posé parce que dans le premier cas on est sur une question d'authentification habilitation d'une personne et dans le second sur un problème d'authentification d'une machine pour lui donner accès au réseau. Les solutions sont différentes selon le cas.

        1 Reply Last reply Reply Quote 0
        • H
          hielleelle
          last edited by

          Tout d'abord, merci pour la réponse rapide.

          Moi ce que je souhaite c'est vraiment que tant que l'on est pas authentifié, on ne puisse accéder à aucun accès/protocole, et je pense que dans le cadre de pfSense c'est impossible à faire car comme tu dis, le ping ou le ssh passera directement par le switch et ne passe pas par pfSense.
          Les machines qui vont se connecter à ce réseau seront des machines de visiteurs, donc sur lequel on a pas la main…

          1 Reply Last reply Reply Quote 0
          • C
            ccnet
            last edited by

            Sur des machines d'entreprises la solution s'appelle Netword Access Control (802.1x).
            Sur des machines non maitrisée vous n'avez aucune autre solution, partielle, que de les isoler dans un réseau spécifique. Et plus qu'à segmenter votre réseau et affiner votre filtrage.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.