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



  • 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.



  • 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).



  • 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.



  • 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 ...



  • @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.


Log in to reply