À quel point est-il risqué d'avoir un serveur personnel avec ssh ouvert sur Internet?

25

La continuation du titre serait «tout en ayant une connaissance limitée de la sécurité Internet».

J'ai récemment mis en place un petit serveur avec un ordinateur bas de gamme exécutant debian dans le but de l'utiliser comme un dépôt git personnel. J'ai activé ssh et j'ai été assez surpris de la rapidité avec laquelle il a souffert d'attaques par force brute et similaires. Ensuite, j'ai lu que c'était assez courant et j'ai appris les mesures de sécurité de base pour conjurer ces attaques (beaucoup de questions et de doublons sur le défaut de serveur le traitent, voir par exemple celui-ci ou celui-ci ).

Mais maintenant, je me demande si tout cela en vaut la chandelle. J'ai décidé de configurer mon propre serveur principalement pour le plaisir: je pouvais simplement compter sur des solutions tierces telles que celles proposées par gitbucket.org, bettercodes.org, etc. Bien qu'une partie du plaisir consiste à se renseigner sur la sécurité Internet, je n'ai pas assez de temps pour y consacrer pour devenir un expert et être presque certain que j'ai pris les bonnes mesures de prévention.

Afin de décider si je vais continuer à jouer avec ce projet de jouet, je voudrais savoir ce que je risque vraiment de faire. Par exemple, dans quelle mesure les autres ordinateurs connectés à mon réseau sont-ils également menacés? Certains de ces ordinateurs sont utilisés par des personnes ayant des connaissances encore moindres que les miennes exécutant Windows.

Quelle est la probabilité que je rencontre de réels problèmes si je respecte des directives de base telles qu'un mot de passe fort, un accès root désactivé pour ssh, un port non standard pour ssh et éventuellement la désactivation de la connexion par mot de passe et l'utilisation d'une des règles fail2ban, denyhosts ou iptables?

Autrement dit, y a-t-il de gros méchants loups que je devrais craindre ou s'agit-il principalement de chasser les enfants de script?

security ssh debian

— Alfred M.
source

Je pense que vous avez mis le doigt sur la tête lorsque vous avez mentionné que vous n'avez pas le temps ni l'envie de devenir un expert en sécurité $ TECHNOLOGY; c'est la principale raison d'utiliser une solution hébergée. Le seul autre argument commun dans l'évaluation en interne par rapport à l'hébergement est le coût. Étant donné que github et autres sont gratuits, vous abandonnez essentiellement votre temps personnel juste pour acquérir des connaissances sur la façon de gérer un dépôt git. Nous ne pouvons pas vous dire ce que vous devriez faire avec votre temps personnel, mais dans une situation professionnelle, cela n'aurait aucun sens. (caveat emptor: les situations compliquées ont plus de variables).

— Chris S

1

Si vous décidez d'exécuter votre propre serveur, ajoutez également à votre liste de tâches une vérification régulière des mises à jour et des vulnérabilités de sécurité pour chaque service que vous exécutez. Le configurer ne suffit pas.

— semaine

Deux mots: clés publiques, comme l'a dit @Stephane. Désactivez l' keyboard-interactiveauthentification et utilisez uniquement l' pubkeyauthentification.

— kostix

14

IMO SSH est l'une des choses les plus sûres à écouter sur Internet. Si vous êtes vraiment inquiet, écoutez-le sur un port haut de gamme non standard. J'aurais toujours un pare-feu (au niveau de l'appareil) entre votre box et Internet et j'utiliserais simplement la redirection de port pour SSH, mais c'est une précaution contre les autres services. SSH lui-même est sacrément solide.

Des personnes ont parfois frappé mon serveur SSH domestique (ouvert à Time Warner Cable). Jamais eu d'impact réel.

Certaines mesures supplémentaires que vous pouvez prendre pour rendre SSH plus sûr sont d'empêcher les tentatives répétées à partir de la même adresse IP pour une machine domestique, quelque chose comme

MaxStartups 2:30:10

dans / etc / ssh / sshd_config, ce qui restreindra le nombre de connexions pouvant être créées sur une ligne avant de se connecter avec succès.

— TheFiddlerWins
source

Mon fournisseur de services Internet fournit un pare-feu dont j'ai vu les paramètres lors de l'ouverture d'un port pour ssh. Est-ce à cela que vous faites référence?

— Alfred M.

2

Peut-être, certains FAI vous donnent un appareil stupide, certains un routeur avec un pare-feu intégré. Je dis simplement que ce n'est JAMAIS une bonne idée de mettre un OS à usage général directement sur Internet, quelles que soient les précautions que vous prenez. Vous voulez une sorte de périphérique matériel (ou quelque chose comme DD-WRT) entre vous et le méchant.

— TheFiddlerWins

1

Configurez l'authentification par clé publique comme indiqué dans une autre réponse et désactivez ChallengeResponseAuthentication et PasswordAuthentication dans / etc / ssh / sshd_config.

— Randy Orrison

Je sais que c'est une question stupide mais dois-je acheter un domaine pour accéder à mon serveur (via ssh ou navigateur) depuis Internet?

— TheRookierLearner

@TheRookierLearner - non, vous pouvez utiliser l'adresse IP que votre FAI vous fournit. Cependant, selon la configuration de votre réseau domestique, il peut être partagé sur tous vos appareils par quelque chose appelé PNAT (la plupart des gens l'appellent simplement NAT). Si vous êtes comme la majorité des gens, vous devrez déterminer l'IP "NATed" du périphérique spécifique auquel vous souhaitez accéder à partir d'Internet (juste ifconfig / ipconfig sur le système, ce sera un 10.xxx, 172.16. adresse xx ou 192.168.xx voir RFC 1918 pour plus que vous ne vous souciez de ces numéros), puis dites à votre routeur de "

— rediriger

10

La configuration d'un système d'authentification à clé publique avec SSH est vraiment triviale et prend environ 5 minutes à configurer .

Si vous forcez toutes les connexions SSH à l'utiliser, cela rendra votre système à peu près aussi résistant que vous pouvez l'espérer sans investir BEAUCOUP dans l'infrastructure de sécurité. Franchement, c'est tellement simple et efficace (tant que vous n'avez pas 200 comptes - alors ça devient compliqué) que ne pas l'utiliser devrait être une infraction publique.

— Stéphane
source

3

Pour forcer les connexions SSH à utiliser l'authentification par clé publique après l'avoir configurée, assurez-vous de DÉSACTIVER ChallengeResponseAuthentication et PasswordAuthentication dans / etc / ssh / sshd_config. J'ai oublié cela une fois, à mon grand regret (une seule fois et plus jamais).

— Randy Orrison

8

Je gère également un serveur git personnel ouvert sur le monde sur SSH, et j'ai également les mêmes problèmes de force brute que vous, donc je peux comprendre votre situation.

TheFiddlerWins a déjà abordé les principales implications en matière de sécurité de l'ouverture de SSH sur une IP accessible au public, mais le meilleur outil IMO en réponse aux tentatives de force brute est Fail2Ban - un logiciel qui surveille vos fichiers journaux d'authentification, détecte les tentatives d'intrusion et ajoute des règles de pare-feu à la iptablespare-feu local de la machine . Vous pouvez configurer à la fois le nombre de tentatives avant une interdiction et la durée de l'interdiction (ma valeur par défaut est de 10 jours).

— Craig Watson
source

Comme l'indiquait mon commentaire sur le post précédent, c'est ce que mon NAS utilise à la maison, et après quelques mois, la quantité de tentatives a été considérablement réduite.

— mveroone

2

Une autre façon de gérer cela est de configurer un VPN. Plutôt que de vous connecter directement aux ports SSH de votre serveur domestique, vous vous connectez d'abord au VPN, puis exécutez tout votre trafic via la connexion cryptée et sécurisée.

La façon idéale de gérer cela est avec un pare-feu qui intègre un point de terminaison VPN, mais vous pouvez également configurer un ordinateur Windows pour agir en tant que serveur VPN.

Voici un exemple:

http://www.howtogeek.com/135996/

Gardez maintenant à l'esprit qu'une configuration de sécurité appropriée impliquerait un ordinateur public (ou semi-public) isolé de votre réseau interne. Un serveur Web ou tout ordinateur hébergeant des services accessibles au public doit être en dehors du réseau sécurisé de votre domicile ou de votre bureau. Vous utiliseriez 2 routeurs pour créer une zone de sécurité, ou une zone démilitarisée, entre vous et Internet.

De cette façon, si votre serveur est piraté, il ne peut pas être utilisé comme vecteur pour attaquer vos autres ordinateurs.

Ainsi, la configuration ressemblerait à ceci:

Configuration DMZ

— TomXP411
source

Désolé pour la petite image ... Je n'arrive pas à comprendre comment modifier mon message.

— TomXP411

2

Les réponses sont très bonnes, je ne recommanderais que deux choses:

Envisagez l'accès uniquement par le système d'authentification par clé
Utiliser Denyhosts : il interdira aux hôtes qui tentent d'accéder à votre serveur avec une authentification non valide

— Carlos C Soto
source