La désactivation de la connexion root améliore-t-elle la sécurité?

J'ai récemment trouvé un argument contre la désactivation d'une connexion utilisateur root sous Linux sur http://archives.neohapsis.com/archives/openbsd/2005-03/2878.html

Je suppose que si tout le monde utilise une authentification par clé publique, il n'y a aucun risque de perdre le mot de passe root.

Est-il toujours préférable de désactiver la connexion root via ssh?

La réponse courte est que plus votre profil d'attaque est petit, mieux c'est. Toujours. Si vous n'en avez pas besoin ou pouvez utiliser une alternative telle que sudo ou su, alors n'activez pas la connexion root.

Un gros argument en faveur de la désactivation de root et de l'utilisation de sudo / su est que vous pouvez suivre qui fait quoi. Un utilisateur - une connexion. Ne partagez jamais de comptes.

L'argument sur ce lien semble être spécifique à la connexion locale, plutôt qu'à ssh.

J'appuie le deuxième point de Dennis, plus:

Autoriser la connexion root via SSH signifie également que root est attaquable par des suppositions de mot de passe par force brute.

Parce que root est toujours là et que la récompense est si élevée, c'est un objectif prioritaire. Le nom d'utilisateur devrait être deviné en premier, ce qui ajoute quelques ordres de grandeur à la difficulté du problème.

Ne désactivez jamais le compte root si vous n'avez pas accès à la console. Si votre système de fichiers se remplit et que le démarrage échoue pendant la création de / etc / nologin, seul le compte root sera autorisé à se connecter à la machine.

Cela dit, si vous avez accès à la console pour faire face à ces situations, la fermeture du compte root peut vous faire économiser des maux de tête, car personne ne pourra accéder au compte root en utilisant une attaque par dictionnaire (mon expérience est que ce sont constants de nos jours - quelqu'un essaie toujours). D'autres choses que vous pourriez penser à faire:

• Installez un programme comme fail2ban qui ferme automatiquement l'accès à une adresse IP s'il échoue plusieurs fois à l'authentification (pour se protéger activement contre les attaques par dictionnaire).
• Utilisez uniquement les clés ssh.
• Si vous gérez un grand nombre de machines, utilisez cfengine ou autre pour gérer les clés publiques que vous autorisez à entrer dans une machine (ou bien vous les récupérez assez rapidement).

Cordialement,
João Miguel Neves

Il est toujours préférable de désactiver la connexion root via SSH.

Il existe des systèmes PKI (par exemple, des clés publiques avec SSH) qui ont été compromis. SSH a déjà eu des failles d'authentification à distance auparavant qui ont permis à un compromis racine de se produire. Les PKI logicielles sont notoirement plus faibles que les PKI basées sur le matériel .... si votre ordinateur hôte est compromis, le serveur cible pourrait également tomber facilement. Ou il pourrait y avoir de nouvelles failles trouvées dans SSH. En limitant la connexion root, vous pouvez également prolonger la période de temps dont un attaquant a besoin pour effectuer une élévation de privilèges.

Historiquement, de nombreux administrateurs utilisaient des hôtes bastion (essentiellement des passerelles) pour entrer dans un réseau, puis passer aux boîtes par la suite. L'utilisation d'une distribution hautement sécurisée (par exemple OpenBSD) comme hôte bastion, en conjonction avec différents systèmes d'exploitation, offre une défense en profondeur et une défense en diversité (une vulnérabilité moins susceptible de compromettre l'ensemble du réseau).

Veuillez également envisager une connexion hors bande à votre réseau, comme un concentrateur série, un commutateur série ou autre. Cela fournira une disponibilité de sauvegarde de votre interface d'administration si nécessaire.

Parce que je suis paranoïaque et en sécurité, je serais plus susceptible d'utiliser un VPN IPSEC ou un VPN de type 1, puis d'exécuter SSH par-dessus, sans aucune exposition Internet de SSH. Mettre le VPN sur votre matériel réseau peut considérablement simplifier cela dans la mise en œuvre.

Nous devons examiner cette question sous différents points.

Ubuntu désactive le compte root par défaut, ce qui signifie que vous ne pouvez pas vous connecter via SSH avec root. Mais, il permet à toute personne disposant d'un CD Ubuntu de démarrer et d'obtenir un accès root.

Je crois que le meilleur compromis est d'activer le compte root avec un accès SSH désactivé. Si vous avez besoin d'un accès root avec SSH, connectez-vous avec un utilisateur normal et utilisez sudo. De cette façon, il sécurise l'accès au boîtier, sans compromettre la sécurité à distance.

Je dirais que oui, la connexion en tant que root doit être désactivée pour l'auditabilité. Si vous êtes le seul administrateur système sur cette machine, il est trivial de déterminer qui a fait quoi à qui, mais si dix personnes sont autorisées à administrer la boîte et qu'elles connaissent toutes le mot de passe root, nous avons un problème.

Que root soit activé ou non, ni root ni aucun autre utilisateur ne doit être autorisé à se connecter à distance avec un mot de passe. fail2ban ne fera rien contre un botnet lent à force brute et ne fonctionne pas du tout avec IPv6. (La version 1 du protocole ssh et les anciennes implémentations de la version 2 étaient vulnérables aux attaques par devinement de mot de passe contre les invites de mot de passe interactives au cours de la session ssh, mais cela ne semble plus être le cas avec une implémentation ssh suffisamment récente.)