Règles firewall par utilisateur



  • Bonjour,

    Je bascule une archi pour un client d'un Netasq vers un Pfsense. Nous avons installé un Pfsense 2.3.4 et celui-ci comporte 2 cartes, un WAN et une LAN (en 192.168.0.0/16), pas de DMZ, pas de Wifi.
    Nous avons HAproxy, OpenVPN et FReeRadius comme package. Haproxy n'est pas encore configuré. OpenVPN est configuré pour interroger la base Radius

    Nous cherchons à reproduire un comportement existant sur le Netasq, à savoir gérer des règles de firewall par utilisateur. J'ai recherché sur Google et dans le forum et de ce que j'ai trouvé, il me faut pour ça OpenVPN et FreeRadius ( https://forum.pfsense.org/index.php?topic=84624.msg464140#msg464140 ).
    A noter que je n'ai pas la main sur le Netasq et n'ai pas possibilité facile de visualiser la configuration.

    Mais d'après ce post, il faudrait avoir une ip assignée par utilisateur.
    https://forum.pfsense.org/index.php?topic=130715.0

    Cela nous ennuie quelque peu car l'idée serait de ne pas attribuer d'ip à un client, sachant qu'il pourrait potentiellement ouvrir 2 connexions VPN. Existe-t-il un moyen pour affecter des règles de firewall à un utilisateur VPN ? J'avais pensé aux aliases mais je n'ai pas le choix d'un utilisateur lorsque je créé un alias

    Il est possible qu'il manque des informations mais j'ai essayé de donner tout ce qui me semblait utile pour comprendre notre problématique. N'hésitez pas à me dire s'il manque quelque chose.

    Pour infomation, je suis admin systèmes depuis bientôt 20 ans. J'ai des notions avancées de réseaux mais loin d'être admin réseaux.

    merci
    Jérôme



  • La réponse de Jimp (co-auteur de 'pfSense - the definitive guide' et plus de 20400 posts sur le forum, excusez du peu !) est très claire : il faut la suivre.

    Il faut bien comprendre qu'un firewall ne voit passer que des paquets ip et doit faire le tri dedans !
    Si vous avez un moyen de vous assurer que tel utilisateur reçoit une adresse ip donnée, cela permet de définir des règles.
    (Les matheux diraient bijection user <-> adresse ip !).



  • Si l'objectif est de gérer par exemple sur l'interface LAN des règles par utilisateur, en effet ça va être difficile car par principe, le firewall gère des règles relatives à des flux réseau (donc adresses source et destination, ports etc)  ce qui n'a pas de lien avec la notion d'utilisateur.
    Ce qui pourrait s'en rapprocher serait une solution de type NAC pour que l'IP ne soit obtenue qu'après authentification. Difficile…

    Ce qui l'intermédiaire, c'est la nature du besoin : dans quel cas a t on ce type de besoin ? Ou n'est pas l'utilisation du fw pour couvrir un besoin d'une autre nature ?



  • j'étais en train de répondre à jdh quand une nouvelle réponse est arrivée. Faisons les choses dans l'ordre :

    Je comprends sans soucis sa seconde phrase mais nous souhaiterions ne pas attribuer d'ip à chaque client.
    Par contre, j'aurais aimé avoir des précisions sur ce morceau de phrase, car c'est potentiellement lui qui m'intéresse et que je ne trouve pas clair en soi :

    It is possible to do if the users and rules come via RADIUS, though

    J'y comprends qu'on pourrait configurer/stocker les règles du firewall dans radius mais je n'ai pas trouvé de documentation à ce sujet et de fait faire des associations règles par utilisateur .. mais peut-être je me trompe

    merci
    Jérôme

    Pour répondre à chris4916, votre réponse me laisse à penser que je n'ai clairement pas assez détaillé notre projet.
    Le pfsense est censé protéger, filtrer, répartir les accès sur une plateforme de plusieurs serveurs. Derrière le Pfsense, il n'y a donc que des serveurs, et aucun poste utilisateur.
    Nous avons des utilisateurs qui vont se connecter en VPN sur Pfsense. Certains de ces utilisateurs ont le droit d'aller sur des serveurs mais pas d'autres.
    L'idée est de pouvoir établir les règles permettant aux utilisateurs d'accès aux ressources auxquelles ils ont droit via le firewall en se basant sur le nom d'utilisateur sans devoir fixer une ip par utilisateur

    merci
    Jérôme



  • on pourrait configurer/stocker les règles du firewall dans radius

    Analyse erronée ! Radius peut identifier un utilisateur et permettre ainsi une attribution unique d'ip, laquelle sert de 'base' à une règle.

    Trafic ip -> aucune notion d'utilisateur.
    Donc le contournement est l'attribution d'une ip à un utilisateur et construction de règles pour cette ip.
    Il faudra donc associer une ip à chacun de vos utilisateurs et des règles basées sur ces ip.

    NB : de mon point de vue, ça devient difficilement gérable à partir d'un petit nombre d'utilisateurs …



  • Si la matrice "nombre d'utilisateurs x nombre de serveurs accessibles" est un peu grosse, ça va devenir effectivement très rapidement ingérable de manière fiable.

    Je pense vraiment qu'il faut se poser la question de l'expression du besoin.
    Par exemple sur un LAN, on ne se pose le plus souvent pas la question de la ségrégation du réseau en fonction des droits des utilisateurs sur les serveurs. On fait assez souvent des VLAN pour des groupes de serveurs par environnement, par exemple, et on autorisé ou pas les postes client a y accéder sans considération d'authentification car la gestion des droits d'accès à la ressource, dès lors que le protocole est autorisé, sse fait au niveau de la ressource elle même.



  • Le problème de l’expression de besoin se pose.
    Si il s'agit en fait d'un problème d'habilitation, le firewall n'est pas l'outil approprié.
    Selon le nombre d'utilisateur on peut toujours envisager plusieurs serveurs vpn, il sera facile de segmenter. On peut aussi dans le contexte d'un accès vpn ssl 'figer' l'ip d'un utilisateur.
    Ce ne sont que des possibilités. L'expression de besoin reste essentielle.



  • Bonjour,

    Je vais essayer de résumer au mieux les besoins. Nous avons actuellement une 30aine de serveurs (physiques et virtuels) hébergeant du web, du mariadb, du mail, de la supervision et quelques machines windows.
    La société compte 4 employés fixes et 2 prestataires.
    deux des employés doivent pouvoir se connecter à mysql sur les serveurs de production mais pas sur celui de supervision
    un autre doit pouvoir se connecter à tous les mysql mais aussi en ssh aux serveurs supervision et déploiement.
    le gérant veut pouvoir se connecter à tous les serveurs de quelques manières que ce soit.
    Les 2 prestas infogérance doivent pouvoir se connecter à tous les serveurs, de la même manière que le gérant.

    Je comprends bien que le firewall en lui-même n'est pas forcément l'outil approprié mais la combinaison du firewall + vpn pourrait laissé à penser que c'est gérable. Dans le sens où Pfsense attribue de lui-même l'ip a un user, nous osions espérer qu'il serait capable d'insérer des règles à l'établissement d'une connexion VPN.

    En écrivant celà, je me demandais si via les options avancées de l'onglet "client specific overrides" il ne serait pas possible d'implémenter ces règles ?



  • Donc 3 typologies d'utilisateurs. Pourquoi pas 3 serveurs Vpn ? Chacun en écoute sur un port distinct. Filtrage sur chacune des interfaces. Vous lier un utilisateur à un certificat et à un serveur Vpn (chacun sa ca et son certificat serveur.

    En écrivant celà, je me demandais si via les options avancées de l'onglet "client specific overrides" il ne serait pas possible d'implémenter ces règles ?

    Les règles non, mais le lien entre un utilisateur, son certificat et une ip fixe pour son tunnel vpn oui. Je l'ai utilisé dans la passé plusieurs fois.

    Je ne sais pas comment vous administrez Pfsense, mais je recommander l'usage d'une interface dédié à l’administration. La séparation des flux applicatifs/métiers de ceux d'administration reste une bonne pratique.



  • Donc 3 typologies d'utilisateurs. Pourquoi pas 3 serveurs Vpn ? Chacun en écoute sur un port distinct. Filtrage sur chacune des interfaces. Vous lier un utilisateur à un certificat et à un serveur Vpn (chacun sa ca et son certificat serveur.

    Je ne vois pas comment 'différencier' les différents serveurs VPN pour le filtrage. Dans la partie Firewall, je ne vois qu'une interface OpenVPN qui englobe (sauf erreur) tous les serveurs VPN.

    Après longue discussion avec mon client (depuis 11h ce matin), on s'oriente vers la solution d'attribuer une IP par utilisateur. Cela lui semble le plus compréhensible et le plus gérable.

    Les règles non, mais le lien entre un utilisateur, son certificat et une ip fixe pour son tunnel vpn oui. Je l'ai utilisé dans la passé plusieurs fois.

    Auriez-vous des pointeurs sur cela ? C'est un point qui pourrait m'intéresser à titre personnel et pour ma culture sur pfsense (en attendant de faire le tour de la documentation)

    Actuellement, nous n'avons pas d'interface dédiée à l'administration mais c'est une voie à approfondir :)

    merci
    Jérôme



  • Je ne vois pas comment 'différencier' les différents serveurs VPN pour le filtrage

    Numéro de réseau différent.



  • Jehster, selon les besoins que tu as exprimé :

    La société compte 4 employés fixes et 2 prestataires.
    deux des employés doivent pouvoir se connecter à mysql sur les serveurs de production mais pas sur celui de supervision
    un autre doit pouvoir se connecter à tous les mysql mais aussi en ssh aux serveurs supervision et déploiement.
    le gérant veut pouvoir se connecter à tous les serveurs de quelques manières que ce soit.
    Les 2 prestas infogérance doivent pouvoir se connecter à tous les serveurs, de la même manière que le gérant.

    Ne serait ce pas plus facile d'attribuer des identifiants différents à chaque utilisateur sur les systèmes en question? 
    De toute façon le partage d'un compte administrateur entre plusieurs personnes dilue rapidement la responsabilité ainsi que la traçabilité des actions et ne fait pas parti des "bonnes pratiques".
    La tâche principale du pare-feu c'est isolation des serveurs de l'Internet mais une fois le VPN ouvert il y a déjà un certain niveau de confiance sous entendu puisque la personne à pu ouvrir le VPN.
    Par la suite les utilisateurs utilisent leurs dits identifiants pour accéder aux machines. 
    On gagne la responsabilité et la traçabilité des actions entrepris auprès des serveurs par les intervenants.



  • @awebster:

    Ne serait ce pas plus facile d'attribuer des identifiants différents à chaque utilisateur sur les systèmes en question?

    +1
    c'est le sens de mon message précédent. Vouloir faire du contrôle d'accès aux ressources uniquement en s'appuyant sur le FW est assez bizarre comme approche.
    Et ça fait effectivement penser qu'il n'y a pas de gestion des identités au niveau des systèmes.



  • Je suis parti du principe que c'était le cas et qu'il s'agissait un second niveau de contrôle.
    Qu'est ce que j’apprends on partagerai des comptes root et administrateur ! On m'aurait menti ?

    Sérieusement il est indispensable que les comptes soient individualisés. C'est un fondamental pour les raisons données plus haut.



  • @chris4916:

    @awebster:

    Ne serait ce pas plus facile d'attribuer des identifiants différents à chaque utilisateur sur les systèmes en question?

    +1
    c'est le sens de mon message précédent. Vouloir faire du contrôle d'accès aux ressources uniquement en s'appuyant sur le FW est assez bizarre comme approche.
    Et ça fait effectivement penser qu'il n'y a pas de gestion des identités au niveau des systèmes.

    Bonjour,

    Aucune intention de donner le compte root à tout le monde. Chacun a déjà son compte ssh et/ou un compte mysql et un compte VPN dédié. L'idée est de pouvoir vraiment cloisonner un utilisateur. Nous aurions aimé ne pas devoir affecter une IP à un utilisateur et pouvoir filtrer les accès via le user VPN utiliser (exemple user1 a le droit de faire du ssh sur server1 et server2 et user2 ssh/mysql sur server2 uniquement)

    Et donc pour chris4916 et ccnet, chaque utilisateur aura bel et bien un compte propre.

    Je n'ai jamais dit que tout le monde utiliserait le même compte .. mais je n'ai pas dit le contraire non plus.

    Je ne sais pas si nos besoins sont explicités plus clairement maintenant. En tout cas merci pour vos réponses, vos suggestions.

    @ccnet : je n'arrive pas à voir/trouver cette notion de numéro de réseau à laquelle vous faites référence.



  • @jehster:

    Nous aurions aimé ne pas devoir affecter une IP à un utilisateur et pouvoir filtrer les accès via le user VPN utiliser (exemple user1 a le droit de faire du ssh sur server1 et server2 et user2 ssh/mysql sur server2 uniquement)

    Certes mais c'est précisément cette formulation qui n'a pas de sens du point de vue du firewall…
    tout ce que le firewall sait dire, c'est:
    "ce qui vient de telle adresse ou de tel réseau à le droit d'accéder à telle adresse ou telle réseau sur tel port"
    Pas de notion d'utilisateur ici.

    La notion d'utilisateur, c'est au niveau de l'operating system ou des services que le serveur expose.
    Si l'utilisateur n'a pas de compte sur le server1, il peut bien accéder au réseau correspondant, il ne pourras pas ouvrir de de session.
    Ce ne sont pas les même couches et vouloir forcer cette logique en essayant de trouver un "truc" pour que le firewall connaisse le compte utilisateur, c'est se donner beaucoup de travail pour, à mon avis, un résultat moyen et des risques de dysfonctionnement importants.

    AMHA bien sûr  8)



  • @chris4916:

    La notion d'utilisateur, c'est au niveau de l'operating system ou des services que le serveur expose.

    C'est justement là dessus que nous avions eu des espoirs. Nous avons une machine pfsense qui à la fois regroupe un serveur vpn, une base d'utilisateurs (locale ou radius ou ldap)  et un firewall. On a, probablement à tort, supposé qu'il serait possible de faire des groupes d'utilisateurs qu'on pourrait utiliser pour des règles du firewall, notamment via les Aliases.

    Je dois refaire le point avec mon client mardi prochain :)

    Merci pour vos interventions, vos réponses et votre aide

    Jérôme



  • Cette base d'utilisateurs, dans le cas de LDAP, peut en revanche être efficacement utilisée pour contrôler l'accès aux serveurs Linux par exemple, via SSSD ou via PAM qui peut implémenter un contrôle d'accès au serveur sur la base de l'appartenance à un groupe LDAP (ou la valeur d'un attribut).

    Mais c'est indépendant du FW, ce qui signifie que ça fonctionne également pour un client qui serait sur le même subnet que le serveur.

    Prenons un exemple dans la solution que tu essaies de mettre en place:

    • tous les serveurs sont sur le même LAN
    • un utilisateur distant est autorisé uniquement, via ta règle de FW, sur le serveur 1
    • il y accède… so far so good :-)
    • et de ce serveur, il ouvre une session sur le serveur 2, depuis le LAN, donc sans passer par le FW, donc pas de "règle de contrôle d'accès"...

    bref, ce n'est pas le bon endroit pour faire ça, même en imaginant faire un VLAN par serveur  ;)



  • Dès le 2ième post, j'écrivais 'un firewall ne voit passer que des paquets ip' : il aura fallu du temps pour comprendre que la notion d'utilisateur n'est pas dans ip.

    Puis on comprend que vous avez des utilisateurs qui partagent le même profil, ce qui est très grave et significatif d'un problème de compréhension : chaque utilisateur DOIT avoir son profil personnel.
    C'est le seul moyen de tracer l'action de chaque utilisateur.

    De facto, un vpn devra être basé sur certificats, un par utilisateur, et avec une ip fixé par le certificat, donc par l'utilisateur.

    Tout cela est une réflexion simple …



  • @jdh:

    Dès le 2ième post, j'écrivais 'un firewall ne voit passer que des paquets ip' : il aura fallu du temps pour comprendre que la notion d'utilisateur n'est pas dans ip.

    Je n'ai jamais dis que je n'avais pas compris mais du fait que PfSense n'est pas qu'un simple firewall, on peut imaginer qu'ils ont implémenter des fonctionnalités avancées.
    Le Netasq le fait bien, pourquoi PfSense ne pourrait pas ?

    @jdh:

    Puis on comprend que vous avez des utilisateurs qui partagent le même profil, ce qui est très grave et significatif d'un problème de compréhension : chaque utilisateur DOIT avoir son profil personnel.
    C'est le seul moyen de tracer l'action de chaque utilisateur.

    Où ai-je dis ça ?? Je dis même l'exact contraire ! Pour le coup, le problème de compréhension n'est pas de mon coté … un soucis de lecture je pense ...
    @jehster:

    Aucune intention de donner le compte root à tout le monde. Chacun a déjà son compte ssh et/ou un compte mysql et un compte VPN dédié.



  • Je ne vois pas comment 'différencier' les différents serveurs VPN pour le filtrage. Dans la partie Firewall, je ne vois qu'une interface OpenVPN qui englobe (sauf erreur) tous les serveurs VPN.

    VPNOpenVPNServers puis dans la définition du serveur VPN : IPv4 Tunnel Network pour le réseau de chaque vpn.
    Dans l'unique onglet (en effet) openvpn pour les règles, vous avez la possibilité d'utiliser l'ip source du client.

    Nous aurions aimé ne pas devoir affecter une IP à un utilisateur et pouvoir filtrer les accès via le user VPN

    Je ne vois pas quelle est la difficulté en ce qui concerne le vpn.

    Cela ne s'entend que si chaque utilisateur possède son propre certificat évidement. Encore une fois, ni ip ni tcp ne "comprennent" la notion d'utilisateur. Il est possible que le cloisonnement de votre réseau soit inadapté en fonction de besoin de sécurité. Je ne sais le dire puisque je ne connais pas votre besoin de sécurité d'un point de vue métier, fonctionnel. Vous raisonnez en solutions technique d'abord. c'est la principale raison des difficultés projet que vous rencontrez. C'est très courant dans ce domaine.



  • C'est awebster dans son post  https://forum.pfsense.org/index.php?topic=133431.msg733320#msg733320 qui imagine que les profils sont partagés, et d'autres aussi ont compris la même chose.

    Si vous avez bien compris la nécessité de disposer d'un profil personnel par intervenant, l'idée d'avoir un certificat personnel pour le vpn et de fixer l'ip à partir de la connexion vpn est 'normale' et logique.

    Comme on peut lire que l'idée de fixer les ip ne vous parait pas évidente, …