Forum Linux.général Serveur SSH comment se proteger

Posté par  .
Étiquettes : aucune
0
3
mai
2007
Bonjour!
Voilà j'ai un petit serveur SSH qui tourne chez moi dans mon reseau local.Il est derrier un routeur firewall qui fait du NAT (un vieux netgear FR 314 recupere de la casse qui me satisfait bien jusque là).
Mon serveur SSH tourne en stand alone, je n'ai pas inetd/xinetd sur ma machine.
Je constate bien sur que comme mon serveur est accessible depuis l'exterieur il est sujet à des attaques frequentes de connexions indesirées.
Sachant que je ne peux pas bannir d'ip sur mon netgear, quelle solution me proposez vous pour pouvoir bannir des ip sur mon serveur, et surtout qu'est ce qui est le meilleur en terme de performance et de disponibilité de mon réseau?
J'avais pensé à tcpwrapper ou un truc du genre, le mieux serait de recuperer une vielle machine et de faire un vrai firewall mais j'ai la flemme.
Merci de vos retours.

  • # ssh itself ?

    Posté par  . Évalué à 5.

    commencer par activer des options kivonbien dans le serveur ssh ?

    ban des connexions d'une certaine ip pendant 5 minutes après 3 mots de passe ratés, ban des connexions d'une certaine ip pendant 12h si tentative de plein de username en quelques minutes, autorisation sur base du nom, login autorisé uniquement sur base de clés publiques/privées...

    • [^] # Re: ssh itself ?

      Posté par  . Évalué à 1.

      Quelles sont les options en question?
      Je viens de relire la manpage sshd_config et je n'ai pas trouvé de paramètres pour faire ce dont tu parle (avec openssh).

  • # DenyHosts

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

    C'est un soft qui va surveiller ton journal des accès, et après un certain nombre d'échec, il va bannir via hosts.deny les adresses IP sources. Tu peux whitelister des adresses.

    http://denyhosts.sourceforge.net/

    Assez pratique, surtout avec les robots qui tournent.

  • # iptables :-) / port d'écoute différent / ...

    Posté par  . Évalué à 2.

    Bonjour,

    Ma première idée est de faire un mini jeu de règles IPTables pour limiter les sources légitimes plutôt que d'utiliser le TCPWrapper (disons que IPTables protège avant, le tcpwrapper interviendrait alors après dans le mode standalone de SSH si SSH compilé et configuré avec le support TCPWrapper).
    En plus, tu peux aussi rajouter des limites du type nombre de connexions max / sec / IP, etc...

    La seconde serait de changer le port d'attaque du service SSH (soit sur le routeur NAT avec la bonne règle qui va bien, soit sur la machine dans une directive type Listen ou Port).
    Selon certains (avis perso: ce n'est pas mon cas), c'est plus "secure".

    La troisième est de n'autoriser que les authentifications par clés pour limiter les attaques sur les login/mot de passe "classiques".

    Etc...

    Bon courage !

    Cdlt,

    PS: Ah oui, je ne l'ai pas cité, mais je te conseille vivement d'interdir l'accès root au serveur SSH :D
    Avec SUDO et (au moins) un utilisateur qui va bien, on peut s'en passer ^__^

  • # Sécurité...

    Posté par  . Évalué à 3.

    Dans la config ssh, bloquer root, ou éventuellement, le mettre accessible via clef uniquement, mais seulement si c'est vraiment nécessaire (besoins de réplication).

    Virer sshv1 des protocoles autorisés.

    Le blocage d'ip est peu productif, autant laisser tomber ce point.

    Changer le port pour un port au dessus des 1024, ça peut aider.

    Bosser avec des utilisateurs non privilégiés et utiliser sudo.

    mettre MaxStartups à 5

    et mettre à jour sshd régulièrement

  • # Port knocking

    Posté par  . Évalué à 6.

    Tu peux aussi utiliser une technique de Port Knocking. Voir:
    http://en.wikipedia.org/wiki/Port_knocking

    Le principe est simple: le port SSH est ferme par defaut. Quand tu envoies un paquet sur un port donne (par exemple: 15000), ca ouvre le port SSH pour 1 minute. Si un paquet est recu sur le port 15001, le port SSH est immediatement referme. En deplacant le port SSH de 22 vers quelque chose de plus exotique, ca dejoue la plupart des attaques de script kiddies. On peut evidemment decliner a l'envi la facon de venir taper a la porte du serveur pour ouvrir le port SSH en se basant sur des paquets TCP, UDP ou meme ICMP. Pour se logger, un petit script est necessaire pour lancer les paquets qui vont bien avant de demarrer une session SSH.

    Pour appuyer les autres commentaires: desactive absolument le login par mot de passe pour tous les utilisateurs. Le login par cle est beaucoup plus robuste et plus simple au quotidien.

    • [^] # Re: Port knocking

      Posté par  . Évalué à 2.

      J'avais entendu parler, il y a quelques temps, d'un système de port knocking qui utilisait carrément un certificat cryptographique: le client signait un timestamp et le communiquait sous forme de port knocking. De l'autre côté, le port knocking était décomposé pour reformer la valeur signée, la signature était validée, et l'accès était donné si nécessaire...

    • [^] # Re: Port knocking

      Posté par  . Évalué à 1.

      Le systeme de port knocking est elegant.
      Mais je doute pouvoir faire ça sur mon netgear.
      J'ai deja du desactiver le stealth mode pour pouvoir me connecter depuis l'exterieur.

      • [^] # Re: Port knocking

        Posté par  . Évalué à 1.

        Effectivement: l'idee du port knocking s'implemente sur une adresse IP publique, pas a l'interieur d'un sous-reseau en NAT. C'est donc le routeur d'entree (comme ton Netgear) qui doit faire le travail. Si tu as un routeur programmable (WRT54G et autres variantes), tous les packages sont a priori disponibles et prets a configurer. Sinon, tu peux mettre la machine qui heberge ton serveur ssh en DMZ et configurer ce serveur (si ton routeur supporte la notion de DMZ). Tu peux aussi faire du port forward des ports qui t'interessent pour implementer le port knocking sur le serveur ssh, et translater le mecanisme de ton routeur vers le serveur.

        NB: le mecanisme de port knocking n'est pas fait pour assurer la securite du serveur, juste rendre plus difficile la detection de port ssh ouvert sur une adresse publique. La veritable protection reside integralement dans les credentials (francais?) presentes pour l'ouverture d'une session. Un mot de passe de 8 caracteres a environ 10-20 bits d'entropie, une cle privee/publique peut en avoir 1024 ou 2048.

  • # C'est noté

    Posté par  . Évalué à 1.

    OK merci de vos réponses.
    Je vais configurer mon serveur comme il se doit.
    J'ai absolument besoin de l'authentification par login/mdp et non par clef.
    Merci pour tout.

Suivre le flux des commentaires

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