Aller au contenu

Securite Systeme et Réseau


-rem-

Messages recommandés

  • 3 semaines après...
  • Réponses 97
  • Créé
  • Dernière réponse

:D c'est encore moi :transpi:

theocrite vient de jeter le doute dans mon esprit en ce qui concerne les mots de passe :D

J'ai un password de 12 caractères pour root. Mais il semble que pour Debian (woody) les caractères > à 8 ne sont pas pris en compte.

Je trouve ça un peu mesquin :incline:

C'est pareil sur ma FC2 ou ça dépends des distribs ?

Lien vers le commentaire
Partager sur d’autres sites

mon mdp root fait 14 caracteres avec md5 + shadow passwd...

Et si debian, qui est la distribution sécurisée par excellence ne prennait pas plus de 8 caracteres, ca serait comique ! Sacrés newbies va...ca fait un truc pas correctement, et apres ca en tire une généralité. Mais bon, c'est bien, on aurait pu conclure sur le noyau linux et non l adistribution debian en particulier, ca aurait pu etre pire !

:transpi: pour le jugement hatif.

Lien vers le commentaire
Partager sur d’autres sites

Sacrés newbies va...ca fait un truc pas correctement, et apres ca en tire une généralité.
:transpi: pour le jugement hatif.
:incline: Il n'est pas question de jugement hatif.
Mais il semble que pour Debian

Dans ce cas pourquoi 90% des sites qui parlent de passwd ou pwgen disent soit d'utiliser au moins 8 caractères, soit au plus 8 caractères ?

Il y a toujours de huit qui revient...

Pour changer de password:

Choisissez un mot de passe de 8 caractères (ou moins mais pas plus), avec au moins un caractère numérique, un caractère spécial, et mélange de Majuscules et minuscules, pas de @ ni de #

Il doit avoir au plus 8 caractères de long

:D

Lien vers le commentaire
Partager sur d’autres sites

eh bien je t'assure que si tu ne tappes pas les 14 caracteres correctement sur ma machine, tu ne te loggue pas, ca m'est deja arrivé une paire de fois...

imagines a combien ca reduit les différentes combinaison de passwd !

EDT : La fonctionnaliité shadow password apporte une taille double pour les mots de passe, soit 16 caracteres. En fait, tu as du refuser l'option shadow password proposée par debian, alors que Fedora a du l'installer par defaut.

Lien vers le commentaire
Partager sur d’autres sites

Bien évidement je ne remets pas ta parole en doute Rem. Mais pourquoi ce chiffre 8 qu'on retrouve partout ? C'est stupide non ?

Et le mec qui m'a dit qu'à partir de huit caractères l'encodage est ineficace, est loin d'être mauvais en sécurité et en prog (si je ne me trompe pas de mec). Il a compilé DES en première année quand nous on était encore à faire du chiffrement Cesar/vigenère/permuatiton etc.

Il me semble qu'il y a un rapport avec la longeur de la clé

N'est ce pas possible (simple suposition) qu'à partir de huit caractères, il y ai des redondances dans les mots de passes stoqués (EDIT : l'algo ne serais plus injectif ??? :roll: En y réfléchissant, j'en doute fort.)

Lien vers le commentaire
Partager sur d’autres sites

Si tu ne prends pas la fonctionnalité shadow passaword, la taille max est apparement 8 caracteres, c'est vrai que ca revient souvent, je me souviens qu'on avait ca aussi a la fac sur des red hat 5.2, mais ca remonte... :eeek2:

Je pense que le mec qui t'a dit ca ne connait pas bien shadow password, ou alors il t'a dit cela avant que shadow password ne soit plus connu.

Toutefois, fester, félicitations pour la recherche et le post sur le topic :roll: , ce que j'ai critiqué c'est la mise en cause de debian alors que le probleme vient d'ailleurs en général. N'oublions pas ce point commun entre toutes les distribs, le noyau Linux.

EDT : Théocrite, si ca t'intéresse :

http://www.freenix.fr/unix/linux/HOWTO/Sha...rd-HOWTO-2.html

et le how-to en général :

http://www.freenix.fr/unix/linux/HOWTO/Sha...word-HOWTO.html

Lien vers le commentaire
Partager sur d’autres sites

En y repensant; ce n'etait pas forcément si evident que ca, et c'est vrai que beaucoup sont encore fixé sur le chiffre 8, et que leur distrib sont installées de maniere a limiter cela a 8. dommage.

donc, je dirais bonne question fester, elle meriterait de figurer dans 100% question pour un pinguoin.

Lien vers le commentaire
Partager sur d’autres sites

Rem : Merci pour le lien. Toutes les docs m'interressent tant que ça a un rapport avec linux et que je ne connais pas le sujet par coeur.

J'ai trouvé une explication : http://vanhu.free.fr/linux/securiserlinux/....html#PASSWDENC

Donc la limitation à 8 caractères serait dûe à DES (comme quoi je ne dis pas que des bètises (pas que :ouioui: )). Activer MD5 (do you want to use MD5 password ? à l'install) permet 16 caractères.

Je ne vois pas l'intéret de ne pas l'activer. Question de puissance peut être ?

fester : 26 lettres + 26 lettres + 10 chiffres + 40 (en gros caractères) spéciaux =102 caractères & 8 caractères/password => 102^8 = 11716593810022656 combinaisons. C'est difficilement bruteforçable. Si quelqu'un doit rentrer, ça se fera plus probablement sans connaissance du mot de passe (et je doute que quelqu'un rentre).

Les autres machines ne sont pas atteignables en ssh direct.

Le problème de certaines personnes, c'est quant leur mappage de clavier est pourri, ils ne peuvent pas mettre de caractère spéciaux dans leurs mots de passe sinon ils ne peuvent pas se loguer en console.

Lien vers le commentaire
Partager sur d’autres sites

mon mdp root fait 14 caracteres avec md5 + shadow passwd...

Et si debian, qui est la distribution sécurisée par excellence ne prennait pas plus de 8 caracteres, ca serait comique ! Sacrés newbies va...ca fait un truc pas correctement, et apres ca en tire une généralité. Mais bon, c'est bien, on aurait pu conclure sur le noyau linux et non l adistribution debian en particulier, ca aurait pu etre pire !

:transpi: pour le jugement hatif.

La plus sécurisé ? Ah bon, je savais que c'était une des plus stables, mais pas la plus sécurisé :ouioui:

Lien vers le commentaire
Partager sur d’autres sites

Cette histoire de longueur max à 8, c'est par compatibilité avec des vieilles versions des autres unix, qui utilisent pas les shadow passwords, et dont les mots de passe sont donc dans /etc/passwd encryptés avec la fonction crypt(). Et cette fonction, basée sur DES, ne gère pas plus de 8 caractères.

Mais pour des distributions linux récentes (y compris Debian :arrow: ), c'est réglé depuis un bail.

Lien vers le commentaire
Partager sur d’autres sites

oui, mais apparement, ce que je ne savais pas avant de rechercher plus de détails sur google, c'est qu'avec shadow password on est limité a seulement 16 caracteres. Je trouve ca un peu juste quand meme, quand on connait les limites d'autres systemes d'authentification sécurisé.

Lien vers le commentaire
Partager sur d’autres sites

On est tous d'accord pour dire que FTP a des tares congénitales graves, mais faut avouer que par rapport au tout jeune SFTP, il a des fonctionnalités très intéressantes, notamment le chroot.

J'ai bien cherché comment vérouiller un utilisateur dans son répertoire personnel, et globalement il y a deux solutions :

  • Faire un vrai chroot, c'est à dire installer une sous-distrib dans sa distrib, c'est assez lourd mais très efficace et sécurisé.
  • Utiliser scponly (http://www.sublimation.org/scponly). C'est une sorte de shell qui n'accepte que les commandes scp et sftp, à mettre pour l'utilisateur à chrooter. Le problème, c'est que pour éviter que l'utlisateur escape des commandes à l'intérieur des siennes (genre "scp rien nullepart: ; cat /etc/passwd"), il interdit tous les caractères qui pourraient être gênants. Comment faire si le nom du fichier contient un de ces caractères alors ? On est obligé d'utiliser des jokers du shell, comme ? et *.... C'est pas top.

Voilà, le transfert de fichiers sécurisé est donc encore un problème si on ne fait pas confiance aux clients (cas d'un hébergeur par exemple).

Si quelqu'un a une solution miracle, je suis intéressé :)

EDIT: Peut-être WebDAV ? Quelqu'un connaît bien ?

Lien vers le commentaire
Partager sur d’autres sites

Bon les users en /bin/false ne peuvent pas utiliser scp

peut-être jouer avec pam ?

en tout cas question très intéressante, je vais creuser de mon côté.

S'ils transfèrent toujours le même fichier, par contre, y'a surement moyen de locker ça (on le fait au taf, quand root tente de se ssh sur une autre machine, ça remplit une fonction et te délogge) : si ton user est dans un répertoire, qu'il se ssh sur la machine cible, ça balance un scp -r et fini ...

du style, dans le fichier .ssh/authorized_keys2

command="/usr/bin/scp -r . serveur:/var/www/... " ssh-rsa la-clé-publique-du-serveur-cible 

évidemment c'est très restrictif ... et faut blinder (fichier en 644 owné par root chez le user ::fume:)

edit ->

ou ftp tunnélé dans ssh

ou ftps (ftp over ssl)

Lien vers le commentaire
Partager sur d’autres sites

Gauret, je n'ai pas très bien compris la question, mais pour ce qui est d'enfermer les utilisateurs dans un répertoire, ça fonctionne.

On a un serveur web en prod (Debian+apache+php+mysql+mod_dav) qui permet de donner à chaque utilisateur un accès à un répertoire /www/login/ et pas un autre (ni /www/, ni /www/login_du_voisin/).

Tous les utilisateurs se loguent via apache (www-data) et tout passe par le port 80 (c'est bien pour les firewalls).

Pour les malchanceux qui sont contrains d'utiliser l'OS du côté sombre, le protocole webdav est implanté nativement dans gruyère explorer (AVEC de GROS BUGS GRRRRR ! Une joie à administrer) et sous linux on peut utiliser un client ligne de commande (:fume: beaucoup plus performant, un truc d'adultes quoi) est disponible.

lorinc : bien vu. Moi aussi j'attends ça avec impatience :incline:

Mais que Rem et Sandeman prennent le temps de vivre quand même.

Rem, tu fais quoi après ?

Lien vers le commentaire
Partager sur d’autres sites

évidemment c'est très restrictif ... et faut blinder

ou ftp tunnélé dans ssh

ou ftps (ftp over ssl)

Ouaip, je cherche une solution plus générale. Mon cas : je voudrais faire un serveur de fichiers avec des potes à moi, qui doivent donc pouvoir télécharger tout ce que je leur propose, quoi.

ftp tunellé dans ssh ce serait cool, mais il faudrait un serveur amélioré par rapport au serveur sftp fourni avec openssh. Ce serveur devrait pouvoir vérifier que le client demande rien qui est au dessus de son répertoire perso, et refuser sinon.

Tiens, je viens d'y penser, il y a peut-être moyen avec rsync et un truc du genre "rsync --include /home/user/", puisque quand on utilise la couche ssh avec rsync, il spawne un serveur à distance et s'y connecte dans le tunnel. On pourrait alors forcer le serveur avec l'option command de la clef ssh... A tester.

FTP/SSL, c'est pas pratiquable, à cause des firewalls et du changement de ports de FTP (mais qui a pondu cette connerie).

Lien vers le commentaire
Partager sur d’autres sites

Je regarde si je peux trouver un poste d'ingénieur, expert en systeme/réseau linux de préférence. Je vais voir aussi si j'ai un peu plus de temps pour devenir éventuellement, mais ce n'est pas encore fait développeur debian.

Concernant ton probleme théo, tu sais que tu peux spécifier aux utilisateurs d' utiliser uniquement rbash comme shell, et sans avoir le droit de le changer :

NAME

      rbash - restricted bash, see bash(1)

RESTRICTED SHELL

      If  bash  is started with the name rbash, or the -r option is supplied at invocation, the shell becomes

      restricted.  A restricted shell is used to set up an environment  more  controlled  than  the  standard

      shell.  It behaves identically to bash with the exception that the following are disallowed or not per-

      formed:

      o      changing directories with cd

      o      setting or unsetting the values of SHELL, PATH, ENV, or BASH_ENV

      o      specifying command names containing /

      o      specifying a file name containing a / as an argument to the .  builtin command

      o      Specifying a filename containing a slash as an argument to the -p option  to  the  hash  builtin

              command

      o      importing function definitions from the shell environment at startup

      o      parsing the value of SHELLOPTS from the shell environment at startup

      o      redirecting output using the >, >|, <>, >&, &>, and >> redirection operators

      o      using the exec builtin command to replace the shell with another command

      o      adding or deleting builtin commands with the -f and -d options to the enable builtin command

      o      Using the enable builtin command to enable disabled shell builtins

      o      specifying the -p option to the command builtin command

      o      turning off restricted mode with set +r or set +o restricted.

      These restrictions are enforced after any startup files are read.

      When  a command that is found to be a shell script is executed, rbash turns off any restrictions in the

      shell spawned to execute the script.

Lien vers le commentaire
Partager sur d’autres sites

On a un serveur web en prod (Debian+apache+php+mysql+mod_dav) qui permet de donner à chaque utilisateur un accès à un répertoire /www/login/ et pas un autre (ni /www/, ni /www/login_du_voisin/).

Tous les utilisateurs se loguent via apache (www-data)

Ah ! Intéressant WebDAV donc. Et est-ce que l'utilisateur peut se retrouver loggué avec son compte plutôt que celui d'apache ?

et tout passe par le port 80 (c'est bien pour les firewalls).

Oui, alors ça je suis contre. Si on a fait des ports dans le protocole TCP, c'est pas pour les chiens. Avec WebDAV et XML-RPC qui se multiplient, le port 80 va devenir une vraie poubelle, et le firewall servira plus à rien. On peut pas filtrer sur les ports si tout passe par le même.

Pour les malchanceux qui sont contrains d'utiliser l'OS du côté sombre, le protocole webdav est implanté nativement dans gruyère explorer (AVEC de GROS BUGS GRRRRR ! Une joie à administrer)

Comment ça se fait que je ne sois pas surpris... :craint:

et sous linux on peut utiliser un client ligne de commande (:incline: beaucoup plus performant, un truc d'adultes quoi) est disponible.

Ouaip, cadaver. Mais WebDAV est implémenté dans de plus en plus de trucs graphiques et de clients ligne de commande évolués (cadaver c'est un peu le ftp BSD, ça fait pas le poids par rapport à un lftp :) )

Rem, tu fais quoi après ?

Ah oui tiens, bonne question. Et vous êtes arrivé à quoi finalement sur jabber2 ?

EDIT: OK. rbash j'ai essayé mais c'est encore trop permissif, on peut faire un "cat /etc/passwd" sans problème.

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.


×
×
  • Créer...