Krunch a écrit 3860 commentaires

Ca dépend de la connexion internet...

Evidemment si ya des contacts avec l'extérieur, l'expérience est fausée :/

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ya un truc qui s'appelle Expect qui permet d'automatiser des interfaces normalement interactives (comme celle de passwd). Après un truc genre

for i in `cat servers.list` ; do rexec $i expect_passwd $newpass ; done

et le tour est joué.

Enfin je connais pas rexec et encore moins sa syntaxe mais je suppose que ça sert bien à exécuter une commande sur une machine distante.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Dans le même genre tu peux mettre ton serveur sur un Soekris et le planquer dans le boitier d'un autre PC. En bricolant un peu ya surement moyen de pomper sur la même alimentation que le PC "hôte" et d'utiliser sa connexion réseau en faisant un bridge ou à coup de wifi par exemple de manière à ne pas avoir de cables suspects "en trop".

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

En fait pour les passerelle, c'est assez mouvant. Pour le moment ça fait quelques heures que je n'ai plus accès à MSN et Yahoo! Messenger ne fonctionne plus depuis plusieurs jours/semaines/mois (de toute façon je l'utilise pas). Par contre ça fait bien longtemps que j'ai pas eu de problème avec ICQ et AIM. Mais bon tout ça dépend aussi du serveur je suppose (je n'administre pas le serveur Jabber que j'utilise).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

D'après NoFrag, c'est bien JC.
http://www.nofrag.com/news/aou2004/04/13059.html(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je ne pense pas qu'effectuer cette expérience avec une seule personne soit très représentatif de l'espèce humaine.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Qu'est-ce que tu veux dire par "innaccessible aux scripts" ? S'il est accessible aux humains il est accessibles aux scripts non ? En admettant que le partage de fichiers sans nmdb est possible, il faudra juste utiliser l'adresse IP (ou le nom DNS) à la place du nom NetBIOS pour accéder aux partage de la machine.

Je serais quand même intéressé de savoir si ça marche ou pas.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Tu peux essayer ça: http://www.testdrive.compaq.com/(...)
Sinon ya la ferme de compilation de SourceForge mais faut avoir un projet chez eux évidemment.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je connais pas grand chose à Samba mais si j'ai bien compris, il y a deux daemons: smbd et nmbd. Le premier s'occupe des partages de fichiers et le second de la résolution des noms NetBIOS. Donc je suppose qu'en arrètant nmbd, ton serveur va devenir "invisible".

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

oui

oui

je crois que c'est Gossip

Psi :)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je crois que par défaut il n'est pas sur OpenBSD non plus. J'ai l'impression que Bash est plutôt spécifique au projet GNU (même s'il est portable et porté un peu partout).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ya aussi des trucs utiles ici: http://unxutils.sourceforge.net/(...) (voir aussi les liens en bas de page). Pour Bash sous Windows, Google me donne ceci: http://www.steve.org.uk/Software/bash/(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ca me fait beaucoup penser à une traduction automatique, notamment le "Restez loin des outils d'attaques ou illégal".

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Pas besoin d'ajouter des utilisateurs. Tu as juste à ajouter une ligne avec login:mdp dans le fichier qui va bien. Si tu veux gérer le fichier par une interface web, Pear est ton ami. C'est pas plus compliqué que de s'amuser à écrire un système d'authentification potentiellement foireux.

http://pear.php.net/package/File_Passwd/docs/0.9.2a/File_Passwd/Fil(...)

Par ailleurs maintenant que tu as dit comment tu trouvais tes mdp, il est bcp plus facile (moins difficile en tout cas) de les cracker :op

Pour éviter d'avoir plusieurs fois le même script qui tourne en parrallèle, on utilise des verrous: tu bloques un verrou au début du script et tu le libéres à la fin. Après tu vérifies si le verrou est bloqué, si c'est le cas le script est en train de tourner. En pratique tu peux utiliser flock() ou une entrée dans une base de données (MySQL sur un P133 avec 48Mo de RAM c'est pas top cependant). Le truc à _ne_ _pas_ faire est d'utiliser un bête fichier genre

while (file_exists($lock)) sleep(0.1);
create_file($lock);
/* do stuff */
delete_file($lock);

Parce que tu n'est pas certains que le fichier n'aura pas été verrouillé par un autre process entre la fin du while et le début du create_file(). Enfin dans 99% des cas sur une machine mono processeur ça ne devrait pas poser de problème mais de toute façon il vaut mieux utiliser flock() qui est fait pour ça (mais c'est pas super portable). Dans ton cas tu peux écrire la date (temps epoch) de la dernière tentative d'authentification dans une db ou un fichier (mais dans ce cas tu dois quand même utiliser flock()) et vérifier que le délais est respecté.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

J'ai eu exactement le même problème il y a deux jours en installant Sarge (mais sur i386): concernant X j'ai juste installé les packages x-window-system-core, xdm et ion2 et AltGr agissait exactement comme Alt donc pas de |@#¼½^[{}\]`·~ (clavier belge).

apt-get install xlibs && /etc/init.d/xdm restart

Ca marche. Ca doit avoir un rapport avec XKB mais j'ai pas cherché plus loin.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je crois que tu peux limiter le nombre de requètes en // dans la configuration d'Apache (RTFM) mais ça risque d'être assez embétant pour les visiteurs. C'est pas parce que c'est un P133 qu'il ne peut pas répondre à plusieurs requètes en même temps. Si tu mets un mdp suffisament "compliqué" (un mdp long mais "facile" à deviner c'est pas mieux qu'un mdp de 4 caractères aléatoires), c'est l'url qui va être plus facile à deviner. Le problème c'est qu'au mieux ton système de mdp ne sert à rien et au pire ça permet de cracker plus facilement.

Si le but c'est juste de faire croire que c'est sécurisé au premier neuneu venu alors je sais pas pourquoi tu as demandé de l'aide ici.

Je comprends pas pourquoi tu veux pas utiliser les htaccess.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Oui apparement current c'est la version "snapshot" (j'avais pas fait attention à la version que tu utilisais). Si c'est pas encore fait, essai la beta 4. Peut-être que le bug n'existait pas dans cette version et qu'il a été introduit plus tard.

Par ailleurs ya un passage sur les disque SATA dans la FAQ de l'installateur.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Juste avant de booter sur le CD, appuie sur F1/F2/... pour avoir les options de boot disponibles. Parmis celle-là il y en a peut-être une qui voudra bien fonctionner avec ton HD. Vérifie aussi que le CD que tu as gravé n'est pas corrompu (ya le md5 dans le même répertoire que l'iso normalement). Si ça marche toujours pas, essai la dernière snapshot de netinst et si ça marche toujours pas, fait quand même un bug report en décrivant au mieux ton problème.

J'ai installé une Sarge il y a encore 2 jours sans problème (mais j'ai jamais essayé le 2.6 non plus en fait).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Pq j'ai mis des guillemets à "fournis" moi.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

C'est juste, j'avais pas pensé à ça. Merci.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

J'utilise uniquement Jabber et les transports. Pour autant que je sache, il n'existe pas encore de moyen de transférer des fichiers avec les clients MSN/ICQ/... en utilisant les transports donc voilà. L'avantage c'est que je peux utiliser une seule connexion SSL pour me connecter à toutes mes adresses d'IM. Vu que je passe la moitié de mon temps sur un réseau non switché où tout le monde peut sniffer ce qu'il veut, je trouve ça assez pratique (bon ça serait switché ça serait presque pareil).

Sinon pour le transfert de fichiers sans FTP/MSN/... -> http://linuxfr.org/tips/296.html(...)

Pour en revenir à cette histoire de mdp, si tu as gardé le même fonctionnement, pas besoin d'utiliser de mdp. Le seul "secret" à connaitre est l'url. Pour protéger les répertoires, le htaccess est probablement la meilleure solution. Je pense que ça le fait même récursivement.

Le délais de 3 secondes empéche rien: qqun peut brute-forcer tranquillement avec X connexions en paralléle, il aura juste les résultat de chacune 3 secondes plus tard mais rien ne l'empèche de refaire une requète avant que le délais se soit écoulé. Et en fait il a même pas besoin de faire ça, il a juste à "brute-forcer" l'url.

Un truc plus "sécurisé" serait de faire une page PHP qui prend 2 paramètres: le mdp et le fichier à accéder. Si le mdp est correct mais que le fichier à accéder n'existe pas, tu "fournis" un listing des fichiers. Si le mdp est correct et le fichier existe, tu renvois directement le fichier. De cette manière tu peux interdire complétement l'accés aux fichiers directement via Apache: on ne peut y accéder que par l'interface web. Mais il faut faire très attention aux fichiers accessibles (gaffe aux trucs genre .. et liens symboliques). Idéalement tu devrais avoir le listing des fichiers accessibles défini explicitement dans un fichier de configuration par exemple.

Ce genre de script existe déjà, suffit de chercher un peu. Enfin pour le mdp je suis pas sur mais ça tu peux le rajouter au niveau d'Apache et comme ça tu n'as qu'une seule page à protéger.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Si j'ai bien compris, tu veux vérifier le mdp et rediriger la personne vers une page à l'url "impossible à deviner" s'il est correct. C'est pas la bonne manière de faire. Si tu penses vraiment que ton url peut rester "secret", autant donner l'url comme mdp, pas besoin de te casser la tête avec PHP et ça sera pas moins sécurisé. Ca le sera même plus si la "difficulté" du mdp est moindre que celle de l'url. Si elle l'est plus, c'est le mdp qui sert à rien.

Maintenant si tu veux un "vrai" accés par mdp, tu vas devoir soit tout mettre dans la même page PHP protégée par elle même (affichage de la page uniquement si le mdp est correct, pas moyen de contourner comme c'est le cas dans ton exemple), soit utiliser les sessions et les cookies pour protéger les autres pages (accès que si le cookie est bon et le cookie ne peut être mis que par la page de login, ou un truc comme ça, j'ai jamais touché à ça), soit utiliser une protection au niveau d'Apache comme suggéré plus haut, qui va te permettre de protéger tout le répertoire du même coup.

A mon avis, la solution la plus facile/rapide à mettre en place est celle des htaccess. C'est pas plus compliqué que ta solution, ça l'est même moins: t'as pas à faire de PHP, t'as juste à maintenir un fichiers d'utilisateurs/mdp. Si tu veux tu peux t'amuser à faire une interface PHP pour gérer le fichier. Si tu veux vraiment pas avoir à taper un login mais juste un mdp, alors amuse toi avec les sessions/cookies ou intégre tout dans la même page si c'est possible.

Pour le problème du brute-force. Avec le système actuel, le méchant n'a qu'à brute-forcer un URL ou un mdp, le plus faible des deux. Avec le htaccess, il doit brute-forcer un login+mdp (en admettant que le login reste "secret" aussi). De toute façon toute application de ce genre est "brute-forçable". Si tu penses que ça en vaut la peine, tu as plusieurs solutions pour limiter les risques. Le plus simple est probablement de bien choisir le mdp, après tu peux t'arranger pour qu'on ne puisse pas faire plus de X tentatives de login par heure (mais pas avec des cookies, du JS ou autre truc "client-side", dans ce cas ça sert à rien et ça fait chier les visiteurs) ou commencer à chercher un système d'authentification plus correct (à coups de PGP/SSL/TLS/... par exemples) mais ça devient tout de suite plus lourd. Yavait un article sur l'authentification par mdp dans le Linux Magazine France du mois dernier je pense (si qqun avec le magazine sous la main peut confirmer...). Ca peut peut-être t'intéresser.

Personnellement, j'ai un serveur FTP avec un compte "invité" qui me sert de temps en temps ("hé pq je peux pas t'envoyer de fichiers par MSN?"). Le mdp change aléatoirement toutes les X heures et il est enregistré dans un fichier auquel moi seul ai accés. Avec ça, bonne chance pour le brute-force. Faut voir si ça peut être applicable à ton cas. Dans le même genre, voir http://slashdot.org/comments.pl?sid=111503&cid=9469343(...)
Le mdp est généré par exemple par un md5 de la somme de l'heure actuelle et du "vrai" mdp (une truc plus correct serait genre md5(md5(time).md5(passwd)), le "." pour la concaténation). Comme ça, toute personne qui a le "vrai" mdp peut reconstituer le mdp actuel mais il change toutes les X heures/minutes. Tu peux aussi t'arranger pour que le mdp change après que qqun se soit loggué, comme ça si la connexion est sniffée, l'attaquant ne sait quand même pas obtenir le mdp puisqu'il a déjà changé (mais bon dans ce cas tu as d'autres problèmes).

Par ailleurs je recommande la lecture de cet article-ci à tous ceux qui débutent dans les applications web (et ça peut surement pas faire de mal à ceux qui en font déjà depuis un moment): http://www.linux-mag.com/2002-09/security_01.html(...)

Pour le coup des md5, vaut mieux comprendre ce qu'on fait avant de l'implémenter. Voir par exemple dans le même magazine: http://www.linux-mag.com/2002-09/cryptography_01.html(...)

-- Krunch le parano

PS: désolé pour les anglicismes et fautes d'orthographes/grammaire mais il est 3h30 passé là

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ba la tour Montparnasse Infernale entre potes en fin de soirée après une cuite ça passe encore. Mais c'est vrai qu'à jeun c'est assez lourd (même apès 12h de LAN).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et moi j'ai un voisin dont la voiture est immatriculée aptXXX (avec XXX qui remplace des chiffres).

Quelle vie trépidante nous avons nous les debianeux/euses/istes/ien/iennes.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et Woody il pue ? Il y a une raison particulière pour vouloir utiliser Sarge ? C'est pour faire tourner quoi plus précisement ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.