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

    [Résolu] Probleme d'application des regles du Firewall

    Scheduled Pinned Locked Moved Français
    5 Posts 3 Posters 1.5k 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.
    • Y
      Yarglo
      last edited by

      Bonjour,
      Après pas mal de temps passée sur différents forum en différentes langues, je me permet de solliciter votre aide.

      Ma config :
      Netgate SG-4860 (Appliance)
      2.3-RELEASE (amd64)
      built on Mon Apr 11 18:28:29 CDT 2016 (Mise à jour récente)
      FreeBSD 10.3-RELEASE

      openvpn-client-export installé
      Squid Proxy désinstallé puis réinstallé proprement
      Squidguard désintallé
      Sarg désinstallé automatiquement à la suite de la MAJ.

      192.168.2.109/24 –------ 192.168.2.251/24 ---(LAN) PFSENSE (DMZ) --- 192.168.250.254/28 ---------- 192.168.250.241/28

      En peu de mots : si j’essaye de bloque les accès rdp 3389 de mon Lan vers ma DMZ (De 2.109 vers 250.241), rien ne se passe et les accès restent ok …

      Pourtant :
      Je reboot le PfSense
      Régles Firewall dans ma DMZ : No rules are currently defined for this interface
      Mais le RDP et l’icmp fonctionnent …

      Diagnostics\States\States
      LAN tcp 192.168.250.241:3389 <- 192.168.2.109:49452 TIME_WAIT:TIME_WAIT 7 / 8 662 B / 2 KiB
      DMZ1 tcp 192.168.2.109:49452 -> 192.168.250.241:3389 TIME_WAIT:TIME_WAIT 7 / 8 662 B / 2 KiB
      LAN tcp 192.168.250.241:3389 <- 192.168.2.109:49454 ESTABLISHED:ESTABLISHED 146 / 177 18 KiB / 120 KiB
      DMZ1 tcp 192.168.2.109:49454 -> 192.168.250.241:3389 ESTABLISHED:ESTABLISHED 146 / 177 18 KiB / 120 KiB
      LAN tcp 192.168.250.241:3389 <- 192.168.2.109:49453 TIME_WAIT:TIME_WAIT 8 / 9 2 KiB / 2 KiB
      DMZ1 tcp 192.168.2.109:49453 -> 192.168.250.241:3389 TIME_WAIT:TIME_WAIT 8 / 9 2 KiB / 2 KiB
      LAN icmp 192.168.250.254:1 <- 192.168.2.109:1 0:0 4 / 4 240 B / 240 B

      Même si les règles coté LAN sont encore active :
      IPv4 * LAN net * * * * none   Default allow LAN to any rule
      Ma DMZ ne devrait pas pouvoir me répondre (car aucune règle …et donc : bloqués par défaut)

      Dans les log je vois passer cela : (un reste de sarg, je suis preneur si quelqu’un sais comment corriger ça …)
      Apr 20 17:00:00 php /usr/local/www/sarg.php: The command 'export LC_ALL=C && /usr/local/bin/sarg ' returned exit code '127', the output was '/usr/local/bin/sarg: not found'
      Apr 20 17:00:00 php /usr/local/www/sarg.php: [sarg] Force refresh now with args, compress(on).

      Merci de votre aide à tous.

      1 Reply Last reply Reply Quote 0
      • J
        jdh
        last edited by

        Tout d'abord, bravo pour ce post : même s'il ne respecte pas absolument le formulaire, on voit le soin apporté à la présentation et à fournir des informations ! Continuez

        J'ai lu rapidement et je vois 2-3 choses :

        • l'adressage de la zone DMZ me paraissait incorrect et puis non, c'est correct : /28 -> 16 machines -2 (network + broadcat), donc ok pour 192.168.250.241-254
        • pas de règles en onglet DMZ : ne me pose pas de problèmes, mais c'est bien d'en mettre pour préciser
        • la protection de LAN -> DMZ se place dans l'onglet LAN puisque on contrôle les sessions initiées par une machine en LAN. Très important.
        • l'autorisation de ping est normale et souhaitable, à condition de la limiter à 8/icmp=echo request
        • il est essentiel de permettre à toutes machines (LAN et DMZ) de correctement résoudre le DNS : p.e. un accès SSH sur un serveur Linux en DMZ, avec un serveur incapable de résoudre, donne l'impression pendant 30" que cela ne fonctionne pas.

        Ma DMZ ne devrait pas pouvoir me répondre (car aucune règle …et donc : bloqués par défaut)

        Eh bien non, erreur de compréhension : on écrit seulement une règle dans l'onglet de l'interface d'arrivée du paquet initial, ou on n'écrit aucune règle sur le retour. D'où l'importance (et le danger) d'une règle 'Default allow LAN to any' !

        Prenez une convention d'écriture :
        Dans l'onglet LAN, commencez par les règles 'LAN subnet' vers 'DMZ subnet' et finissez par une règle d'interdiction totale (pour DMZ subnet), puis vous écrirez les règles 'LAN subnet' vers 'any' qui seront DONC celle de LAN vers WAN !

        A minima, sauf si pfSense est le serveur DNS, il faut une règle dans l'onglet DMZ pour résoudre le DNS (53/udp+tcp).

        Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

        1 Reply Last reply Reply Quote 0
        • Y
          Yarglo
          last edited by

          Bonjour, et merci pour vos encouragements.

          Merci aussi pour vos conseils, ils m'ont permis de grandement progresser dans la gestion des règles de fw.

          J'ai ajouté des règles selon vos préconisations mais il me reste un petit doute :

          et finissez par une règle d'interdiction totale (pour DMZ subnet)

          Pourtant il me semblait que cette règle d'interdiction totale était implicite  : "ce qui n'est pas autorisé est interdit" du coup, j'ai l'impression que ça fait doublon.

          Pour le reste, ça commence à fonctionner pas mal du tout !
          Il me reste un petit souci d'autorisation explicite en 80 et 443 via le Proxy, mais j'ai bon espoir !

          Merci.

          1 Reply Last reply Reply Quote 0
          • J
            jdh
            last edited by

            Le traitement des règles se fait de haut en bas.
            Si vous groupez, en haut, toutes celles qui vont de LAN subnet vers DMZ subnet,
            la ligne d'interdiction, certes inutile, servira de 'séparation visuelle'.

            Perso, dans les commentaires je commence par un l2d = lan to dmz, l2w = lan to wan, …
            De même, je norme les noms d'alias ipxxx = ip externe, srvxxx = serveur, ...
            Ne pas oublier de vous facilitez la lecture ...

            Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

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

              @Yarglo:

              Pourtant il me semblait que cette règle d'interdiction totale était implicite  : "ce qui n'est pas autorisé est interdit" du coup, j'ai l'impression que ça fait doublon.

              oui elle est implicite et la gestion du log pour cette règle se fait, de la même manière que pour l'affichage des paquets acceptés, dans les settings du log

              Log packets matched from the default block rules put in the ruleset
              Hint: packets that are blocked by the implicit default block rule will not be logged if you uncheck this option. Per-rule logging options are still respected.

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

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