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.
Forum Linux.général Serveur SSH comment se proteger
3
mai
2007
# ssh itself ?
Posté par nicodache . Évalué à 5.
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 wismerhill . Évalué à 1.
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 Xarli (site web personnel) . Évalué à 2.
http://denyhosts.sourceforge.net/
Assez pratique, surtout avec les robots qui tournent.
[^] # Re: DenyHosts
Posté par aurel . Évalué à 1.
# iptables :-) / port d'écoute différent / ...
Posté par Steve Azriel . Évalué à 2.
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 ragoutoutou . Évalué à 3.
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 malin . Évalué à 6.
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 ragoutoutou . Évalué à 2.
[^] # Re: Port knocking
Posté par jean_clume . Évalué à 1.
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 malin . Évalué à 1.
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 jean_clume . Évalué à 1.
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.
[^] # Re: C'est noté
Posté par other . Évalué à 1.
Vite fait comme ça.
C'est pour Debian mais ça devrais s'appliquer a tout openssh, enfin je crois.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.