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

    DUPLIQUER TRAFFIC SUR UNE 3EME INTERFACE

    Scheduled Pinned Locked Moved Français
    13 Posts 3 Posters 1.1k 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.
    • C
      ccnet
      last edited by

      Sur le plan fonctionnel quel est l'objectif ? Quel intérêt y  t il a dupliquer ce trafic ?

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

        @ccnet:

        Quel intérêt y  t il a dupliquer ce trafic ?

        Snort et autres NIDS  ;)

        Mais c'est quelque chose qu'on fait généralement avec des switchs. Pas sûr que le FW soit le meilleur endroit pour le faire. de plus, dupliquer à la fois du WAN et du LAN vers la même interface…  ???

        Jah Olela Wembo: Les mots se muent en maux quand ils indisposent, agressent ou blessent.

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

          J'imagine aussi. Je préfère avoir la réponse de l’intéressé. Le cas échéant ce n'est pas, de loin, la meilleure option pour ce travail.

          1 Reply Last reply Reply Quote 0
          • L
            locklock
            last edited by

            @ccnet:

            Sur le plan fonctionnel quel est l'objectif ? Quel intérêt y  t il a dupliquer ce trafic ?

            l'objectif est simplement de dupliquer le traffic à partir du LAN et de la DMZ et de l'a récuperer sur 3eme patte pour faire de l'analyse de paquet, sans que ce dernier emet ces propres paquets dans les deux autres interfaces.

            pfsense propose une option de bridge avec le SPAN, mais perplexe puisque il duplique juste au niveau 2 de la couche OSI.

            Ce que j'aimerais faire est que pfsense fonctionne comme un TAP.

            J'ai déjà mis en place une sonde snort pour sniffer le traffic des autres pattes, mais je veux une duplication du traffic, comme si les requettes venant du LAN transitent vers la DMZ et soit dupliqué vers la 3eme patte en utilisant pfsense pour qu'une VM par exemple les recuperes.

            Cordialement.

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

              perplexe puisque il duplique juste au niveau 2 de la couche OSI.

              Qu'entendez vous par juste dupliquer au niveau 2 ? Là c'est moi qui suis perplexe.

              Ce que j'aimerais faire est que pfsense fonctionne comme un TAP.

              Mais Pfsense est un firewall et n'est pas conçu pour cela. A essayer de planter un clou avec un tournevis vous allez vous faire mal aux doigts. On trouve des tap box pour moins de 200€ sur ebay.
              Les gens savent ce qu'ils voudraient mais ils ne savent pas ce qu'ils veulent. Vous avez besoin d'un tap, prenez un tap.
              Par ailleurs la solution du switch avec un port de copie connecté a l'interface de capture de la sonde (donc sans adresse ip) est aussi une solution "best pratices".

              1 Reply Last reply Reply Quote 0
              • L
                locklock
                last edited by

                @ccnet:

                perplexe puisque il duplique juste au niveau 2 de la couche OSI.

                Qu'entendez vous par juste dupliquer au niveau 2 ? Là c'est moi qui suis perplexe.

                je me suis mal exprimé, je voulais dire il ne route pas de paquet ip, mais c'est vrai, qu'il peut transmettre l'ensemble des paquets.

                Ce que j'aimerais faire est que pfsense fonctionne comme un TAP.

                Mais Pfsense est un firewall et n'est pas conçu pour cela. A essayer de planter un clou avec un tournevis vous allez vous faire mal aux doigts. On trouve des tap box pour moins de 200€ sur ebay.
                Les gens savent ce qu'ils voudraient mais ils nt pas ce qu'ils veulent. Vous avez besoin d'un tap, prenez un tap.
                Par ailleurs la solution du switch avec un port de copie connecté a l'interface de capture de le savena sonde (donc sans adresse ip) est aussi une solution "best pratices".

                je n'ai pas saisi la solution avec une sonde sans ip (parce que connecté à un switch), ce que je veux, c'est qu'une VM (ubnutu, debian) recupere les paquets du LAN et de la DMZ qui on été dupliqué par le pfsense.

                Je travaille dans un environement virtuel vmware

                Donc la methode serait :

                Avec pfsense d'utiliser sa fonctionalité "bridge" pour faire du SPAN, en rajoutant une 4eme patte reseau, 1 pour le lan, 1 pour la dmz, 1 bridge lan to span, 1 bridge dmz to span ?

                et avec la Vm, elle n'a plus de gw ip pour communiqué avec pfsense ?

                pk avec pfsense ? parce que il est concu à partir d'un freeBDS, il y a peut etre un moyen de taper des commandes pour la duplication de trafic, donc potentiellement de faire du TAP, je ne sais pas.

                par exemple, avec iptable2, en utilisant la table mangle, il est possible de faire du port mirror sur une ubuntu.

                Cordialement.

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

                  je n'ai pas saisi la solution avec une sonde sans ip (parce que connecté à un switch), ce que je veux, c'est qu'une VM (ubnutu, debian) recupere les paquets du LAN et de la DMZ qui on été dupliqué par le pfsense.

                  Que l'on utilise un switch, un tap ou autre chose ne change rien. Il n'y a pas de rapport de cause à effet entre le swiitch (avec span port) et l'absence d'ip sur la sonde. Pour des raisons de sécurité assez évidentes une sonde n'écoute jamais le réseau qu'elle doit surveiller avec une adresse ip mais toujours en mode promiscuité. Donc sans ip.

                  Je vous recommande la lecture donnée en lien ci dessous qui vous permettra, je l'espère, d'acquérir une vision plus opérationnelle et moins faites d'aprioris sur ce sujet.

                  pk avec pfsense ? parce que il est concu à partir d'un freeBDS, il y a peut etre un moyen de taper des commandes pour la duplication de trafic, donc potentiellement de faire du TAP, je ne sais pas.

                  Encore faudrait il que Pfsense ait été développé avec l'idée d'en faire un tap logiciel, hors ce n'est pas le cas. C'est un firewall.
                  Pour la lecture : http://www.ssi.gouv.fr/uploads/2015/01/architecture_systeme_securisee_sonde_IDS_reseau-article.pdf

                  1 Reply Last reply Reply Quote 0
                  • L
                    locklock
                    last edited by

                    @ccnet:

                    je n'ai pas saisi la solution avec une sonde sans ip (parce que connecté à un switch), ce que je veux, c'est qu'une VM (ubnutu, debian) recupere les paquets du LAN et de la DMZ qui on été dupliqué par le pfsense.

                    Que l'on utilise un switch, un tap ou autre chose ne change rien. Il n'y a pas de rapport de cause à effet entre le swiitch (avec span port) et l'absence d'ip sur la sonde. Pour des raisons de sécurité assez évidentes une sonde n'écoute jamais le réseau qu'elle doit surveiller avec une adresse ip mais toujours en mode promiscuité. Donc sans ip.

                    Je vous recommande la lecture donnée en lien ci dessous qui vous permettra, je l'espère, d'acquérir une vision plus opérationnelle et moins faites d'aprioris sur ce sujet.

                    pk avec pfsense ? parce que il est concu à partir d'un freeBDS, il y a peut etre un moyen de taper des commandes pour la duplication de trafic, donc potentiellement de faire du TAP, je ne sais pas.

                    Encore faudrait il que Pfsense ait été développé avec l'idée d'en faire un tap logiciel, hors ce n'est pas le cas. C'est un firewall.
                    Pour la lecture : http://www.ssi.gouv.fr/uploads/2015/01/architecture_systeme_securisee_sonde_IDS_reseau-article.pdf

                    Merci pour le lien.

                    Donc la best practice, serait d'avoir juste une troisieme patte pfsense en l'a reliant à une sonde réseau (snort) ?
                    sinon, je pourrais tout simplement utilisé un script python qui utilise la bibliothéque libpcap pour capturer le traffic en mode promiscuité ? (ca m'éviterait d'installer snort, qui  propose d'autres solutions).

                    Mais sinon, pour l'extension bridge sur pfsense, personne ne m'a répondu.
                    Elle est déconseillé d'utiliser ?

                    • Avec pfsense d'utiliser sa fonctionalité "bridge" pour faire du SPAN, en rajoutant une 4eme patte reseau, 1 pour le lan, 1 pour la dmz, 1 bridge lan to span, 1 bridge dmz to span ?

                    • et avec la Vm, elle n'a plus de gw ip pour communiqué avec pfsense ?

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

                      Donc la best practice, serait d'avoir juste une troisieme patte pfsense en l'a reliant à une sonde réseau (snort) ?

                      Non, le firewall n'est pas le lieu idéal où réaliser cette opération. Si votre firewall tombe vous n'avez plus d'analyse de trafic. Vous rendez un moyen de défense dépendant du fonctionnement d'un autre, ce qui n'est pas souhaitable. Ce n'est qu'un des problèmes.
                      Je déconseille d'utiliser la fonction bridge de Pfsense pour traiter votre besoin. Il m'est arrivé de l'utiliser mais pour des raisons tout à fait différentes.

                      1 Reply Last reply Reply Quote 0
                      • L
                        locklock
                        last edited by

                        @ccnet:

                        Donc la best practice, serait d'avoir juste une troisieme patte pfsense en l'a reliant à une sonde réseau (snort) ?

                        Non, le firewall n'est pas le lieu idéal où réaliser cette opération. Si votre firewall tombe vous n'avez plus d'analyse de trafic. Vous rendez un moyen de défense dépendant du fonctionnement d'un autre, ce qui n'est pas souhaitable. Ce n'est qu'un des problèmes.
                        Je déconseille d'utiliser la fonction bridge de Pfsense pour traiter votre besoin. Il m'est arrivé de l'utiliser mais pour des raisons tout à fait différentes.

                        C'est justement pour des raisons expérimentale que je veux cette duplication de trafic au niveau de pfsense.
                        Je suis d'accord, qu'il faudrait une appliance indépendant de pfsense pour réaliser cette opération.

                        1 Reply Last reply Reply Quote 0
                        • L
                          locklock
                          last edited by

                          @chris4916:

                          @ccnet:

                          Quel intérêt y  t il a dupliquer ce trafic ?

                          Snort et autres NIDS  ;)

                          Mais c'est quelque chose qu'on fait généralement avec des switchs. Pas sûr que le FW soit le meilleur endroit pour le faire. de plus, dupliquer à la fois du WAN et du LAN vers la même interface…  ???

                          snort ne visualisera pas les paquets s'il lui son directement adressé (snort sera sur une interface du pfsense et non en coupure).

                          Mais peut on le configurer pour qu'il recoit les paquets ?

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

                            Je ne comprend pas cette histoire de visualisation de paquet avec Snort dans l'hypothèse où l'on se sert d'un spin port sur un switch.

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