Obsidian a écrit 5291 commentaires

#TLS_CACERT /etc/openldap/cacerts/ldap.crt
#TLS_CERT /etc/openldap/cacerts/ldap.crt
#TLS_KEY /etc/openldap/cacerts/ldap.key

S'il y a des # devant tes lignes, c'est qu'elles sont commentées.

Sinon, essaie d'appeler ldapsearch avec -Z au lieu de -ZZ (qui force la validation).

Par contre, je maintiens que le mieux que tu aies à faire est de refaire des certificats au propre.

Essaie sudo startx ou sudo init 5.

À noter également que ldapsearch lit sa config dans /etc/openldap/ldap.conf

Il y existe TLS_REQCERT pour contourner ce contrôle, mais le mieux reste encore de générer un certificat valide.

C'est ce que je pensais (et j'ai buté dessus aussi) : le certificat envoyé par serveur n'est pas reconnu. Avec quoi, l'as-tu généré ? As-tu bien fourni la clé avec ?

Olalah ! GROSSE ERREUR de ma part ! Le port 177, c'est le Xdmcp ! Rien à voir, donc (c'était mon problème précédent en fait).

Bon, alors en gros :

- Commenter host et garder uri dans /etc/ldap.conf ;
- Utiliser ldap:// et pas ldaps:// dans cet URI (et ne pas oublier le deux-points, non plus) ;
- Ne pas préciser le numéro de port dans l'URI ;
- Passer en mode TLS par le port par défaut (389, donc) avec ssl start_tls;
- tlscacertfile pour préciser le nom de fichier de la CA qui a signé le certificat de ton serveur, pour que le client puisse l'authentifier. Peut-être pas nécessaire si tls_checkpeer no.

Ensuite, côté serveur, donc dans slapd.conf

- il te faut au moins un certificat côté serveur, fût-il autosigné (mais moi j'ai pris le temps de créer une CA puis de créer un certificat propre à LDAP).

TLSCertificateFile /etc/pki/tls/certs/ldap.pem
TLSCertificateKeyFile /etc/pki/tls/private/ldap.key

sans oublier de redémarrer :

# /etc/init.d/ldap restart

Ça devrait suffire à faire démarrer le TLS.
Puis :

ldapsearch -x -H ldap://srvtest3.test.org -ZZ '*'

Pour voir si tu peux établir une connexion en TLS avec ton serveur.

Après, c'est la configuration de PAM et NSS.
Bon courage.

Si tu lances vi dans un script, celui-ci va rester en attente jusqu'à ce que tu refermes vi de toi-même puis passer à la suite.

Si tu veux simuler une entrée clavier, tu peux utiliser <<END mon texte END sous bash.

Si tu veux simplement faire un script qui écrit quelque chose dans un fichier, tu utilises echo ou cat.

Que cherches-tu à faire, exactement ?

venant étayé ce chiffre, de coups cachés.

Ouch ! C'est vrai qu'on s'en prend plein la tronche, là ...

Ok, après en avoir sué, l'authentification utilisateur via LDAP-TLS fonctionne chez moi, tcpdump à l'appui pour comparer les flux.

Il faut d'abord configurer proprement /etc/ldap.conf et /etc/openldap/ldap.conf, puis veiller a ce que les clients aient accès au certificat de l'autorité racine qui à signé celui du serveur (si pas auto-signé), faire attention au format (.PEM,.CRT,...) et surtout se méfier de host et uri, mutuellement exclusifs. Enfin, il faut se souvenir que le TLS écoute le port 177 par défaut (le SSL Netscape utilisait le 636).

Le piège, c'est que si on spécifie uri ldaps://ldap.serveur.org, le mot-clé est associé au port 636, qui n'est pas ouvert si on fonctionne en start_tls. Moralité, les modules nss_ldap et pam_ldap ne peuvent pas se connecter, alors qu'un ldapsearch -h ldap.serveur.org -ZZ, lui, y arrive très bien parce qu'on ne précise que le nom d'hôte sans le protocole, et que l'on négocie ensuite le TLS manuellement, avec l'option idoine.

Beaucoup de temps perdu, mais ça servira bien.

Depuis le serveur, ce n'est peut-être pas une bonne idée, puisqu'il peut ouvrir des sockets UNIX plutôt qu'UDP (ils appellent çà le LDAP over IPC :-).

Essaie d'ajouter l'option -Z à ta commande, pour forcer le TLS, puis -ZZ pour l'obliger à s'arrêter en cas d'échec de l'authentification. Cette étape fonctionne désormais chez moi, mais nsswitch, lui, continue d'échouer sur un timeout.

Au fait, ça fait quoi si tu commentes host et que dans uri, tu remplaces ldap:// par ldaps:// ?

J'utilise une Fedora 9, donc ce doit être relativement proche. Il faut distinguer d'un côté les vrais fichiers de conf' et de l'autre les GNOMEries qui permettent de les manipuler. Par exemple : Système->Administration->Authentification.

Oui.

Quelle distribution utilises-tu au fait ?

mais je me trompe peut-être

Oui, enfin en partie.

La man page stipule que l'une des grandes particuliarités du passage de SSL à TLS est l'utilisation (par défaut) du même port de communication.

À vue de nez, j'ai l'impression que NSS gère déjà le LDAP alors que ton serveur n'est pas encore lancé, et ça affecte toutes tes applications ... y compris le serveur LDAP lui-même.

D'autre part, le TLS_CACERT en majuscule est une directive de /etc/openldap/ldap.conf et pas /etc/ldap.conf (une saloperie, ce truc). Ceci dit, on utilise les mêmes directives dans l'autre aussi, mais en minuscules. Je ne sais pas si le parser fait la distinction ou pas.

Enfin, essaie déjà de désactiver LDAP dans le NSS puis lancer une recherche avec ldapsearch -h tonserveurldap -LLL -x -ZZ dn pour voir si le TLS fonctionne bien du côté d'OpenLDAP et de ses outils.

Moi, j'en suis à cette étape aussi. OpenLDAP ok, NSS échoue.

Pas grave, moi aussi, je devrais être couché !

Bananuit à tous.

Non ? 16 fois le budget pub de Windows 95 ? Nan, pas possible.

Ça me rappelle la fois où un pirate s'est mis à scanner mon port 22, aussi. À cette époque, j'avais sous WindowMaker une dockapp très réactive qui reproduisait l'activité de ma carte réseau. La p'tite LED verte qui se mettait à clignoter frénétiquement n'était pas discrète :-) Un petit coup de tcpdump pour lever les doutes, ensuite ...

Pas eu besoin de gueuler beaucoup. Un p'tit ssh en retour vers sa machine a fait tout de suite comprendre au gars que je l'avais repéré et que je savais ce qu'il faisait.

Maintenant, il y a une Freebox en routeur devant, c'est moins drôle :-)

C'est bien ce que je dis au début de mon post.

Par contre, d'une manière générale, la « réinstall » n'est pas une solution. D'abord, parce que ça maintient l'utilisateur dans l'ignorance, qui reste donc vulnérable au moindre pépin, ensuite par qu'après le temps de la réinstallation, vient celui de la reconfiguration.

Compromis pour compromis, je trouve que c'est un très bon exercice que d'essayer de nettoyer son système en conditions réelles, même si c'est avant de tout casser. Sebzonelibre a réussi à détecter l'attaque et à en identifier toutes les conséquences, et je l'en félicite.

Dans ce cas précis, oui, mais il faut savoir faire les deux, à mon avis. Connaître chattr, spécialement en cas de menace (qu'elle soit délibérée ou non), c'est quand même d'utilité publique.

On ne gère pas un Unix comme un Windows. Ce n'est pas un système jetable.

Addendum :

J'ajoute que si tu en es là, et que l'opération à faire sur les paquets est fort simple, largue le C++ et code directement en C. Tu économiseras beaucoup de ressources.

N'oubliez pas qu'au final, tous ces threads vont tourner sur la même machine et engendrer beaucoup d'overhead système ! Le multi-processus, c'est bien quand on fait du SMP. Pour le reste, ce n'est certainement pas une manière d'accélérer le travail en le distribuant, sauf en cas d'appel bloquant.

Étant donné que les machines récentes sont toutes hyper-threadées, je ferais exactement deux processus, qui partagent un buffer circulaire (le fameux graveur de CD). L'une en charge du disque, qui peut se permettre de l'attendre, et l'autre qui remplit le tampon.

Par contre, je pense quand même que la charge sera moins lourde si un seul processus lit tous les ports. Il y a un seul noyau et surtout, c'est la même carte réseau derrière pour tout le monde.

L'effort fourni !

C'est drôle comme les gens ont du mal avec les participes passés en « i ». C'est probablement dû au fait que les trois verbes en« ir » les plus fréquents sont en fait en « ire » et, par conséquent, du troisième groupe, pas du second : lire, dire, écrire (et je ne parle pas de «&nsbp;suffire&nsbp;», ce serait trop compliqué :-).

Je le dis parce que certaines personnes sont même allées jusqu'à révoquer mes modifs Wikipédia pour restaurer les fautes. Pourtant, ce n'est pas bien dur de faire la différence :

Au féminin, dit-on « fournie » ou « fournise » ?

Ce sont surtout les mots « clientèle captive » qui me font marrer. Pour du logiciel libre, c'est quand même un comble.

Par contre, vis-à-vis de prestations et maintenance, il est de fait que c'est ce sur quoi se rabattent la plupart des compagnies qui distribuent du logiciel libre si elles veulent faire un minimum d'argent.

M'enfin bon. Ça sent l'argumentaire commandé par la hiérarchie. Pondre quelque chose qui ait l'air de tenir à peu près debout en première lecture, et qui défende les intérêts de quelque chose en quoi on ne croit absolument pas, c'est toujours un exercice délicat.

Tout dépend de ta charge réseau. À priori, un bête fopen de débutant doit suffire à tout faire puisque les fichiers ainsi ouverts sont dotés d'un tampon, vidés à intervalles définis par le système, et qui peuvent être flushés sur commande avec sync.

Après, si tu reçois des milliers de paquets à la seconde, tu peux peut-être envisager autre chose.

Le contrôleur DMA relève du système d'exploitation, et est fortement lié à la gestion interne du filesystem, etc. Bref, c'est beaucoup plus que d'écrire un pilote, ce qui n'est déjà pas trivial. Si tu utilises de l'IDE, utilises hdparm pour voir si tes disques l'utilisent par défaut.

Ensuite, tu peux faire du raw device. Avant, ça se fait en associant un /dev/raw/rawX à ton périphérique. Maintenant, c'est en passant l'option O_DIRECT à open().

Par contre, d'après ce que je lis, il semblerait que ce qu'il te faille, c'est du file mapping. Vois du coté de $ man mmap. C'est un appel système, donc en C, aisément encastrable dans du code en C++.

Bon courage.