Salut,
Depuis quelques temps, je gère un projet libre sur SF.
http://sourceforge.net/projects/planningrh/
Je le développe et le fait développer par mes stagiaires.
Étant paranoïaque de nature, je me pose pas mal de question.
Suite au journal sur la "SquirrelMail compromis...one more time !" de patrick_g (http://linuxfr.org/~patrick_g/28619.html), je souhaitais réagir et vous faire de part de mes réflexions sur ce sujet.
Avec un simple Login et mot de passe, on peut tout faire sur SF:
- publier du code
- publier des fichiers
- administrer le site ...
Je ne parlerais pas de la longueur du mot de passe qui peut être critique et qui est souvent présenté comme le point le plus important à tord. Le plus grand risque qu'offre une protection basée sur un login/mot de passe est que celui-ci se retrouve dans une base de données connu d'un potentiel attaquant.
Ce potentiel attaquant a plusieurs moyen pour collecter ce type d'information:
- vole via un KeyLogger.
- récolte par un site malveillant ou compromis.
Je me rappelle d'un article où leur d'une perquisition la police a trouvé une machine zombi hébergeant des centaines de millier de login/mot de passe. Il est plus rapide de tester une base de couple login/mot de passe que d'utiliser la force brut.
D'ailleurs, une base de tous les login/mot de passes est "informatiquement" envisageable: 4 milliard d'humain, 1 à 10 mot passe par humain , chacun faisant 1 à 10 caractères. Dans le meilleurs des cas, 4 milliard * 10 * 10 = 400 milliard d'octet soit une base de 400 Go.
Personnellement, j'ai un mot de passe qui est propre à SF. J'utilise ce compte uniquement à partir d'une machine que j'estime comme seine.
Mais je peux difficilement garantir cette bonne pratique chez mes stagiaires.
Je peux difficilement garantir que le compte de mes stagiaires n'a jamais été utilisé dans un contexte qui pourrait compromettre leurs login/mot de passe.
Dernier point, je viens de découvrir que SF adhère à OpenID. Mes contributeurs pourraient avoir un compte identique sur Yahoo! , AOL, MySpace, ...
Le seul moyen qu'il me reste pour garantir que mon code est non compromis, Il faut dans l'ordre d'importance:
1) M'assurer que la machine pour coder est seine.
2) Changer régulièrement de mot de passe.
3) Réaliser une audit régulière du code , en priorité celui modifié.
4) Signer les paquets que je publie.
5) Exécutez le programme sur une machine seine et m'assurer que celle-ci ne présente pas de signe de compromission à l'exécution
Actuellement, je ne réponds qu'aux trois premiers critères.
En conclusion , SF offre une grande facilité pour le développement et la publication de logiciel libre mais il pose un réel problème de sécurité.
Enfin pour ceux qui pourrait penser que cette problématique n'existe pas dans le monde du logiciel propriétaire.
Certes le problème de ce Login/Mot de passe n'est pas aussi important mais on perd la garantit fondamentale de pouvoir auditer le code ou d'espérer qu'un tiers compétent la fait.
Dans l'ensemble tous les éditeurs que je côtoie ou que j'ai côtoyé dans mon métier d'admins d'une clinique, aucun ne semble respecter les bonnes pratiques qui permettent de garantir que les machines servant au développement reste seine.
- Les dev sont quasiment toujours admins de leurs machines avec pleins de programme plus ou moins utile d'installé.
- Quand on voit les librairies tiers qui sont intégrés à certains logiciels , il y a de quoi se poser des questions.
Au moins avec les logiciels libres, on peut contrôler.
Journal Compromission de code source.
3
août
2009
# duplication ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
"La première sécurité est la liberté"
[^] # Re: duplication ?
Posté par syj . Évalué à 4.
Mais c'est plutôt le "source" qui m'inquiète.
Par exemple, je pourrais dans mon projet avoir un .java ou .jar de corrompu. Que je republierais à chaque version.
D'ailleurs, un .jar serait très difficile à détecter. Je peux plus facilement prouver que l'ensemble de mes .java sont bon alors qu'un jar d'Apache Commons ...
[^] # Re: duplication ?
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à -1.
pas d'accent grave à « ça » ! On retrouve aussi « içi » çà et là..
(pour ceux que cela embête, désolé pour le bruit)
# Logiciel propriétaire
Posté par claudex . Évalué à 4.
Certes le problème de ce Login/Mot de passe n'est pas aussi important mais on perd la garantit fondamentale de pouvoir auditer le code ou d'espérer qu'un tiers compétent la fait.
Et ça ne garanti pas du tout, comme dans le cas de Squirrel¹, que le binaire sur le site n'est pas corrompu.
¹: sauf que c'est du php et qu'il n'y a donc pas de binaire mais c'est le même problème.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Logiciel propriétaire
Posté par eastwind☯ . Évalué à 4.
[^] # Re: Logiciel propriétaire
Posté par syj . Évalué à 2.
Tu peux t'en convaincre avec le lien ci-dessous:
http://www.google.fr//extern_js/f/CgJmchICZnIrMAo4GywrMA44BS(...)
[^] # Re: Logiciel propriétaire
Posté par eastwind☯ . Évalué à 2.
Laisser un stagiaire pondre un code pareil , ce serait trop incorrect non ?
Ce serait pas plus simple pour les autres languages script de faire comme le python; obliger les indentations dans le code pour garder sa lisibilité / propreté ? (c'est pas un troll )
[^] # Re: Logiciel propriétaire
Posté par Alex . Évalué à 3.
Les devs eux ne travaillent pas sur ce genre de source
Une bonne obfuscation devrait supporter une "réindentation" du code (le js en exemple me semble être "reformatable")
[^] # Re: Logiciel propriétaire
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Logiciel propriétaire
Posté par 2PetitsVerres . Évalué à 2.
Par exemple :
return{
ok : false
};
et
return {ok : false
};
ne font pas la même chose.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Logiciel propriétaire
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: Logiciel propriétaire
Posté par 2PetitsVerres . Évalué à 3.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Logiciel propriétaire
Posté par Octabrain . Évalué à 2.
Comparer http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.j(...) et http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.js
# Journal intéressant
Posté par Zorro (site web personnel) . Évalué à 9.
J’ajouterai qu’il faut aussi s’interroger sur la proportion entre les mesures à prendre et la chose à défendre, et savoir aussi s’interroger rationnellement, sans paranoïa, sur la gravité des attaques, des gens qui entourent, de la probabilité de l’attaque, etc… Je sais que seuls les paranoïaques survivront, mais ceux qui sont plus cools pourront aussi survivre, à mon avis.
Sinon, on écrit « sain, saine ».
[^] # Re: Journal intéressant
Posté par syj . Évalué à 3.
Je serais étonné qu'il ne trouve pas un ou deux comptes offrants des opportunités intéressantes.
# Les petits ruisseaux font les grandes rivières.
Posté par ß ß . Évalué à 10.
« pour garantir que mon code est non compromis, Il faut [...] Exécutez le programme sur une machine seine »Ça coule de source.
[^] # Re: Les petits ruisseaux font les grandes rivières.
Posté par syj . Évalué à 2.
[^] # Re: Les petits ruisseaux font les grandes rivières.
Posté par djibb (site web personnel) . Évalué à 0.
[^] # Re: Les petits ruisseaux font les grandes rivières.
Posté par Octabrain . Évalué à 4.
[^] # Re: Les petits ruisseaux font les grandes rivières.
Posté par Anonyme . Évalué à 3.
seine -> saine
un peu comme santé c'est avec un A pas un E
(je signale le probleme, et ne donne pas de leçon)
[^] # Re: Les petits ruisseaux font les grandes rivières.
Posté par B16F4RV4RD1N . Évalué à 6.
l'orthographe sur ce site va à vau-l'eau ;)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Les petits ruisseaux font les grandes rivières.
Posté par syj . Évalué à 1.
Je ne le prends pas mal car je suis conscient que c'est un de mes plus gros défaut.
D'ailleurs, je dépense mes jours de DIF en cours d'orthographe et rédaction pour le corriger :).
[^] # Re: Les petits ruisseaux font les grandes rivières.
Posté par Anonyme . Évalué à 2.
je vais demander un DIF à mon employeur, je me demandais si une vulgaire lettre avec le nom de la formation suffisait ? ou il faut etre plus precis ?
dans la mesure du possible pourrais tu poster ta lettre, grosso modo. Et pour ta contribution on te pardonnera tes fautes :D
# Personnellement ...
Posté par Mr Kapouik (site web personnel) . Évalué à 3.
Oui bon il peut arriver aussi qu'un stagière passe dans le coin et donne un coup de main ou qu'un nouvelle employé non encore formé aux méthodes de développement propre passe dans le coin et alors j'ai une bonne méthode qui s'appuie sur un tuteur qui forme la personne correctement avant de le laisser en semi liberté avec un audit de sécurité régulier.
Et oui faire confiance aux gens avec qui ont bosse et contrôler régulièrement la sécurité des méthodes de développement ainsi que le code me parait relativement naturel au sein d'une entreprise plutôt que d'avoir une armée de stagière lâchée dans la nature dont on se méfie.
[^] # Re: Personnellement ...
Posté par godzom . Évalué à 1.
La correction orthographique n'est donc pas disponible dans ton navigateur?
# Mots de passe? 400Go??
Posté par octane . Évalué à 0.
Heu..
4 milliards d'humain qui ont plusieurs comptes, donc plusieurs logins. (je devrais compter le nombre de login que j'utilise, mais à première vue je dirais plus de 20 facile).
Ensuite:
10 mots de passes de 10 caractères ==> 10x10 = 100 ???? WTF
Si tu as 10 caractères dans un mot de passe, tu as un choix (bas) de 62 caractères par caractères (26 lettres min, 26 lettres maj, 10 chiffres et je ne compte pas les caractères spéciaux..) donc c'est 62^10 possibilités...
Si je recompte, on obtient donc, rien que pour les mots de passe: 745 Petta Octets de données....
Ensuite, tu indiques que les mots de passe sont stockés sur le site de sourceforge. J'espère que ce n'est pas le cas. Normalement, les mots de passe sont hachés. Lorsque tu donnes ton mot de passe, il est haché à son tour et les hashs sont comparés. (Regarde le contenu de ton /etc/shadow par exemple, les mots de passe ne sont pas présents. De plus, pour éviter les attaques par précalcul des hash, les mots de passes sont souvent 'salés' puis hachés. Le sel est contenu entre les $ du mot de passe. Le mot de passe est toujours: $sel$hash si tu regardes bien).
Ceci dit, pleins de sites conservent les mots de passe en clair, mais c'est MAL.
Et pour finir, ton point 5)
5) Exécutez le programme sur une machine seine et m'assurer que celle-ci ne présente pas de signe de compromission à l'exécution
C'est sans doute le plus dur... Imagine un attaquant qui introduit un subtil buffer overflow dans ton code. Une exécution du code ne le trouvera pas. N'oublie pas, comme disais un grand chercheur en sécurité:
un programme fiable, c'est un programme qui fait ce qu'on lui demande. Un programme secure, c'est un programme qui ne fait que ce qui lui est demandé
[^] # Re: Mots de passe? 400Go??
Posté par syj . Évalué à 1.
L'attaquant a juste besoin de consulter sa base avec le login recherchait et de tester tous les mots de passes qu'il a pu récolté pour ce login. Bref , beaucoup plus rapide qu'un brut force ^^.
Pour le reste ,je suis entièrement d'accord avec toi.
J'ajouterai juste que pour éviter le buffer overflow , je programme en Java. Toutefois, il faut encore que le système soit à jour , ainsi que la jvm et le SGBDR.
Enfin, l'attaquant pourrait quand même supprimer une protection contre l'injection de code SQL ou l'injection de cross site scripting.
[^] # Re: Mots de passe? 400Go??
Posté par octane . Évalué à 2.
Je ne comprends pas plus ton calcul 10 x10..
Ceci dit:
L'attaquant a juste besoin de consulter sa base avec le login recherchait et de tester tous les mots de passes qu'il a pu récolté pour ce login. Bref , beaucoup plus rapide qu'un brut force ^^.
Oui, et ça se fait beaucoup. Trouver un bon fichier de mots de passe c'est difficile. Et les pirates partagent peu ce genre de fichiers. Ils permettent de casser à une vitesse impressionnante énormément de mots de passe.
Il est difficile de casser un mot de passe précis, mais lorsque tu tombes sur un site communautaire, tu as de grandes chances de casser très vite la majorité des mots de passes à l'aide de ce type de fichiers.
Il n'y a pas longtemps, le site phpBB s'était fait pirater. Et un gars s'était amusé à faire des stats sur les mots de passe utilisés.
C'est là
http://pentester.fr/blog/index.php?post/2009/02/09/Audit-des(...)
et c'est super instructif.
[^] # Re: Mots de passe? 400Go??
Posté par yellowiscool . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: Mots de passe? 400Go??
Posté par beagf (site web personnel) . Évalué à 2.
4 milliards d'humain qui ont plusieurs comptes, donc plusieurs logins. (je devrais compter le nombre de login que j'utilise, mais à première vue je dirais plus de 20 facile).
Beaucoup d'informaticiens on bien plus de 10 mots de passe, mais madame michu n'en a en general qu'un seul. J'ai compris que protéger un site avec un mot de passe ne servait à rien après une discution avec des amis sur le sujet où j'ai apris qu'ils utilisaient tous un seul mot de passe quel que soit le site.
Donc en moyenne je pense même que 10 mot de passe par personne soit surestimè.
10 mots de passes de 10 caractères ==> 10x10 = 100 ???? WTF
Si tu as 10 caractères dans un mot de passe, tu as un choix (bas) de 62 caractères par caractères (26 lettres min, 26 lettres maj, 10 chiffres et je ne compte pas les caractères spéciaux..) donc c'est 62^10 possibilités...
Si je recompte, on obtient donc, rien que pour les mots de passe: 745 Petta Octets de données....
Non, sont calcul est juste, si tu doit stocker 10 mot de passe de 10 caracteres, tu as besoin de 10 emplacement de 10 octets, donc 100 octets.
Il parle de stocker le mots de passe utilisés par les gens, pas l'ensemble des mots de passe possibles.
Ensuite, tu indiques que les mots de passe sont stockés sur le site de sourceforge. J'espère que ce n'est pas le cas. Normalement, les mots de passe sont hachés. Lorsque tu donnes ton mot de passe, il est haché à son tour et les hashs sont comparés. (Regarde le contenu de ton /etc/shadow par exemple, les mots de passe ne sont pas présents. De plus, pour éviter les attaques par précalcul des hash, les mots de passes sont souvent 'salés' puis hachés. Le sel est contenu entre les $ du mot de passe. Le mot de passe est toujours: $sel$hash si tu regardes bien).
Ceci dit, pleins de sites conservent les mots de passe en clair, mais c'est MAL.
Il parle ici de créer une base de donnèe de mots de passe pour des attaque, pas de celle de sf. Pour faire cette base de donnée tu crer de faux sites aléchants ou l'utilisateur doit s'enregistrer, ou bien tu pirate un site du genre sf et tu modifie le code pour qu'il t'envoie les couples login/password.
Donc le site peut conserver ces mots de passes comme il veut, toi tu te constitu ta base d'une maniere ou d'une autre et ensuite tu essaye tous les couple que tu as en base. la probabilitee qu'un d'entre eux marche est loin d'être négligeable.
[^] # Re: Mots de passe? 400Go??
Posté par campagnard . Évalué à 4.
De plus, si toi tu parle en terme de mots de passe possibles, alors dans ce cas on se CONTREFOUT du nombre de mot-de-passe par personne (on a déja compté tous les mots de passe possible, on va pas remultiplier par le nombre de mot de passe par personne !)
Bref, tu donnes l'impression de t'emmeler les pinceaux.
# Adapter la sécurité à la criticité
Posté par Zenitram (site web personnel) . Évalué à 4.
Une mauvaise sécurité est de mettre trop de sécurité perçue comme gavante par les utilisateurs.
Dans ton exemple, une personne ayant ton login/password ne pourra pas faire de mal à beaucoup de monde, il ne s'y intéressera donc pas. Reste alors les scripts, qu'on bloque avec un minimum de sécurité chez soi.
En conclusion , SF offre une grande facilité pour le développement et la publication de logiciel libre mais il pose un réel problème de sécurité.
SF pose un réel problème de sécurité? vraiment? tout est en SSL (du web à l'upload des fichiers en passant par le SVN), reste alors ta machine. Si elle est compromise, quoique fasse SF tu perdras (ben oui, si ta machine est compromise ta clé SSH serait elle aussi compromise en mémorisant ta passphrase)
Reste à utiliser des codes uniques, mais on revient au problème initial : trop de sécurité tue la sécurité (déja que pour ma banque ça me gave et donc que je tue leur sécurité en stockant leur codes uniques à des endroits "pas biens"... Alors pour "juste" SF!)
SF a beaucoup de défauts (put**** de mises à jour ces temps-ci, qui cassent une tonne de choses), mais je ne pense pas mettre la sécurité dans ses défauts.
Reste de ton côté à maitriser ta sécurité, tout en ayant en tête de ne pas en faire trop au risque que tes utilisateurs contourne la chose : a chaque niveau de sécurité sa politique de sécurité, et j'ai l'impression que tu veux être plus sécurisé que les développeurs de Azureus à 300 000 downloads par jour.
[^] # Re: Adapter la sécurité à la criticité
Posté par syj . Évalué à 4.
Le fait de réfléchir sur la sécurité de mon projet (qui n'est pas un modèle de sécurité).
Cela m'oblige à douter de la sécurité des autres projets hébergés.
[^] # Re: Adapter la sécurité à la criticité
Posté par Alex . Évalué à 3.
Pour toi et tes stagiaires, tu peux également monter un serveur openid interne à l'entreprise qui ne servirait qu'à l'authentification sf, tu pourrais même rajouter une authentification par certificat pour éviter les mauvais mots de passes.
# Une solution dans ton cas
Posté par jeffcom . Évalué à 10.
Donner un accès critique à un stagiaire c'est mal.
À chaque fois qu'on donne un accès critique à un stagiaire, Dieu tue un chaton, le ressuscite et le re-tue.
[^] # Re: Une solution dans ton cas
Posté par syj . Évalué à 2.
Je ne le fais pas pour pouvoir mettre en valeur leur travail.
çà fait bien sur un cv de dire qu'on bosse sur un projet libre et d'être référencé sur le net pour autres choses que son MySpace ou son commentaire sur Allo Ciné.
[^] # Re: Une solution dans ton cas
Posté par jeffcom . Évalué à 2.
[^] # Re: Une solution dans ton cas
Posté par syj . Évalué à 1.
Et si ils sont motivés , ils peuvent continuer à m'aider de cette manière. Même
si j'ai peu d'espoir :)
En plus, le fait que çà identifie leur travail personnel. çà oblige à être plus rigoureux si ils veulent pouvoir en bénéficier plus tard.
Même si çà me fait un courir un risque. Je le prends en ayant conscience et puis si je veux bloquer leur compte sur ce projet, il me suffit de décocher une case.
[^] # Re: Une solution dans ton cas
Posté par jeffcom . Évalué à 3.
Apprendre à mettre en place et gérer un cvs/svn/git/autre en local aussi, ça encourage à faire de l'OS
En plus, le fait que çà identifie leur travail personnel.
Je pense qu'il serait encore plus profitable de noter le nom de ces gens dans la liste des contributeurs, de placer leur nom en en-tête des fichiers auxquels ils ont contribué, voire placer leurs références en regard des fonctions dont ils sont les auteurs.
ça aussi ça encourage pas mal à faire de l'OS
Même si çà me fait un courir un risque. Je le prends en ayant conscience et puis si je veux bloquer leur compte sur ce projet, il me suffit de décocher une case.
Ok, mais ton journal parle de manières d'éviter la compromission des sources, et agir comme tu le fais est un gros risque. Je me doute que tu ne le fais pas avec n'importe qui (j'espère du moins), mais dans le cas "lambda" : il vaut mieux compartimenter car ça n'est pas moins formateur, au contraire (en entreprise, en général on utilise assez peu SF mais de plus en plus d'autres systèmes comme Trac et le gestionnaire de sources qui l'accompagne), et ça garantit une certaine sécurité au code.
[^] # Re: Une solution dans ton cas
Posté par Kerro . Évalué à 2.
Ah oui tout de même ! C'est donc plus grave que la branl que certaines pratiques.
Je préciserais en disant que l'accès critique doit être donné aux personnes responsables de l'accès. Donc rarement à un stagiaire (sauf pour les choses dont il est responsable, sinon c'est un stagiaire qui s'ennuie), et rarement à tous les programmeurs d'un projet. Souvent il n'y a qu'une ou deux personnes qui ont l'accès. Avec le double des clef au coffre, mais ça reste la théorie bien souvent :-)
[^] # Re: Une solution dans ton cas
Posté par jeffcom . Évalué à 3.
Oui, le rendre responsable d'une portion de code ou d'une branche (s'il en a les compétences) sur un gestionnaire de source local, oui, bien sûr, c'est très formateur ! et en cas de soucis, aucun soucis : c'est en local, c'est lui, ça n'impactera pas l'image de l'entreprise, ni le travail des collaborateurs. Si le repo SF est compromis ou balance du code moisi alors qu'il est l'unique repo, là c'est autre chose.
sinon c'est un stagiaire qui s'ennuie
Un stagiaire qui s'ennuie en stage, pour moi c'est un branleur. Toute formation, aussi poussée soit elle, n'apporte qu'une partie des connaissances et savoir-faire qu'il est souhaitable de posséder pour être un professionnel compétent et responsable. Les stages sont souvent la seule occasion de toucher d'aborder certaines notions et pratiques professionnelles, donc, normalement, un stagiaire ne doit pas avoir le temps de s'ennuyer, ne serait-ce parce qu'il lui reste, par définition, pas mal à apprendre.
Note :
pour devancer les remarques, non, il n'est pas difficile d'être en stage avec moi.
Le stagiaire qui se comporte de manière responsable (en faisant en sorte de protéger les autres des conséquences de ses faux pas, qui sont normaux, inévitables et formateurs, par exemple) et qui montre un minimum d'intérêt pour son travail aura droit à toute mon attention et ma bienveillance.
Le stagiaire incompétent et fier de l'être et/ou qui se prend pour un gourou parce qu'il est dans "la meilleure école européenne" (elle disent toutes qu'elles le sont) et qui, à ce titre, se permet de bourder à tours de bras sans prendre la peine de comprendre ses erreurs et en contaminant et perturbant le travail des autres, mettant par la même en danger leur emploi, lui, n'aura droit qu'à mon plus profond mépris, au fruit de mon imagination sans limites concernant les sévices physiques et a une appréciation des plus nuisible comme j'en ai le secret.
# délai entre les essais ?
Posté par palm123 (site web personnel) . Évalué à 3.
Il n'y a pas de mécanisme de ce genre sous SF
http://www.sysworks.com.au/disk$cddoc03jul11/decw$book/d32va(...)
ou
http://forums11.itrc.hp.com/service/forums/questionanswer.do(...)
ウィズコロナ
[^] # Re: délai entre les essais ?
Posté par ewasx . Évalué à 1.
Mon serveur perso, enfin c'est un portable PIII 500 mhz avec 128Mo de RAm mais bon... c'est un serveur, bien que n'ayant pas de nom de domaine officiel associé est régulièrement, enfin constamment, attaqué avec du brute force sur le port 22.
Y'a plusieurs solutions j'imagine comme:
a) ne pas mettre de serveur ssh mais ca on oublie car tout l'interet de mon serveur c'est de me fournir un linux car comme ca j'ai acces à tous mes petits scripts chéris de partout, quelque soit l'OS que j'utilise (boulot tout ca...)
b) changer le port ssh pour quelque chose de plus exotique. J'y ai pensé mais ca ne ferait que réduire le problème, pas le résoudre, mais je devrais le faire j'imagine.
c) utiliser denyhosts
d) utiliser un truc encore plus meilleur mieux que denyhosts.
denyhosts ne marche pas nickel chez moi. Je ne suis pas un expert et comme disait l'autre plus haut il faut savoir adapter sa sécurité a la valeur des données qui sont stockées sur le serveur en question mais on n'est jamais a l'abris des idiots qu'y n'en ont rien à foutre de la valeur et veulent juste tester leur script et de toutes facons ca ne leur coute rien. que ca prenne un jour ou 1 mois c'est rien, ca tourne en tache de fond hein...
Perso j'aimerai un denyhosts en plus incrémental, genre:
premier mot de passe faux: pas de delais, ca arrive à nous tous de faire une faute de frappe hein
2eme erreur, x secondes de delais.
3eme erreur, x secondes encore
4eme erreur, x minutes
4eme erreur, ban d'une heure pour ce login
xeme erreur ban de l'IP pour X heures. une IP pouvant etre partagée par plusieurs individus il me semble sage de faire gaffe avant de la bloquer. la betise d'un membre ne devrait pas affecter l'ensemble des membres d'une communauté donnée autant que possible.
denyhosts resoud le probleme du brute force pour le ssh mais ca serait sympa d'avoir ce mechanisme pour tous les services.
[^] # Re: délai entre les essais ?
Posté par ekyo . Évalué à 4.
[^] # Re: délai entre les essais ?
Posté par Sphax . Évalué à 5.
Je l'ai mis en place pour voir sur mon serveur, et je n'ai plus aucune attaque.
Par contre il faut penser à bien envoyer la séquence pour refermer le port sinon on a vite fait de se retrouver avec 36 règles iptables identiques.
[^] # Re: délai entre les essais ?
Posté par Sébastien B. . Évalué à 3.
[^] # Re: délai entre les essais ?
Posté par jcs (site web personnel) . Évalué à 1.
À l'époque où j'avais un serveur chez moi j'avais remplacé le port 22 par 7022 et du jour au lendemain je n'avais pour ainsi dire plus aucune attaque. Il en avait bien une de temps en temps mais ça restait suffisamment rare pour être visible et pas noyé au milieu des tentatives de moult botnets et autres script kiddies.
# Utilisez savane!
Posté par Brioche4012 (site web personnel) . Évalué à 1.
Porter son projet vers une autre forge n'est pas forcément pratique ni simple, mais si sourceforge (que je ne connais pas) n'est pas sur, alors cela peut etre une bonne solution.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.