Pare-feu avec authentification

Posté par  . Modéré par Franck Yvonnet.
Étiquettes :
0
4
avr.
2002
OpenBSD
Sur OpenBSD, l'authpf introduite (le 1er avril ;-) la notion d'authentification dans son module de filtrage. En gros :

On se connecte (en ssh) sur le firewall. Le pare-feu rajoute des règles, par système et/ou par utilisateur. Si l'utilisateur se déconnecte, le pare-feu lui retire les règles ajoutées.

Imaginons les applications possibles en combinant avec :

* Un serveur Samba/Netatalk
* Un AP pour un réseau en 802b11

Et le top du top serait remplacer l'authentification SSH pour SSL, des volontaires ?

(article honteusement copié d'OpenBSD journal)

Aller plus loin

  • # L'idée est bonne mais ...

    Posté par  . Évalué à 10.

    ... la solution ultime reste IPsec.
    Ici, une fois l'accès ouvert pour l'IP de la personne authentifiée par SSH, quelqu'un d'autre peut toujours spoofer cette IP et passer. En plus, tout passe toujours en clair sur le fil.

    Avec IPsec, au moins, tout est chiffré, l'authentification est plutôt robuste (avec isakpmd) et ça tourne pas mal. Chiant à configurer, mais groovy.

    Au moins, l'équipe d'OpenBSD prévient bien dans la page de man :
    http://www.openbsd.org/cgi-bin/man.cgi?query=authpf(...)
    • [^] # Re: L'idée est bonne mais ...

      Posté par  (site web personnel) . Évalué à 5.

      L'ipsec c'est très bien, mais malheureusement tout le monde n'a pas un vrai système à sa disposition, donc ça peut etre utile en tant que pis aller pour les windows, grace à putty.

      Concernant le spoofing, les exemples donnent un truc pour que le hijacker n'ait au maximum qu'une minute pour accomplir ses méfaits, à ajouter dans le sshd_config :
      ClientAliveInterval 15
      ClientAliveCountMax 3


      Et puis cette possibilité d'avoir des règles de fw/user a l'avantage non négligeable d'etre un argument de vente supplémentaire.
      • [^] # Re: L'idée est bonne mais ...

        Posté par  . Évalué à 7.

        À ce moment, je suppose que putty permet (tout comme le client OpenSSH) de faire du forwarding de port. Il suffit de forwarder vers un proxy (socks ou moins generique) sur la passerelle. C'est plus sûr.

        Cela dit, je suis d'accord, c'est pas mal du tout comme truc authpf, surtout si il est rajouté une option pour empêcher de lire le fichier de configuration écrit par l'utilisateur (on peut pour l'instant, il suffit de bourriner dans le source, mais bon).
        • [^] # Re: L'idée est bonne mais ...

          Posté par  . Évalué à -6.

          Un chown root et un chmod 0400 ne suffit pas ?
          • [^] # Re: L'idée est bonne mais ...

            Posté par  . Évalué à 5.

            Si mais pour chaque utilisateur il faut créer le répertoire et le donner à root, c'est chiant. En bloquant la fonctionnalité au moins on est sûr.
            • [^] # Re: L'idée est bonne mais ...

              Posté par  . Évalué à -2.

              man useradd :

              -k skeleton directory
              gives the skeleton directory in which to find files with which to
              populate the new user's home directory. This value can be preset
              for all users by using the skel_dir field in the
              /etc/usermgmt.conf file - it has the format:
              skel_dir path-to-skeleton-dir

              De tout façon, si on a besoin des règles particulières par user, il faut le faie un moment ou un autre ...

              Mais bon, je chipote là.
              • [^] # Re: L'idée est bonne mais ...

                Posté par  . Évalué à 4.

                Ça c'est pour les nouveau utilisateurs. Quand tu a déjà 200000 homedirs, tu peux modifier ça tant que tu veux ça ne changera rien. Il faudra scripter un truc pour ajouter le rép partout.
                Bon, on chipote tous les deux mais disons que je serais plus tranquille si la fonctionnalité (config utilisateur) était désactivée plutot que de faire confiance à un fichier sensé être immuable.

                Finalement (après réflexion) c'est pas mal. Je bloque tout par défaut (sauf SSH) et je n'ouvre mon port imap et smtp que si je suis connecté en SSH, mais imap et smtp demandent quand même une authentification (avec chiffrement SSL).

                Ouais, plus simple à mettre en place qu'IPsec mais forcément avec moins de fonctionnalités ... c'est correct. Et puis ça fera toujours ça de charge en moins sur mon démon imap ... (marre des scans de ports de porcs)
  • # Pas mal pour FTP sécurisé

    Posté par  (site web personnel) . Évalué à -3.

    Dans les exemples donnés dans la page de man, il y a une bonne utilisation pour faire un accès FTP sécurisé via SSH.

    On ouvre le port FTP 21 (via du proxying sur la FW) seulement après un accès SSH pour un utilisateur autorisé.
  • # ENFIN !

    Posté par  . Évalué à 10.

    Enfin un firewall qui permet de faire cela ! Pour l'instant, à ma connaissance, seul FW-1 de CheckPoint (avec son agent d'authentification) permettait cela. Le gros avantage, c'est que l'on peut baser des règles firewall non plus sur une machine et une adresse IP, mais sur un utilisateur... Très pratique quand un utilisateur se balade de machine en machine ou quand l'adresse de sa bécane change sans cesse (par exemple : connexion RTC).

    Entre nous, c'est une fonction qui pourrait aussi être implémentée sous Linux avec IPChains ou IPTables. En plus, cela n'implique pas de développement au niveau du kernel, mais "seulement" au niveau utilisateur.
    • [^] # Re: ENFIN !

      Posté par  (site web personnel) . Évalué à 4.

      Ben ca existe deja !!

      D'ailleurs je suis decu que les lecteurs de Linuxfr soient aussi peu critiques : c'est pas parce qu'un posteur de news dis qqch que c'est l'information ultime et unique ! Si on connqis pas, le premier truc a fgaire c'est de demander a google !

      http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_sing(...)

      Heureusement, les commentaires sont la pour eclairer les lanternes :)
      • [^] # Re: ENFIN !

        Posté par  . Évalué à 3.

        STOOOOOP !

        Ici, on dit que l'authentification de l'utilisateur permet d'ajouter des règles personnalisées pour cet utilisateur. Or, dans le Authentication-Gateway-HOWTO, on se contente d'ouvrir tous les flux possibles pour n'importe quel utilisateur authentifié... Nuance ! Si on regarde de près les sources de pam_iptables.c (http://www.itlab.musc.edu/~nathan/pam_iptables/pam_iptables.c(...)), aux alentours de la ligne 226, on remarque que la conf du firewall ne fait qu'ajouter cette règle :

        iptables -I FORWARD -s <host> -o <interface> -j ACCEPT

        Dommage, c'est quand même un peu léger, le "tout ou rien"... L'avantage d'authpf, c'est que chaque utilisateur peut disposer de ses propres règles, présentes dans $HOME/.authpf/authpf.rules. C'est là que ça devient intéressant !!!

        Comme quoi, les deux projets ne sont pas comparables, et donc, je répète, à ma connaissance, il n'existe pas d'outil semblable sous Linux (bien que le Authentication-Gateway-HOWTO et pam_iptables donnent déjà de bonnes bases...).
    • [^] # Re: ENFIN !

      Posté par  . Évalué à 2.

      NSM (http://www.solsoft.org/(...)) permet de faire ça depuis 1994.
  • # approche différente ...

    Posté par  (site web personnel) . Évalué à 2.

    Donc, en fait, si j'ai bien compris le principe de la chose, on se logge sur la machine firewall via ssh (donc nécessite un compte système) sur un compte ayant pour shell cette commande particulière qui va modifier les règles du firewall suivant le fichier de config contenu dans le homedir du compte.

    Ce qui veut dire que si, a posteriori, je veux analyser les règles firewall d'une machine avec ce système, il faut que je regarde la config globale de pf, puis que je fasse attention à tous les comptes utilisateurs ayant ce shell pour lire les règles associées, fichier par fichier ... Bof, quoi ...

    Je trouve un peu dommage cette approche de ce problème simple.

    Pour rappel, ipfilter (oh, le concurrent de pf!) supporte normalement une règle qui n'est ni "pass" ou "block", mais "auth". Donc en gros, le packet va être passé via une interface particulière à un programme (en userland) qui dire si le packet sera passé/refusé/whatever. Malheureusement, je ne crois pas qu'il y ait de daemon opensource pour gérer ce genre de choses. Pourtant le fonctionnement me semblait plus simple et plus sain.

    Oh, et puis, ça veut dire que ça devient franchement incompatible entre pf/ipfilter, c'est cool, un avantage de moins pour les deux, alors qu'avant on pouvait "facilement" transposer le second sur du (net|free|open)bsd ou sur du solaris ou autre ...

    'fin bref ...


    seb.
    • [^] # Re: approche différente ...

      Posté par  . Évalué à 3.

      euh ... a propos de ton dernier paragraphe :
      Ca ne rajoute pas d'incompatibilite ipf>pf. Et tu le dit toi meme : le programme modifie les regles du firewall. Il n'y a rien de change dans le fichier de config du firewall en question. Tes fichiers ipf resteront facilement transposables sur pf. Le truc c'est qu'avec pf tu as une possibilite supplementaire (et separee de la config globale) : authpf.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.