Re: Authentification ssh et PAM

[RogerT]

> Le 21 juil. 2023 à 10:26, Michel Verdier  a écrit :
> 
> Le 19 juillet 2023 RogerT a écrit :
> 
>> La validation par le gouvernement n’est en rien une garantie (sgdg…). 
> 
> Bien sûr, mais c'est quand même un plus par rapport à rien du tout.

Ça ne vaut rien du tout. Rien.

> 
>> Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
>> d’exporter en clair les pwds :
>> https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/
> 
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24055
> Celui-là concerne le client KeePass, d'autres clients comme KeePassXC ne
> sont pas touchés. Et ça concerne le paramétrage du client pas la
> base elle-même.
> 
>> Encore une nouvelle faille en 2023 : CVE-2023-35866
>> 19/07/2023
>> https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/
> 
> https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-35866
> Ca concerne KeePassXC mais il faut laisser la base ouverte en libre
> d'accès. A partir de là forcément n'importe quoi peut être fait sur la
> base et sans doute aussi sur le poste. Ce CVE est disputé.

C’est suffisamment grave et répété (pour d’autres gestionnaires de pwd) pour 
reconsidérer l’utilisation de ces passoires. 

« Disputed » : l’éditeur n’est pas d’accord. Ça ne veut rien dire d’autre 
(comme d’être partie à un procès dont on ignore l’issue). 
Avec des arguments pour keepass[xc] comme:
 « Oui, mais si un attaquant prend le contrôle de la machine alors il n’y a 
rien à faire » !!
 et « On ne peut pas faire de la sécurité en milieu non sûr » !!!
Ils sont fous ces gars !

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> La validation par le gouvernement n’est en rien une garantie (sgdg…). 

Bien sûr, mais c'est quand même un plus par rapport à rien du tout.

> Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
> d’exporter en clair les pwds :
> https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-24055
Celui-là concerne le client KeePass, d'autres clients comme KeePassXC ne
sont pas touchés. Et ça concerne le paramétrage du client pas la
base elle-même.

> Encore une nouvelle faille en 2023 : CVE-2023-35866
> 19/07/2023
> https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=CVE-2023-35866
Ca concerne KeePassXC mais il faut laisser la base ouverte en libre
d'accès. A partir de là forcément n'importe quoi peut être fait sur la
base et sans doute aussi sur le poste. Ce CVE est disputé.

Re: Authentification ssh et PAM

[Vincent Lefevre]

On 2023-07-19 09:05:05 +0200, Michel Verdier wrote:
> Le 18 juillet 2023 roger tarani a écrit :
> > Quel est le mécanisme détaillé conduisant à l'authentification de 
> > l'utilisateur par l'hôte distant ? 
> > (la clef privée reste sur l'hôte local ; comment la clef publique et la 
> > clef privée sont-elles liées ? par la création d'un jeton ? ou autre ? ) 
> 
> La clef publique est indiquée au serveur lors de la demande de connexion.
> Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
> client avec sa clef privée.

Le chiffrage se fait avec la clé *publique* du destinataire. Mais
c'est HS ici, car il ne s'agit pas de chiffrer, mais d'authentifier,
qui est l'équivalent de vérifier une signature. Et la signature se
fait avec sa propre clé privée (et se vérifie avec la clé publique
associée).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Authentification ssh et PAM

[Jean Bernon]

Non je ne crois pas que ce soit des bijections inverses, sauf à s'entendre sur 
ce qu'on met derrière cette expression.

J'ai pioché la question du chiffrement il y a quelques années. Voici la petite 
synthèses que nous avions faite des principes de base. Elle ne répond pas à 
toutes questions de Roger. Mais elle peut aider à cadrer le débat.

Deux usages d'une paire de clés PGP dans l'échange de fichiers.

Premier usage : la paire de clés PGP permet de chiffrer / déchiffrer certains 
documents ou mails. Plus précisément, la clé publique sert au chiffrement et la 
clé privée au déchiffrement.

Deuxième usage : cette même paire de clés PGP peut aussi servir à signer 
électroniquement un mail (et à vérifier l’authenticité de la signature). Dans 
ce cas, la clé privée sert à signer et la clé publique à vérifier la signature.

Usages de GnuPG dans l'envoi d'un mail
Pourquoi ?  Qui ?   Comment ?
Chiffrement Expéditeur  Clé publique du destinataire
Déchiffrement   DestinataireClé privée du destinataire
Signature   Expéditeur  Clé privée de l'expéditeur
Vérification de la signatureDestinataireClé publique de l'expéditeur


- Mail original - 

> De: "elguero eric" 
> À: debian-user-french@lists.debian.org
> Envoyé: Mercredi 19 Juillet 2023 18:28:24
> Objet: Re: Authentification ssh et PAM

> pour moi crypter et décrypter ne sont que des mots
> et en réalité il s'agit de deux bijections inverses
> l'une de l'autre. donc on peut aussi bien dire qu'on commence
> par décrypter un message avant de l'envoyer et
> que le récipiendaire devra alors le crypter pour retrouver
> le message original. Ou l'inverse.

> e.e.

> Le mercredi 19 juillet 2023 à 18:08:00 UTC+2, Michel Verdier
>  a écrit :

> Le 19 juillet 2023 RogerT a écrit :

> > Après vérification, et sauf erreur ou omission de ma part, je
> > regrette
> > mais en cryptographie asymétrique, seule la clef privée permet de
> > DÉchiffrer.
> > Tandis que la clef publique permet à tout le monde de chiffrer un
> > message.

> Oui tu as raison, autant pour moi, ça fait du bien de relire les
> bases de
> temps en temps. Voilà une description assez claire :
> https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[didier gaumet]

Le 20/07/2023 à 10:48, RogerT a écrit :
[...]

En pratique, si j’utilise une clef USB sans chiffrement ou avec chiffrement ou 
carrément un HSM, PAM est-il transparent à utiliser (cad qu’il suffit de 
configurer account, auth, password, session) ou faut-il trouver/développer un 
composant logiciel pour interagir avec chaque type ou modèle de HSM ?

[...]

Rappel: je suis nul en sécurité donc je réponds sur ce point uniquement 
(à l'exclusion de tes autres interrogations) et ma réponse est à prendre 
avec des pincettes


- pour une clé USB (au sens large ça semble considéré comme un HSM 
aussi?) apparemment il y a le module PAM USB et la commande pamusb-conf, 
une page du wiki Debian évoque ça:

https://wiki.debian.org/pamusb

- pour les HSM plus évolués de type smartcard, de mémoire, un lien 
Redhat précédent semblait indiquer un standard PKCS#11 avec parfois des 
périphériques devant rajouter un pilote propriétaire. Le wiki Debian a 
une page sur les smartcards où il évoque deux standards, openPGP ou PKSC#11:

https://wiki.debian.org/fr/Smartcards?highlight=%28pkcs%2311%29

Re: Authentification ssh et PAM

[RogerT]

> Le 20 juil. 2023 à 10:16, didier gaumet  a écrit :
> 
> Le 20/07/2023 à 09:25, Michel Verdier a écrit :
>> Le 19 juillet 2023 didier gaumet a écrit :
>>> Pour autant que ça s'applique ici, Wikipedia a une explication d'un 
>>> mécanisme
>>> d'autentification à clés asymétriques par l'utilisation d'un double
>>> chiffrement avec les deux clés publiques (celles de chaque partie):
>>> https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification
>> En français c'est mieux :)
>> On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
>> travaillais c'est de l'authentification qui crypte avec la clef privée,
>> d'où mon inversion pour ssh.
> 
> Ah, c'est pas à moi que ça arriverait, ça: je ne me trompe jamais, qu'on se 
> le dise ;-)
> 
> D'ailleurs c'est à se demander quel phénomène occulte et maléfique est 
> intervenu pour corrompre et distordre mon message précédent, puisque à le 
> lire soigneusement ainsi que le lien qu'il cite, on s'aperçoit que je me suis 
> encore planté (c'est pas un double chiffrement par les deux clés publiques, 
> c'est un double chiffrement par la clé privée de l'émetteur puis la clé 
> publique du destinataire ;-)
> 
> Encore une preuve qu'il ne faut pas faire aveuglément confiance à un 
> contributeur mais valider l'exactitude et la pertinence de ses propos :-)
> 
Bonjour,
Il faut toujours vérifier. 
Ça me semblait bizarre de chiffrer avec les deux clefs publiques. 

En vérifiant, j’ai redécouvert le mécanisme que je connaissais de chiffrement 
d’un fichier par l’expérience avec la clef publique du destinataire. 
C’est un mécanisme pour assurer la confidentialité. 

En revérifiant, j’ai découvert le mécanisme de chiffrement d’un (hash de) 
fichier avec la clef privée de l’expéditeur, qui permet au destinataire de 
vérifier que l’expéditeur est bien celui qui le revendique. 
C’est un mécanisme d’authentification (par signature). 

Et si on combine les deux (chiffrement par l’expéditeur avec sa clef privée 
d’un hash du fichier et avec la clef publique du fichier, alors on obtient une 
communication confidentielle et authentifiée. 

On peut donc supposer que le client ssh envoie simplement au serveur un message 
signé avec sa clef privée. Et le serveur ssh qui a une copie de la clef 
publique peut vérifier que celui qui demande la connexion est celui qu’il dit 
être (authentification). 

Échanger ici a permis de mettre les idées au clair. 
Merci. 

PS : une fois cette authentification configurée, il faut penser impérativement 
à désactiver l’authentification par pwd ou bien avoir un fail2ban installé pour 
éviter des intrusions qu’on croirait devenues impossibles sans avoir la clef 
privée si longue (RSA 2048 ou 4096).


J’ai commencé à étudier PAM et ses fichiers de configuration. 

En pratique, si j’utilise une clef USB sans chiffrement ou avec chiffrement ou 
carrément un HSM, PAM est-il transparent à utiliser (cad qu’il suffit de 
configurer account, auth, password, session) ou faut-il trouver/développer un 
composant logiciel pour interagir avec chaque type ou modèle de HSM ?

Quelle est votre expérience pratique avec un HSM/une clef USB et PAM ?


PS : La question viendra ensuite de savoir quelle confiance on peut accorder à 
PAM en tant que « bus/slot/interface). Cad quelle garantie apporte-t-il de 
n’être pas un trou de sécurité ? 

Re: Authentification ssh et PAM

[Daniel Caillibaud]

Le 19/07/23 à 16:28, elguero eric  a écrit :
> pour moi crypter et décrypter ne sont que des mots

Mais les mots ont un sens ;-)

Et ici ce n'est pas le bon. En français, décrypter c'est déchiffrer un message 
dont on a pas la
clé de chiffrement (et crypter n'existe pas car ça n'a pas de sens, ça voudrait 
dire chiffrer
sans avoir la clé de chiffrement).

C'est pour ça qu'on parle de chiffrer / déchiffrer quand on code/décode un 
message en ayant la
clé.

En anglais, il n'y a pas de mot différent lorsqu'on a la clé ou pas, c'est 
toujours
encrypt/decrypt, d'où l'usage erroné très courant de crypter(sic)/décrypter en 
français.

-- 
Daniel

On tue un homme, on est un assassin.
On tue des millions d'hommes, on est un conquérant.
On les tue tous, on est un dieu.
Edmond Rostand

Re: Authentification ssh et PAM

[elguero eric]

pour moi crypter et décrypter ne sont que des mots
et en réalité il s'agit de deux bijections inverses
l'une de l'autre. donc on peut aussi bien dire qu'on commence
par décrypter un message avant de l'envoyer et
que le récipiendaire devra alors le crypter pour retrouver
le message original. Ou l'inverse.

e.e.



Le mercredi 19 juillet 2023 à 18:08:00 UTC+2, Michel Verdier  a 
écrit : 

Le 19 juillet 2023 RogerT a écrit :

> Après vérification, et sauf erreur ou omission de ma part, je regrette
> mais en cryptographie asymétrique, seule la clef privée permet de
> DÉchiffrer.
> Tandis que la clef publique permet à tout le monde de chiffrer un message. 


Oui tu as raison, autant pour moi, ça fait du bien de relire les bases de
temps en temps. Voilà une description assez claire :
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 17:58, Michel Verdier  a écrit :
> 
> Le 19 juillet 2023 RogerT a écrit :
> 
 Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>>> 
>>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
>> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd 
>> qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 
> 
> keepass est validé par le gouvernement
> https://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-version-2-10-portable/
> D'autres gestionnaires attaqués dont j'ai entendu parlé (1password, etc) 
> avaient du
> stockage en ligne, ce n'est pas le cas de keepass. As-tu les références 
> d'articles ?


La validation par le gouvernement n’est en rien une garantie (sgdg…). 
Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité 
d’exporter en clair les pwds :
https://www.it-connect.fr/faille-critique-dans-keepass-un-attaquant-peut-exporter-les-mots-de-passe-en-clair/

L’éditeur n’a pas craint d’affirmer :
« l'éditeur de KeePass estime que la base de données de mots de passe n'est pas 
censée être protégée contre un attaquant disposant déjà d'un accès local sur un 
PC. »

L’éditeur aurait aussi affirmé « on ne peut pas faire de la sécurité dans un 
environnement non sûr » !!! (j’ai lu ça ; je recherche la source). 

Encore une nouvelle faille en 2023 : CVE-2023-35866
19/07/2023
https://www.it-connect.fr/une-faille-de-securite-keepassxc-permet-de-changer-le-mot-de-passe-maitre-lediteur-conteste/
L’éditeur écrit :
 "Pour l'instant, nous ne prévoyons pas de modifier radicalement le programme 
pour répondre à cette demande." - Et aussi : "La solution la plus simple pour 
contrer ce vecteur de menace est de verrouiller votre base de données avant de 
quitter votre poste de travail."


Rappel : ne quittez pas votre poste en laissant la BD déverrouillée :
https://security.stackexchange.com/questions/115086/is-it-safe-to-leave-keepass-always-opened-on-a-computer
 

On attend la révélation des autres failles ou faiblesses…

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> Après vérification, et sauf erreur ou omission de ma part, je regrette
> mais en cryptographie asymétrique, seule la clef privée permet de
> DÉchiffrer.
> Tandis que la clef publique permet à tout le monde de chiffrer un message. 

Oui tu as raison, autant pour moi, ça fait du bien de relire les bases de
temps en temps. Voilà une description assez claire :
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

>>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>> 
>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd 
> qui ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 

keepass est validé par le gouvernement
https://www.ssi.gouv.fr/entreprise/certification_cspn/keepass-version-2-10-portable/
D'autres gestionnaires attaqués dont j'ai entendu parlé (1password, etc) 
avaient du
stockage en ligne, ce n'est pas le cas de keepass. As-tu les références 
d'articles ?

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 16:32, Michel Verdier  a écrit :
> Le 19 juillet 2023 RogerT a écrit :
> 
>> Pour chiffrer une phrase il suffit de la clef publique. 
>> Pour déchiffrer une phrase il faut la clef privée.
> 
> Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
> diffuses la publique à tous ceux qui doivent déchiffrer

Après vérification, et sauf erreur ou omission de ma part, je regrette mais en 
cryptographie asymétrique, seule la clef privée permet de DÉchiffrer. 
Tandis que la clef publique permet à tout le monde de chiffrer un message. 

En cas d’erreur de ma part, je te/vous remercie de m’expliquer en quoi je me 
tromperais alors que c’est le premier cas de figure ultra connu entre Alice et 
Bob pour échanger un secret (chiffré avec la clef publique et déchiffré avec la 
seule clef privée). 

> 
>> Le serveur a seulement la clef publique.  
> 
> Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
> lesquels tu dois te connecter) ont la publique
Le serveur distant a la clef publique que j’y ai copié. Mais pas pour 
déchiffrer. Voir plus haut. Sauf erreur ou omission. 


>> Le client a les deux clefs. 
>> Seul le client peut déchiffrer une phrase chiffrée.
> 
> Non, seul le client peut chiffrer

Tous ceux qui ont la clef publique peuvent chiffrer. 
Et aussi celui qui a seulement la clef privée car elle permet de générer une 
clef publique (je suppose qu’on peut chiffrer aussi avec la clef privée)

> 
>> Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
>> la clef privée qui frappe à la porte ?
> 
> Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
> client avec sa clef privée
Toujours pas d’accord. 
Peut-être as-tu un détail de la séquence entre client et serveur ?


>>> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
>>> facteurs d'authentification.
>> Ça enlève l’intérêt d’une authentification rapide.
>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
> 
> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd qui 
ont tous déjà été attaqués. Y compris dashlane. Voir divers articles. 

> 
>>> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
>>> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
>>> pour qu'elle soit accessible par le client.
>> Entendu.
>> Modulo le nom du dev /dev/sdb …
>> Sauf à utiliser un UUID pour le device (ça se fait, je crois).
> 
> oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, avec
> l'option user, et le client fait un mount du nom du répertoire que tu
> précise. Par exemple chez moi :
> 
> #/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" 
> BLOCK_SIZE="512" TYPE="vfat" PARTUUID="f42f95e2-01"
> LABEL="CLEF"/media/usb   vfat user,noexec,noauto,noatime,lazytime 
> 0   2
> 
> PARTUUID="42711922-2694-43bd-bf1f-9d6a7fccebec" /media/backup exfat 
> user,noexec,noauto,noatime,lazytime 0   0
> 
> /dev/mmcblk0p1 /media/sd  xfs 
> user,noexec,noauto,rw,noatime,inode64,logbufs=8,logbsize=32k,noquota,lazytime 
> 0 0
Ok. Merci. 


>> Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, 
>> et
>> aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans 
>> doute
>> utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification
>> LDAP).
> 
> A la base les PAM c'est plutôt pour le local, d'ailleurs sshd appelle les
> PAM pour établir la session. Là ce que tu travailles c'est la
> sécurisation d'une connexion ssh sur le client, donc à priori aucun
> rapport avec les PAM.
> Mais peut-être plutôt avec udev qui peut lancer le ssh qui va bien dès
> que tu insères une clef USB ?

Je ne sais pas trop. 
PAM offre aux applications une interface standard pour l’authentification qui 
permet de s’affranchir du mécanisme sous-jacent. Je suis en train d’étudier 
PAM. 

Re: Authentification ssh et PAM

[Michel Verdier]

Le 19 juillet 2023 RogerT a écrit :

> Pour chiffrer une phrase il suffit de la clef publique. 
> Pour déchiffrer une phrase il faut la clef privée. 

Non c'est l'inverse. C'est pour ça que seul toi a la privée et que tu
diffuses la publique à tous ceux qui doivent déchiffrer

> Le serveur a seulement la clef publique.  

Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
lesquels tu dois te connecter) ont la publique

> Le client a les deux clefs. 
> Seul le client peut déchiffrer une phrase chiffrée. 

Non, seul le client peut chiffrer

> Comment fait le serveur ssh pour savoir que c’est bien le détenteur de
> la clef privée qui frappe à la porte ?

Parce qu'il décode, avec la clef publique, une phrase chiffrée par le
client avec sa clef privée

>> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
>> facteurs d'authentification.
> Ça enlève l’intérêt d’une authentification rapide.
> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…

Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc

>> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
>> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
>> pour qu'elle soit accessible par le client.
> Entendu.
> Modulo le nom du dev /dev/sdb …
> Sauf à utiliser un UUID pour le device (ça se fait, je crois). 

oui tu mets ce qui va bien avec uuid ou partuid ou label dans /etc/fstab, avec
l'option user, et le client fait un mount du nom du répertoire que tu
précise. Par exemple chez moi :

#/dev/sdc1: LABEL_FATBOOT="CLEF" LABEL="CLEF" UUID="CC7E-404F" BLOCK_SIZE="512" 
TYPE="vfat" PARTUUID="f42f95e2-01"
LABEL="CLEF"/media/usb   vfat user,noexec,noauto,noatime,lazytime 0 
  2

PARTUUID="42711922-2694-43bd-bf1f-9d6a7fccebec" /media/backup exfat 
user,noexec,noauto,noatime,lazytime 0   0

/dev/mmcblk0p1 /media/sd  xfs 
user,noexec,noauto,rw,noatime,inode64,logbufs=8,logbsize=32k,noquota,lazytime   
  0 0

> Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, et
> aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans doute
> utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification
> LDAP).

A la base les PAM c'est plutôt pour le local, d'ailleurs sshd appelle les
PAM pour établir la session. Là ce que tu travailles c'est la
sécurisation d'une connexion ssh sur le client, donc à priori aucun
rapport avec les PAM.
Mais peut-être plutôt avec udev qui peut lancer le ssh qui va bien dès
que tu insères une clef USB ?

Re: Authentification ssh et PAM

[didier gaumet]

Le 19/07/2023 à 11:26, RogerT a écrit :

Merci beaucoup pour tes pointeurs. Je vais étudier ça.

Le HSM gérera la clef ; ou plutôt il gérera la passphrase de protection 
beaucoup plus courte que la clef elle-même 2048 bits.

En pratique, sais-tu si pour utiliser un HSM on DOIT s’interfacer avec le 
système via PAM ? (Je me dis que oui, car je crois savoir que 
l’authentification par LDAP passe par PAM).
Qui a de l’expérience sur utiliser un HSM via ou sans PAM ?
Merci.


rappel d'avertissement: je suis une tanche en réseau et sécurité, donc 
ne te fie surtout pas à mes suppositions sans te référer à des personnes 
dont tu estimes qu'elles ont une expertise valable et sans étudier avec 
esprit critique les solutions possibles.


J'ai l'*impression* (je suis une tanche) que les bonnes pratiques 
actuellement recommandent l'emploi de PAM au sein d'un groupe de 
solutions lorsqu'il s'agit d'un contexte réseau global (exemple: réseau 
d'une grosse entreprise, par opposition à un réseau d'un particulier 
offrant un unique service quelconque sans que les conséquences soient 
catastrophiques si il y a intrusion dans le réseau) ayant des impératifs 
de sécurité.


Mais j'ai l'*impression* qu'il est possible, même pour un administrateur 
réseau consciencieux et prudent, d'avoir laissé des trous dans sa config 
PAM qui permettent le contournement de PAM.


Donc j'ai l'*impression* aussi qu'il doit être possible de 
volontairement court-circuiter PAM pour employer un HSM, probablement 
dans un but de simplification


Mais j'ai aussi l'*impression* que ce serait potentiellement 
contre-productif puisque le but de PAM me semblant plus ou moins de 
border la sécurité d'accès en général et l'emploi d'un HSM représentant 
un cas d'emploi, ce serait alors potentiellement bizarre de vouloir 
contourner PAM par facilité.


Tu noteras que ça fait beaucoup d'impressions et qu'il ne serait pas 
sage de s'appuyer trop fort là-dessus ;-)


Si tu me permets une suggestion (amicale et d'un ignare du sujet), la 
réponse que t'a faite Michel Verdier par ailleurs pourrait laisser 
penser que comme moi, il s'interroge sur la clarté de tes objectifs 
(qu'est-ce que tu veux faire exactement?), et peut-être pourrais-tu 
essayer de débroussailler le but à atteindre sans dans un premier temps 
envisager les moyens à mettre en oeuvre (ici un HSM) car ça influe sur 
la réflexion


:-)

Re: Authentification ssh et PAM

[RogerT]

Merci beaucoup pour tes pointeurs. Je vais étudier ça.

Le HSM gérera la clef ; ou plutôt il gérera la passphrase de protection 
beaucoup plus courte que la clef elle-même 2048 bits.

En pratique, sais-tu si pour utiliser un HSM on DOIT s’interfacer avec le 
système via PAM ? (Je me dis que oui, car je crois savoir que 
l’authentification par LDAP passe par PAM).  
Qui a de l’expérience sur utiliser un HSM via ou sans PAM ?
Merci. 


> Le 19 juil. 2023 à 10:08, didier gaumet  a écrit :
> 
> je n'y connais rien mais tu peux éventuellement consulter ce qui suit:
> 
> - sur le fonctionnement général de PAM: la vieille doc de kernel.org (The 
> Linux-PAM System Administrators' Guide) n'est plus semble-t-il disponible sur 
> le site d'origine mais on la dtouve encore ailleurs:
> https://beausanders.org/linux_shared_files/Linux-PAM_System_Administrators_Guide.pdf
> la mage man de PAM(8) peut aussi être consultée
> 
> - sur le principe général (avec diagrammes, plus visuels) de l'emploi des 
> smartcards (sous-type de HSM); RedHat propose cette doc:
> https://www.redhat.com/en/blog/consistent-pkcs-11-support-red-hat-enterprise-linux-8
> 
> - sur la configuration particulière nécessaire à cet usage en liaison avec 
> des applis/serveurs, Red Hat propose cette doc:
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-applications-to-use-cryptographic-hardware-through-pkcs-11_security-hardening
> 

Re: Authentification ssh et PAM

[RogerT]

> Le 19 juil. 2023 à 09:05, Michel Verdier  a écrit :
> Le 18 juillet 2023 roger tarani a écrit :
> 
>> Quel est le mécanisme détaillé conduisant à l'authentification de 
>> l'utilisateur par l'hôte distant ? 
>> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef 
>> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )
> 
> La clef publique est indiquée au serveur lors de la demande de connexion.
> Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
> client avec sa clef privée.

Je ne comprends pas. 
Pour chiffrer une phrase il suffit de la clef publique. 
Pour déchiffrer une phrase il faut la clef privée. 
Le serveur a seulement la clef publique.  
Le client a les deux clefs. 
Seul le client peut déchiffrer une phrase chiffrée. 
Comment fait le serveur ssh pour savoir que c’est bien le détenteur de la clef 
privée qui frappe à la porte ?
Je ne vois que ça : le serveur chiffre une phrase et l’envoie au client qui lui 
retourne déchiffrée. Il compare et constate si le client a su déchiffrer. C’est 
ça ?

>> Stocker la clef privée localement avec pour seule protection des droits 600 
>> me semble léger même si c'est habituel.
> 
> L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
> facteurs d'authentification.
Ça enlève l’intérêt d’une authentification rapide.
Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…

> 
>> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur 
>> une
>> clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément
>> sur un HSM, comment dois-je procéder pour qu'elle soit utilisée par le 
>> système
> 
> sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
> ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
> pour qu'elle soit accessible par le client.
Entendu.
Modulo le nom du dev /dev/sdb …
Sauf à utiliser un UUID pour le device (ça se fait, je crois). 

> 
>> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>>  
>> 
>> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte 
>> local et le HSM afin de réaliser une authentification ssh ? 
>> Comment faut-il faire ?
> 
> Je ne comprend pas ce que tu cherches à faire ? Tu veux qu'une
> authentification PAM passe par ssh et pas par le login habituel ?
Je me dis que pour que le HSM se substitue à moi dans la gestion des clefs, et 
aller au-delà d’indiquer le chemin de la clef (avec ssh -i) il faut sans doute 
utiliser PAM (d’ailleurs, qui sert aussi à interfacer une authentification 
LDAP).

Re: Authentification ssh et PAM

[didier gaumet]

je n'y connais rien mais tu peux éventuellement consulter ce qui suit:

- sur le fonctionnement général de PAM: la vieille doc de kernel.org 
(The Linux-PAM System Administrators' Guide) n'est plus semble-t-il 
disponible sur le site d'origine mais on la dtouve encore ailleurs:

https://beausanders.org/linux_shared_files/Linux-PAM_System_Administrators_Guide.pdf
la mage man de PAM(8) peut aussi être consultée

- sur le principe général (avec diagrammes, plus visuels) de l'emploi 
des smartcards (sous-type de HSM); RedHat propose cette doc:

https://www.redhat.com/en/blog/consistent-pkcs-11-support-red-hat-enterprise-linux-8

- sur la configuration particulière nécessaire à cet usage en liaison 
avec des applis/serveurs, Red Hat propose cette doc:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-applications-to-use-cryptographic-hardware-through-pkcs-11_security-hardening

Re: Authentification ssh et PAM

[Michel Verdier]

Le 18 juillet 2023 roger tarani a écrit :

> Quel est le mécanisme détaillé conduisant à l'authentification de 
> l'utilisateur par l'hôte distant ? 
> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef 
> privée sont-elles liées ? par la création d'un jeton ? ou autre ? ) 

La clef publique est indiquée au serveur lors de la demande de connexion.
Le serveur s'en sert ensuite pour décrypter une phrase cryptée par le
client avec sa clef privée.

> Stocker la clef privée localement avec pour seule protection des droits 600 
> me semble léger même si c'est habituel. 

L'idée c'est quand même d'y mettre un mot de passe pour avoir les 2
facteurs d'authentification.

> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur une
> clef flash déconnectée du réseau (avec ou sans chiffrement), soit carrément
> sur un HSM, comment dois-je procéder pour qu'elle soit utilisée par le système

sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
pour qu'elle soit accessible par le client.

> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>  
>
> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte 
> local et le HSM afin de réaliser une authentification ssh ? 
> Comment faut-il faire ? 

Je ne comprend pas ce que tu cherches à faire ? Tu veux qu'une
authentification PAM passe par ssh et pas par le login habituel ?

Re: Authentification ssh et PAM

[RogerT]

Merci. 
Je connais l’usage.

Je voudrais savoir comment fonctionne le mécanisme d’authentification par clefs 
asymétriques permettant de donner l’accès à l’hôte distant. Qui fait quoi. 

Et surtout comment procéder pour utiliser un HSM ou une clef USB où sera 
stockée la clef privée. Et aussi savoir si on doit utiliser PAM, et comment.



> Le 19 juil. 2023 à 00:00, ajh-valmer  a écrit :
> 
> Il suffit de taper 3 mots dans un moteur de recherche :
> www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server-fr
> :-)
> 
>> On Tuesday 18 July 2023 18:16:21 roger.tar...@free.fr wrote:
>> Un utilisateur dispose d'une clef ssh privée et d'une clef publique 
>> rangés dans ~/.ssh/ , avec des droits 600.  
>> S'il a copié la clef publique sur un serveur distant, l'agent local
>> saura "lier la clef publique et la privée" pour lui donner accès à l'hôte
>> distant sans besoin de saisir id et pwd.   
>> Classique. 
>> Quel est le mécanisme détaillé conduisant à l'authentification de
>> l'utilisateur par l'hôte distant ?  
>> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef
>> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )  
>> Stocker la clef privée localement avec pour seule protection des droits 600
>> me semble léger même si c'est habituel.  
>> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur
>> une clef flash déconnectée du réseau (avec ou sans chiffrement), soit
>> carrément sur un HSM, comment dois-je procéder pour qu'elle soit utilisée
>> par le système ?
>> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>> https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
>>  
>> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte
>> local et le HSM afin de réaliser une authentification ssh ?  
>> Comment faut-il faire ?
> 

Re: Authentification ssh et PAM

[ajh-valmer]

Il suffit de taper 3 mots dans un moteur de recherche :
www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server-fr
:-)

On Tuesday 18 July 2023 18:16:21 roger.tar...@free.fr wrote:
> Un utilisateur dispose d'une clef ssh privée et d'une clef publique 
> rangés dans ~/.ssh/ , avec des droits 600.  
> S'il a copié la clef publique sur un serveur distant, l'agent local
> saura "lier la clef publique et la privée" pour lui donner accès à l'hôte
> distant sans besoin de saisir id et pwd.   
> Classique. 
> Quel est le mécanisme détaillé conduisant à l'authentification de
> l'utilisateur par l'hôte distant ?  
> (la clef privée reste sur l'hôte local ; comment la clef publique et la clef
> privée sont-elles liées ? par la création d'un jeton ? ou autre ? )  
> Stocker la clef privée localement avec pour seule protection des droits 600
> me semble léger même si c'est habituel.  
> Si je décide de stocker la clef privée en dehors de l'hôte local, soit sur
> une clef flash déconnectée du réseau (avec ou sans chiffrement), soit
> carrément sur un HSM, comment dois-je procéder pour qu'elle soit utilisée
> par le système ?
> En cherchant, j'ai lu des choses sur PAM que je n'ai jamais pratiqué. 
>https://linux.goffinet.org/administration/securite-locale/pluggable-authentication-modules-pam/
> 
> Puis-je utiliser ce qui existe (biblio PAM) pour faire communiquer l'hôte
> local et le HSM afin de réaliser une authentification ssh ?  
> Comment faut-il faire ?

Re: Authentification mixte Linux/AD

[Pierre Malard]

Bonjour,

Est-ce que cela ne viendrait pas de la configuration de nss ?
Et/ou la configuration de pam.d ?
Voir votre fichier /etc/nsswitch.conf et ce qui a été modifié
(ou pas) dans /etc/pam.d/ comme « common-* » .

Attention tout cela est à manier avec précaution car vous pouvez
arriver à … votre situation. ;-)
Au point où vous en êtes… une bonne lecture des « man » avec une
recherche documentaire pourrait être utile. Lisez la page
https://wiki.debian.org/LDAP/Kerberos elle aborde justement la
configuration de PAM, NSS, …
Idem avec https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectory,
voir les paragraphes « Setup Authentification », « PAM » et …

Cordialement


> Le 24 avr. 2020 à 22:45, Jean-Luc Chandezon  a écrit :
> 
> 
> Bonjour,
> 
> J’ai paramétré l’authentification Active Directory va Kerberos en suivant le 
> documentation https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectory, 
> et ça fonctionne bien.
> J’ai bien ajouté un groupe AD dans sudoers, sans problème. Le suffixe par 
> défaut est @mydomain.ad. Les utilisateurs n’ont donc pas besoin de le saisir.
> 
> Le problème est que, même localement, je ne peux plus ouvrir de session avec 
> root, ou avec un utilisateur local. Est-ce que cela est possible ? J’ai testé 
> root@localhost par exemple, sans succès.
> Voici ci-dessous le paramétrage de krb5.conf.
> 
> Merci
> 
> ---
> logging]
> Default = FILE:/var/log/krb5.log
> 
> [libdefaults]
> ticket_lifetime = 24000
> click-skew = 300
> default_realm = MYDOMAIN.AD
> 
> # The following krb5.conf variables are only for MIT Kerberos.
> kdc_timesync = 1
> ccache_type = 4
> forwardable = true
> proxiable = true
> [realms]
> MYDOMAIN.AD = {
> kdc = mydomain.ad:88
> admin_server = mydomain.ad:464
> default_domain = mydomain.ad
> }
> 
> Jean-Luc

--
Pierre Malard

   « Si, comme le disait le général de Gaulle, la France n'avait pas été la
   France... on peut logiquement penser que tous les français auraient été
   des étrangers » ;-)
   
Pierre Dac
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Authentification failure

[steve]

Le 05-06-2019, à 14:23:04 +0200, Yahoo a écrit :



Il est donc possible que  soit trop simple


C'est ce qui semble en effet. J'ai choisi un port différent (guess what)
et depuis 4 jours, pas une seule tentative !

Re: Authentification failure

[Florian Blanc]

Je persiste et signe qu'un DROP est je ne sais combien de fois mieux qu'un
REJECT sur du traffic non legit.
Il le bénéfice de masquer ton service.
Le botnets peuvent avoir le timeout qu'ils veulent même de 1s c'est pas un
problème.
Justement à chaque DROP tu économise un ICMP destination-unreachable par
rapport au REJECT...

après niveau lectures tu trouveras toujours de tout du style: les
reptiliens existent et voici un peu de lecture :
https://8e-etage.fr/2014/11/07/les-reptiliens-la-plus-grande-conspiration-politique-jamais-inventee/


Le ven. 7 juin 2019 à 19:37, daniel huhardeaux  a
écrit :

> Le 07/06/2019 à 18:40, Florian Blanc a écrit :
> > le client va timeout
>
> Sauf qu'un attaquant ne va pas utiliser des scanners habituels mais des
> outils spécifiques qui pour eux DROP ou REJECT ne change rien, leur
> timeout sera très court
>
> Une lecture par ex.
>
> http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
>
> >
> > Le ven. 7 juin 2019 à 18:39, Florian Blanc  > > a écrit :
> >
> >  > si on peut lister les URL légitimes, un silent DROP systématique
> > permet de ne pas confirmer la présence d'une cible potentielle, non ?
> > exactement
> >
> > Le ven. 7 juin 2019 à 18:34, Eric Degenetais  > > a écrit :
> >
> > bonjour,
> > si on peut lister les URL légitimes, un silent DROP systématique
> > permet de ne pas confirmer la présence d'une cible potentielle,
> > non ?
> > À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour
> > arrêter les tentatives de brute force qui atteignent le service
> > protégé, a besoin d'enregistrer un certain nombre d'échecs avant
> > de bannir, donc l'existence et la nature de la cible (sshd) sont
> > confirmées à l'attaquant.
> >
> > Éric Dégenètais
> >
> > Le ven. 7 juin 2019 17:48, Daniel Caillibaud  > > a écrit :
> >
> > Le 07/06/19 à 16:39, Florian Blanc
> >  > > a écrit :
> >  >  > Et ça change vraiment grand chose ?
> >
> >  > cf. modele OSI ton firewall refusera les connexions layer
> > 3/4.
> >
> > Merci ;-)
> >
> > Ce que je voulais dire, c'est que le gain de perfs[1] est
> > tellement
> > négligeable que je pense qu'on arrive même pas à le mesurer
> > sur une machine
> > en prod (qui bosse).
> >
> > Mais ici le pb est pas tellement la perf, tu veux bloquer
> > des connexions
> > ssh avec un liste blanche d'ip (dynamique dans ton cas), ça
> > n'est pas
> > envisageable dans mon contexte (mes ssh publics doivent
> > rester accessibles
> > par trop d'ip ≠ qui changent tout le temps), et sur le fond
> > je vois pas
> > d'intérêt à sécuriser davantage ssh que de forcer la
> > connexion par clé.
> >
> > [1] si y'en a un, faudrait comparer ce que coûte une règle
> > iptable
> > supplémentaire (qq cycles cpu sur tous les paquets reçus) vs
> > qq connexions
> > ssh inutiles (sshd doit attendre une clé qui ne vient pas
> > puis couper).
> >
> > --
> > Daniel
> >
> > La médecine est un métier dangereux :
> > les clients qui ne meurent pas peuvent porter plainte.
> > Coluche
> >
>
>

Re: Authentification failure

[daniel huhardeaux]

Le 07/06/2019 à 18:40, Florian Blanc a écrit :

le client va timeout


Sauf qu'un attaquant ne va pas utiliser des scanners habituels mais des 
outils spécifiques qui pour eux DROP ou REJECT ne change rien, leur 
timeout sera très court


Une lecture par ex.

http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject



Le ven. 7 juin 2019 à 18:39, Florian Blanc > a écrit :


 > si on peut lister les URL légitimes, un silent DROP systématique
permet de ne pas confirmer la présence d'une cible potentielle, non ?
exactement

Le ven. 7 juin 2019 à 18:34, Eric Degenetais mailto:edegenet...@henix.fr>> a écrit :

bonjour,
si on peut lister les URL légitimes, un silent DROP systématique
permet de ne pas confirmer la présence d'une cible potentielle,
non ?
À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour
arrêter les tentatives de brute force qui atteignent le service
protégé, a besoin d'enregistrer un certain nombre d'échecs avant
de bannir, donc l'existence et la nature de la cible (sshd) sont
confirmées à l'attaquant.

Éric Dégenètais

Le ven. 7 juin 2019 17:48, Daniel Caillibaud mailto:m...@lairdutemps.org>> a écrit :

Le 07/06/19 à 16:39, Florian Blanc
mailto:florian.blanc@gmail.com>> a écrit :
 >  > Et ça change vraiment grand chose ?

 > cf. modele OSI ton firewall refusera les connexions layer
3/4.

Merci ;-)

Ce que je voulais dire, c'est que le gain de perfs[1] est
tellement
négligeable que je pense qu'on arrive même pas à le mesurer
sur une machine
en prod (qui bosse).

Mais ici le pb est pas tellement la perf, tu veux bloquer
des connexions
ssh avec un liste blanche d'ip (dynamique dans ton cas), ça
n'est pas
envisageable dans mon contexte (mes ssh publics doivent
rester accessibles
par trop d'ip ≠ qui changent tout le temps), et sur le fond
je vois pas
d'intérêt à sécuriser davantage ssh que de forcer la
connexion par clé.

[1] si y'en a un, faudrait comparer ce que coûte une règle
iptable
supplémentaire (qq cycles cpu sur tous les paquets reçus) vs
qq connexions
ssh inutiles (sshd doit attendre une clé qui ne vient pas
puis couper).

-- 
Daniel


La médecine est un métier dangereux :
les clients qui ne meurent pas peuvent porter plainte.
Coluche

Re: Authentification failure

[Florian Blanc]

le client va timeout

Le ven. 7 juin 2019 à 18:39, Florian Blanc  a
écrit :

> > si on peut lister les URL légitimes, un silent DROP systématique permet
> de ne pas confirmer la présence d'une cible potentielle, non ?
> exactement
>
> Le ven. 7 juin 2019 à 18:34, Eric Degenetais  a
> écrit :
>
>> bonjour,
>> si on peut lister les URL légitimes, un silent DROP systématique permet
>> de ne pas confirmer la présence d'une cible potentielle, non ?
>> À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour arrêter les
>> tentatives de brute force qui atteignent le service protégé, a besoin
>> d'enregistrer un certain nombre d'échecs avant de bannir, donc l'existence
>> et la nature de la cible (sshd) sont confirmées à l'attaquant.
>>
>> Éric Dégenètais
>>
>> Le ven. 7 juin 2019 17:48, Daniel Caillibaud  a
>> écrit :
>>
>>> Le 07/06/19 à 16:39, Florian Blanc  a
>>> écrit :
>>> >  > Et ça change vraiment grand chose ?
>>>
>>> > cf. modele OSI ton firewall refusera les connexions layer 3/4.
>>>
>>> Merci ;-)
>>>
>>> Ce que je voulais dire, c'est que le gain de perfs[1] est tellement
>>> négligeable que je pense qu'on arrive même pas à le mesurer sur une
>>> machine
>>> en prod (qui bosse).
>>>
>>> Mais ici le pb est pas tellement la perf, tu veux bloquer des connexions
>>> ssh avec un liste blanche d'ip (dynamique dans ton cas), ça n'est pas
>>> envisageable dans mon contexte (mes ssh publics doivent rester
>>> accessibles
>>> par trop d'ip ≠ qui changent tout le temps), et sur le fond je vois pas
>>> d'intérêt à sécuriser davantage ssh que de forcer la connexion par clé.
>>>
>>> [1] si y'en a un, faudrait comparer ce que coûte une règle iptable
>>> supplémentaire (qq cycles cpu sur tous les paquets reçus) vs qq
>>> connexions
>>> ssh inutiles (sshd doit attendre une clé qui ne vient pas puis couper).
>>>
>>> --
>>> Daniel
>>>
>>> La médecine est un métier dangereux :
>>> les clients qui ne meurent pas peuvent porter plainte.
>>> Coluche
>>>
>>>

Re: Authentification failure

[Florian Blanc]

> si on peut lister les URL légitimes, un silent DROP systématique permet
de ne pas confirmer la présence d'une cible potentielle, non ?
exactement

Le ven. 7 juin 2019 à 18:34, Eric Degenetais  a
écrit :

> bonjour,
> si on peut lister les URL légitimes, un silent DROP systématique permet de
> ne pas confirmer la présence d'une cible potentielle, non ?
> À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour arrêter les
> tentatives de brute force qui atteignent le service protégé, a besoin
> d'enregistrer un certain nombre d'échecs avant de bannir, donc l'existence
> et la nature de la cible (sshd) sont confirmées à l'attaquant.
>
> Éric Dégenètais
>
> Le ven. 7 juin 2019 17:48, Daniel Caillibaud  a
> écrit :
>
>> Le 07/06/19 à 16:39, Florian Blanc  a écrit
>> :
>> >  > Et ça change vraiment grand chose ?
>>
>> > cf. modele OSI ton firewall refusera les connexions layer 3/4.
>>
>> Merci ;-)
>>
>> Ce que je voulais dire, c'est que le gain de perfs[1] est tellement
>> négligeable que je pense qu'on arrive même pas à le mesurer sur une
>> machine
>> en prod (qui bosse).
>>
>> Mais ici le pb est pas tellement la perf, tu veux bloquer des connexions
>> ssh avec un liste blanche d'ip (dynamique dans ton cas), ça n'est pas
>> envisageable dans mon contexte (mes ssh publics doivent rester accessibles
>> par trop d'ip ≠ qui changent tout le temps), et sur le fond je vois pas
>> d'intérêt à sécuriser davantage ssh que de forcer la connexion par clé.
>>
>> [1] si y'en a un, faudrait comparer ce que coûte une règle iptable
>> supplémentaire (qq cycles cpu sur tous les paquets reçus) vs qq connexions
>> ssh inutiles (sshd doit attendre une clé qui ne vient pas puis couper).
>>
>> --
>> Daniel
>>
>> La médecine est un métier dangereux :
>> les clients qui ne meurent pas peuvent porter plainte.
>> Coluche
>>
>>

Re: Authentification failure

[Eric Degenetais]

bonjour,
si on peut lister les URL légitimes, un silent DROP systématique permet de
ne pas confirmer la présence d'une cible potentielle, non ?
À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour arrêter les
tentatives de brute force qui atteignent le service protégé, a besoin
d'enregistrer un certain nombre d'échecs avant de bannir, donc l'existence
et la nature de la cible (sshd) sont confirmées à l'attaquant.

Éric Dégenètais

Le ven. 7 juin 2019 17:48, Daniel Caillibaud  a écrit :

> Le 07/06/19 à 16:39, Florian Blanc  a écrit :
> >  > Et ça change vraiment grand chose ?
>
> > cf. modele OSI ton firewall refusera les connexions layer 3/4.
>
> Merci ;-)
>
> Ce que je voulais dire, c'est que le gain de perfs[1] est tellement
> négligeable que je pense qu'on arrive même pas à le mesurer sur une machine
> en prod (qui bosse).
>
> Mais ici le pb est pas tellement la perf, tu veux bloquer des connexions
> ssh avec un liste blanche d'ip (dynamique dans ton cas), ça n'est pas
> envisageable dans mon contexte (mes ssh publics doivent rester accessibles
> par trop d'ip ≠ qui changent tout le temps), et sur le fond je vois pas
> d'intérêt à sécuriser davantage ssh que de forcer la connexion par clé.
>
> [1] si y'en a un, faudrait comparer ce que coûte une règle iptable
> supplémentaire (qq cycles cpu sur tous les paquets reçus) vs qq connexions
> ssh inutiles (sshd doit attendre une clé qui ne vient pas puis couper).
>
> --
> Daniel
>
> La médecine est un métier dangereux :
> les clients qui ne meurent pas peuvent porter plainte.
> Coluche
>
>

Re: Authentification failure

[Daniel Caillibaud]

Le 07/06/19 à 16:39, Florian Blanc  a écrit :
>  > Et ça change vraiment grand chose ?

> cf. modele OSI ton firewall refusera les connexions layer 3/4.

Merci ;-)

Ce que je voulais dire, c'est que le gain de perfs[1] est tellement
négligeable que je pense qu'on arrive même pas à le mesurer sur une machine
en prod (qui bosse).

Mais ici le pb est pas tellement la perf, tu veux bloquer des connexions
ssh avec un liste blanche d'ip (dynamique dans ton cas), ça n'est pas
envisageable dans mon contexte (mes ssh publics doivent rester accessibles
par trop d'ip ≠ qui changent tout le temps), et sur le fond je vois pas
d'intérêt à sécuriser davantage ssh que de forcer la connexion par clé.

[1] si y'en a un, faudrait comparer ce que coûte une règle iptable
supplémentaire (qq cycles cpu sur tous les paquets reçus) vs qq connexions
ssh inutiles (sshd doit attendre une clé qui ne vient pas puis couper).

-- 
Daniel

La médecine est un métier dangereux :
les clients qui ne meurent pas peuvent porter plainte.
Coluche

Re: Authentification failure

[Florian Blanc]

 > Et ça change vraiment grand chose ?
cf. modele OSI ton firewall refusera les connexions layer 3/4.

> C'est ça que je comprends pas trop, quel rapport avec ip fixe ou pas ?
> Sans ip fixe ça fonctionne aussi très bien avec un ssh classique sur le
> port 22 (sans ces règles iptables).
Si client avec ip fixe, tu ajoutes ta règle définitivement.
Si client avec ip dynamique ou nomade, ta règle doit évoluer .. (d'où
l'utilisation du noip avec cron).

> Ta solution bloque le port 22 si on arrive pas de la bonne ip, qu'elle
soit
> fixe ou pas, et c'est ça que je trouve pas très utile (car me concernant
> je veux pas restreindre l'accès ssh à une seule ip, mais je pensais
surtout
> au gain du port fermé si on vient pas du bon endroit vs l'énergie à
déployer
> pour maintenir ces règles et la perte potentielle de temps le jour où on
> voudra comprendre pourquoi un truc standard marche pas), mais ça reste mon
> avis, y'a pas de jugement de valeur.
bin une règle par ip ( ou noip )/range/network.
le reste du traffic non legit => DROP.
(la requête est encaissée mais pas de retour client ni de propagation).

Le ven. 7 juin 2019 à 14:25, Daniel Caillibaud  a
écrit :

> Le 07/06/19 à 03:53, Florian Blanc  a écrit :
> > Alors non ssh ne recevra seulement les requêtes provenant de l'adresse Ip
> > autorisée dans iptables tu le sais,  donc tout le reste du traffic sera
> > traité par iptables et non par le service.
>
> Et ça change vraiment grand chose ?
>
> Car un ssh qui écoute, ouvre une connexion pour attendre une clé et
> referme, même avec des ssh souvent attaqués en bruteforce, ça se voit pas
> sur mes mesures tellement c'est négligeable devant le reste.
>
> Avec ta solution iptables ça lui fait une chaîne de plus à traiter pour
> chaque paquet entrant, ça doit pas être bien cher non plus mais je ne suis
> pas sûr que ce soit meilleur coté perfs (j'en sais rien, et amha la perf
> n'est pas le pb ici).
>
> > Effectivement je flush une chaîne iptables et je réinsére mes (3)règles
> > (dynamiques seulement) avec résolution dns(3) toutes les 20 minutes.
> Alors
> > bench le si tu veux mais c'est rien comparé aux flux que tu as si tu
> > laisse tout le monde accéder jusqu'à l'authentification du service.
> > (3 car 3 postes clients, même plus ça serait pas un problème).
> >
> > Et pour finir la mise à jour du noip c'est côté client donc ça c'est pas
> > un problème on en parle même pas.
> >
> > Ma solution n'est pas la meilleure mais c'est une bonne alternative si on
> > n'a pas d'ip fixe côté client bien entendu.
>
> C'est ça que je comprends pas trop, quel rapport avec ip fixe ou pas ?
>
> Sans ip fixe ça fonctionne aussi très bien avec un ssh classique sur le
> port 22 (sans ces règles iptables).
>
> Ta solution bloque le port 22 si on arrive pas de la bonne ip, qu'elle soit
> fixe ou pas, et c'est ça que je trouve pas très utile (car me concernant
> je veux pas restreindre l'accès ssh à une seule ip, mais je pensais surtout
> au gain du port fermé si on vient pas du bon endroit vs l'énergie à
> déployer
> pour maintenir ces règles et la perte potentielle de temps le jour où on
> voudra comprendre pourquoi un truc standard marche pas), mais ça reste mon
> avis, y'a pas de jugement de valeur.
>
> Amicalement,
>
> --
> Daniel
>
> Un clavier azerty en vaut deux.
>
>

Re: Authentification failure

[Daniel Caillibaud]

Le 07/06/19 à 03:53, Florian Blanc  a écrit :
> Alors non ssh ne recevra seulement les requêtes provenant de l'adresse Ip
> autorisée dans iptables tu le sais,  donc tout le reste du traffic sera
> traité par iptables et non par le service.

Et ça change vraiment grand chose ?

Car un ssh qui écoute, ouvre une connexion pour attendre une clé et
referme, même avec des ssh souvent attaqués en bruteforce, ça se voit pas
sur mes mesures tellement c'est négligeable devant le reste.

Avec ta solution iptables ça lui fait une chaîne de plus à traiter pour
chaque paquet entrant, ça doit pas être bien cher non plus mais je ne suis
pas sûr que ce soit meilleur coté perfs (j'en sais rien, et amha la perf
n'est pas le pb ici).

> Effectivement je flush une chaîne iptables et je réinsére mes (3)règles
> (dynamiques seulement) avec résolution dns(3) toutes les 20 minutes. Alors
> bench le si tu veux mais c'est rien comparé aux flux que tu as si tu
> laisse tout le monde accéder jusqu'à l'authentification du service.
> (3 car 3 postes clients, même plus ça serait pas un problème).
> 
> Et pour finir la mise à jour du noip c'est côté client donc ça c'est pas
> un problème on en parle même pas.
> 
> Ma solution n'est pas la meilleure mais c'est une bonne alternative si on
> n'a pas d'ip fixe côté client bien entendu.

C'est ça que je comprends pas trop, quel rapport avec ip fixe ou pas ?

Sans ip fixe ça fonctionne aussi très bien avec un ssh classique sur le
port 22 (sans ces règles iptables). 

Ta solution bloque le port 22 si on arrive pas de la bonne ip, qu'elle soit
fixe ou pas, et c'est ça que je trouve pas très utile (car me concernant
je veux pas restreindre l'accès ssh à une seule ip, mais je pensais surtout
au gain du port fermé si on vient pas du bon endroit vs l'énergie à déployer
pour maintenir ces règles et la perte potentielle de temps le jour où on
voudra comprendre pourquoi un truc standard marche pas), mais ça reste mon
avis, y'a pas de jugement de valeur.

Amicalement,

-- 
Daniel

Un clavier azerty en vaut deux.

Re: Authentification failure

[Florian Blanc]

C'est dommage on arrive dans tes retranchements, pour quelqu'un
d'omniscient ça doit faire bizarre.

Alors non ssh ne recevra seulement les requêtes provenant de l'adresse Ip
autorisée dans iptables tu le sais,  donc tout le reste du traffic sera
traité par iptables et non par le service.

Effectivement je flush une chaîne iptables et je réinsére mes (3)règles
(dynamiques seulement) avec résolution dns(3) toutes les 20 minutes. Alors
bench le si tu veux mais c'est rien comparé aux flux que tu as si tu laisse
tout le monde accéder jusqu'à l'authentification du service.
(3 car 3 postes clients, même plus ça serait pas un problème).

Et pour finir la mise à jour du noip c'est côté client donc ça c'est pas un
problème on en parle même pas.

Ma solution n'est pas la meilleure mais c'est une bonne alternative si on
n'a pas d'ip fixe côté client bien entendu.
Si tu es nomade, cette solution peut t'intéresser également.

C'est dommage car c'est pas la première fois que je te vois répondre ici et
tu as plein de connaissances. Malheureusement tu n'aime vraiment pas le
contre exemple ou solution qui ne va pas en ton sens.
Cependant t'as une bonne habileté rhétorique en général.

Un esprit humble plus communautaire et moins "mentorisé" serait apprécié.

Pour finir, iptables est livré avec un hitcount qui est très utile si vous
êtes capable de définir un nombre max de hit sur une durée par user pour
tel service. Finissez avec Fail2ban qui regarde les logs. (Ceux utilisant
des certificats ne sont pas exempts).

Bonne journée.

Re: Authentification failure

[Daniel Huhardeaux]

Le 06/06/2019 à 20:10, Florian Blanc a écrit :
Lol tu réduis la charge serveur au lieu de laisser ssh écouter et 
répondre à tout le net... (valable pour tous les types 
d'authentification ssh)

Merci de me faire savoir si je me trompe 👌


Je pense que oui:

. avec tes règles ssh écoute également tout le net, il doit bien savoir 
si c'est toi qui tente une connexion

. tu génères du trafic cron inutile toutes les 20mn
. tu génères du trafic pour mettre noip à jour


T'es le meilleur Daniel


Je suis d'accord, sa solution est la meilleure



On Thu, Jun 6, 2019, 19:42 Daniel Caillibaud > wrote:


Le 06/06/19 à 16:51, Florian Blanc mailto:florian.blanc@gmail.com>> a écrit :
 > Bon je vais vous livrer un petit secret.
 > J'utilise des noip qui mettent à jour mon ip public cliente sur
un dns.
 >
 > Sur mon script principal iptables je crée une chain qui s'appelle
 > INDYNAMIC à partir de INPUT:
 > /sbin/iptables -A INPUT -j INDYNAMIC
 >
 > Ensuite j'ai un second script iptables pour écraser mes regles
dynamique
 > comme ceci:
 > /sbin/iptables -F INDYNAMIC # ici je flush
 > /sbin/iptables -A INDYNAMIC -m tcp -p tcp --src
 > lolilol.dyndnsnoiplalala.io 
--dport 22 -j ACCEPT # j'autorise
 > lolilol.dyndnsnoiplalala.io 
sur le port 22 (il fait la résolution comme
 > un grand).
 >
 > je crontab ce dernier script qui s'execute toutes les x minutes
(20 par
 > exemple).
 > tu le combine à fail2ban et c'est bon.

C'est bien ce que je disais :

 > > Pourquoi faire (compliqué) ?

Car je ne vois aucun avantage par rapport à ne rien faire (en dehors de
virer l'auth par mot de passe si c'est pas déjà le cas).

-- 
Daniel


Certaines zones de pêche commencent a être tellement polluées
par les hydrocarbures qu'on y pêche des turbots diesels.
Philippe Geluck, Le chat

Re: Authentification failure

[Florian Blanc]

Lol tu réduis la charge serveur au lieu de laisser ssh écouter et répondre
à tout le net... (valable pour tous les types d'authentification ssh)
Merci de me faire savoir si je me trompe 👌
T'es le meilleur Daniel

On Thu, Jun 6, 2019, 19:42 Daniel Caillibaud  wrote:

> Le 06/06/19 à 16:51, Florian Blanc  a écrit :
> > Bon je vais vous livrer un petit secret.
> > J'utilise des noip qui mettent à jour mon ip public cliente sur un dns.
> >
> > Sur mon script principal iptables je crée une chain qui s'appelle
> > INDYNAMIC à partir de INPUT:
> > /sbin/iptables -A INPUT -j INDYNAMIC
> >
> > Ensuite j'ai un second script iptables pour écraser mes regles dynamique
> > comme ceci:
> > /sbin/iptables -F INDYNAMIC # ici je flush
> > /sbin/iptables -A INDYNAMIC -m tcp -p tcp --src
> > lolilol.dyndnsnoiplalala.io --dport 22 -j ACCEPT # j'autorise
> > lolilol.dyndnsnoiplalala.io sur le port 22 (il fait la résolution comme
> > un grand).
> >
> > je crontab ce dernier script qui s'execute toutes les x minutes (20 par
> > exemple).
> > tu le combine à fail2ban et c'est bon.
>
> C'est bien ce que je disais :
>
> > > Pourquoi faire (compliqué) ?
>
> Car je ne vois aucun avantage par rapport à ne rien faire (en dehors de
> virer l'auth par mot de passe si c'est pas déjà le cas).
>
> --
> Daniel
>
> Certaines zones de pêche commencent a être tellement polluées
> par les hydrocarbures qu'on y pêche des turbots diesels.
> Philippe Geluck, Le chat
>
>

Re: Authentification failure

[Daniel Caillibaud]

Le 06/06/19 à 16:51, Florian Blanc  a écrit :
> Bon je vais vous livrer un petit secret.
> J'utilise des noip qui mettent à jour mon ip public cliente sur un dns.
> 
> Sur mon script principal iptables je crée une chain qui s'appelle
> INDYNAMIC à partir de INPUT:
> /sbin/iptables -A INPUT -j INDYNAMIC
> 
> Ensuite j'ai un second script iptables pour écraser mes regles dynamique
> comme ceci:
> /sbin/iptables -F INDYNAMIC # ici je flush
> /sbin/iptables -A INDYNAMIC -m tcp -p tcp --src
> lolilol.dyndnsnoiplalala.io --dport 22 -j ACCEPT # j'autorise
> lolilol.dyndnsnoiplalala.io sur le port 22 (il fait la résolution comme
> un grand).
> 
> je crontab ce dernier script qui s'execute toutes les x minutes (20 par
> exemple).
> tu le combine à fail2ban et c'est bon.

C'est bien ce que je disais :

> > Pourquoi faire (compliqué) ?

Car je ne vois aucun avantage par rapport à ne rien faire (en dehors de
virer l'auth par mot de passe si c'est pas déjà le cas).

-- 
Daniel

Certaines zones de pêche commencent a être tellement polluées 
par les hydrocarbures qu'on y pêche des turbots diesels.
Philippe Geluck, Le chat

Re: Authentification failure

[Florian Blanc]

Bon je vais vous livrer un petit secret.
J'utilise des noip qui mettent à jour mon ip public cliente sur un dns.

Sur mon script principal iptables je crée une chain qui s'appelle INDYNAMIC
à partir de INPUT:
/sbin/iptables -A INPUT -j INDYNAMIC

Ensuite j'ai un second script iptables pour écraser mes regles dynamique
comme ceci:
/sbin/iptables -F INDYNAMIC # ici je flush
/sbin/iptables -A INDYNAMIC -m tcp -p tcp --src lolilol.dyndnsnoiplalala.io
--dport 22 -j ACCEPT # j'autorise lolilol.dyndnsnoiplalala.io sur le port
22 (il fait la résolution comme un grand).

je crontab ce dernier script qui s'execute toutes les x minutes (20 par
exemple).
tu le combine à fail2ban et c'est bon.

Le jeu. 6 juin 2019 à 15:45, Daniel Caillibaud  a
écrit :

> Le 06/06/19 à 10:31, Arnaud Gambonnet  a
> écrit :
> > Bonjour la liste,
> >
> > Je n'ai pas lu en détails le fil, mais pour protéger les demandes
> > intempestives de connexions ssh (et d'autres si besoin), il existe la
> > solution de port knocking.
>
> Pourquoi faire (compliqué) ?
>
> > Ce qui n’empêche pas de mettre en place une authentification par
> > certificat et fail2ban pour les services moins sensibles.
>
> Au contraire, auth par certif pour tous les serveurs, sensibles ou pas, et
> plus besoin de port knocking ni port exotique ni fail2ban, on peut rester
> sur du standard avec ssh sur le port 22 qui fonctionne comme attendu.
>
> --
> Daniel
>
> On devient jeune à soixante ans.
> Malheureusement c'est trop tard.
> Pablo Picasso
>
>

Re: Authentification failure

[Daniel Caillibaud]

Le 06/06/19 à 10:31, Arnaud Gambonnet  a écrit :
> Bonjour la liste,
> 
> Je n'ai pas lu en détails le fil, mais pour protéger les demandes
> intempestives de connexions ssh (et d'autres si besoin), il existe la
> solution de port knocking.

Pourquoi faire (compliqué) ?

> Ce qui n’empêche pas de mettre en place une authentification par
> certificat et fail2ban pour les services moins sensibles.

Au contraire, auth par certif pour tous les serveurs, sensibles ou pas, et
plus besoin de port knocking ni port exotique ni fail2ban, on peut rester
sur du standard avec ssh sur le port 22 qui fonctionne comme attendu.

-- 
Daniel

On devient jeune à soixante ans.
Malheureusement c'est trop tard.
Pablo Picasso

Re: Authentification failure

[Arnaud Gambonnet]

Bonjour la liste,

Je n'ai pas lu en détails le fil, mais pour protéger les demandes
intempestives de connexions ssh (et d'autres si besoin), il existe la
solution de port knocking.
Ce qui n’empêche pas de mettre en place une authentification par certificat
et fail2ban pour les services moins sensibles.

Bonnes cogitations...

Le jeu. 6 juin 2019 à 09:18, Pierre Malard  a écrit :

>
> > Le 6 juin 2019 à 09:09, Daniel Caillibaud  a écrit :
> >
> > Le 06/06/19 à 08:30, Pierre Malard  a écrit :
> >> Bonjour,
> >>
> >> Sans présumer de qui est le plus « méchant » (Chinois, Russes, USA, Fr…)
> >> et pratique le scan massif, je ne saurait trop conseiller un filtrage
> >> avec la limitation des ports ouverts par un pare-feu et, sur les
> serveurs
> >> ouverts, l’installation de « Fail2Ban » en validant les règles «
> récidive
> >> ».
> >
> > Sur un serveur en prod, l'intérêt d'un pare-feu est quand même très
> limité
> > (éventuellement pour gérer du throttle), à priori si un port est ouvert
> sur
> > une ip publique c'est qu'on veut qu'il soit accessible (sinon on l'aurait
> > pas ouvert là).
>
> Effectivement c’est pourquoi il y avait un « et » et non un « ou ».
>
> > Pour le sshd, le plus efficace reste encore de le configurer pour
> interdire
> > la connexion par mot de passe, ensuite fail2ban n'est plus nécessaire
> > (sinon pour réduire le bruit dans auth.log).
> >
> > Il faut mettre dans /etc/ssh/sshd_config la ligne :
> >
> >  PasswordAuthentication no
>
> Effectivement, c’est même l’option par défaut sur toute installation
> actuellement. C'était, dans mon esprit, la configuration de base mais il
> est vrai
> que ce n’est pas parce que « ça allait sans le dire qu’il ne faut pas …
> le dire ».
>
> Merci
>
> --
> Pierre Malard
> - --> Ce message n’engage que son auteur <--
>
>

Re: Authentification failure

[Pierre Malard]

> Le 6 juin 2019 à 09:09, Daniel Caillibaud  a écrit :
> 
> Le 06/06/19 à 08:30, Pierre Malard  a écrit :
>> Bonjour,
>> 
>> Sans présumer de qui est le plus « méchant » (Chinois, Russes, USA, Fr…)
>> et pratique le scan massif, je ne saurait trop conseiller un filtrage
>> avec la limitation des ports ouverts par un pare-feu et, sur les serveurs
>> ouverts, l’installation de « Fail2Ban » en validant les règles « récidive
>> ».
> 
> Sur un serveur en prod, l'intérêt d'un pare-feu est quand même très limité
> (éventuellement pour gérer du throttle), à priori si un port est ouvert sur
> une ip publique c'est qu'on veut qu'il soit accessible (sinon on l'aurait
> pas ouvert là).

Effectivement c’est pourquoi il y avait un « et » et non un « ou ».

> Pour le sshd, le plus efficace reste encore de le configurer pour interdire
> la connexion par mot de passe, ensuite fail2ban n'est plus nécessaire
> (sinon pour réduire le bruit dans auth.log).
> 
> Il faut mettre dans /etc/ssh/sshd_config la ligne :
> 
>  PasswordAuthentication no

Effectivement, c’est même l’option par défaut sur toute installation
actuellement. C'était, dans mon esprit, la configuration de base mais il est 
vrai
que ce n’est pas parce que « ça allait sans le dire qu’il ne faut pas …
le dire ».

Merci

--
Pierre Malard
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Authentification failure

[Daniel Caillibaud]

Le 06/06/19 à 08:30, Pierre Malard  a écrit :
> Bonjour,
> 
> Sans présumer de qui est le plus « méchant » (Chinois, Russes, USA, Fr…)
> et pratique le scan massif, je ne saurait trop conseiller un filtrage
> avec la limitation des ports ouverts par un pare-feu et, sur les serveurs
> ouverts, l’installation de « Fail2Ban » en validant les règles « récidive
> ».

Sur un serveur en prod, l'intérêt d'un pare-feu est quand même très limité
(éventuellement pour gérer du throttle), à priori si un port est ouvert sur
une ip publique c'est qu'on veut qu'il soit accessible (sinon on l'aurait
pas ouvert là).

Pour le sshd, le plus efficace reste encore de le configurer pour interdire
la connexion par mot de passe, ensuite fail2ban n'est plus nécessaire
(sinon pour réduire le bruit dans auth.log).

Il faut mettre dans /etc/ssh/sshd_config la ligne :

  PasswordAuthentication no

-- 
Daniel

Ne disons pas du mal du diable : c'est peut-être l'homme 
d'affaires du bon dieu.
Bernard Fontenelle 


pgpoEkqiupUlf.pgp
Description: Signature digitale OpenPGP

Re: Authentification failure

[Pierre Malard]

Bonjour,

Sans présumer de qui est le plus « méchant » (Chinois, Russes, USA, Fr…) et 
pratique
le scan massif, je ne saurait trop conseiller un filtrage avec la limitation des
ports ouverts par un pare-feu et, sur les serveurs ouverts, l’installation de
« Fail2Ban » en validant les règles « récidive ».

Pour ceux qui ne savent pas entendre raison il y a le truc de « ban-them » qui
construit une liste à chaud de ceux-là et … les bannis définitivement. C’est
très utile et évite de faire tout ça à la main :
https://www.cybernaute.ch/bannir-definitivement-ip-bannies-frequemment-fail2ban/#comment-366
Cela demande tout de même une surveillance pour éviter les faux positifs mais
c’est très bien.

Cordialement

> Le 5 juin 2019 à 14:23, Yahoo  a écrit :
> 
> D??sol??, je n'avais pas compris ta demande.
> 
> Donc sur la fr??quence, de mon c??t?? j'ai tr??s peu d'attaque force brut sur 
> le service ssh, mais effectivement j'utilise un port un peu plus exotique que 
> le tiens
> 
> la vue pour un serveur up depuis 1 ans:
> 
> Status for the jail: sshd
> |- Filter
> |?? |- Currently failed: 0
> |?? |- Total failed: 23
> |?? `- File list:?? /var/log/auth.log
> `- Actions
>  |- Currently banned: 0
>  |- Total banned: 1
>  `- Banned IP list:
> 
> Il est donc possible que  soit trop simple
> 
> 
> Le 05/06/2019 ?? 13:33, steve a ??crit??:
>> Le mercredi 05 juin 2019, Yahoo a ??crit??:
>> 
>>> ?? Bonjour,
>>> 
>>> ?? c'est quasiment tous le temps, si tu veux limiter cela tu peux modifier 
>>> le
>>> ?? port de ta connexion ssh, cela ??vite une bonne partie de ces bots,
>> 
>> D??j?? fait depuis longtemps (22->). Peut-??tre faudrait-il que je
>> mette un port moins ??vident???
>> 
>>> ?? ensuite tu peux mettre fail2ban pour les irr??ductibles que trouverais le
>>> ?? bon ports.
>> 
>> # fail2ban-client status sshd
>> Status for the jail: sshd
>> |- Filter
>> |?? |- Currently failed:?? 2
>> |?? |- Total failed:?? 11952
>> |?? `- File list:?? /var/log/auth.log
>> `- Actions
>> ?? |- Currently banned:?? 3
>> ?? |- Total banned:?? 54
>> ?? `- Banned IP list:?? 73.15.91.251 104.248.187.179 41.223.142.211
>> 
>> 
>> Mais en fait ma question ??tait plus sur une ??ventuelle augmentation de
>> la fr??quence de scan que sur les m??thodes de mitigation que je connais
>> d??j?? et qui sont en place.
>> 
> 

--
Pierre Malard

  « Les utopies ne sont souvent que des vérités prématurées »
  Alphonse de Lamartine
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Authentification failure

[Yahoo]

D??sol??, je n'avais pas compris ta demande.

Donc sur la fr??quence, de mon c??t?? j'ai tr??s peu d'attaque force brut 
sur le service ssh, mais effectivement j'utilise un port un peu plus 
exotique que le tiens


la vue pour un serveur up depuis 1 ans:

Status for the jail: sshd
|- Filter
|?? |- Currently failed: 0
|?? |- Total failed: 23
|?? `- File list:?? /var/log/auth.log
`- Actions
 |- Currently banned: 0
 |- Total banned: 1
 `- Banned IP list:

Il est donc possible que  soit trop simple


Le 05/06/2019 ?? 13:33, steve a ??crit??:

Le mercredi 05 juin 2019, Yahoo a ??crit??:


?? Bonjour,

?? c'est quasiment tous le temps, si tu veux limiter cela tu peux 
modifier le

?? port de ta connexion ssh, cela ??vite une bonne partie de ces bots,


D??j?? fait depuis longtemps (22->). Peut-??tre faudrait-il que je
mette un port moins ??vident???

?? ensuite tu peux mettre fail2ban pour les irr??ductibles que 
trouverais le

?? bon ports.


# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|?? |- Currently failed:?? 2
|?? |- Total failed:?? 11952
|?? `- File list:?? /var/log/auth.log
`- Actions
?? |- Currently banned:?? 3
?? |- Total banned:?? 54
?? `- Banned IP list:?? 73.15.91.251 104.248.187.179 41.223.142.211


Mais en fait ma question ??tait plus sur une ??ventuelle augmentation de
la fr??quence de scan que sur les m??thodes de mitigation que je connais
d??j?? et qui sont en place.

Re: Authentification failure

[steve]

Le mercredi 05 juin 2019, Yahoo a écrit :


  Bonjour,

  c'est quasiment tous le temps, si tu veux limiter cela tu peux modifier le
  port de ta connexion ssh, cela évite une bonne partie de ces bots,


Déjà fait depuis longtemps (22->). Peut-être faudrait-il que je
mette un port moins évident ?


  ensuite tu peux mettre fail2ban pour les irréductibles que trouverais le
  bon ports.


# fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed: 11952
|  `- File list:/var/log/auth.log
`- Actions
  |- Currently banned:  3
  |- Total banned:  54
  `- Banned IP list:73.15.91.251 104.248.187.179 41.223.142.211


Mais en fait ma question était plus sur une éventuelle augmentation de
la fréquence de scan que sur les méthodes de mitigation que je connais
déjà et qui sont en place.

Re: Authentification failure

[Cyrille Bollu]

Oui oui ça fait partie de l’Internet standard.

Si cela t’inquiète vraiment, le programme fail2ban peut t’aider.

Cyrille

> Le 5 juin 2019 à 08:37, Belaïd  a écrit :
> 
> Bonjour, 
> 
> Pour ma part,  tout le temps !  😀 et la quasi totalité des tentatives de 
> connexions viennent d'Asie (sans cité un paye en particulier  !  😀 )
> 
> Le mer. 5 juin 2019 08:32, steve  a écrit :
>> Salut à tous,
>> 
>> Depuis une dizaine de jours, j'observe une augmentation massive de scans
>> sur ma machine.
>> 
>> sshd:
>> Authentication Failures:
>>unknown (115.159.235.17): 100 Time(s)
>>unknown (153.37.192.4): 99 Time(s)
>>unknown (183.103.146.208): 99 Time(s)
>>unknown (190.0.159.69): 99 Time(s)
>>unknown (106.13.103.204): 98 Time(s)
>>unknown (109.86.200.141): 98 Time(s)
>>unknown (94.23.62.187): 98 Time(s)
>>unknown (45.127.106.51): 96 Time(s)
>>unknown (103.202.132.175): 95 Time(s)
>>unknown (217.182.95.16): 95 Time(s)
>>unknown (47.74.150.153): 95 Time(s)
>>unknown (220.168.86.37): 87 Time(s)
>>unknown (122.155.223.31): 73 Time(s)
>>unknown (190.111.239.48): 70 Time(s)
>>unknown (188.166.31.205): 56 Time(s)
>>unknown (47.254.158.221): 48 Time(s)
>>unknown (51.15.117.94): 47 Time(s)
>>unknown (142.93.237.233): 34 Time(s)
>>unknown (223.83.155.77): 16 Time(s)
>>unknown (41.77.145.34): 13 Time(s)
>>unknown (118.24.99.163): 12 Time(s)
>>unknown (46.190.57.82): 9 Time(s)
>>unknown (89.79.197.61): 9 Time(s)
>>unknown (115.159.30.108): 8 Time(s)
>>backup (188.166.31.205): 2 Time(s)
>>root (104.236.102.16): 2 Time(s)
>>root (223.17.237.138): 2 Time(s)
>>unknown (128.199.221.18): 2 Time(s)
>>backup (103.202.132.175): 1 Time(s)
>>backup (47.254.158.221): 1 Time(s)
>>backup (47.74.150.153): 1 Time(s)
>>daemon (45.127.106.51): 1 Time(s)
>>backup (188.166.31.205): 2 Time(s)
>>root (104.236.102.16): 2 Time(s)
>>root (223.17.237.138): 2 Time(s)
>>unknown (128.199.221.18): 2 Time(s)
>>backup (103.202.132.175): 1 Time(s)
>>backup (47.254.158.221): 1 Time(s)
>>backup (47.74.150.153): 1 Time(s)
>>daemon (45.127.106.51): 1 Time(s)
>>games (103.202.132.175): 1 Time(s)
>>games (188.166.31.205): 1 Time(s)
>>games (94.23.62.187): 1 Time(s)
>>gnats (159.65.144.233): 1 Time(s)
>>gnats (190.111.239.48): 1 Time(s)
>>gnats (45.127.106.51): 1 Time(s)
>>hplip (103.202.132.175): 1 Time(s)
>>irc (106.13.103.204): 1 Time(s)
>>irc (217.182.95.16): 1 Time(s)
>>irc (41.77.145.34): 1 Time(s)
>>irc (47.74.150.153): 1 Time(s)
>>list (47.254.158.221): 1 Time(s)
>>lp (217.182.95.16): 1 Time(s)
>>mail (103.202.132.175): 1 Time(s)
>>man (115.159.30.108): 1 Time(s)
>>man (153.37.192.4): 1 Time(s)
>>man (47.74.150.153): 1 Time(s)
>>mysql (109.86.200.141): 1 Time(s)
>>mysql (153.37.192.4): 1 Time(s)
>>mysql (190.111.239.48): 1 Time(s)
>>mysql (202.88.241.107): 1 Time(s)
>>mysql (45.127.106.51): 1 Time(s)
>>mysql (51.15.117.94): 1 Time(s)
>>mysql (81.133.216.92): 1 Time(s)
>>mysql (94.23.62.187): 1 Time(s)
>>news (190.0.159.69): 1 Time(s)
>>news (47.74.150.153): 1 Time(s)
>>nobody (118.25.221.166): 1 Time(s)
>>nobody (217.182.95.16): 1 Time(s)
>>plex (217.182.95.16): 1 Time(s)
>>proxy (103.202.132.175): 1 Time(s)
>>proxy (47.74.150.153): 1 Time(s)
>>root (104.248.211.180): 1 Time(s)
>>root (105.235.116.254): 1 Time(s)
>>Invalid Users:
>>Unknown Account: 1610 Time(s)
>> 
>> 
>> Je me demandais si vous observiez la même chose.
>> 
>> Merci
>> 
>> Steve
>> 

Re: Authentification failure

[Yann Serre]

Bonjour,

Même si vous faites parti des personnes sensibilisées, voici un article 
de presse grand public. Je pense que ça a un rapport avec le sujet même 
si la piste mafieuse serait probablement à privilégier.


https://www.ouest-france.fr/high-tech/le-risque-d-un-pearl-harbor-informatique-contre-la-france-est-bien-reel-6381766

Re: Authentification failure

[Jean Millet]

Bonjour,

J’observe cela depuis plusieurs années. au départ les bot chinois qui 
sont très actifs puis d'autres.


Chez GuppY (CMS) nous avons préconisé l'utilisation de blocage de plages 
IP dans le .htaccess à la racine des sites hébergés en mutualisé et nous 
utilisons iptables sur nos serveurs


Exemple pour les htaccess à la racine des sites :


  
    Require all granted

# Cambodia (KH)
Require not ip 114.134.184.0/21
# Chinese (CN) IP addresses follow (split into two lines on 7/6/17 to 
avoid possible Server 500 due to excess line length):
Require not ip 1.24.0.0/13 1.48.0.0/15 1.50.0.0/16 1.56.0.0/13 
1.68.0.0/14 1.80.0.0/13 1.92.0.0/14 1.180.0.0/14 1.188.0.0/14 
1.192.0.0/13 1.202.0.0/15 1.204.0.0/14 14.16.0.0/12 14.104.0.0/13 
14.112.0.0/12 14.134.0.0/15 14.144.0.0/12 14.204.0.0/15 14.208.0.0/12 
23.80.54.0/24 23.104.141.0/24 23.105.14.0/24 23.226.208.0/24 27.8.0.0/13 
27.16.0.0/12 27.36.0.0/14 27.40.0.0/13 27.50.128.0/17 27.54.192.0/18 
27.106.128.0/18 27.115.0.0/17 27.148.0.0/14 27.152.0.0/13 27.184.0.0/13 
27.192.0.0/11 27.224.0.0/14 36.1.0.0/16 36.4.0.0/14 36.26.0.0/16 
36.32.0.0/14 36.36.0.0/16 36.40.0.0/13 36.48.0.0/15 36.56.0.0/13 
36.96.0.0/11 36.128.0.0/11 36.248.0.0/14 39.64.0.0/11 39.128.0.0/10 
42.4.0.0/14 42.48.0.0/15 42.52.0.0/14 42.56.0.0/14 42.84.0.0/14 
42.88.0.0/13 42.96.128.0/17 42.100.0.0/14 42.120.0.0/14 42.156.0.0/16 
42.176.0.0/13 42.185.0.0/16 42.202.0.0/15 42.224.0.0/12 42.242.0.0/15 
42.248.0.0/15 43.255.0.0/20 43.255.16.0/22 43.255.48.0/22 43.255.60.0/22 
43.255.64.0/20 43.255.96.0/20 43.255.144.0/22 43.255.168.0/22 
43.255.176.0/22 43.255.184.0/22 43.255.192.0/22 43.255.200.0/21 
43.255.208.0/21 43.255.224.0/21 43.255.232.0/22 43.255.244.0/22 
47.88.0.0/14 47.92.0.0/14 49.5.0.0/16 49.64.0.0/11 49.112.0.0/13 
54.222.0.0/15 58.16.0.0/14 58.20.0.0/16 58.21.0.0/16 58.22.0.0/15 
58.34.0.0/16 58.37.0.0/16 58.38.0.0/16 58.40.0.0/16 58.42.0.0/16 
58.44.0.0/14 58.48.0.0/13 58.56.0.0/14 58.60.0.0/14 58.68.128.0/17 
58.82.0.0/15 58.100.0.0/15 58.116.0.0/14 58.128.0.0/13 58.208.0.0/12 
58.240.0.0/13 58.248.0.0/13 59.32.0.0/12 59.48.0.0/14 59.52.0.0/14 
59.56.0.0/13 59.72.0.0/16 59.108.0.0/15 59.172.0.0/14 60.0.0.0/12 
60.11.0.0/16 60.12.0.0/14 60.16.0.0/13 60.24.0.0/13 60.160.0.0/11 
60.194.0.0/15 60.205.0.0/16 60.208.0.0/12 60.253.128.0/17 61.4.64.0/20 
61.4.80.0/22 61.4.176.0/20 61.48.0.0/13 61.128.0.0/10 61.135.0.0/16 
61.136.0.0/18 61.139.0.0/16 61.145.73.208/28 61.147.0.0/16 61.150.0.0/16 
61.152.0.0/16 61.154.0.0/16 61.160.0.0/16 61.162.0.0/15 61.164.0.0/16 
61.172.0.0/15 61.175.0.0/16 61.177.0.0/16 61.179.0.0/16 61.183.0.0/16 
61.184.0.0/16 61.185.219.232/29 61.187.0.0/16 61.188.0.0/16 
61.232.0.0/14 61.236.0.0/15 61.240.0.0/14


Etc

__

pour iptables :

iptables -I INPUT 1 -s 212.83.144.0/20 -j DROP
iptables -I INPUT 1 -s 118.200.0.0/16 -j DROP
iptables -I INPUT 1 -s 207.46.0.0/16 -j DROP
iptables -I INPUT 1 -s 54.254.0.0/16 -j DROP
iptables -I INPUT 1 -s 91.224.160.0/23 -j DROP
iptables -I INPUT 1 -s 175.100.144.0/20 -j DROP
iptables -I INPUT 1 -s 134.212.0.0/15 -j DROP
iptables -I INPUT 1 -s 134.214.0.0/16 -j DROP
iptables -I INPUT 1 -s 190.255.176.88/29 -j DROP
iptables -I INPUT 1 -s 118.70.176.0/20 -j DROP
iptables -I INPUT 1 -s 195.154.0.0/17 -j DROP
iptables -I INPUT 1 -s 91.200.12.0/22 -j DROP
iptables-save -c > /etc/iptables-save

Etc


Amicalement,
Jean alias JeandePeyrat
https://www.freeguppy.org/
https://asso.freeguppy.org/
https://www.anacr-correze.fr/
https://Beaucoup d'autres !

Le 05/06/2019 à 08:32, steve a écrit :

Salut à tous,

Depuis une dizaine de jours, j'observe une augmentation massive de scans
sur ma machine.

sshd:
   Authentication Failures:
  unknown (115.159.235.17): 100 Time(s)
  unknown (153.37.192.4): 99 Time(s)
  unknown (183.103.146.208): 99 Time(s)
  unknown (190.0.159.69): 99 Time(s)
  unknown (106.13.103.204): 98 Time(s)
  unknown (109.86.200.141): 98 Time(s)
  unknown (94.23.62.187): 98 Time(s)
  unknown (45.127.106.51): 96 Time(s)
  unknown (103.202.132.175): 95 Time(s)
  unknown (217.182.95.16): 95 Time(s)
  unknown (47.74.150.153): 95 Time(s)
  unknown (220.168.86.37): 87 Time(s)
  unknown (122.155.223.31): 73 Time(s)
  unknown (190.111.239.48): 70 Time(s)
  unknown (188.166.31.205): 56 Time(s)
  unknown (47.254.158.221): 48 Time(s)
  unknown (51.15.117.94): 47 Time(s)
  unknown (142.93.237.233): 34 Time(s)
  unknown (223.83.155.77): 16 Time(s)
  unknown (41.77.145.34): 13 Time(s)
  unknown (118.24.99.163): 12 Time(s)
  unknown (46.190.57.82): 9 Time(s)
  unknown (89.79.197.61): 9 Time(s)
  unknown (115.159.30.108): 8 Time(s)
  backup (188.166.31.205): 2 Time(s)
  root (104.236.102.16): 2 Time(s)
  root (223.17.237.138): 2 Time(s)
  unknown (128.199.221.18): 2 Time(s)
  backup (103.202.132.175): 1 Time(s)
  backup (47.254.158.221): 1 Time(s)

Re: Authentification failure

[Yahoo]

Bonjour,

c'est quasiment tous le temps, si tu veux limiter cela tu peux modifier 
le port de ta connexion ssh, cela ??vite une bonne partie de ces bots,


ensuite tu peux mettre fail2ban pour les irr??ductibles que trouverais le 
bon ports.


Lo??c

Le 05/06/2019 ?? 08:32, steve a ??crit??:

Salut ?? tous,

Depuis une dizaine de jours, j'observe une augmentation massive de scans
sur ma machine.

sshd:
 Authentication Failures:
?? unknown (115.159.235.17): 100 Time(s)
?? unknown (153.37.192.4): 99 Time(s)
?? unknown (183.103.146.208): 99 Time(s)
?? unknown (190.0.159.69): 99 Time(s)
?? unknown (106.13.103.204): 98 Time(s)
?? unknown (109.86.200.141): 98 Time(s)
?? unknown (94.23.62.187): 98 Time(s)
?? unknown (45.127.106.51): 96 Time(s)
?? unknown (103.202.132.175): 95 Time(s)
?? unknown (217.182.95.16): 95 Time(s)
?? unknown (47.74.150.153): 95 Time(s)
?? unknown (220.168.86.37): 87 Time(s)
?? unknown (122.155.223.31): 73 Time(s)
?? unknown (190.111.239.48): 70 Time(s)
?? unknown (188.166.31.205): 56 Time(s)
?? unknown (47.254.158.221): 48 Time(s)
?? unknown (51.15.117.94): 47 Time(s)
?? unknown (142.93.237.233): 34 Time(s)
?? unknown (223.83.155.77): 16 Time(s)
?? unknown (41.77.145.34): 13 Time(s)
?? unknown (118.24.99.163): 12 Time(s)
?? unknown (46.190.57.82): 9 Time(s)
?? unknown (89.79.197.61): 9 Time(s)
?? unknown (115.159.30.108): 8 Time(s)
?? backup (188.166.31.205): 2 Time(s)
?? root (104.236.102.16): 2 Time(s)
?? root (223.17.237.138): 2 Time(s)
?? unknown (128.199.221.18): 2 Time(s)
?? backup (103.202.132.175): 1 Time(s)
?? backup (47.254.158.221): 1 Time(s)
?? backup (47.74.150.153): 1 Time(s)
?? daemon (45.127.106.51): 1 Time(s)
?? backup (188.166.31.205): 2 Time(s)
?? root (104.236.102.16): 2 Time(s)
?? root (223.17.237.138): 2 Time(s)
?? unknown (128.199.221.18): 2 Time(s)
?? backup (103.202.132.175): 1 Time(s)
?? backup (47.254.158.221): 1 Time(s)
?? backup (47.74.150.153): 1 Time(s)
?? daemon (45.127.106.51): 1 Time(s)
?? games (103.202.132.175): 1 Time(s)
?? games (188.166.31.205): 1 Time(s)
?? games (94.23.62.187): 1 Time(s)
?? gnats (159.65.144.233): 1 Time(s)
?? gnats (190.111.239.48): 1 Time(s)
?? gnats (45.127.106.51): 1 Time(s)
?? hplip (103.202.132.175): 1 Time(s)
?? irc (106.13.103.204): 1 Time(s)
?? irc (217.182.95.16): 1 Time(s)
?? irc (41.77.145.34): 1 Time(s)
?? irc (47.74.150.153): 1 Time(s)
?? list (47.254.158.221): 1 Time(s)
?? lp (217.182.95.16): 1 Time(s)
?? mail (103.202.132.175): 1 Time(s)
?? man (115.159.30.108): 1 Time(s)
?? man (153.37.192.4): 1 Time(s)
?? man (47.74.150.153): 1 Time(s)
?? mysql (109.86.200.141): 1 Time(s)
?? mysql (153.37.192.4): 1 Time(s)
?? mysql (190.111.239.48): 1 Time(s)
?? mysql (202.88.241.107): 1 Time(s)
?? mysql (45.127.106.51): 1 Time(s)
?? mysql (51.15.117.94): 1 Time(s)
?? mysql (81.133.216.92): 1 Time(s)
?? mysql (94.23.62.187): 1 Time(s)
?? news (190.0.159.69): 1 Time(s)
?? news (47.74.150.153): 1 Time(s)
?? nobody (118.25.221.166): 1 Time(s)
?? nobody (217.182.95.16): 1 Time(s)
?? plex (217.182.95.16): 1 Time(s)
?? proxy (103.202.132.175): 1 Time(s)
?? proxy (47.74.150.153): 1 Time(s)
?? root (104.248.211.180): 1 Time(s)
?? root (105.235.116.254): 1 Time(s)
?? Invalid Users:
?? Unknown Account: 1610 Time(s)


Je me demandais si vous observiez la m??me chose.

Merci

Steve

Re: Authentification failure

[Eric Degenetais]

Il y a 5 ans déjà, je constatais des scans à longueur de journées sur l'ip
publique serveurs sans nom de domaine, dès leur première journée. Il y a
clairement une exploration systématique de certaines plages IP à la
recherche de serveurs à subvertir.

Éric Dégenètais

Le mer. 5 juin 2019 8:37 AM, Belaïd  a écrit :

> Bonjour,
>
> Pour ma part,  tout le temps !  😀 et la quasi totalité des tentatives de
> connexions viennent d'Asie (sans cité un paye en particulier  !  😀 )
>
> Le mer. 5 juin 2019 08:32, steve  a écrit :
>
>> Salut à tous,
>>
>> Depuis une dizaine de jours, j'observe une augmentation massive de scans
>> sur ma machine.
>>
>> sshd:
>> Authentication Failures:
>>unknown (115.159.235.17): 100 Time(s)
>>unknown (153.37.192.4): 99 Time(s)
>>unknown (183.103.146.208): 99 Time(s)
>>unknown (190.0.159.69): 99 Time(s)
>>unknown (106.13.103.204): 98 Time(s)
>>unknown (109.86.200.141): 98 Time(s)
>>unknown (94.23.62.187): 98 Time(s)
>>unknown (45.127.106.51): 96 Time(s)
>>unknown (103.202.132.175): 95 Time(s)
>>unknown (217.182.95.16): 95 Time(s)
>>unknown (47.74.150.153): 95 Time(s)
>>unknown (220.168.86.37): 87 Time(s)
>>unknown (122.155.223.31): 73 Time(s)
>>unknown (190.111.239.48): 70 Time(s)
>>unknown (188.166.31.205): 56 Time(s)
>>unknown (47.254.158.221): 48 Time(s)
>>unknown (51.15.117.94): 47 Time(s)
>>unknown (142.93.237.233): 34 Time(s)
>>unknown (223.83.155.77): 16 Time(s)
>>unknown (41.77.145.34): 13 Time(s)
>>unknown (118.24.99.163): 12 Time(s)
>>unknown (46.190.57.82): 9 Time(s)
>>unknown (89.79.197.61): 9 Time(s)
>>unknown (115.159.30.108): 8 Time(s)
>>backup (188.166.31.205): 2 Time(s)
>>root (104.236.102.16): 2 Time(s)
>>root (223.17.237.138): 2 Time(s)
>>unknown (128.199.221.18): 2 Time(s)
>>backup (103.202.132.175): 1 Time(s)
>>backup (47.254.158.221): 1 Time(s)
>>backup (47.74.150.153): 1 Time(s)
>>daemon (45.127.106.51): 1 Time(s)
>>backup (188.166.31.205): 2 Time(s)
>>root (104.236.102.16): 2 Time(s)
>>root (223.17.237.138): 2 Time(s)
>>unknown (128.199.221.18): 2 Time(s)
>>backup (103.202.132.175): 1 Time(s)
>>backup (47.254.158.221): 1 Time(s)
>>backup (47.74.150.153): 1 Time(s)
>>daemon (45.127.106.51): 1 Time(s)
>>games (103.202.132.175): 1 Time(s)
>>games (188.166.31.205): 1 Time(s)
>>games (94.23.62.187): 1 Time(s)
>>gnats (159.65.144.233): 1 Time(s)
>>gnats (190.111.239.48): 1 Time(s)
>>gnats (45.127.106.51): 1 Time(s)
>>hplip (103.202.132.175): 1 Time(s)
>>irc (106.13.103.204): 1 Time(s)
>>irc (217.182.95.16): 1 Time(s)
>>irc (41.77.145.34): 1 Time(s)
>>irc (47.74.150.153): 1 Time(s)
>>list (47.254.158.221): 1 Time(s)
>>lp (217.182.95.16): 1 Time(s)
>>mail (103.202.132.175): 1 Time(s)
>>man (115.159.30.108): 1 Time(s)
>>man (153.37.192.4): 1 Time(s)
>>man (47.74.150.153): 1 Time(s)
>>mysql (109.86.200.141): 1 Time(s)
>>mysql (153.37.192.4): 1 Time(s)
>>mysql (190.111.239.48): 1 Time(s)
>>mysql (202.88.241.107): 1 Time(s)
>>mysql (45.127.106.51): 1 Time(s)
>>mysql (51.15.117.94): 1 Time(s)
>>mysql (81.133.216.92): 1 Time(s)
>>mysql (94.23.62.187): 1 Time(s)
>>news (190.0.159.69): 1 Time(s)
>>news (47.74.150.153): 1 Time(s)
>>nobody (118.25.221.166): 1 Time(s)
>>nobody (217.182.95.16): 1 Time(s)
>>plex (217.182.95.16): 1 Time(s)
>>proxy (103.202.132.175): 1 Time(s)
>>proxy (47.74.150.153): 1 Time(s)
>>root (104.248.211.180): 1 Time(s)
>>root (105.235.116.254): 1 Time(s)
>>Invalid Users:
>>Unknown Account: 1610 Time(s)
>>
>>
>> Je me demandais si vous observiez la même chose.
>>
>> Merci
>>
>> Steve
>>
>>

Re: Authentification failure

[Belaïd]

Bonjour,

Pour ma part,  tout le temps !  😀 et la quasi totalité des tentatives de
connexions viennent d'Asie (sans cité un paye en particulier  !  😀 )

Le mer. 5 juin 2019 08:32, steve  a écrit :

> Salut à tous,
>
> Depuis une dizaine de jours, j'observe une augmentation massive de scans
> sur ma machine.
>
> sshd:
> Authentication Failures:
>unknown (115.159.235.17): 100 Time(s)
>unknown (153.37.192.4): 99 Time(s)
>unknown (183.103.146.208): 99 Time(s)
>unknown (190.0.159.69): 99 Time(s)
>unknown (106.13.103.204): 98 Time(s)
>unknown (109.86.200.141): 98 Time(s)
>unknown (94.23.62.187): 98 Time(s)
>unknown (45.127.106.51): 96 Time(s)
>unknown (103.202.132.175): 95 Time(s)
>unknown (217.182.95.16): 95 Time(s)
>unknown (47.74.150.153): 95 Time(s)
>unknown (220.168.86.37): 87 Time(s)
>unknown (122.155.223.31): 73 Time(s)
>unknown (190.111.239.48): 70 Time(s)
>unknown (188.166.31.205): 56 Time(s)
>unknown (47.254.158.221): 48 Time(s)
>unknown (51.15.117.94): 47 Time(s)
>unknown (142.93.237.233): 34 Time(s)
>unknown (223.83.155.77): 16 Time(s)
>unknown (41.77.145.34): 13 Time(s)
>unknown (118.24.99.163): 12 Time(s)
>unknown (46.190.57.82): 9 Time(s)
>unknown (89.79.197.61): 9 Time(s)
>unknown (115.159.30.108): 8 Time(s)
>backup (188.166.31.205): 2 Time(s)
>root (104.236.102.16): 2 Time(s)
>root (223.17.237.138): 2 Time(s)
>unknown (128.199.221.18): 2 Time(s)
>backup (103.202.132.175): 1 Time(s)
>backup (47.254.158.221): 1 Time(s)
>backup (47.74.150.153): 1 Time(s)
>daemon (45.127.106.51): 1 Time(s)
>backup (188.166.31.205): 2 Time(s)
>root (104.236.102.16): 2 Time(s)
>root (223.17.237.138): 2 Time(s)
>unknown (128.199.221.18): 2 Time(s)
>backup (103.202.132.175): 1 Time(s)
>backup (47.254.158.221): 1 Time(s)
>backup (47.74.150.153): 1 Time(s)
>daemon (45.127.106.51): 1 Time(s)
>games (103.202.132.175): 1 Time(s)
>games (188.166.31.205): 1 Time(s)
>games (94.23.62.187): 1 Time(s)
>gnats (159.65.144.233): 1 Time(s)
>gnats (190.111.239.48): 1 Time(s)
>gnats (45.127.106.51): 1 Time(s)
>hplip (103.202.132.175): 1 Time(s)
>irc (106.13.103.204): 1 Time(s)
>irc (217.182.95.16): 1 Time(s)
>irc (41.77.145.34): 1 Time(s)
>irc (47.74.150.153): 1 Time(s)
>list (47.254.158.221): 1 Time(s)
>lp (217.182.95.16): 1 Time(s)
>mail (103.202.132.175): 1 Time(s)
>man (115.159.30.108): 1 Time(s)
>man (153.37.192.4): 1 Time(s)
>man (47.74.150.153): 1 Time(s)
>mysql (109.86.200.141): 1 Time(s)
>mysql (153.37.192.4): 1 Time(s)
>mysql (190.111.239.48): 1 Time(s)
>mysql (202.88.241.107): 1 Time(s)
>mysql (45.127.106.51): 1 Time(s)
>mysql (51.15.117.94): 1 Time(s)
>mysql (81.133.216.92): 1 Time(s)
>mysql (94.23.62.187): 1 Time(s)
>news (190.0.159.69): 1 Time(s)
>news (47.74.150.153): 1 Time(s)
>nobody (118.25.221.166): 1 Time(s)
>nobody (217.182.95.16): 1 Time(s)
>plex (217.182.95.16): 1 Time(s)
>proxy (103.202.132.175): 1 Time(s)
>proxy (47.74.150.153): 1 Time(s)
>root (104.248.211.180): 1 Time(s)
>root (105.235.116.254): 1 Time(s)
>Invalid Users:
>Unknown Account: 1610 Time(s)
>
>
> Je me demandais si vous observiez la même chose.
>
> Merci
>
> Steve
>
>

Re: Authentification imap par clé

[Wallace]

En mobile ça peut être pénible car ça déconnecte souvent en changement
de réseau mobile et les optimisations batteries ont tendance à couper
cours les communications.

L'autre solution c'est d'avoir un mot de passe renforcé sur ces comptes,
si la personne a un gestionnaire de mot de passe, mettre un mot de passe
de 50 caractères aléatoires qu'elle copie collera dans ses configurations.

Pour Fail2ban, mettre un ban plus long du type 24h voir plus au bout de
10 tentatives infructueuses. 10 tentatives ça laisse de la marge pour
les utilisateurs légitimes qui tapent encore leur mot de passe de tête
et plusieurs jours de ban ça ralentira très très fortement l'utilisateur.

Avec le fail2ban et le mot de passe fort ça rendra la tâche impossible.

Idéalement je rêve d'avoir un système de 2FA sur les comptes mails, mais
je n'ai pas vu d'implémentation probante pourtant sur un élément aussi
vital et sensible ...


Le 21/03/2019 à 17:39, Sil a écrit :
> Le 21/03/2019 à 15:38, Wallace a écrit :
>>
>> As tu regardé si ton bruteforce vise explicitement un compte qui
>> existe déjà?
>>
> Bonjour,
>
> L'attaque est bien ciblée sur des comptes existants...
>
> Le VPN pourrait être une bonne solution, il est déjà en place sur ce
> serveur. Une clé par client. Je vais regarder si ça n'est pas trop
> lourd en utilisation mobile.
>
> Merci.
>
> Sil
>



signature.asc
Description: OpenPGP digital signature

Re: Authentification imap par clé

[Sil]

Le 21/03/2019 à 15:38, Wallace a écrit :


As tu regardé si ton bruteforce vise explicitement un compte qui 
existe déjà?



Bonjour,

L'attaque est bien ciblée sur des comptes existants...

Le VPN pourrait être une bonne solution, il est déjà en place sur ce 
serveur. Une clé par client. Je vais regarder si ça n'est pas trop lourd 
en utilisation mobile.


Merci.

Sil

Re: Authentification dans NTP

[Vincent Lefevre]

On 2015-08-24 12:22:40 +0200, j...@free.fr wrote:
> Il y a une couche d'authentification dans NTP ? 

Oui, à partir de NTPv3:

  http://linux.die.net/man/5/ntp_auth

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Authentification webmail

[Vincent Danjean]

On 11/12/2014 15:36, BERTRAND Joël wrote:
> andre_deb...@numericable.fr a écrit :
>> On Thursday 11 December 2014 13:29:49 BERTRAND Joël wrote:
>>> Pour roundcube, j'ai ceci :
>>> Dec 11 13:23:37 rayleigh imapd-ssl: couriertls: accept:
>>> error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1
>>> alert unknown ca
>>
>> On dirait un problème de protocole SSL dans imapd-ssl.

Il y a eu des changements dans les (sous)protocoles SSL
supportés dans les différentes bibliothèques suite à des failles
dans les protocoles eux-même.
  C'est possible qu'un protocole qui était utilisé soit maintenant
interdit par le client et/ou le serveur et qu'ils n'arrivent pas
à ce mettre d'accord sur un autre protocole commun.
  Ceci dit, il faudra fouiller plus pour avoir l'info complète.
J'ai mis ici tout ce dont je me souviens de mémoire.

  A+
Vincent



-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54a1d769.8010...@free.fr

Re: Authentification webmail

[BERTRAND Joël]

andre_deb...@numericable.fr a écrit :

On Thursday 11 December 2014 13:29:49 BERTRAND Joël wrote:

Pour roundcube, j'ai ceci :
Dec 11 13:23:37 rayleigh imapd-ssl: couriertls: accept:
error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1
alert unknown ca


On dirait un problème de protocole SSL dans imapd-ssl.


	Je ne pense pas parce que ce qui n'est pas webmail arrive à 
s'authentifier. Donc le problème n'est pas dans courier.



Un fichier de conf, openssl, apache... suite à l'upgrade ?


Là encore, je ne vois pas trop lequel.


http://serverfault.com/questions/453300/openssl-client-authentication-error-tlsv1-alert-unknown-ca-ssl-alert-numbe

Ça doit pas être trop grave :-)


Certes, mais c'est emm*rdant.

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/5489abe6.5060...@systella.fr

Re: Authentification webmail

[andre_debian]

On Thursday 11 December 2014 13:29:49 BERTRAND Joël wrote:
>   Pour roundcube, j'ai ceci :
> Dec 11 13:23:37 rayleigh imapd-ssl: couriertls: accept:
> error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 
> alert unknown ca 

On dirait un problème de protocole SSL dans imapd-ssl.

Un fichier de conf, openssl, apache... suite à l'upgrade ?

http://serverfault.com/questions/453300/openssl-client-authentication-error-tlsv1-alert-unknown-ca-ssl-alert-numbe

Ça doit pas être trop grave :-)

André

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/201412111407.59443.andre_deb...@numericable.fr

Re: Authentification webmail

[Sébastien NOBILI]

Le jeudi 11 décembre 2014 à 13:29, BERTRAND Joël a écrit :
> Sébastien NOBILI a écrit :
> >Bonjour,
> >
> >Le jeudi 11 décembre 2014 à 11:38, BERTRAND Joël a écrit :
> >>Depuis une mise à jour récente, alors que le serveur de mail continue à
> >>parfaitement fonctionner, je suis devenu incapable de me connecter aux
> >>webmails. L'authentification échoue. J'avoue ne plus savoir où chercher.
> >>
> >>Squirrelmail est assez verbeux et affiche :
> >>Erreur lors de la connexion au serveur IMAP tls://...
> >>
> >>Roudcube indique juste que l'authetification a échoué.
> >
> >Courrier est assez verbeux, il trace notamment les ouvertures et fermetures 
> >de
> >session. Par exemple chez moi :
> >
> > Dec 11 12:32:43 serveur imapd: Connection, ip=[:::192.168.1.52]
> > Dec 11 12:32:43 serveur imapd: LOGIN, user=, 
> > ip=[:::192.168.1.52], port=[46932], protocol=IMAP
> >
> >Quand tu tentes de te connecter avec ton Webmail, vois-tu ce genre de traces
> >(/var/log/syslog) ?
> 
>   Pour roundcube, j'ai ceci :
> 
> Dec 11 13:23:37 rayleigh imapd-ssl: couriertls: accept: error:14094418:SSL
> routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

SSL3 refoulé ? Un rapport avec POODLE peut-être ?

https://fr.wikipedia.org/wiki/POODLE

Le serveur IMAP est-il sur la même machine que le Webmail ? Si oui, le plus
simple sera sûrement de désactiver la crypto dans les échanges…

Si non, alors je vais avoir du mal à t'aider plus, puisque chez moi, la
connexion entre le Webmail et le serveur IMAP se fait en clair (et donc je n'ai
pas le problème).

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141211130219.gc15...@sebian.nob900.homeip.net

Re: Authentification webmail

[BERTRAND Joël]

Sébastien NOBILI a écrit :

Bonjour,

Le jeudi 11 décembre 2014 à 11:38, BERTRAND Joël a écrit :

Depuis une mise à jour récente, alors que le serveur de mail continue à
parfaitement fonctionner, je suis devenu incapable de me connecter aux
webmails. L'authentification échoue. J'avoue ne plus savoir où chercher.

Squirrelmail est assez verbeux et affiche :
Erreur lors de la connexion au serveur IMAP tls://...

Roudcube indique juste que l'authetification a échoué.


Courrier est assez verbeux, il trace notamment les ouvertures et fermetures de
session. Par exemple chez moi :

 Dec 11 12:32:43 serveur imapd: Connection, ip=[:::192.168.1.52]
 Dec 11 12:32:43 serveur imapd: LOGIN, user=, ip=[:::192.168.1.52], 
port=[46932], protocol=IMAP

Quand tu tentes de te connecter avec ton Webmail, vois-tu ce genre de traces
(/var/log/syslog) ?


Pour roundcube, j'ai ceci :

Dec 11 13:23:37 rayleigh imapd-ssl: couriertls: accept: 
error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca


	Pour squirrelmail, j'ai la même chose. Ce comportement semble provenir 
d'une modification du fonctionnement de je ne sais plus quelle fonction 
de php.



J'ai bien vu passer une alerte PHP dont certaines fonctions du 5.6 sont
incompatibles avec les anciennes 5.5, mais je n'ai pas réussi à contourner
le problème.


Quelle version de RoundCube utilises-tu ? Celle des dépôts ou bien une autre ?


Celle des dépôts.


Chez moi (avec le PHP des dépôts mais un RoundCube venant du site officiel du
projet), je n'ai aucun souci.


	Je ne sais pas s'il y a encore un effort pour maintenir roundcube dasn 
les dépôts officiels :-( Il me semble que le problème est corrigé dans 
la version officielle, mais pour l'instant, je préfère rester avec la 
version officielle debian.


Cordialement,

JKB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54898e3d.3000...@systella.fr

Re: Authentification webmail

[Sébastien NOBILI]

Bonjour,

Le jeudi 11 décembre 2014 à 11:38, BERTRAND Joël a écrit :
>   Depuis une mise à jour récente, alors que le serveur de mail continue à
> parfaitement fonctionner, je suis devenu incapable de me connecter aux
> webmails. L'authentification échoue. J'avoue ne plus savoir où chercher.
> 
>   Squirrelmail est assez verbeux et affiche :
> Erreur lors de la connexion au serveur IMAP tls://...
> 
>   Roudcube indique juste que l'authetification a échoué.

Courrier est assez verbeux, il trace notamment les ouvertures et fermetures de
session. Par exemple chez moi :

Dec 11 12:32:43 serveur imapd: Connection, ip=[:::192.168.1.52]
Dec 11 12:32:43 serveur imapd: LOGIN, user=, ip=[:::192.168.1.52], 
port=[46932], protocol=IMAP

Quand tu tentes de te connecter avec ton Webmail, vois-tu ce genre de traces
(/var/log/syslog) ?

>   J'ai bien vu passer une alerte PHP dont certaines fonctions du 5.6 sont
> incompatibles avec les anciennes 5.5, mais je n'ai pas réussi à contourner
> le problème.

Quelle version de RoundCube utilises-tu ? Celle des dépôts ou bien une autre ?

Chez moi (avec le PHP des dépôts mais un RoundCube venant du site officiel du
projet), je n'ai aucun souci.

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/2014123506.gb15...@sebian.nob900.homeip.net

Re: Authentification AD: directe ou via OpenLDAP ?

[Olivier]

Le 9 octobre 2012 09:31, Mathias Dufresne  a
écrit :

> Salut,
>
> Les deux devraient fonctionner sans souci, d'un point de
> l'authentification.
>
> La difficulté réside essentiellement, si je ne dis pas de bêtises, dans la
> configuration de Kerberos, mais le net doit fourmiller de documentation
> depuis le temps que les Linux accèdent aux AD.
> La question du coup me semble plus être :
> - faut-il configurer Kerberos pour une auth directe ?
> - si oui, ne serait-ce pas plus simple de configurer Kerberos avec
> OpenLDAP et avoir une auth web pure LDAP ? Ce qui pourrait faire un poil
> diminuer la sécurité du site s'il n'utilise pas krb, celui-ci ne devant pas
> être complètement inutile :p
>
> Cdlt,
>
> mathias
>
> Le 8 octobre 2012 08:49, Olivier  a écrit :
>
> Bonjour,
>>
>> Je suis totalement novice dans le domaine des annuaires LDAP.
>> Je développe une appli web (apache2, ...) qui comprend un module
>> d'authentification-autorisation.
>> Elle va être utilisée chez un client qui utilise Active Directory.
>>
>> Est-il préférable de configurer apache2 pour authentifier-autoriser les
>> utilisateurs en interrogeant directement Active Directory ou bien est-il
>> préférable d'interroger une base intermédiaire sous OpenLDAP, par exemple,
>> et de mettre en place une synchronisation entre OpenLDAP et Active
>> Directory ?
>>
>> Slts
>>
>
>
Suite aux indications de Mathias, je viens en effet, de (re-)découvrir le
protocole Kerberos et son module libapache2-mod-auth-kerb.
Ce protocole semble bien adapté à mon contexte car il permet le Single Sign
On.
Il semble donc possible de configurer Apache2 pour authentifier-autoriser
des utilisateurs définis dans une base Active Directory via le protocole
Kerberos.

Pour bien faire, j'ai recherché des annuaires LDAP Open Source supportant
aussi Kerberos et qui pourraient avantageusement de se substituer  à une
base Active Directory, pour des tests ou des démos, par exemple.

Le projet 389-ds semble inclure un module Kerberos mais 389-ds n'est pas
encore empaqueté pour Squeeze ou Wheezy.
Le projet FusionDirectory prévoit pour sa future version 1.0.5, un plugin
Kerberos mais la version 1.0.4 du projet n'est pas encore publiée.

Avez-vous des recommandations en la matière ?

Re: Authentification AD: directe ou via OpenLDAP ?

[Mathias Dufresne]

Salut,

Les deux devraient fonctionner sans souci, d'un point de
l'authentification.

La difficulté réside essentiellement, si je ne dis pas de bêtises, dans la
configuration de Kerberos, mais le net doit fourmiller de documentation
depuis le temps que les Linux accèdent aux AD.
La question du coup me semble plus être :
- faut-il configurer Kerberos pour une auth directe ?
- si oui, ne serait-ce pas plus simple de configurer Kerberos avec OpenLDAP
et avoir une auth web pure LDAP ? Ce qui pourrait faire un poil diminuer la
sécurité du site s'il n'utilise pas krb, celui-ci ne devant pas être
complètement inutile :p

Cdlt,

mathias

Le 8 octobre 2012 08:49, Olivier  a écrit :

> Bonjour,
>
> Je suis totalement novice dans le domaine des annuaires LDAP.
> Je développe une appli web (apache2, ...) qui comprend un module
> d'authentification-autorisation.
> Elle va être utilisée chez un client qui utilise Active Directory.
>
> Est-il préférable de configurer apache2 pour authentifier-autoriser les
> utilisateurs en interrogeant directement Active Directory ou bien est-il
> préférable d'interroger une base intermédiaire sous OpenLDAP, par exemple,
> et de mettre en place une synchronisation entre OpenLDAP et Active
> Directory ?
>
> Slts
>

Re: authentification du dépôt backports pour squeeze

[Tulum]

Le dimanche 03 octobre 2010 13:16:41 François, vous avez écrit :
> Le 03/10/2010 11:31, Tulum a écrit :
> > Par contre j'ai installé dans les sources le dépôt backports.debian.org.
> > Lorsque je met à jour les sources, j'ai un problème d'authentification de
> > la source backports.
> 
> Il n'y a de backports que pour les versions stables. Il faudra donc
> attendre que la Squeeze soit stable pour qu'elle ait des backports.
ok merci pour la réponse

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201010091640.57243.tu...@laposte.net

Re: authentification du dépôt backports pour squeeze

[François]

Le 03/10/2010 13:16, François a écrit :

Le 03/10/2010 11:31, Tulum a écrit :

Par contre j'ai installé dans les sources le dépôt backports.debian.org.
Lorsque je met à jour les sources, j'ai un problème d'authentification
de la
source backports.


Il n'y a de backports que pour les versions stables. Il faudra donc
attendre que la Squeeze soit stable pour qu'elle ait des backports.

Pour accéder aux backports, il faut installer le paquet 
debian-backports-keyring qui fournit la clé.


--
François

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i8aml0$eq...@dough.gmane.org

Re: authentification du dépô t backports pour squeeze

[Jeremie COURREGES-ANGLAS]

Le Sunday 03 October 2010 à 11:31:05AM, Tulum a écrit :
> Bonjour,
> 
> Je suis sous debian depuis 1 semaine. Pour l'instant tout fonctionne très 
> bien 
> et vu l'usage de mon PC (assez basique) cela devrait durer.
> 
> Par contre j'ai installé dans les sources le dépôt backports.debian.org. 
> Lorsque je met à jour les sources, j'ai un problème d'authentification de la 
> source backports.
> 
> Je ne trouve pas la clé sur le site et google ne m'aide pas plus.
> 
> Une idée ? merci
> 

http://backports.org/dokuwiki/doku.php?id=instructions

Nettoie tes lunettes ;)

-- 
"Free software, free society."
Jérémie Courrèges-Anglas
GPG key : 06A11494


pgpiye78EvRGh.pgp
Description: PGP signature

Re: authentification du dépôt backports pour squeeze

[François]

Le 03/10/2010 11:31, Tulum a écrit :

Par contre j'ai installé dans les sources le dépôt backports.debian.org.
Lorsque je met à jour les sources, j'ai un problème d'authentification de la
source backports.


Il n'y a de backports que pour les versions stables. Il faudra donc 
attendre que la Squeeze soit stable pour qu'elle ait des backports.


--
François

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/i89ohg$tj...@dough.gmane.org

Re: authentification du dépôt backports pour squeeze

[Thierry Chatelet]

On Sunday 03 October 2010 11:31:05 Tulum wrote:
> Bonjour,
> 
> Je suis sous debian depuis 1 semaine. Pour l'instant tout fonctionne très
> bien et vu l'usage de mon PC (assez basique) cela devrait durer.
> 
> Par contre j'ai installé dans les sources le dépôt backports.debian.org.
> Lorsque je met à jour les sources, j'ai un problème d'authentification de
> la source backports.
> 
> Je ne trouve pas la clé sur le site et google ne m'aide pas plus.
> 
> Une idée ? merci

Je crois que backport est le portage de  certains package de squeeze vers 
lenny. Donc si tu as une squeeze, backport ne t'apportera rien de nouveau.
Thierry

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201010031228.44181.tchate...@free.fr

Re: Authentification sur le site de la poste

[Gaëtan PERRIER]

Le Sun, 04 Apr 2010 22:46:21 +0200
Jean-Baptiste Bourgoin  a écrit:

> Oui, mais j'ai remarqué quelque chose d'étrange :
> 
> Je n'ai ces symptômes que lorsque j'utilise le plugin flash gnash,
> lorsque j'installe le plugin flash officiel, j'accède sans problèmes à
> la fenêtre de saisie.
> 
> Pourtant ce ne me semble pas être un outil flash.
> 

Moi, ça le fait aussi avec le flash d'adobe.

A+

-- 
Gaëtan PERRIER 

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100404230714.7b7cb939.gaetan.perr...@neuf.fr

Re: Authentification sur le site de la poste

[Jean-Baptiste Bourgoin]

Le lundi 29 mars 2010 à 22:55 +0200, Guy Roussin a écrit :
> Bonsoir,
> 
> https://www.labanquepostale.fr/index.html
> 
> Résultats obtenus avec une debian sid 386 à jour :
> 
> Avec iceweasel, je n'arrive pas à faire apparaître la
> fenêtre de saisie du compte et du mot de passe
> sur le site de la poste. A la place, j'ai toujours
> "connexion réinitialisée".
> 
> Avec le navigateur web de gnome (epiphany) et konqueror
> ça va un peu mieux mais il ne m'affiche que des zéros pour les
> codes à saisir et la vocalisation ne marche pas : impossible de
> saisir son code, ou alors, il faut de la chance ;-)
> 
> 
> C'est finalement avec google chrome que je peux accéder
> à mon compte (ça à l'air aussi ok avec opera, vocalisation ok) ..,
> 
> Avez vous les mêmes symptômes ?
> 
> 
> Merci.
> 
> -- 
> Guy

Oui, mais j'ai remarqué quelque chose d'étrange :

Je n'ai ces symptômes que lorsque j'utilise le plugin flash gnash,
lorsque j'installe le plugin flash officiel, j'accède sans problèmes à
la fenêtre de saisie.

Pourtant ce ne me semble pas être un outil flash.

Jean-Baptiste Bourgoin


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Authentification sur le site de la poste

[Guy Roussin]

Merci, effectivement en rechargeant plusieurs fois la page ça fini
par passer ...



ça me fait penser à un problème de load balancing sans "transfert de
session", ça ne fait pas avancer le problème directement, mais peut
être qu'en changeant la stratégie locale (iceweasel et le cookies pour
ce site, il pourrait y avoir un moyen de faire fonctionner)

J'ai bon ?
  

Je sais pas, en tout cas maintenant ça marche à tous les coups sans avoir
rien fait ! c'est sans doute côté serveur de la poste qu'il se passe des 
choses ...

Si le problème se pose à nouveau, je ferai quelques tests supplémentaires
dans ce sens.

Guy

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4bb1ae14.1030...@teledetection.fr

Re: Authentification sur le site de la poste

[Grégory Bulot]

Guy Roussin  à écrit le Tue, 30 Mar 2010
09:34:32 +0200

 
> > Idem
> > En rechargeant plus fois la page, j'arrive à avoir la page de login.
> >
> > alex
> >   
> Merci, effectivement en rechargeant plusieurs fois la page ça fini
> par passer ...

ça me fait penser à un problème de load balancing sans "transfert de
session", ça ne fait pas avancer le problème directement, mais peut
être qu'en changeant la stratégie locale (iceweasel et le cookies pour
ce site, il pourrait y avoir un moyen de faire fonctionner)

J'ai bon ?

-- 

Cordialement
Grégory BULOT

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100330093839.4ec15...@morpheus.bulot-fr.com

Re: Authentification sur le site de la poste

[Guy Roussin]

https://www.labanquepostale.fr/index.html

Résultats obtenus avec une debian sid 386 à jour :

Avez vous les mêmes symptômes ?


  

J'ai 3 machines en testing. Une me pose des problèmes mais en
rechargeant plusieurs fois la page j'arrive à obtenir la page
d'identification. Avec les deux autres je n'ai jamais de problème.
J'utilise iceweasel sur les 3.


Idem
En rechargeant plus fois la page, j'arrive à avoir la page de login.

alex
  

Merci, effectivement en rechargeant plusieurs fois la page ça fini
par passer ...

--
Guy 


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4bb1a988.5050...@teledetection.fr

Re: Authentification sur le site de la poste

[Alex Perso]

Gaëtan PERRIER a écrit :
> Le Mon, 29 Mar 2010 22:55:58 +0200
> Guy Roussin  a écrit:
> 
>> Bonsoir,
>>
>> https://www.labanquepostale.fr/index.html
>>
>> Résultats obtenus avec une debian sid 386 à jour :
>>
>> Avez vous les mêmes symptômes ?
>>
>>
> 
> J'ai 3 machines en testing. Une me pose des problèmes mais en
> rechargeant plusieurs fois la page j'arrive à obtenir la page
> d'identification. Avec les deux autres je n'ai jamais de problème.
> J'utilise iceweasel sur les 3.
> 
> Gaëtan
> 
Idem
En rechargeant plus fois la page, j'arrive à avoir la page de login.

alex

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4bb1a5d7.3050...@rendour.org

Re: Authentification sur le site de la poste

[Pierre Meurisse]

Bonjour,

On Mon, Mar 29, 2010 at 10:55:58PM +0200, Guy Roussin wrote:
> 
> Bonsoir,
> 
> https://www.labanquepostale.fr/index.html
> 
> Résultats obtenus avec une debian sid 386 à jour :

chez moi, pas de pb ce matin avec iceweasel et sid amd64.


-- 
Pierre Meurisse

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100330060848.ga3...@cosidlvm.bureau.maison

Re: Authentification sur le site de la poste

[Gaëtan PERRIER]

Le Mon, 29 Mar 2010 22:55:58 +0200
Guy Roussin  a écrit:

> 
> Bonsoir,
> 
> https://www.labanquepostale.fr/index.html
> 
> Résultats obtenus avec une debian sid 386 à jour :
> 
> Avec iceweasel, je n'arrive pas à faire apparaître la
> fenêtre de saisie du compte et du mot de passe
> sur le site de la poste. A la place, j'ai toujours
> "connexion réinitialisée".
> 
> Avec le navigateur web de gnome (epiphany) et konqueror
> ça va un peu mieux mais il ne m'affiche que des zéros pour les
> codes à saisir et la vocalisation ne marche pas : impossible de
> saisir son code, ou alors, il faut de la chance ;-)
> 
> 
> C'est finalement avec google chrome que je peux accéder
> à mon compte (ça à l'air aussi ok avec opera, vocalisation ok) ..,
> 
> Avez vous les mêmes symptômes ?
> 
> 

J'ai 3 machines en testing. Une me pose des problèmes mais en
rechargeant plusieurs fois la page j'arrive à obtenir la page
d'identification. Avec les deux autres je n'ai jamais de problème.
J'utilise iceweasel sur les 3.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20100330005523.4fca77b1.gaetan.perr...@neuf.fr

Re: Authentification sur le site de la poste

[Jean-Yves F. Barbier]

Le Mon, 29 Mar 2010 22:55:58 +0200,
Guy Roussin  a écrit :

> Bonsoir,
> 
> https://www.labanquepostale.fr/index.html
> 
> Résultats obtenus avec une debian sid 386 à jour :
> 
> Avec iceweasel, je n'arrive pas à faire apparaître la
> fenêtre de saisie du compte et du mot de passe
> sur le site de la poste. A la place, j'ai toujours
> "connexion réinitialisée".
> 
> Avec le navigateur web de gnome (epiphany) et konqueror
> ça va un peu mieux mais il ne m'affiche que des zéros pour les
> codes à saisir et la vocalisation ne marche pas : impossible de
> saisir son code, ou alors, il faut de la chance ;-)
> 
> 
> C'est finalement avec google chrome que je peux accéder
> à mon compte (ça à l'air aussi ok avec opera, vocalisation ok) ..,
> 
> Avez vous les mêmes symptômes ?

@20100330-000306:TU: Yep avec iceweasel
another fine day in m$ fucking world...

-- 
Even a blind pig stumbles upon a few acorns.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/2010033651.1e41a...@anubis.defcon1

Re: Authentification smtp [Résolu]

[Mourad Jaber]

On 07/01/2010 12:11, Mourad Jaber wrote:



On 06/01/2010 10:09, Bernardo wrote:

Bonjour,

ce tuto peut t'intéresser :

http://blog.rom1v.com/2010/01/ajouter-lauthentification-smtp-sur-un-serveur-mail/ 



C'est pour un Ubuntu Server, mais c'est du Debian ! ;-)

Merci pour ce lien, après avoir modifié quelques droits sur les 
répertoires de saslauthd, j'arrive presque à une authentification...


J'ai un souci avec greylist !

Si le domaine vers lequel j'envoie n'est pas connu par greylist, il 
refuse de router le message la première fois, et il faut que j'attende 
le timeout de postgrey pour pouvoir envoyer le message !


Existe-il une possibilité de by passer grey liste pour les 
utilisateurs authentifiés ?


@ +

Mourad





Je me réponds à moi-même...

il manquait la clause permit_sasl_authenticated au niveau du 
smtpd_sender_restrictions


Merci pour vos réponse instructives ;)

Mourad

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Authentification smtp

[Mourad Jaber]

On 06/01/2010 10:09, Bernardo wrote:

Bonjour,

ce tuto peut t'intéresser :

http://blog.rom1v.com/2010/01/ajouter-lauthentification-smtp-sur-un-serveur-mail/

C'est pour un Ubuntu Server, mais c'est du Debian ! ;-)

   
Merci pour ce lien, après avoir modifié quelques droits sur les 
répertoires de saslauthd, j'arrive presque à une authentification...


J'ai un souci avec greylist !

Si le domaine vers lequel j'envoie n'est pas connu par greylist, il 
refuse de router le message la première fois, et il faut que j'attende 
le timeout de postgrey pour pouvoir envoyer le message !


Existe-il une possibilité de by passer grey liste pour les utilisateurs 
authentifiés ?


@ +

Mourad



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Authentification smtp

[Bernardo]

Bonjour,

ce tuto peut t'intéresser :

http://blog.rom1v.com/2010/01/ajouter-lauthentification-smtp-sur-un-serveur-mail/

C'est pour un Ubuntu Server, mais c'est du Debian ! ;-)

Mourad Jaber nous disait il y a peu :
> Bonjour,
>
> J'aimerai mettre en place un serveur smtp pour permettre d'envoyer des
> messages de n'importe quel réseau.
> Pour eviter l'utilisation en open relay, je voudrai mettre en place une
> authentification et du tls.
>
> Actuellement, j'ai un postfix (avec spamassassin clamav et postgrey) qui
> distribue les boites mails des utilisateurs de cette machine.
>
> Comment activer le sasl et faire en sorte que ce soit les identifiants
> (via PAM) des utilisateurs de la machine que soit pris en compte ?
>
> J'ai trouvé plusieurs tuto, mais à chaque fois il faut utiliser une base
> externe, et ce n'est pas ce que je cherche, je voudrai éviter les
> doubles saisies de mot de passe !
>
> Merci pour votre aide
>
> Mourad
>

-- 

Cordialement,
Bernardo.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Authentification smtp

[Webmaster Informatique et entreprise]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mourad Jaber a écrit :
> Bonjour,
>
> J'aimerai mettre en place un serveur smtp pour permettre d'envoyer
> des messages de n'importe quel réseau.
> Pour eviter l'utilisation en open relay, je voudrai mettre en place
> une authentification et du tls.
>
> Actuellement, j'ai un postfix (avec spamassassin clamav et postgrey)
> qui distribue les boites mails des utilisateurs de cette machine.
>
> Comment activer le sasl et faire en sorte que ce soit les
> identifiants (via PAM) des utilisateurs de la machine que soit pris
> en compte ?
>
> J'ai trouvé plusieurs tuto, mais à chaque fois il faut utiliser une
> base externe, et ce n'est pas ce que je cherche, je voudrai éviter
> les doubles saisies de mot de passe !
>
> Merci pour votre aide
>
> Mourad
>
Je me pause la même question

J'aimerai envoyer mes message systeme par Exim avec mon smtp.domaine.fr

sans authentification avec le smtp.fai.com , pas de soucis,

je ne cherche pas forcement l'encryptage
  je ne suis pas persuader que les mails transits entre
serveurs de manière crypté ...

j'ai rempli le fichier client.password,
cela ne fonctionne pas,

Quelqu'un aurait il une réponse ?

Poustiquet

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktETGIACgkQcvW/yJuiUQk+0ACgg9Z2qL2Wsnc5nbItVy6VRrmi
F+UAnjtbPwEdnh1vOMeyyaHCetHbaizT
=CRs4
-END PGP SIGNATURE-

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Authentification smtp

[lefoudupc]

Le Tue, 05 Jan 2010 20:26:13 +0100,
Nicolas KOWALSKI  a écrit :

> Mourad Jaber  writes:
> 
> > Bonjour,
> 
> Bonjour,

Bonjour,
> 
> > Actuellement, j'ai un postfix (avec spamassassin clamav et postgrey)
> > qui distribue les boites mails des utilisateurs de cette machine.
> >
> > Comment activer le sasl et faire en sorte que ce soit les
> > identifiants (via PAM) des utilisateurs de la machine que soit pris
> > en compte ?
> 
Il me semble que ce tuto explique cela (En Français :)):
http://irp.nain-t.net/doku.php/200messagerie:020postfix2:070_relais

Personnellement je passe tout en claire dans mon VPN fait avec OPENVPN
>
> 

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Authentification smtp

[Nicolas KOWALSKI]

Mourad Jaber  writes:

> Bonjour,

Bonjour,

> Actuellement, j'ai un postfix (avec spamassassin clamav et postgrey)
> qui distribue les boites mails des utilisateurs de cette machine.
>
> Comment activer le sasl et faire en sorte que ce soit les identifiants
> (via PAM) des utilisateurs de la machine que soit pris en compte ?

La documentation officielle de postfix explique comment le faire, avec
dovecot ou cyrus-sasl:
http://www.postfix.org/SASL_README.html#server_sasl

> J'ai trouvé plusieurs tuto, mais à chaque fois il faut utiliser une
> base externe, et ce n'est pas ce que je cherche, je voudrai éviter les
> doubles saisies de mot de passe !

Si tu utilises cyrus-sasl (paquets sasl2-bin et libsasl2-modules), par
défaut le démon saslauthd utilise pam, donc pas de problème de
duplication. 

Personellement j'utilise le sasl de dovecot, et l'authentification se
déroule également sans souci, via pam.

-- 
Nicolas

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re : Authentification proxy Squid transparente.

[keneda2k]

Bonjour,

j'ai résolue mon problème, il s'agissait tout bêtement de winbind qui 
était manquant.
pour info, je vous note la démarche que j'ai suivis je part bien sur du 
principe qu'il y a déjà contrôleur de domaine fonctionnelle sur le serveur


Tout d'abord, il faut installer winbind
Dans /etc/samba/smb.conf pour "activer" windbind ajouter au minimum ceci
winbind use default domain = yes

Modifier /etc/nsswitch.conf pour qu'il prenne en charge winbind
passwd: compat winbind ldap
group:  compat winbind ldap

Je ne suis pas sur que le support LDAP soit toujours nécessaire mais  
dans le doute j'ai préférer le laisser


Reinitialisé le services de nom nscd
/etc/init.d/nscd stop
/etc/init.d/nscd start
 N'utiliser pas restart car cela n'invalide pas les "bases de 
données existante"


Ajouter le serveur au domaine si cd n'est deja fait
# net join -S serveur

tester le bon fonctionnement de winbind
# wbinfo -t
checking the trust secret via RPC calls succeeded
# wbinfo -u
retourne la liste des utilisateurs
# wbinfo -g
retourne la liste des groupes

dans /ets/squid/squid.conf
# Si dans le domaine authentification transparente
auth_param ntlm program /usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-ntlmssp

auth_param ntlm children 1
auth_param ntlm keep_alive on

# Si pas dans le domaine un popup demande les identifitans
auth_param basic program /usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-basic

auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

# Pour utiliser le proxy, il faut etre authentifié !!!
acl password proxy_auth REQUIRED
http_access allow all password

Walla .. normalement si tout c'est bien passé ça marche :)

pour ma part j'ai ajouter dansguardian,
dans /etc/dansguardian/dansguardian.conf  j'ai juste eu a deomenter
authplugin = '/etc/dansguardian/authplugins/proxy-ntlm.conf'

bien sur cette configuration reste a ameliorer .

pour ceux qui souhaiterais plus d'infos n'hésitez pas me contacter ;)



Dominique Claver KOUAME a écrit :

Bonjour,
J'ai vu ton poste et étant donné que tu as déjà une authentification 
Samba/ldap autant en profiter pour l'authentification Squid.

Voici un tuto :
http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html

Bon succès 
 


*--*

*Dominique Claver KOUAME*

/*Consultant indépendant en télécoms*/

25 BP 1464 Abidjan 25

Contacts: *+225 45802315   *

* +225 02316080*   





*De :* keneda2k 
*À :* debian-user-french@lists.debian.org
*Envoyé le :* Mer 9 Décembre 2009, 15 h 19 min 31 s
*Objet :* Authentification proxy Squid transparente.

Bonjour,

J’ai mis en place récemment un contrôleur de domaine sur le couple 
Samba LDAP.


J’ai ensuite installé et configuré ibnss-ldap libpam-ldap et modifier 
les fichiers suivants :


/etc/nsswith.conf

/etc/pam.d/common-account

/etc/pam.d/common-auth

/etc/pam.d/common-password

etc/pam.d/common-session

pour que les utilisateurs présent dans le LDAP puissent s’authentifier 
sur le System Debian.


Le client Windows (XP) se connecte correctement au domaine, et les 
utilisateurs peuvent s’authentifier sur le System Debian, bref le 
domaine fonctionne correctement et l’authentification aussi.


La phase 2 consiste à installer un proxy squid avec authentification 
pour les utilisateurs et c’est la que je rencontre des problemes.


Sans authentification, le proxy fonctionne correctement.

J’ai ensuite mis l’authentification NTLM (qui permet de s’authentifier 
de manière transparente si je ne me trompe) mais pour teste je me suis 
contenter de l’utiliser en basic soit dans le fichier de conf de squid :


auth_param basic program /usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-basic

auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

lors de l’ouverture  du navigateur, j’ai  une demande 
d’authentification (Normal puis que je suis en basic) un fois les 
identifiants entré, je peux naviguer sur internet, sa marche.


En revanche pour l’authentification NTLM transparente j’active dans 
mon fichier de conf :


auth_param ntlm program /usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-ntlmssp

auth_param ntlm children 5
auth_param ntlm keep_alive on

Et la, lors de l’ouverture  du navigateur, j’ai  une demande 
d’authentification (Pas normale cela devrais être transparent) et mes 
identifiants sont régenté alors qu’ils sont valide


Il me semble que le problème viens du fait qu’en mode Basic les 
identifiants sont envoyer en clair alors que dans le mode ntlmssp les 
identifiants sont envoyé en crypté, mais je ne sais pas comment 
résoudre cela.


Je viens donc vous demander votre aide pour résoudre ce problème

Merci à vous




--
Lisez la FAQ de la liste avant de poser une question :
h

Re : Authentification proxy Squid transparente.

[keneda2k]

Re desolé, je ne sais pas pourquoi mais le webmail de gmail me fait des 
choses etranges .


je disais donc que mon problème se situe au niveau de l'authentification 
transparente. étant
donnée que les utilisateurs on déjà entré leurs identifiants pour ouvrir 
leurs session
sur le poste client, je ne vois pas la nécessité de redemander les 
identifiants lors de l'ouverture

du navigateurs


Dominique Claver KOUAME a écrit :

Bonjour,
J'ai vu ton poste et étant donné que tu as déjà une authentification 
Samba/ldap autant en profiter pour l'authentification Squid.

Voici un tuto :
http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html

Bon succès 
 


*--*

*Dominique Claver KOUAME*

/*Consultant indépendant en télécoms*/

25 BP 1464 Abidjan 25

Contacts: *+225 45802315   *

* +225 02316080*   





*De :* keneda2k 
*À :* debian-user-french@lists.debian.org
*Envoyé le :* Mer 9 Décembre 2009, 15 h 19 min 31 s
*Objet :* Authentification proxy Squid transparente.

Bonjour,

J’ai mis en place récemment un contrôleur de domaine sur le couple 
Samba LDAP.


J’ai ensuite installé et configuré ibnss-ldap libpam-ldap et modifier 
les fichiers suivants :


/etc/nsswith.conf

/etc/pam.d/common-account

/etc/pam.d/common-auth

/etc/pam.d/common-password

etc/pam.d/common-session

pour que les utilisateurs présent dans le LDAP puissent s’authentifier 
sur le System Debian.


Le client Windows (XP) se connecte correctement au domaine, et les 
utilisateurs peuvent s’authentifier sur le System Debian, bref le 
domaine fonctionne correctement et l’authentification aussi.


La phase 2 consiste à installer un proxy squid avec authentification 
pour les utilisateurs et c’est la que je rencontre des problemes.


Sans authentification, le proxy fonctionne correctement.

J’ai ensuite mis l’authentification NTLM (qui permet de s’authentifier 
de manière transparente si je ne me trompe) mais pour teste je me suis 
contenter de l’utiliser en basic soit dans le fichier de conf de squid :


auth_param basic program /usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-basic

auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

lors de l’ouverture  du navigateur, j’ai  une demande 
d’authentification (Normal puis que je suis en basic) un fois les 
identifiants entré, je peux naviguer sur internet, sa marche.


En revanche pour l’authentification NTLM transparente j’active dans 
mon fichier de conf :


auth_param ntlm program /usr/bin/ntlm_auth 
--helper-protocol=squid-2.5-ntlmssp

auth_param ntlm children 5
auth_param ntlm keep_alive on

Et la, lors de l’ouverture  du navigateur, j’ai  une demande 
d’authentification (Pas normale cela devrais être transparent) et mes 
identifiants sont régenté alors qu’ils sont valide


Il me semble que le problème viens du fait qu’en mode Basic les 
identifiants sont envoyer en clair alors que dans le mode ntlmssp les 
identifiants sont envoyé en crypté, mais je ne sais pas comment 
résoudre cela.


Je viens donc vous demander votre aide pour résoudre ce problème

Merci à vous




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "From" et "Reply-To:"

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org

Re: Re : Authentification proxy Squid transparente.

[keneda2k]

désolé, mon precedent mail est partis suite a

Le 14 décembre 2009 12:36, Dominique Claver KOUAME  a
écrit :

> Bonjour,
> J'ai vu ton poste et étant donné que tu as déjà une authentification
> Samba/ldap autant en profiter pour l'authentification Squid.
> Voici un tuto :
>
> http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html
>
> Bon succès 
>
>
> *--*
>
> *Dominique Claver KOUAME*
>
> *Consultant indépendant en télécoms*
>
> 25 BP 1464 Abidjan 25
>
> Contacts: *+225 45802315   *
>
> * +225 02316080*
>
>
> --
> *De :* keneda2k 
> *À :* debian-user-french@lists.debian.org
> *Envoyé le :* Mer 9 Décembre 2009, 15 h 19 min 31 s
> *Objet :* Authentification proxy Squid transparente.
>
> Bonjour,
>
> J’ai mis en place récemment un contrôleur de domaine sur le couple Samba
> LDAP.
>
> J’ai ensuite installé et configuré ibnss-ldap libpam-ldap et modifier les
> fichiers suivants :
>
> /etc/nsswith.conf
>
> /etc/pam.d/common-account
>
> /etc/pam.d/common-auth
>
> /etc/pam.d/common-password
>
> etc/pam.d/common-session
>
> pour que les utilisateurs présent dans le LDAP puissent s’authentifier sur
> le System Debian.
>
> Le client Windows (XP) se connecte correctement au domaine, et les
> utilisateurs peuvent s’authentifier sur le System Debian, bref le domaine
> fonctionne correctement et l’authentification aussi.
>
> La phase 2 consiste à installer un proxy squid avec authentification pour
> les utilisateurs et c’est la que je rencontre des problemes.
>
> Sans authentification, le proxy fonctionne correctement.
>
> J’ai ensuite mis l’authentification NTLM (qui permet de s’authentifier de
> manière transparente si je ne me trompe) mais pour teste je me suis
> contenter de l’utiliser en basic soit dans le fichier de conf de squid :
>
> auth_param basic program /usr/bin/ntlm_auth
> --helper-protocol=squid-2.5-basic
> auth_param basic children 5
> auth_param basic realm Squid proxy-caching web server
> auth_param basic credentialsttl 2 hours
> auth_param basic casesensitive off
>
> lors de l’ouverture  du navigateur, j’ai  une demande d’authentification
> (Normal puis que je suis en basic) un fois les identifiants entré, je peux
> naviguer sur internet, sa marche.
>
> En revanche pour l’authentification NTLM transparente j’active dans mon
> fichier de conf :
>
> auth_param ntlm program /usr/bin/ntlm_auth
> --helper-protocol=squid-2.5-ntlmssp
> auth_param ntlm children 5
> auth_param ntlm keep_alive on
>
> Et la, lors de l’ouverture  du navigateur, j’ai  une demande
> d’authentification (Pas normale cela devrais être transparent) et mes
> identifiants sont régenté alors qu’ils sont valide
>
> Il me semble que le problème viens du fait qu’en mode Basic les
> identifiants sont envoyer en clair alors que dans le mode ntlmssp les
> identifiants sont envoyé en crypté, mais je ne sais pas comment résoudre
> cela.
>
> Je viens donc vous demander votre aide pour résoudre ce problème
>
> Merci à vous
>
>

Re: Re : Authentification proxy Squid transparente.

[keneda2k]

Bonjour,

l'authentification n'est pas vraiment le problème que je rencontre, pour
l'instant en atendant mieux j'utilise l'authentification ntlm basic. mon
problème ce situe sur l'authentification transparente. les utilisatreurs
ayant dej

Le 14 décembre 2009 12:36, Dominique Claver KOUAME  a
écrit :

> Bonjour,
> J'ai vu ton poste et étant donné que tu as déjà une authentification
> Samba/ldap autant en profiter pour l'authentification Squid.
> Voici un tuto :
>
> http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html
>
> Bon succès 
>
>
> *--*
>
> *Dominique Claver KOUAME*
>
> *Consultant indépendant en télécoms*
>
> 25 BP 1464 Abidjan 25
>
> Contacts: *+225 45802315   *
>
> * +225 02316080*
>
>
> --
> *De :* keneda2k 
> *À :* debian-user-french@lists.debian.org
> *Envoyé le :* Mer 9 Décembre 2009, 15 h 19 min 31 s
> *Objet :* Authentification proxy Squid transparente.
>
> Bonjour,
>
> J’ai mis en place récemment un contrôleur de domaine sur le couple Samba
> LDAP.
>
> J’ai ensuite installé et configuré ibnss-ldap libpam-ldap et modifier les
> fichiers suivants :
>
> /etc/nsswith.conf
>
> /etc/pam.d/common-account
>
> /etc/pam.d/common-auth
>
> /etc/pam.d/common-password
>
> etc/pam.d/common-session
>
> pour que les utilisateurs présent dans le LDAP puissent s’authentifier sur
> le System Debian.
>
> Le client Windows (XP) se connecte correctement au domaine, et les
> utilisateurs peuvent s’authentifier sur le System Debian, bref le domaine
> fonctionne correctement et l’authentification aussi.
>
> La phase 2 consiste à installer un proxy squid avec authentification pour
> les utilisateurs et c’est la que je rencontre des problemes.
>
> Sans authentification, le proxy fonctionne correctement.
>
> J’ai ensuite mis l’authentification NTLM (qui permet de s’authentifier de
> manière transparente si je ne me trompe) mais pour teste je me suis
> contenter de l’utiliser en basic soit dans le fichier de conf de squid :
>
> auth_param basic program /usr/bin/ntlm_auth
> --helper-protocol=squid-2.5-basic
> auth_param basic children 5
> auth_param basic realm Squid proxy-caching web server
> auth_param basic credentialsttl 2 hours
> auth_param basic casesensitive off
>
> lors de l’ouverture  du navigateur, j’ai  une demande d’authentification
> (Normal puis que je suis en basic) un fois les identifiants entré, je peux
> naviguer sur internet, sa marche.
>
> En revanche pour l’authentification NTLM transparente j’active dans mon
> fichier de conf :
>
> auth_param ntlm program /usr/bin/ntlm_auth
> --helper-protocol=squid-2.5-ntlmssp
> auth_param ntlm children 5
> auth_param ntlm keep_alive on
>
> Et la, lors de l’ouverture  du navigateur, j’ai  une demande
> d’authentification (Pas normale cela devrais être transparent) et mes
> identifiants sont régenté alors qu’ils sont valide
>
> Il me semble que le problème viens du fait qu’en mode Basic les
> identifiants sont envoyer en clair alors que dans le mode ntlmssp les
> identifiants sont envoyé en crypté, mais je ne sais pas comment résoudre
> cela.
>
> Je viens donc vous demander votre aide pour résoudre ce problème
>
> Merci à vous
>
>

Re: Authentification LDAP et SSH

[deny]

Le 03/04/2009 10:12 AM,  en cette journée d'hiver *François Cerbelle* a 
écrit fort à propos :

Debian User French a écrit :
Il y a quelques temps j'avais gardé un lien en marque-page en me 
disant que ça pourrait bien me servir un jour:

http://wiki.debian.org/LDAPAuthentication
Manque de bol, la page n'existe plus.


Tu peux consulter une archive web comme web.archive.org et lui donner le 
lien. j'ai vérifié, ce moteur a parcouru et enregistré le contenu de ton 
lien à plusieurs dates. Tu vas donc pouvoir le consulter.


Ce moteur et particulièrement pratique pour des pages comme la tienne 
qui ont purement et simplement disparu du web.


http://web.archive.org

http://web.archive.org/web/20071013020255/http://wiki.debian.org/LDAPAuthentication 




il existe aussi le cache de google
ou le tag site devant l'url de ton site dans le champ de recherche google

--
Qui pisse contre le vent se lave les dents.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Authentification LDAP et SSH

[François Cerbelle]

Debian User French a écrit :
Il y a quelques temps j'avais gardé un lien en marque-page en me disant 
que ça pourrait bien me servir un jour:

http://wiki.debian.org/LDAPAuthentication
Manque de bol, la page n'existe plus.


Tu peux consulter une archive web comme web.archive.org et lui donner le 
lien. j'ai vérifié, ce moteur a parcouru et enregistré le contenu de ton 
lien à plusieurs dates. Tu vas donc pouvoir le consulter.


Ce moteur et particulièrement pratique pour des pages comme la tienne 
qui ont purement et simplement disparu du web.


http://web.archive.org

http://web.archive.org/web/20071013020255/http://wiki.debian.org/LDAPAuthentication

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Authentification LDAP et SSH

[Gabriel Moreau]

Auriez-vous quelques pointeurs car mes recherches me proposent plein de 
truc, sauf ça. Des conseils avisés sur le meilleur moyen de réaliser 
cela sont également les bienvenus.


La page LDAP. Sinon, tu fais une recherche sur leur wiki avec LDAP...

 http://wiki.debian.org/LDAP/PAM?highlight=%28LDAP%29

Il faut il me semble utiliser la classe LDAP 'account' pour gérer un 
accès par machine pour les utilisateurs.


Sinon, cela se fait a coup de AllowUser et DenyUser dans sshd_config 
pour ssh mais cela ne gère que l'accès distant.


gabriel

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Authentification LDAP

[Kevin C]

Merci pour cet article très interessant, je vais m'y atteler!


Le mardi 13 janvier 2009 21:33:47, vous avez écrit :
> On Tue, Jan 13, 2009 at 05:32:27PM +0100,
>  Kevin C  wrote
>
>  a message of 47 lines which said:
> > J'ai ajouté  ça dans /etc/pam.d/system-password
>
> Non, cela ne concerne que le changement de mot de passe, pas la
> connexion.
>
> Comptes Unix stockés sur LDAP
>
> http://www.bortzmeyer.org/comptes-unix-ldap.html
>
> 
>
> Si on gère de nombreux ordinateurs multi-utilisateurs, on se pose
> forcément la question de la centralisation des *comptes*, des
> informations sur les utilisateurs. Il est très pénible de devoir créer
> un compte sur N machines dès qu'un nouvel employé arrive ou de devoir
> se rappeler des M mots de passe précédents parce qu'on ne les a pas
> changé sur toutes les machines. Il existe plusieurs solutions
> techniques à ce problème, et je présente ici l'utilisation de LDAP pour
> gérer une base centralisée de comptes, notamment pour des machines
> Unix.
>
> LDAP est un protocole client-serveur d'interrogation d'un annuaire. Il
> offre donc quelques analogies avec le DNS. Mais son histoire est très
> différente. Issu à l'origine du projet X.500, il en est aujourd'hui le
> seul survivant. LDAP est normalisé dans les RFC 4510 et suivants.
>
> LDAP est juste un protocole, il n'impose rien sur le mécanisme de
> stockage des données, dont on dira un mot au moment de configurer le
> *serveur*. Mais nous allons commencer par la configuration du *client*,
> car il y a davantage de clients que de serveurs.
>
> Nous avons donc une machine Unix (en l'occurrence une Debian) qui a une
> base d'utilisateurs traditionnelle (le fichier /etc/passwd) et qui
> voudrait l'enrichir avec les informations venues du serveur LDAP
> ldap.example.org. L'administrateur de ce serveur nous a donné le nom du
> serveur et la *base* à utiliser, dc=example,dc=org (contrairement au
> DNS, LDAP ne part pas de la racine mais d'une base, souvent dérivée
> d'un nom de domaine). L'administrateur nous dira également la version
> utilisée (la version 3 reste aujourd'hui la seule) et le mécanisme
> d'authentification auprès du serveur (contrairement au DNS, un serveur
> LDAP peut nécessiter une authentification des clients), l'usage ou non
> de TLS, etc. Les objets LDAP décrivant les utilisateurs seront
> probablement de la *classe* posixAccount.
>
> Que faut-il connaitre sur LDAP encore ? Outre les références à la fin
> de cet article, nécessaires pour tout savoir, notons simplement que
> chaque objet stocké dans la base LDAP a un DN ("Distinguished Name") et
> que ce DN l'identifie de manière unique. Le DN est formé de plusieurs
> composants, chaque composant étant un doublet attribut=valeur. Par
> exemple, uid=bleriot,ou=People,dc=example,dc=org est un DN.
>
> Utilisons le client ldapsearch (un outil de test, comme dig pour le
> DNS ; sur Debian, il est dans le paquetage ldap-utils) pour tester que
> notre machine peut joindre le serveur :
>
> % ldapsearch -h ldap.example.org -x -b dc=example,dc=org  \
>  '(objectClass=posixAccount)'
> ...
> dn: cn=Louis Bleriot,ou=People,dc=example,dc=org
> objectClass: posixAccount
> objectClass: shadowAccount
> cn: Louis Bleriot
> sn: bleriot
> uid: bleriot
> uidNumber: 1011
> homeDirectory: /home/bleriot
> gecos: Louis Bleriot
> loginShell: /usr/bin/zsh
> ...
> (-x veut dire accès anonyme, sans authentification)
> Une fois qu'on est sûr du serveur, nous pouvons commencer à configurer
> le client.
>
>
> Pour éviter de mettre du code LDAP dans chaque application qui fait de
> l'authentification (une liste pas du tout limitative nous donne sshd,
> login, sudo, etc), Unix utilise en général le système PAM dans lequel
> l'application appelle un greffon PAM pour les différentes opérations.
> PAM à son tour charge, selon sa configuration, du code LDAP (ou bien
> utilisant d'autres techniques d'authentification).
>
> On va donc installer le support LDAP de PAM. Sur une Debian, c'est le
> paquetage libpam-ldap. Il faut le configurer pour lui donner les
> informations que nous a transmises l'administrateur système. Cela se
> fait dans /etc/pam_ldap.conf dont voici les extraits pertinents :
>
> # On peut aussi indiquer le serveur par la directive "uri" mais je n'ai
> # jamais réussi à la faire fonctionner
> host ldap.example.org
> base dc=example,dc=org
> # Ne pas oublier ces trois lignes, commentées par défaut !
> nss_base_passwd ou=People,dc=example,dc=org?one
> nss_base_shadow ou=People,dc=example,dc=org?one
> nss_base_group  ou=Group,dc=example,dc=org?one
> # Pour savoir quel couple attribut/valeur ajouter à la base (ici
> ou=People), # demander à l'administrateur du serveur LDAP.
> On configure ensuite PAM pour
> utiliser LDAP, dans /etc/pam.d. Chaque application
> qui authentifie a un fichier dans ce répertoire mais la plupart des
> fichiers se contentent d'inclure les fichiers communs comme
> common-auth. Éditons
> common-auth 

Re: Authentification LDAP

[Stephane Bortzmeyer]

On Tue, Jan 13, 2009 at 05:32:27PM +0100,
 Kevin C  wrote 
 a message of 47 lines which said:

> J'ai ajouté  ça dans /etc/pam.d/system-password

Non, cela ne concerne que le changement de mot de passe, pas la
connexion.

Comptes Unix stockés sur LDAP

http://www.bortzmeyer.org/comptes-unix-ldap.html



Si on gère de nombreux ordinateurs multi-utilisateurs, on se pose 
forcément la question de la centralisation des *comptes*, des 
informations sur les utilisateurs. Il est très pénible de devoir créer 
un compte sur N machines dès qu'un nouvel employé arrive ou de devoir 
se rappeler des M mots de passe précédents parce qu'on ne les a pas 
changé sur toutes les machines. Il existe plusieurs solutions 
techniques à ce problème, et je présente ici l'utilisation de LDAP pour 
gérer une base centralisée de comptes, notamment pour des machines 
Unix.

LDAP est un protocole client-serveur d'interrogation d'un annuaire. Il 
offre donc quelques analogies avec le DNS. Mais son histoire est très 
différente. Issu à l'origine du projet X.500, il en est aujourd'hui le 
seul survivant. LDAP est normalisé dans les RFC 4510 et suivants.

LDAP est juste un protocole, il n'impose rien sur le mécanisme de 
stockage des données, dont on dira un mot au moment de configurer le 
*serveur*. Mais nous allons commencer par la configuration du *client*, 
car il y a davantage de clients que de serveurs.

Nous avons donc une machine Unix (en l'occurrence une Debian) qui a une 
base d'utilisateurs traditionnelle (le fichier /etc/passwd) et qui 
voudrait l'enrichir avec les informations venues du serveur LDAP 
ldap.example.org. L'administrateur de ce serveur nous a donné le nom du 
serveur et la *base* à utiliser, dc=example,dc=org (contrairement au 
DNS, LDAP ne part pas de la racine mais d'une base, souvent dérivée 
d'un nom de domaine). L'administrateur nous dira également la version 
utilisée (la version 3 reste aujourd'hui la seule) et le mécanisme 
d'authentification auprès du serveur (contrairement au DNS, un serveur 
LDAP peut nécessiter une authentification des clients), l'usage ou non 
de TLS, etc. Les objets LDAP décrivant les utilisateurs seront 
probablement de la *classe* posixAccount.

Que faut-il connaitre sur LDAP encore ? Outre les références à la fin 
de cet article, nécessaires pour tout savoir, notons simplement que 
chaque objet stocké dans la base LDAP a un DN ("Distinguished Name") et 
que ce DN l'identifie de manière unique. Le DN est formé de plusieurs 
composants, chaque composant étant un doublet attribut=valeur. Par 
exemple, uid=bleriot,ou=People,dc=example,dc=org est un DN.

Utilisons le client ldapsearch (un outil de test, comme dig pour le 
DNS ; sur Debian, il est dans le paquetage ldap-utils) pour tester que 
notre machine peut joindre le serveur :

% ldapsearch -h ldap.example.org -x -b dc=example,dc=org  \
 '(objectClass=posixAccount)'
...
dn: cn=Louis Bleriot,ou=People,dc=example,dc=org
objectClass: posixAccount
objectClass: shadowAccount
cn: Louis Bleriot
sn: bleriot
uid: bleriot
uidNumber: 1011
homeDirectory: /home/bleriot
gecos: Louis Bleriot
loginShell: /usr/bin/zsh
...
(-x veut dire accès anonyme, sans authentification)
Une fois qu'on est sûr du serveur, nous pouvons commencer à configurer
le client.


Pour éviter de mettre du code LDAP dans chaque application qui fait de 
l'authentification (une liste pas du tout limitative nous donne sshd, 
login, sudo, etc), Unix utilise en général le système PAM dans lequel 
l'application appelle un greffon PAM pour les différentes opérations. 
PAM à son tour charge, selon sa configuration, du code LDAP (ou bien 
utilisant d'autres techniques d'authentification).

On va donc installer le support LDAP de PAM. Sur une Debian, c'est le 
paquetage libpam-ldap. Il faut le configurer pour lui donner les 
informations que nous a transmises l'administrateur système. Cela se 
fait dans /etc/pam_ldap.conf dont voici les extraits pertinents :

# On peut aussi indiquer le serveur par la directive "uri" mais je n'ai 
# jamais réussi à la faire fonctionner
host ldap.example.org
base dc=example,dc=org
# Ne pas oublier ces trois lignes, commentées par défaut !
nss_base_passwd ou=People,dc=example,dc=org?one
nss_base_shadow ou=People,dc=example,dc=org?one
nss_base_group  ou=Group,dc=example,dc=org?one
# Pour savoir quel couple attribut/valeur ajouter à la base (ici ou=People),
# demander à l'administrateur du serveur LDAP.
On configure ensuite PAM pour
utiliser LDAP, dans /etc/pam.d. Chaque application
qui authentifie a un fichier dans ce répertoire mais la plupart des
fichiers se contentent d'inclure les fichiers communs comme
common-auth. Éditons
common-auth pour se servir de LDAP (l'ordre du
fichier est significatif, c'est celui dans lequel on utilisera les
différentes techniques) :


# Utiliser LDAP
auth   sufficient pam_ldap.so
# Garder une authentification traditionnelle au cas où...
authrequiredpam_u

Re: Authentification LDAP

[Stephane Bortzmeyer]

On Tue, Jan 13, 2009 at 02:45:12PM +0100,
 Kevin Hinault  wrote 
 a message of 82 lines which said:

> L'intérêt de LDAP dans le cas de l'authentification est de ne pas
> les avoir dans le fichier /etc/passwd mais dans la base LDAP et la
> ligne que tu as mis plus haut est typiquement celle du fichier
> /etc/passwd donc tu dois avoir un problème quelque part

Non, pas du tout, il est tout à fait normal que 'getent passwd'
renvoie des lignes à la syntaxe /et/passwd. Le problème, comme indiqué
par Nicolas Dandrimont, est très probablement du côté de PAM.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Authentification LDAP

[Kevin C]

J'ai ajouté  ça dans /etc/pam.d/system-password

passwordsufficient  pam_ldap.so use_authtok md5
passwordrequiredpam_deny.so



Le mardi 13 janvier 2009 16:50:04 Nicolas Dandrimont, vous avez écrit :

> * Kevin COUSIN  [2009-01-13 15:07:54 +0100]:
> > J'ai fais la commande getent passwd : elle me renvoie toute les lignes du
> > fichier /etc/passwd ainsi que mon user de test
> >
> > ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
> >
> > j'ai mais exprès un UID assez haut pour mes users LDAP. je peux bien
> > m'authentifier avec ce user quand je suis root quand je fais su - ttest.
> > Le mot de passe stocké dans LDAP n'a pas l'air d'être pris en compte.
>
> Le fait que tu récupères cette ligne signifie que les utilisateurs sont
> bien récupérés dans la base ldap par nscd. J'en déduis donc que tu as
> mis en place nss-ldap ou libnss-ldapd avec succès.
>
> Pour que l'authentification LDAP soit possible, il faut configurer un
> plugin PAM pour identifier les utilisateurs sur la base LDAP. Le paquet
> libpam-ldap est-il installé et configuré ?
>
> A+,


-- 
-
Kévin C
www.tuxalafenetre.net

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Authentification LDAP

[Nicolas Dandrimont]

* Kevin COUSIN  [2009-01-13 15:07:54 +0100]:

> 
> J'ai fais la commande getent passwd : elle me renvoie toute les lignes du 
> fichier /etc/passwd ainsi que mon user de test
> 
> ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
> 
> j'ai mais exprès un UID assez haut pour mes users LDAP. je peux bien 
> m'authentifier avec ce user quand je suis root quand je fais su - ttest. Le 
> mot 
> de passe stocké dans LDAP n'a pas l'air d'être pris en compte.
> 

Le fait que tu récupères cette ligne signifie que les utilisateurs sont
bien récupérés dans la base ldap par nscd. J'en déduis donc que tu as
mis en place nss-ldap ou libnss-ldapd avec succès. 

Pour que l'authentification LDAP soit possible, il faut configurer un
plugin PAM pour identifier les utilisateurs sur la base LDAP. Le paquet
libpam-ldap est-il installé et configuré ?

A+,
-- 
Nicolas Dandrimont

"Besides, I think [Slackware] sounds better than 'Microsoft,' don't you?"
(By Patrick Volkerding)


signature.asc
Description: Digital signature

Re: Authentification LDAP

[Kevin COUSIN]

Le mardi 13 janvier 2009 14:45:12 Kevin Hinault, vous avez écrit :
> 2009/1/13 Kevin COUSIN 
>
> > Bonjour à tous,
> >
> > Je cherche actuellement à faire de l'authentification LDAP sur ma
> > Debian
> > Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas
> > les mots de passe, le compte a l'air vérouillé :
> >
> > ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
> >
> > Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
> >
> > Merci d'avance pour vos lumières
> >
> > Kévin C
>
> Bonjour,
>
> L'intérêt de LDAP dans le cas de l'authentification est de ne pas les avoir
> dans le fichier /etc/passwd mais dans la base LDAP et la ligne que tu as
> mis plus haut est typiquement celle du fichier /etc/passwd donc tu dois
> avoir un problème quelque part dans ce que tu veux faire ou dans ce que tu
> expliques.
>
> Kévin H


J'ai fais la commande getent passwd : elle me renvoie toute les lignes du 
fichier /etc/passwd ainsi que mon user de test

ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:

j'ai mais exprès un UID assez haut pour mes users LDAP. je peux bien 
m'authentifier avec ce user quand je suis root quand je fais su - ttest. Le mot 
de passe stocké dans LDAP n'a pas l'air d'être pris en compte.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Authentification LDAP

[Kevin C]

Le mardi 13 janvier 2009 14:45:12 Kevin Hinault, vous avez écrit :
> 2009/1/13 Kevin COUSIN 
>
> > Bonjour à tous,
> >
> > Je cherche actuellement à faire de l'authentification LDAP sur ma
> > Debian
> > Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas
> > les mots de passe, le compte a l'air vérouillé :
> >
> > ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
> >
> > Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
> >
> > Merci d'avance pour vos lumières
> >
> > Kévin C
>
> Bonjour,
>
> L'intérêt de LDAP dans le cas de l'authentification est de ne pas les avoir
> dans le fichier /etc/passwd mais dans la base LDAP et la ligne que tu as
> mis plus haut est typiquement celle du fichier /etc/passwd donc tu dois
> avoir un problème quelque part dans ce que tu veux faire ou dans ce que tu
> expliques.
>
> Kévin H

-- 
-
Kévin C
www.tuxalafenetre.net

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Authentification LDAP

[Kevin Hinault]

2009/1/13 Kevin COUSIN 

> Bonjour à tous,
>
> Je cherche actuellement à faire de l'authentification LDAP sur ma
> Debian
> Lenny. Quand je fais getent passwd mes users aparaissent bien, mais pas les
> mots de passe, le compte a l'air vérouillé :
>
> ttest:*:5000:5000:test test:/srv/vusers/linuxmiroir.fr/ttest:
>
> Je ne peux évidement pas me logguer. Ais-je oublié quelque chose?
>
> Merci d'avance pour vos lumières
>
> Kévin C
>

Bonjour,

L'intérêt de LDAP dans le cas de l'authentification est de ne pas les avoir
dans le fichier /etc/passwd mais dans la base LDAP et la ligne que tu as mis
plus haut est typiquement celle du fichier /etc/passwd donc tu dois avoir un
problème quelque part dans ce que tu veux faire ou dans ce que tu expliques.

Kévin H

Re: authentification

[Jean-Yves F. Barbier]

Pascal Hambourg a écrit :

Salut,

Jean-Yves F. Barbier a écrit :


Est-ce qu'un chiffrage WPA avec une clé non triviale n'est pas
suffisant dans ce cas ?


Ben nan, je ne peux parce qu'en plus des micros, il-y-a aussi des DS qui
doivent pouvoir se connecter, et elles ne supportent aucun type de 
crypto.


Après analyse, je pense que la solution la moins contraignante serait une
authentification par adresse MAC.


C'est surtout la solution la moins contraignante pour les petits malins 
qui voudraient s'incruster, étant donné que sniffer et usurper une 
adresse MAC est trivial avec du matériel qui le permet.


non, pas vraiment (quoique le risque ne soit jamais inexistant):
il existe 2 scripts manuels (bridge_on||off) + un cron qui coupe @0200; et
la maison se trouve dans un petit lotissement de 12 maisons à l'écart, pas
d'autres wifi dans le voisinage.

en, fait c'est plus une exercice de style (et la manière d'apprendre qq
chose de nouveau plutôt qu'une sécurité réelle:)

et j'ai fais au plus vite parce que la première LAN-party est pour demain
soir.

il est tt à fait clair que je n'aurais jamais pris cette option s'il avait
habité la ville.

--
Shit Happens.


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et

"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: authentification

[Pascal Hambourg]

Salut,

Jean-Yves F. Barbier a écrit :


Est-ce qu'un chiffrage WPA avec une clé non triviale n'est pas
suffisant dans ce cas ?


Ben nan, je ne peux parce qu'en plus des micros, il-y-a aussi des DS qui
doivent pouvoir se connecter, et elles ne supportent aucun type de crypto.

Après analyse, je pense que la solution la moins contraignante serait une
authentification par adresse MAC.


C'est surtout la solution la moins contraignante pour les petits malins 
qui voudraient s'incruster, étant donné que sniffer et usurper une 
adresse MAC est trivial avec du matériel qui le permet.



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et

"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: authentification

[Jean-Yves F. Barbier]

Jean-Michel OLTRA a écrit :

Bonjour,


Le jeudi 21 février 2008, Jean-Yves F. Barbier a écrit...



Après analyse, je pense que la solution la moins contraignante serait une
authentification par adresse MAC.


J'utilise ebtables, pour mon bridge eth-ath
Il peut filtrer sur les adresses mac.


vi, je viens de découvrir, et ça a l'air particulièrement bien; mais 
malheureusement

je n'ai pas trop le temps de me pencher dessus; donc, pour l'instant, ça
reste en iptables


--
Hamburg was fantastic. Between the whores and the groupies our dicks
all just about dropped off.
-- John Lennon, on the Beatles' early career in Germany


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et

"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: authentification

[Jean-Michel OLTRA]

Bonjour,


Le jeudi 21 février 2008, Jean-Yves F. Barbier a écrit...


> Après analyse, je pense que la solution la moins contraignante serait une
> authentification par adresse MAC.

J'utilise ebtables, pour mon bridge eth-ath
Il peut filtrer sur les adresses mac.

-- 
jm

A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.spidboutic.fr



-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: authentification

[Jean-Yves F. Barbier]

Frédéric BOITEUX a écrit :

Le mer 20 fév 2008 23:31:35 CET, "Jean-Yves F. Barbier" <[EMAIL PROTECTED]>
a écrit :
...

Et je cherche une solution simple d'authentification (il-y-a déjà un
serveur DHCP avec ctrl des adresses MAC sur ce router), pour éviter les
squatters.


Est-ce qu'un chiffrage WPA avec une clé non triviale n'est pas
suffisant dans ce cas ?


Ben nan, je ne peux parce qu'en plus des micros, il-y-a aussi des DS qui
doivent pouvoir se connecter, et elles ne supportent aucun type de crypto.

Après analyse, je pense que la solution la moins contraignante serait une
authentification par adresse MAC.

--
"Well, it don't make the sun shine, but at least it don't deepen the shit."
-- Straiter Empy, in _Riddley_Walker_ by Russell Hoban


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench   
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et

"Reply-To:"

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: authentification

[Frédéric BOITEUX]

Le mer 20 fév 2008 23:31:35 CET, "Jean-Yves F. Barbier" <[EMAIL PROTECTED]>
a écrit :

> salut liste,
> 
> je viens de paramétrer un bridge wifi pour le routeur de mon fils
> comme suit:
> eth0 = WAN
> eth1 = LAN
> ath0 = WiFi
> br0 = eth1 + ath0
> 
> Et je cherche une solution simple d'authentification (il-y-a déjà un
> serveur DHCP avec ctrl des adresses MAC sur ce router), pour éviter les
> squatters.

Est-ce qu'un chiffrage WPA avec une clé non triviale n'est pas
suffisant dans ce cas ?

Fred.