Première ouverture d'un serveur SSH sur Internet, que vérifier

9

J'exécute quelques serveurs depuis assez longtemps, mais je ne les ai toujours loués, donc je n'ai pas beaucoup d'expérience pour sécuriser le serveur réel (contrairement à l'application que j'exécute).

Maintenant, j'ai envie d'ouvrir mon petit serveur SSH domestique à Internet.

Je serai le seul à l'utiliser, mes mots de passe sont assez compliqués, j'ai changé le port SSH par défaut à environ 4000, le seul port accessible est ce port SSH via la redirection de port sur mon routeur / pare-feu, et il est mis à jour automatiquement tous les soirs (il exécute Arch Linux, une distribution de version continue).

Quelles sont les autres mesures à prendre, le cas échéant, pour garantir la sécurité?

Merci!

security  ssh  linux 
— houbysoft
source

Réponses:

22

Assurez-vous que les connexions root sont désactivées PermitRootLogin no. J'envisagerais également de désactiver complètement les mots de passe PasswordAuthentication noet d'utiliser des clés publiques PubkeyAuthentication yes.

— chx
source
+1 m'a battu ...
— gravyface
1
Si vous prévoyez d'utiliser des mots de passe, vous pouvez essayer de rechercher un système d'authentification à deux facteurs. Sinon, je vous déconseille de taper votre mot de passe sur un système de bibliothèque / café Internet aléatoire.
— Mark Wagner
4
Si vous autorisez l'authentification par mot de passe, envisagez d'installer fail2ban pour empêcher les attaques par force brute et utilisez des mots de passe forts pour tout compte autorisé à se connecter via ssh
— uSlackr
@embobo - pourquoi ça? Les mots de passe envoyés via le câble sont cryptés en ssh. Oui, l'authentification par clé est de loin supérieure à bien des égards, mais tant que les mots de passe sont suffisamment forts et que vous avez vérifié que personne ne surfe sur les épaules, alors ce n'est pas énorme.
— EEAA
3
@Erika Je pense qu'embobo fait allusion à la méfiance générale envers tout système étranger. Même si SSH est crypté, une machine étrangère peut toujours dire, enregistrez vos frappes. Ainsi mot de passe = compromis.
— rthomson
9

Assurez-vous que seul SSH-2 est autorisé (puisque SSH-1 a soulevé des problèmes de sécurité dans le passé):

Protocol 2

Spécifiez quels sont les seuls utilisateurs autorisés à se connecter via SSH:

AllowUsers bob, john

Pour une sécurité accrue, interdisez l'authentification par mot de passe et utilisez l'authentification par clé publique:

PasswordAuthentication no
PubkeyAuthentication yes

Remarque: ce didacticiel contient des instructions pour créer des clés et configurer l'authentification par clé publique.

— bambam
source
5

Outre les points concernant la désactivation de la connexion root ou l'utilisation de l'authentification par clé publique uniquement, je vérifierais également qu'aucun compte utilisateur sur le système n'a de mots de passe triviaux ou vides. Vous avez dit que vos mots de passe personnels sont corrects, mais cela n'exclut pas qu'un compte avec un mauvais mot de passe ait été créé pour une autre raison.

À titre d'exemple: j'ai dû réparer un réseau où l'administrateur précédent avait installé nagios sur tous ses systèmes à partir de la source, et créé un utilisateur nagios sans mot de passe, ou avec le mot de passe "nagios", puis j'ai procédé à l'obtention de trois machines différentes compromis.

— Daniel Lawson
source
4

Vous voudrez peut-être regarder une sorte d'outil de liste noire IP comme http://denyhosts.sourceforge.net/ . Il bloque toutes les adresses IP qui tentent de se connecter trop souvent sans succès et est hautement configurable.

— Boucliers de Lynden
source
Probablement une perte de temps si vous avez désactivé les connexions root. D'après mon expérience (2 années ish de serveur SSH sur Internet), seul un couple a même obtenu mon nom d'utilisateur (évident). Les robots vérifient simplement les mots de passe évidents sur les noms d'utilisateur courants (99% des connexions échouées sur mon serveur sont pour root, ce qui est bien sûr désactivé).
— Brendan Long
4
Certainement pas une perte de temps - mais jetez un œil à fail2ban
— symcbean
+1 pour fail2ban.
— JamesBarnett
1
root n'est pas le seul compte évident que les bots recherchent, voir nagios comme mentionné ci-dessus. Il existe également des comptes de base de données comme mysql et postgres. Plus tout autre compte d'application.
— JamesBarnett
Oui, ma machine SSH face au net a été prise en charge par un bot devinant un mot de passe non root, donc certainement pas une perte de temps. En outre, depuis l'obtention d'un blacklister comme celui-ci, en regardant les journaux, un très faible pourcentage de tentatives est en fait pour root.
— Lynden Shields
0

Revues récurrentes des journaux sur les parties / composants pertinents de vos systèmes (en fonction de sa configuration réelle / spécifique) ...

— user48838
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.