Forum Linux.général securité serveur

Posté par  .
Étiquettes : aucune
0
10
oct.
2005
Bonjour,

sur mon serveur, lorque je regarde le resume de mes logs j'ai entre autres :

sshd:
Authentication Failures:
root (201-25-100-2.cbace300.ipd.brasiltelecom.net.br ): 1207 Time(s)


et un autre jour

sshd:
Authentication Failures:
root (221x243x28x74.ap221.ftth.ucom.ne.jp ): 245 Time(s)

Est- ce inquietant ??? Qqn essai de rentrer... quelles mesures dois-je prendre

merci

chbruno

  • # Plusieurs solutions

    Posté par  (site web personnel) . Évalué à 3.

    Déjà, tu peux commencer par mettre un PermitRootLogin à no dans /etc/ssh/sshd_config.

    Ensuite, tu peux utiliser un outil[1] qui drop les requêtes après trop d'essais faux. Voir aussi des discussions[2] pertinentes.

    Pour finir, tu peut implémenter le port knocking[3] ou faire écouter le serveur ssh sur un port non standard ce qui rends les logs beaucoup moins sales...

    [1] http://fail2ban.sourceforge.net/(...)
    [2] http://www.debian-administration.org/articles/250(...)
    http://www.debian-administration.org/articles/87(...)
    [3] http://www.debian-administration.org/articles/268(...)

  • # re

    Posté par  . Évalué à 6.

    Dans la mesure ou il s'agit d'"authentification failure", cela n'est pas grave.
    Beaucoup de bruteforcer sshd tourne sur le net (je crois avoir vu passer 4 ou 5 tentatives depuis ce matin sur mon serveur).
    Tant que ton mot de passer est sûr tu n'as aucune crainte à avoir.

    Pour avoir un sshd digne de confiance, je te conseille de:

    1/ Interdire les connexions en tant que root (généralement fait par défaut).
    2/ N'autoriser que les connexions par clefs publiques.
    3/ N'autoriser que la version 2 du protocole (généralement fait par défaut).
    4/ Changer le port d'écoute de ton sshd.

    Pour ce faire, man sshd_config

    C'est tout ce qui me vient à l'esprit dans un premier jet, mais Il y a certainement d'autres choses à faire

    • [^] # Re: re

      Posté par  . Évalué à 3.

      J'ai aussi eu ce type de problème sur mes serveurs, j'avais appliqué les mêmes conseils que tu proposes et ça fait fuir beaucoup de gens :)

      Par ordre d'efficacité décroissante :
      1) authentification uniquement par certificat (empêche direct les brute forcer et les connexions non authorisées)
      2) désactivation des connexions root (t'empêche de faire des conneries sur tes serveurs, use sudo, luke)
      3) utilisation stricte du protocole v2 (empêchera un thésard en cryptologie de casser ton DSA ou je sais pas quoi :)
      4) changer le port d'écoute (sers à rien mais c'est marrant)

      Je crois que déjà là c'est pas mal.
      Eventuellement, je pense qu'on doit pouvoir pousser le vice avec PAM et une authentification à base de token physique ou ce que tu veux, mais ça n'est peut-être pas nécessaire...

    • [^] # Re: re

      Posté par  (site web personnel) . Évalué à 3.

      5/ autoriser les connexions au port ssh seulement depuis des IPs "de confiance" (limiter aux IPs de ton continent ça serait déjà un début)
      6/ ne pas faire tourner ssh du tout sur l'interface réseau connectée à internet

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

Suivre le flux des commentaires

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