Journal Compromission de code source.

Posté par .
Tags : aucun
11
3
août
2009
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.
  • # duplication ?

    Posté par . Évalué à 7.

    Une fois les paquets signés, il faut les dupliquer sur plusieurs miroirs. La probabilité de pouvoir modifier plusieurs miroir est très faible.

    "La première sécurité est la liberté"

    • [^] # Re: duplication ?

      Posté par . Évalué à 4.

      çà peut venir en 6)

      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 ...
  • # Logiciel propriétaire

    Posté par (page perso) . Évalué à 4.

    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.


    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

  • # Journal intéressant

    Posté par (page perso) . Évalué à 9.

    Merci pour les réflexions. C’est vraiment, une fois de plus, la preuve que la sécurité, c’est un processus qui ne se termine jamais, et pas une liste de petites recettes à appliquer sans plus se poser de questions par la suite.
    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 . Évalué à 3.

      En l'occurrence sur SF, un attaquant pourrait tester le compte de tous les contributeurs et les comparer à une base de données "login/mot de passe" récoltée.

      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.
  • # Personnellement ...

    Posté par (page perso) . Évalué à 3.

    Moi je me pose moins de question vu que les applications créés dans ma boite ne le sont pas fait par des stagières.

    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 . Évalué à 1.

      stagières
      La correction orthographique n'est donc pas disponible dans ton navigateur?
  • # Mots de passe? 400Go??

    Posté par . Évalué à 0.

    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.

    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 . Évalué à 1.

      Tu n'as pas compris mon propos. Je ne parle pas de faire une base de tous les logins/mots de passes possibles mais de tous les mots de passes utilisés.

      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 . Évalué à 2.

        tous les mots de passes utilisés.

        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 (page perso) . Évalué à 2.

      Je pense que tu n'a pas du bien comprendre ce qu'il disait.

      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 . Évalué à 4.

      Euh... ton coup de 62^10 c'est pour connaitre tous les mots de passes de 10 caractères possibles et il parlait de tous les mots de passes utilisés.
      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 (page perso) . Évalué à 4.

    Sans vouloir te rabaisser, tu développes une appli qui est au 5000è rang de SF, avec environ 1 téléchargement par jour, ça n'interresse aucun pirate.

    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 . Évalué à 4.

      Je ne suis pas vexé.

      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 . Évalué à 3.

        Bon hors contributeurs externes

        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 . Évalué à 10.

    Ne pas donner aux stagiaires un accès à SF mais à ton cvs/svn/git/équivalent local, puis faire toi même la propagation du code sur SF.

    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 . Évalué à 2.

      çà serait une bonne pratique effectivement.

      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 . Évalué à 2.

        ça n'est pas incompatible : tu peux les citer dans les sources et sur la page du projet sur SF, qu'ils n'aient pas un accès direct au projet hébergé sur SF est aisément compréhensible, et ça leur apporterait la reconnaissance que leur travail peut leur apporter.
        • [^] # Re: Une solution dans ton cas

          Posté par . Évalué à 1.

          C'est une manière aussi de les encourager à faire de l'Open Source.

          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 . Évalué à 3.

            C'est une manière aussi de les encourager à faire de l'Open Source.

            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 (page perso) . Évalué à 2.

      À chaque fois qu'on donne un accès critique à un stagiaire, Dieu tue un chaton, le ressuscite et le re-tue.
      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 . Évalué à 3.

        sauf pour les choses dont il est responsable

        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 (page perso) . Évalué à 3.

    Ca me laisse toujours perplexe quand je vois que l'on peut faire autant d'essais que l'on veut avec un couple user/password sans se faire jeter.

    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(...)

    If you choose open source because you don't have to pay, but depend on it anyway, you're part of the problem.evloper) February 17, 2014

    • [^] # Re: délai entre les essais ?

      Posté par . Évalué à 1.

      tout à fait!
      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 . Évalué à 4.

        Il n'y a à ma connaissance pas de mécanisme "incrémental" tel que tu l'entends, mais fail2ban est un bon compromis : simple à mettre en oeuvre et efficace.
      • [^] # Re: délai entre les essais ?

        Posté par . Évalué à 5.

        Regarde http://www.zeroflux.org/projects/knock
        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 . Évalué à 3.

        Ça serait bien que, lorsque tu es ban, tu doive entrer un mot de passe pour supprimer ce ban ( différent de celui de l'user). La probabilité de le trouver par bruteforce est très faible, et après il a ton vrai mot de passe à trouver.
      • [^] # Re: délai entre les essais ?

        Posté par (page perso) . Évalué à 1.

        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.

        À 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 (page perso) . Évalué à 1.

    Savane, utilisé par GNA! et Savannah de GNU permet de signer et modérer les commits, et aussi de gérer assez finement les droits des contributeurs.

    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.