Journal une petite attaque

• # Machine infectée

  Posté par Sébastien Koechlin le 03 juin 2005 à 17:30. Évalué à 7.

  

  C'est rien, c'est normal, tous les serveurs ssh ont cela
  
  - Ca passe par une machine infectée, il est difficile de remonter à la source, le FAI ne peut pas grand chose.
  - Les logins sont toujours les mêmes, si root n'a pas le droit de se connecter et si ton user ne s'appelle pas adm, user, web, data ou quelques autres nom de programme, ça ne teste même pas la sécurité de ton mot de passe (qui n'est pas attaquable au dictionnaire de toute façon parce que tu l'as convenablement choisi).
  - Ca ne diminue pas la sécurité de sshd

  • [^] # Re: Machine infectée

    Posté par chtitux (site web personnel) le 03 juin 2005 à 18:57. Évalué à 5.

    

    Je suis surpris qu'on puisse échouer à tant de logins ...
    Sshd ne bloque pas l'IP après un nombre x d'essais qui ont échoués ?
    
    C'est la porte ouvert à des attauqes par dictionnaires sinon ...
    Mais j'espère me tromper, si il ne le fait pas par deefaut, une option doit bien exister ...

    • [^] # Re: Machine infectée

      Posté par adibou le 03 juin 2005 à 21:46. Évalué à 4.

      

      si sshd peut le faire ou non ne change rien au fait qu'on peut limiter le nb de requetes a n par minutes : dans le cas d'un serveur sur un pc pour peu d'utilisateur, qq chose comme 3/min suffit largement, et une attaque par dico risque d'etre bien longue...

    • [^] # Re: Machine infectée

      Posté par Raoul Volfoni (site web personnel) le 03 juin 2005 à 23:45. Évalué à 10.

      

      > Sshd ne bloque pas l'IP après un nombre x d'essais qui ont échoués ?
      
      Et comme ça avec une IP spoofée tu peux te chopper un magnifique DOS. Si l'attaquant sait quelle est ton IP, tu ne pourras même plus te connecter à ton serveur! AMHA c'est une stratégie dangeureuse si implémentée sans précaution.
      
      Il y a plusieurs solutions pour résoudre le petit désagrément des vilains bots:
      
      - changer le port d'écoute de sshd (les bots pour ssh n'attaquent que le 22 la +part du temps)
      - n'autoriser que les connections avec des clés valides (authorized_keys) depuis des machines connues (known_hosts)
      - utiliser des mots de passes jetables (skey ou OPIE) très utile quand on se connecte depuis une machine que l'on ne connait pas (évidemment incompatible avec le known_hosts)
      - désactiver la connection par mot de passe: PasswordAuthentication no
      - comme indiqué + bas, utiliser Portknocking: http://www.portknocking.org/(...)
      - enfin en dernier recours faire un script pour iptables qui bloque l'IP pendant un temps bien déterminé de façon à éviter le DOS. Mais je ne suis pas trop pour. :(
      
      Sinon quelques conseils de bon sens:
      - avoir évidemment des mots de passe à toute épreuve (y compris celle des Rainbow Tables C.f. http://passcracking.com/(...) Donc au minimum 20 caractères avec tous ceux que l'on utilise habituellement que pour les jurons. ;)
      - éventuellement bloquer la connection à root sauf si on utilise des mots de passe jetables pour administrer la machine depuis une autre machine sans confiance. Auquel cas un su ou sudo mettrait toute la sécurité par terre si la machine est infectée par un logger.
      - s'il s'agit d'une machine passerelle et que l'on a pas besoin de s'y connecter depuis un des réseaux, ne mettre sshd qu'en écoute sur l'autre adresse.
      - vérifier les options de son sshd_config et surtout MaxAuthTries, PermitEmptyPasswords, UsePAM (dans ce cas voir aussi la config de PAM) et ne pas oublier de bloquer SSH1: Protocol 2
      - et enfin si on est vraiment parano, utiliser Kerberos.
      
      Finalement mettre un message d'interdiction des connections non authorisées dans /etc/ssh/banner. Les bots s'en foutent, mais si quelqu'un réussit à percer toutes les barrières précédentes, il ne pourra pas prétendre qu'il n'a pas vu l'interdiction d'entrer (pour le forensic).

• # Bot

  Posté par DjinnS le 03 juin 2005 à 17:31. Évalué à 8.

  

  C'est en général des bots/prog/virus/vers ou tout ces saloperies qui soit sont lancées volontairement par des personnes n'ayant pas beaucoup de connaissances ... soit par des PCs infectés.
  
  Je pense pas que t'es trop de bille à te faire. Un petit RootLogin No dans ssh et surtout un AllowGroups et AllowUsers bien placé te mettra à l'abrit de ce genre de choses ... tout en ayant un password digne de ce nom, évidement.
  
  Ca na ne te protegera par contre les failles de SSH mais c'est un bon début !

• # Bof

  Posté par seeschloss le 03 juin 2005 à 17:35. Évalué à 4.

  

  C'est juste des trucs automatiques, moi aussi j'ai ça assez souvent...
  
  Le dernier : Jun 3 00:07:17 [sshd] Failed password for invalid user jacob from 209.232.191.98 port 45005 ssh2)
  Mais qui peut avoir un login qui s'appelle "jacob" ?!
  
  Hier, 202.29.52.250 a aussi essayé toutes les lettres individuellement, plus eee, qqq, www, ppp, kkk, ttt, mmm et abc, j'ai aussi eu une centaine d'essais de login en root par 64.92.163.98 et divers admin, guest, mysql, etc.
  
  Enfin bon, en désactivant le root login, l'autentification par mot de passe et avec un nom d'utilisateur pas trop facile à trouver automatiquement, il y a pas trop de risques... j'aimerais bien que sshd me montre les mots de passe qu'ils essayent, par contre :)

  • [^] # Re: Bof

    Posté par redfish le 03 juin 2005 à 17:45. Évalué à 10.

    

    Mais qui peut avoir un login qui s'appelle "jacob" ?!
    
    quelqu'un qui s'appelle Jacob, non ?
    
    R.

    • [^] # Re: Bof

      Posté par lampapiertramol (site web personnel) le 03 juin 2005 à 23:16. Évalué à 6.

      

      Tu te contentes de déplacer la question là. Qui peut bien appeler son enfant jacob ?

      • [^] # Re: Bof

        Posté par Fil Ipo le 03 juin 2005 à 23:59. Évalué à 8.

        

        Et qui peut appeler sont enfant lampapiertramol ???

      • [^] # Re: Bof

        Posté par jcs (site web personnel) le 04 juin 2005 à 09:42. Évalué à 2.

        

        C'est parti, pagesblanches.fr, nom : Jacob, localité : Paris
        
        > Il y a 322 réponses en orthographe exacte
        > ce qui est supérieur au seuil autorisé de 100 réponses.
        > Vous pouvez préciser la recherche
        > (prénom, adresse, arrondissement, numéro de rue...)
        > ou afficher les réponses concernant seulement les professionnels
        
        Voilà 322 Monsieur ou Madame Jacob dans l'annuaire à Paris, 1084 en Ile de France.
        
        Et son nom de famille on ne le choisit pas :-) (enfin pas complètement)

  • [^] # Re: Bof

    Posté par fabien le 03 juin 2005 à 21:13. Évalué à 4.

    

    j'aimerais bien que sshd me montre les mots de passe qu'ils essayent, par contre :)
    
    non, ca me semble etre une mesure de securité de base.
    
    si tu vois dans tes logs les erreurs de tes utilisateurs tu pourrait facilement en deduire leur mot de passe (par exemple le cas d'un mot de passe suivant : "cattherine", je vous laisse deviner le bon)
    
    or, justement, l'administrateur ne dois pas connaitre les mots de passe des utilisateurs, il peut les changer, mais pas les connaitre.

    • [^] # Re: Bof

      Posté par ckyl le 03 juin 2005 à 23:05. Évalué à 2.

      

      Heu comment dire. L'administrateur en général il est root. Alors l'administrateur s'il veut avoir les mots de passe il les aura même si ca demande de recompiler et faire un printf au bon endroit.
      
      De deux chose l'une. Soit le mot de passe ne se retrouve pas en clair sur la machine administrée et il ne l'aura jamais soit il l'(a|aura). Ce que tu expliques c'est de la sécurité par l'obscurité, on affiche pas par défaut une information que l'on pourrait. Mauvaise réponse !
      
      La mesure de sécurité c'est que généralement on met en place des logs distant et que les logs se baladent en clair dans des jolies trames UDP et que c'est pas top top. M'enfin bon syslog est tellement pourri qu'on est plus à ca près :-)
      
      Si tu n'as pas confiance dans ton root ne te connecte pas à ses machines en tout cas pas à ses machines UNIX.
      
      Exercice: Comment, sauf clé ssh, l'administrateur peut-il n'avoir aucun moyen de récuperer le mot de passe ? Sachant que pour cela il faudra utiliser (y)passwd pour le changer...

      • [^] # Re: Bof

        Posté par fabien le 03 juin 2005 à 23:44. Évalué à 7.

        

        je suis d'accord, je sais bien l'aplication sshd recoit le mot de passe, et donc qu'il suffit de la recompiler pour qu'elle en fasse ce que tu en veux.
        
        je veux juste dire que (et je ne parle pas d'impossibilité technique) root ne devrait pas connaitre les mot de passe des utilisateur.
        je ne parle pas non plus en terme de securité de votre machine, simplement nombre d'utilsiateur de la vrai vie (et qui ne sont pas forcement informaticien) ont plein de mots de passe retenir et utilisent parfois les même.
        par exemple pour le logiciel de gestion des payes dans ma boite, il faut un mot de passe pour y acceder, la fille qui gere celà a au moins quotidiennement 10 mots de passes pour differentes application, je suis sur qu'elle réutilise ses mots de passe, et je la comprends. et donc elle n'aimerais pas du tout que l'admin connaisse l'un de ses mot de passe. voilà.
        
        et accessoirement quand on est root, on n'a pas besoin de connaitre le mot de passe avec la commande "su".

      • [^] # Re: Bof

        Posté par fabien le 04 juin 2005 à 00:04. Évalué à 9.

        

        c'est de la sécurité par l'obscurité..(blabla)...Mauvaise réponse !
        je te trouve bien sarcastique, calme toi un peu, c'est le week end.
        
        relis moi je n'ai pas dit que ce n'etait pas possible, j'ai dis qu'il ne faudrait pas. que c'est pas bien.
        Pas bien, pas pour des raisons phylosophiques (sécurité par l'obscurité...[1]) mais simplement que par principe tu ne dois pas les connaitre, je t'ai donnée un vrai exemple de la vraie vie avec des vraie gens dans mon post precedant.
        
        [1] : ca me fais doucement rigoler les types qui balancent des "sécurité par l'obscurité", c'est à la mode. (ca fait gagner des points sur la tribune?)
        Mais a ton avis, pourquoi donc on ne stoque pas les mots de passe en clair finalement dans /etc/password ? (en ne donnant les droit qu'a root bien sur). hein ? obscurité ?
        Et puis tiens, lundi, je vais dire aux employés d'ecrire leur mot de passe sur un post-it a coller sur leur ecran. je leur dirait qu'un brillant conseil m'a convaincu que l'obscurité c'est pas bien, (ca doit pas être GPL?).
        
        j'te donne une astuce : un mot de passe, intrinsequement, ca doit rester secret.
        
        même s'il existe plein plein de moyen de les connaitre. j'ai pas dis le contraire, mais je m'en fou c'est pas l'objet. (il y a même la torture aussi, et ca ne necessite aucune competence en info).
        
        alors, s'il te plait garde tes grandes phrases sur l'obscurité pour les cas qui le vallent vraiment.
        
        PS : j'ai confiance en leur root, c'est moi ;)
        
        PPS: le plus difficile avec certains informaticiens, c'est qu'ils ont le nez dans le guidon... ha ca pour la technique des le debut il va te sortir le sniff reseau, le printf... alors qu'il a tout simplement pas compris l'objet de mon message.
        
        PPPS : si le ton ne vous plait pas, moinsez moi.

        • [^] # Re: Bof

          Posté par PLuG le 04 juin 2005 à 13:13. Évalué à 0.

          

          >Mais a ton avis, pourquoi donc on ne stoque pas les mots de passe en clair
          > finalement dans /etc/password ?
          >(en ne donnant les droit qu'a root bien sur). hein ? obscurité ?
          
          C'est historique.
          on ne peut pas enlever les droits lecture sur /etc/passwd pour tout le monde car c'est necessaire pou l'association uid/nom sur le systeme (un simple /bin/ls en a déjà besoin).
          A l'époque, on stockait quand meme le mot de passe dans /etc/passwd (mais de façon codée on va dire). Les attaques dictionnaire et autres ont fini par générer l'évolution suivante: mot de passe dans /etc/shadow et uid dans /etc/passwd, /etc/passwd étant toujours lisible de tout le monde, /etc/shadow étant limité à root.
          
          bref c'est historique, y'a eu des évolutions ...
          mais ne pas stocker les mots de passe en clair a quand même un gros avantage. Si chaque fois qu'on regarde, on lit en clair les mots de passe, on s'en rappelle malgré nous ... on fini par les connaitre quasiement sans le vouloir. Alors que devoir lancer une attaque dictionnaire c'est pas la même démarche. Devant une accusation ce sera plus difficile de prétendre ne pas l'avoir fait exprès.

          • [^] # Re: Bof

            Posté par fabien le 04 juin 2005 à 22:01. Évalué à 2.

            

            merci pour les infos, j'aurait du ecrit "/etc/shadow" c'est vrai.
            
            mon exemple n'etait pas réaliste de toute maniere, c'etait juste pour les besoins de l'explication.
            
            > (mais de façon codée on va dire)
            il me semble que c'est un "hash" plutot qu'un codage, c-a-d une empreinte, comme un SHA un MD5...
            c'est pas reversible, mais effectivement on peut l'attaquer (brut force ou dico).
            PS: c'est sur ce site que j'ai appris qu'on dis pas "crypter" mais "chiffrer" :)

        • [^] # Re: Bof

          Posté par ckyl le 04 juin 2005 à 15:20. Évalué à 0.

          

          > (ca fait gagner des points sur la tribune?
          
          Jamais mis les pieds sur la tribune
          
          > par principe tu ne dois pas les connaitre
          
          Tu as raison c'est un principe. Mais afficher les password que tu peux avoir de toute façon n'ouvre pas une faille. La faille existait avant ! Si ton mot de passe était si précieux (le même que ta banque) il n'aurait jamais du se retrouver là en clair. L'administrateur n'ouvre pas une faille il ne fait que l'exploiter. La faille c'est *toi* qui l'a introduite (c'est vrai que les outils actuels ne t'aident pas non plus).
          
          Après il n'est clairement pas souhaitable que ca l'affiche par défaut on est d'accord la dessus.

          • [^] # Re: Bof

            Posté par Matthieu le 05 juin 2005 à 09:56. Évalué à 6.

            

            Questions bêtes et impertinentes :
            
            L'administrateur système est-il en droit de connaître les mots de passe des utilisateurs ou de mettre en oeuvre un moyen de les découvrir ?
            
            Si jamais un utilisateur a des problèmes et se rend compte que l'administrateur connaît son mot de passe, comment fera l'administrateur pour se défendre devant la justice ? (on rencontre actuellement les mêmes problèmes pour la messagerie... des administrateurs sont traînés devant les tribunaux pour avoir lu des messages à l'insu des utilisateurs....)
            
            Je vous laisse réfléchir à ses points...

            • [^] # Re: Bof

              Posté par ckyl le 05 juin 2005 à 12:59. Évalué à 1.

              

              Si l'administrateur n'a pas à connaitre les mots de passe il ne DOIT pas pouvoir les connaitre. C'est bien le point sur lequel j'insiste.
              
              La technique de fermer les yeux et dire "je le vois pas" n'est pas une solution.
              
              Le problème est beaucoup plus vaste. Un exemple qui me vient immédiatement en tête est "Pourquoi l'administrateur d'un l'hopital peut avoir accès à ton dossier médical ?".
              
              Le problème est que les systèmes n'ont pas été conçu avec ces problématiques en tête, et que la plupart des protocoles non plus. On se retrouve alors avec un tas de boue ambulant sur lequel on rajoute des rustines au fur et à mesure pour que ca soit acceptable.
              
              Sniffer un réseau wifi sur lequel tu es connecté c'est mal. Mais se baser sur le fait que c'est mal pour l'interdire... Non ca ne devrait pas être possible !

              • [^] # Re: Bof

                Posté par Matthieu le 05 juin 2005 à 14:05. Évalué à 3.

                

                Sniffer un réseau wifi sur lequel tu es connecté c'est mal. Mais se baser sur le fait que c'est mal pour l'interdire... Non ca ne devrait pas être possible !
                
                A aucun moment j'ai dis cela. Je dis simplement que y'a des choses que l'on ne peut pas faire comme modifier le code de sshd pour qu'il affiche les mots de passe en clair dans les fichiers de logs. C'est tout d'abord un problème d'éthique et de respect de la vie privée, et secondo un problème juridique (respect de la vie privée également).
                
                Il y a un problème que tu viens de faire ressurgir : nous utilisons des technologies faites pour améliorer l'ergonomie, mais désastreuse d'un point de vue sécurité. On peut prendre pour exemple le WIFI. C'est bien, c'est beau, tu fais une démo devant un public et 2 secondes après le public sort son chéquier pour t'acheter ta borne wifi. Du point de vue usabilité, le wifi est bon. Du point de vue sécurité, c'est désastreux. Tellement désastreux que je pense que si tu mets une borne wifi sur ton réseau sans l'isoler complètement, alors tu peux enlever tes firewalls (ça ne sert à rien de fermer ta porte d'entrée à triple tours si derrière tes portes fenêtres sont grandes ouvertes).
                Donc on a d'un côté un outils qui peut être utilisé, mais qui n'est pas bon du point de vue sécurité. La question est maintenant : "doit-on le mettre en oeuvre ?", n'est pas tromper l'utilisateur en lui mettant en place une telle technologie, sachant que pour l'utilisateur, inconsciemment (tellement inconsciemment qu'il n'en parle plus et qu'il pense maintenant à tort que la sécurité n'a pas de contrainte), la sécurité doit être prise en compte à tout moment ? L'utilisateur pourra-t-il se retourner contre l'administrateur système en cas de problème ?
                
                Nous pouvons faire la relation avec d'autres technologies imaginaires. Imaginons que dans l'automobile, il soit commercialisé un système qui permet de controler sa voiture à la voix (gloups). En disant "stop", la voiture s'arrête. Malheureusement, ce système n'est pas sécurisé et peut donc être utilisé à l'insu de l'utilisateur (ce ne sera pas un pirate qui va utiliser le système, mais la fonction principale sera détourné par un élément extérieur à cause d'une mauvaise conception de l'outils). Ce qui devait arriver arriva, un jour, l'automobiliste roulait à 132km/h sur l'autoroute, il écoutait sa radio quand le speaker utilisa le mot "stop". La voiture s'arrêta brusquement.. carambolage... Qu'en pensons-nous? le système de contrôle par la voix était mal conçu, non sécurisé dans le sens où un élément extérieur pu en prendre le contrôle. L'automobile est-il en droit de demander réparation auprès du vendeur de voiture ? on peut le penser fortement.
                L'analogie avec le wifi n'est pas très loin.
                
                Voila quelques éléments de réflexion. Je n'ai pas de réponse, personne n'a de réponse. Mais ça nous (administrateur système/réseaux) pend au nez !

                • [^] # Re: Bof

                  Posté par Sylvain Sauvage le 05 juin 2005 à 17:16. Évalué à 2.

                  

                  Nous pouvons faire la relation [...] L'analogie avec le wifi n'est pas très loin.

                  
                  Ça me rappelle la (sans doute fausse) anecdote sur un système de reconnaissance vocale dans les années 1990 : pendant une démo en public, le démonstrateur montre que l'on peut demander l'ouverture d'une fenêtre DOS (ben oui, ça tournait sous windows) et, à son invitation (ou non, ça n'est pas très important), quelqu'un dans le public dit « format C column, return » et un autre de crier « yes, return ».
                  
                  Pour ceux qui ne comprendraient pas, demandez à quelqu'un de vous prêter son windows (ben oui : les linuxfr-iens n'ont pas de windows ou ne sont pas assez fous pour faire des tests sur le leur), ouvrez une fenêtre de commande et tapez « format C: », puis répondez « yes » à la question (comme on le fait toujours avec les questions sous windows). Prévoyez quelques heures pour réparer après coup ou bien courrez très vite.
                  
                  Pour revenir à la question principale, il n'y a pas de système absolument sûr, en informatique ou ailleurs : de la même façon que les portes blindées sont toutes cassables, tous les systèmes de chiffrement sont cassables, ce que l'on espère, c'est que le cambrioleur se fatiguera avant d'y arriver ou ira cambrioler le voisin dont la porte prend moins de temps à ouvrir.
                  
                  Et pour revenir à ce fil en particulier, tout en restant dans l'analogie des portes et serrures, les serruriers sont capables d'ouvrir les portes, le concierge de l'immeuble aussi, les employés de banque ont accès à vos comptes, etc.
                  Il y a un moment où il faut faire confiance.
                  Il y a aussi un moment où les abus sont punis.
                  Cela s'appelle l'éthique.
                  Ce n'est pas facile de la définir, ce n'est pas facile de l'appliquer.

                  • [^] # Re: Bof

                    Posté par bertrand le 06 juin 2005 à 10:36. Évalué à 1.

                    

                    "les employés de banques ont accès à vos compte"
                    
                    oui mais c'est enregistré et on peut retrouver qui a fait quoi.
                    (s'il n'y a pas usurpation de login !)

                    • [^] # Re: Bof

                      Posté par briaeros007 le 12 juin 2005 à 19:37. Évalué à 2.

                      

                      pas forcement ; les dossiers pouvant etre aussi sur papier (et les justificatif qu'ils te demandent, ils les mettent ou ? je crois pas qu'il les scannent)

          • [^] # Re: Bof

            Posté par Matthieu le 05 juin 2005 à 10:15. Évalué à 0.

            

            Questions bêtes et impertinentes :
            
            L'administrateur système est-il en droit de connaître les mots de passe des utilisateurs ou de mettre en oeuvre un moyen de les découvrir ?
            
            Si jamais un utilisateur a des problèmes et se rend compte que l'administrateur connaît son mot de passe, comment fera l'administrateur pour se défendre devant la justice ? (on rencontre actuellement les mêmes problèmes pour la messagerie... des administrateurs sont traînés devant les tribunaux pour avoir lu des messages à l'insu des utilisateurs....)
            
            Je vous laisse réfléchir à ses points...

      • [^] # Re: Bof

        Posté par Raoul Volfoni (site web personnel) le 04 juin 2005 à 00:12. Évalué à 3.

        

        > M'enfin bon syslog est tellement pourri qu'on est plus à ca près
        
        Mon conseil: regardes du coté de syslog-ng, c'est impressionnant tout ce qu'il permet de faire:
        http://www.balabit.com/products/syslog_ng/(...)

        • [^] # Re: Bof

          Posté par ckyl le 04 juin 2005 à 14:23. Évalué à 3.

          

          Pour information je suis contributeur à un démon syslog et au WG de l'IETF sur syslog :-)
          
          Enfin bon si l'ensemble de nouveaux drafts arrive jusqu'au status de RFC et qu'un jour hypothétiquement elles sont adoptées ca deviendra acceptable.

    • [^] # Re: Bof

      Posté par igor38 le 05 juin 2005 à 19:45. Évalué à 2.

      

      " adieu sshd aussi "
      Euh... Pourquoi ?
      
      Tu peux aussi configurer ton hosts.deny, et mettre seulement tes ip autorisées (ou dyndns) dans ton hosts.allow

• # Re: une petite attaque

  Posté par kd le 03 juin 2005 à 18:07. Évalué à 4.

  

  Oui, moi aussi j'en ai plein les logs. Les essais d'intrusion proviennent d'ordinateurs situés en Chine, Corée, Mongolie, surement des ordinateurs piratés.
  
  Je trouve ça assez embêtant, mais on s'y fait. Un seul utilisateur a le droit de se loguer via ssh (moi), donc a priori, je ne crains vraiment rien.
  
  M'enfin bon, pour ne pas avoir des logs pourris jusqu'à la moelle, j'ai mis sshd en écoute sur un autre port (22222). Depuis, je n'ai plus de problèmes.

  • [^] # Re: une petite attaque

    Posté par smorico le 03 juin 2005 à 18:19. Évalué à 7.

    

    lol, t'as plus qu'a changer de port...
    
    :p

• # Les robots Attaques ??

  Posté par smorico le 03 juin 2005 à 18:11. Évalué à 5.

  

  Oui c'est certainement un bot...
  Assure toi d'avoir un mot de passe solide...
  Ce que tu peut faire, c'est déjà loguer le trafic avec iptable pour voir d'ou l'attaque vient... Tu peut ensuite bannir la ou les adresses IP.
  
  Tu peut aussi mettre en place un truc sympa grâce au logiciel Knocker. Il s'agit d'un port knocker. Il permet de lancer un service uniquement si certains paquets précis sont reçus.
  
  Par exemple 2 paquet SYN/ACK avec tel numéro de séquence, suivi d'un paquet RST provenant du port heu je sais pas 53...
  
  Tu te fait ensuite un petit utilitaire qui permet d'envoyer ces paquets sur ton serveur. A son execution (sur un pc depuis lequel tu veux te connecter), ca lancera le service SSH. Tu peut executer une commande, donc par exemple ajouter une régle iptable pour autoriser seulement l'IP qui à envoyé les paquets à se connecter sur le port 22.
  
  Plus d'info sur : http://knocker.sourceforge.net/(...)
  Le paquet debian s'appelle knoker.

  • [^] # Re: Les robots Attaques ??

    Posté par Victor le 03 juin 2005 à 18:30. Évalué à 2.

    

    le packet debian s'appelerait pas knocker plutot ?
    
    et ou vois tu qu'il peut avoir le comportement que tu decris ?
    
    je n'ai pas reussi a trouver :(

    • [^] # Re: Les robots Attaques ??

      Posté par smorico le 03 juin 2005 à 18:49. Évalué à 7.

      

      m**** je me suis gouré désolé. knocker est un port scanner ce qui n'a rien à voir...
      
      Je voulais parler de "Advanced Port Knocking Suite" : APKS
      Tu trouvera des infos sur la page de Renaud Bidou :
      
      http://www.iv2-technologies.com/~rbidou/(...)
      
      le readme est ici : http://www.iv2-technologies.com/~rbidou/apk.README.html(...)
      
      C'est du perl. En fait il y a une partie "serveur" et même une partie cliente qui permet de générer les paquets donc pas besoin de coder quoi que ce soit...

    • [^] # Re: Les robots Attaques ??

      Posté par chtitux (site web personnel) le 03 juin 2005 à 18:52. Évalué à 2.

      

      Sur ubuntu, j'ai :

      # apt-cache search knocker
      knocker - a simple and easy to use TCP security port scanner
      

      ainsi que la description :

      Description: a simple and easy to use TCP security port scanner
       Knocker is a new, simple, and easy to use TCP security port
       scanner written in C, using threads. It is able to analyze hosts
       and the network services which are running on them.
       The URL for this project is http://knocker.sourceforge.net/(...)
      

      Il y a comme seule dépendance libc6 je crois.

• # Pubkey

  Posté par Bruno (site web personnel) le 03 juin 2005 à 18:21. Évalué à 6.

  

  Tu peux aussi activer la connexion par clef publique uniquement. Dans ce cas, ça coupe (très) court à ces tentatives externes.
  
  L'inconvénient, c'est qu'il faut avoir son couple de clefs sur soi (mais bon, maintenant tout le monde se balade avec sa clé usb/lecteur mp3 dans la poche, non ?)

• # HS : Suis-je un geek normalement constitué ?

  Posté par plagiats le 03 juin 2005 à 18:25. Évalué à 5.

  

  Lorsque je lis "Journal : une petite attaque", je pense à un infarctus. est-ce grave docteur ?

  • [^] # Re: HS : Suis-je un geek normalement constitué ?

    Posté par smorico le 03 juin 2005 à 18:31. Évalué à 2.

    

    Le plus dur c'est de pas avoir une attaque quand on t'attaque :D

• # firewall

  Posté par M le 03 juin 2005 à 19:08. Évalué à 4.

  

  perso ssh est ouvert que pour les machines auquel je fais confiance...

• # Pas de root par SSH

  Posté par Xavier MOGHRABI (site web personnel) le 03 juin 2005 à 21:35. Évalué à 2.

  

  désactive la connexion par root avec SSH
  
  et pour les autres utilisateurs utilisent si possible des clefs et désactive la connexion par mot de passe

• # Moi aussi !

  Posté par Miguel Moquillon (site web personnel) le 03 juin 2005 à 21:39. Évalué à 2.

  

  Salut,
  
  Après lecture de ton journal, je me suis aussi penché sur mes log d'authentification. Et j'ai les même traces !
  
  Pour mon serveur SSH, j'ai juste activé la connexion par clé publique (les clés des serveurs distants doivent être listés parmi ceux autorisés) + par user/challenge (pas par mot de passe).
  Le root n'est pas non plus autorisé à se connecter par ssh.
  
  Bien que cela devrait suffire, j'ai toutefois quelques inquiétudes.
  La dernière tentative d'attaque date du 1er juin.

• # Host Deny

  Posté par bghflt (site web personnel) le 03 juin 2005 à 22:27. Évalué à 2.

  

  Voir:
  
  http://freshmeat.net/projects/denyhosts/(...)
  
  Pour éviter ces attaques en quasi temps réel...
  
  Sinon faire des graphes pour voir l'horreur et la constance de ces attaques..

• # Une petite attaque : NON ! Un essai !

  Posté par Fil Ipo le 04 juin 2005 à 11:31. Évalué à -1.

  

  Et alors ton pc est mort ? Quelles consequences ?
  Ta machine est tombée au moins ???

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.