On m'a dit que c'est une pratique courante de créer un nouvel utilisateur avec des privilèges sudo et de désactiver l'utilisateur root. Quels risques cela permet-il d'atténuer ?
Réponses
Trop de publicités?
L'un des avantages de la désactivation de l'utilisateur root et de la création d'un utilisateur non root capable d'utiliser les fonctions suivantes sudo protège votre serveur contre les attaques par force brute qui tentent de deviner votre mot de passe "root".
Comme Rinzwind l'a dit, lequel des deux est le plus sûr ?
- Compte racine + mot de passe difficile à deviner
- Un nom d'utilisateur personnalisé + un mot de passe difficile à deviner
L'autre avantage, plus important, est que lorsque vous n'avez qu'un seul utilisateur root, tout ce que vous exécutez est exécuté avec le pouvoir de "root" qui a accès à tout, de sorte que l'exécution d'une mauvaise commande ou une simple erreur peut potentiellement détruire votre serveur.
En créant simplement un utilisateur non root :
- Vous ne donnez pas votre mot de passe root !
- Vous êtes en mesure de définir qui peut faire quoi !
- Vous pouvez vérifier qui a fait quoi !
- Vous minimisez la possibilité d'exécuter une commande erronée ou dangereuse avec un accès root.
N'oubliez pas non plus que si quelqu'un a un accès physique au serveur, il peut y faire presque tout ce qu'il veut, à moins que tout soit crypté sur ce serveur.
Yudhistre
Points
107
En plus des préoccupations valables mentionnées dans La réponse de @Ravexina je pense qu'il est important de le noter :
Se connecter à votre serveur n'est pas le seul moyen pour un acteur malveillant d'effectuer des actions.
En fait, une attaque par force brute réussie sur SSH est probablement la le moins probable façon dont un hacker pourrait entrer dans votre serveur. SSH se met en veille pendant 3 secondes lorsqu'un mot de passe invalide est saisi. Il est donc pratiquement impossible de forcer un mot de passe SSH fort à distance.
Il est plus probable qu'ils trouvent une vulnérabilité d'exécution de code à distance et qu'ils s'introduisent de cette façon. Si quand vous voulez qu'ils aient le moins de permission possible. Vous vraiment ne veulent pas qu'ils soient root .
Vous voyez, lorsque vous exécutez un programme, comme Apache, PHP, ou un script de PHP/Python/NodeJS, ou même votre navigateur web : ce "processus" doit aussi s'exécuter en tant qu'utilisateur. Par exemple : Si vous exécutez un script PHP en tant que root alors ce processus PHP peut faire n'importe quoi root peut faire.
Disons, par exemple, qu'un acteur malveillant est capable de mener une attaque par "exécution de code à distance" : il peut exécuter du code sur votre serveur. Si PHP exécute ce code malveillant, et que PHP est exécuté en tant que root ce qui signifie que le code du pirate s'exécute aussi en tant que root . Mais si PHP est exécuté en tant qu'utilisateur moins privilégié (c'est-à-dire : webapp ), vous atténuez considérablement les dégâts qu'il peut causer. Cela s'applique également lorsque vous exécutez des scripts de console, et pas seulement à PHP : Chaque langage peut avoir ce problème.
La chose délicate ici est que la vulnérabilité RCE pourrait ne pas être du code. vous a écrit : il pourrait être enterré profondément dans une bibliothèque/module tiers que votre code appelle pour : calculer des dates, interagir avec une base de données, rendre du HTML, etc... En d'autres termes : Vous pourriez ne même pas savoir qu'il est là. Et il pourrait être ajouté silencieusement à votre base de code lorsque vous mettez à jour vos dépendances/bibliothèques. Comme nous l'avons vu dans le EventStream hack il peut être très facile de prendre le contrôle d'un dépôt de bibliothèques en amont et de l'utiliser pour envoyer du code malveillant à des applications en aval qui ne se doutent de rien. Si ce code malveillant s'exécute en tant que root, il peut prendre le contrôle de l'ensemble de votre serveur, et même couvrir ses traces pour que vous ne sachiez jamais que cela s'est produit.
Donc, bien que le fait d'avoir des utilisateurs séparés pour tout ne soit pas prévenir une attaque entièrement, il atténuer considérablement les dommages qui pourraient résulter d'une attaque par exécution de code à distance si elle se produit.
* Évidemment, si votre mot de passe est abc123 ne s'applique pas, car c'est probablement l'une des premières que les pirates essaieront lors du brute-forcing.
serv-inc
Points
2741
Cela dépend en fait de ce que vous faites sur votre serveur. En plus de la réponse de @Ravexina (attaque par mot de passe deviné) : Est-ce que vous, par exemple.
- accéder à certains sites web
- lire le courrier
- voir quelques photos
- lire les PDF
Tous ces éléments ont été des vecteurs d'attaque dans le passé (navigateurs sur une base régulière). Si quelqu'un a utilisé l'un de ces vecteurs, il pourrait
- (non-root) accéder et supprimer tous vos fichiers, installer des logiciels pour l'utilisateur local, etc.
- (racine) faire tout
Alors que les exploits non-root peuvent être escaladés (cf. https://superuser.com/questions/301646/linux-keylogger-without-root-or-sudo-is-it-real ), cela offre une couche supplémentaire de protection. Il protège également contre les accidents comme mentionné par @David Schwartz :
Tous ceux qui utilisent Linux depuis assez longtemps ont un jour ou l'autre entré accidentellement une commande qui, s'ils avaient été root à ce moment-là, aurait complètement détruit leur système. Mon cas le plus récent est celui où je voulais supprimer tout le contenu de mon répertoire courant et où j'ai accidentellement tapé
rm -rf . /*au lieu derm -rf ./*.
Koraktor
Points
9532
