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
- man authpf (16 clics)
- cvs log (2 clics)
- OpenBSD journal (3 clics)
# L'idée est bonne mais ...
Posté par Jean-Yves B. . Évalué à 10.
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 Annah C. Hue (site web personnel) . Évalué à 5.
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 Jean-Yves B. . Évalué à 7.
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 falbala . Évalué à -6.
[^] # Re: L'idée est bonne mais ...
Posté par Jean-Yves B. . Évalué à 5.
[^] # Re: L'idée est bonne mais ...
Posté par falbala . Évalué à -2.
-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 Jean-Yves B. . Évalué à 4.
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 Foxy (site web personnel) . Évalué à -3.
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 Ludovic Boisseau . Évalué à 10.
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 Yann KLIS (site web personnel) . Évalué à 4.
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 Ludovic Boisseau . Évalué à 3.
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 rominet . Évalué à 2.
# approche différente ...
Posté par Sebastien (site web personnel) . Évalué à 2.
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 Jean-Yves B. . Évalué à 3.
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.