Pourquoi sshd autoriserait-il les connexions root par défaut?


7

Je travaille actuellement sur le durcissement de mes serveurs contre le piratage - entre autres choses, je reçois beaucoup de tentatives de connexion en tant que root sur ssh. Bien que j'aie implémenté fail2ban, je me demande pourquoi les ouvertures de session root seraient autorisées par défaut au départ? Même avec des distributions non basées sur sudo, je peux toujours me connecter en tant qu'utilisateur normal et basculer - je me demande donc s'il y a un avantage clair à autoriser les ouvertures de session root sur ssh, ou est-ce juste quelque chose que personne ne se soucie de changer?

Réponses:


8

Il y a un net avantage à autoriser les connexions root sur ssh

Certains systèmes de sauvegarde nécessitent un root sur le système distant pour effectuer réellement une sauvegarde. Il n'est pas rare de voir les choses se configurer avec une authentification par clé pour effectuer des tâches de maintenance sur des systèmes distants.

Je souhaite fortement que la valeur par défaut soit modifiée de PermitRootLogin yesau moins PermitRootLogin without-password, cela autoriserait uniquement l'authentification par clé. L'authentification par mot de passe à distance au compte racine n'est presque jamais nécessaire.

Il devient de plus en plus courant sur les systèmes (comme Ubuntu) que le système soit configuré avec un compte root avec un mot de passe désactivé. Il n'y a pas beaucoup de risques dans la configuration par défaut car il n'y a aucun moyen de s'authentifier directement auprès d'un compte avec un mot de passe désactivé.

Considérez également qu'une tentative de connexion à distance à root via ssh par force brute a très peu de chances de réussir si vous avez un compte root avec un mot de passe suffisamment complexe. La désactivation du compte root fournit une couche supplémentaire de sécurité, mais elle peut ne pas être nécessaire si vous avez un mot de passe fort. Si vous combinez un mot de passe fort avec des outils réactifs comme denyhosts et fail2ban, il n'y a généralement presque aucun risque qu'une tentative de force brute sur le mot de passe root fonctionne.

Il est toujours recommandé de durcir le système après l'installation en fonction du risque et des besoins de votre réseau. Un système qui n'est pas critique et qui n'a pas de données utilisateur n'a pas vraiment besoin du même niveau de renforcement que le système qui stocke les dossiers médicaux ou bancaires.


2

Je ne suis pas sûr, mais je suppose qu'ils voulaient s'assurer que les personnes effectuant des installations étrangères pouvaient se connecter. La première connexion peut avoir besoin d'être root car il n'y a pas encore d'autres utilisateurs.

Cependant, vous devez vous assurer de désactiver l'option de connexion en tant que root dans la configuration sshd après avoir créé votre utilisateur et lui avoir accordé des autorisations sudo.

Je vous recommande également de changer le port SSH en autre chose que 22. Bien que cela ne rende pas votre machine plus sécurisée - cela arrête toutes ces demandes inutiles / ennuyeuses.


Je suis vraiment en désaccord avec le changement des ports standard. Utilisez le filtrage de paquets.
Warner

Vraiment? Quel est le problème? Je viens de commencer à le faire parce que j'ai vu des administrateurs respectés le faire ...
Xeoncross

C'est quelque chose que les gens ont adopté en exécutant des serveurs colocalisés sans filtrage ni séparation de réseau.
Warner

@Warner mais, je ne comprends pas, changer de port standard ne serait pas un moyen assez simple pour la plupart des gens de repousser la plupart des tentatives?
Camilo Martin

2

Envisagez d'empêcher les connexions root comme protection supplémentaire. Il y a quelques années, bruteforce était à son apogée, de nos jours, ils ont tendance à rechercher des vulnérabilités via ce qu'ils peuvent voir par les démons (apache, pureftpd, ...). Empêcher les connexions root devient une excellente idée si demain un exploit est trouvé avec SSHD. Bien que SSHD soit mature et sécurisé, vous ne savez jamais. Dernièrement, les exploits visaient davantage l'escalade de privilèges avec le noyau ou l'utilisation d'une application tierce avec le noyau, donc empêcher les connexions root n'aurait rien changé.

La distribution basée sur Debian a déjà fait le changement alors que la distribution basée sur RedHat le suggère (si vous lisez leurs documents de bonnes pratiques)


1

Eh bien, car root est un utilisateur valide et sshd le fait en le permettant. Sur OpenBSD (les mêmes gars d'OpenSSH), par exemple, vous n'êtes pas invité à créer un utilisateur lors de l'installation, vous devez donc utiliser root pour accéder à votre box.

Certaines distributions basées sur le bureau vous obligent à créer des utilisateurs supplémentaires, mais pour les serveurs, vous n'en avez réellement pas besoin.

De plus, ces arguments selon lesquels sudo ou su sont plus sûrs que la connexion en tant que root est un grand mythe. Sur Ubuntu, par exemple, l'utilisateur peut exécuter N'IMPORTE QUELLE commande en utilisant sudo par défaut, donc tout attaquant qui entre peut également exécuter N'IMPORTE QUELLE commande en tant que root. Assez inutile du point de vue de la sécurité.


d'un autre côté, un attaquant devrait deviner à la fois le nom d'utilisateur et le mot de passe, par opposition à simplement forcer brutalement le mot de passe. Je noterais également que sudo est limité aux personnes du fichier sudoers - donc ce n'est que le premier utilisateur dans la plupart des cas
Journeyman Geek

0

C'est à peu près spécifique à la distribution. Certains le permettent, d'autres non.

Si je gérais une distribution, je configurerais le système pour qu'il soit aussi durci que possible lors de l'installation. Il vaut mieux oublier d'activer certaines fonctionnalités que d'oublier de désactiver certaines faeture.


Renforcer le système autant que possible devient difficile si vous essayez également d'utiliser votre système sur le bureau par de nombreux utilisateurs finaux. Vous devez compromettre et durcir le système juste assez pour protéger les utilisateurs dans le cas par défaut, mais permettre aux utilisateurs avancés de modifier le système pour répondre à leurs besoins.
Zoredache
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.