Quelle est l'importance du mot de passe sudo?

Je sais que le mot de passe sudo protège mon ordinateur contre le piratage local par quelqu'un y ayant un accès physique ( modifier: en fait, il ne le fait pas ). Mon mot de passe est assez fort à cet effet, mais je sais qu'il n'est pas assez fort si quelqu'un peut le forcer à distance à distance.

Quelqu'un peut-il accéder à mon ordinateur en mode root en utilisant mon mot de passe sudo sans accès physique à l'ordinateur, sur une installation de bureau Ubuntu standard?

1. Si vous avez un accès au réseau, certainement oui (réponse courte)
2. Si vous ne faites pas assez attention à la sécurité, oui (réponse longue)
3. Si vous avez "ssh" en cours d'exécution et pas de 2FA , oui ( commentaires et réponses)
4. On peut accéder à votre ordinateur en tant que root sans sudo / mot de passe utilisateur

Je sais que le mot de passe sudo protège mon ordinateur contre le piratage local par une personne y ayant un accès physique.

Je ne veux pas vous faire trop peur, mais si quelqu'un a un accès physique, vous lui avez donné accès, quelle que soit la force de votre mot de passe. Il faudra 1 redémarrage par quelqu'un pour que cette personne puisse changer votre mot de passe root (peut être fait à partir de "grub rescue" sans avoir à fournir votre mot de passe actuel). Soit dit en passant: cette méthode est considérée comme valide et une fonctionnalité, et un risque de sécurité accepté (sinon vous ne seriez jamais en mesure de réparer votre système au cas où le mot de passe serait compromis).

mais je sais que ce n'est pas assez fort si quelqu'un peut le forcer à distance à distance.

Voici quelque chose d'autre en jeu: un ROUTEUR doit être suffisamment intelligent pour verrouiller l'accès de l'extérieur s'il s'agit d'une demande répétée demandant les mêmes informations sur une courte période de temps. Fondamentalement, ce que vous avez ici est une attaque DOS (ou un DDOS si 2+ ordinateurs vous attaquent). Un routeur doit supprimer cette connexion et appliquer une période d'attente avant d'accepter de nouvelles demandes de cette connexion.

Quelqu'un peut-il accéder à mon ordinateur en mode root en utilisant mon mot de passe sudo sans accès physique à l'ordinateur, sur une installation de bureau Ubuntu standard?

Ils doivent d'abord se connecter, puis fournir le mot de passe sudo. le mode "root" est désactivé et vous ne pouvez pas vous connecter directement à une invite "#".

Notez qu'il est possible d'abuser d'un service. Si vous avez "ssh" en cours d'exécution sur cette machine et qu'ils peuvent "ssh" sur votre système, et obtenir un coup de main sur votre nom d'utilisateur et mot de passe pour cet utilisateur (et comme c'est un utilisateur administrateur votre mot de passe sudo aussi), ils peuvent accéder à votre machine et gâcher. Soit dit en passant: s'ils le font comme ça, ils doivent d'abord connaître votre système (comme votre mot de passe).

Mais il y a ensuite un problème avec cela (et toute autre méthode): comment ont-ils obtenu votre mot de passe? Ils ne peuvent PAS l'obtenir de votre système lui-même. Et en général, deviner ne vaut pas la peine. S'il a été conçu socialement ... alors votre problème est là, pas avec le modèle de sécurité de votre système, Ubuntu ou Linux en général.

Tant que votre mot de passe sudo est le vôtre, tout ira bien. Et vous serez encore mieux si c'est un mot de passe fort (peut-être facile à retenir pour vous mais pas devinable par les autres). Un exemple que j'ai utilisé auparavant lorsque j'en ai discuté: Si votre chien est nommé "Abwegwfkwefkwe" en utilisant "Abwegwfkwefkwe" comme mot de passe, c'est MAUVAIS même s'il a l'air bien (car quelqu'un pourrait vous demander: "quel est le nom de votre chien" et ils essaient cela comme une estimation gratuite). Si vous n'avez aucun lien avec "Abwegwfkwefkwe", c'est un bon mot de passe.

Le meilleur conseil que je puisse donner:

• n'entrez pas votre mot de passe administrateur lorsque vous le demandez, sauf si vous savez qu'il devait être demandé. Si vous ouvrez un navigateur et que vous recevez une fenêtre contextuelle qui ressemble à notre "demande de mot de passe de compte administrateur" ... arrêtez ... et réfléchissez d'abord.

• ne laissez pas votre système sans surveillance lorsque la période de grâce "sudo" est active. sudo --reset-timestampsupprime la période de grâce actuelle et demandera à nouveau le mot de passe lors de la prochaine utilisation de "sudo". Verrouillez votre écran lorsque vous allez AFK.

• n'installez pas de services ou de logiciels pour le plaisir. Si vous n'avez pas besoin de sshne pas installer ssh, si vous n'utilisez pas de serveur Web, n'installez pas de serveur Web. Et jetez un œil aux services en cours d'exécution. Si vous n'utilisez pas BT sur un ordinateur portable, désactivez-le. Si vous n'utilisez pas de webcam, désactivez-la (si elle est active). Supprimez les logiciels que vous n'utilisez plus.

• et pour les vraiment paranoïaques (et oui Paranoid Panda je vous regarde): changez le mot de passe de temps en temps. Vous pouvez même installer des chasseurs de rootkit pour vérifier un accès inapproprié.

• sauvegarder vos données importantes sur quelque chose que vous gardez hors ligne. Donc, même si vous trouvez quelqu'un sur votre système, vous pouvez le formater et recommencer avec une nouvelle installation et vos données restaurées.

Oui, ils peuvent.

Il existe cependant plusieurs façons de le faire, et le forçage brutal du sudomot de passe n'est probablement pas le premier.

Tout d'abord, le sudomot de passe est le mot de passe de votre utilisateur; Donc, ce dont ils auraient besoin, c'est de votre mot de passe.

Deuxièmement, déchiffrer le mot de passe d'un utilisateur en utilisant la force brute pour accéder à un système est probablement le dernier recours.

Il existe des moyens beaucoup plus élégants (mais surtout plus efficaces) de pénétrer dans un autre système.

En règle générale, un attaquant ira simplement et tentera d'exploiter les vulnérabilités les plus courantes (la plus connue étant probablement d'obtenir un shell utilisateur par tous les moyens et d'exploiter un ShellShock pour obtenir un shell racine) ou de faire un excellent travail dans le sens de:

• Analyse des ports ouverts sur le système afin d'obtenir des informations telles que:
  • Version du système d'exploitation
  • Exécution de la version des services
• Exploiter un système d'exploitation connu ou exécuter des bugs de services (débordements de buffer, ...) afin d'obtenir au moins un shell utilisateur puis essayer d'obtenir un shell root (là encore, peut-être en exploitant un ShellShock)

Le forçage sudobrutal du mot de passe / user peut être une tentative dans le cas où un shell root ne peut pas être obtenu autrement, mais par exemple, l'exploitation d'un service exécuté en tant que root ne nécessitera pas que l'attaquant force par force le sudomot de passe / user.

1. Si j'ai appris quelque chose au cours des dernières années sur la sécurité, alors une chose: rien n'est impossible .

2. Tant que vous avez accès à un réseau, certainement. Chaque service exécuté sur votre système et accessible via le réseau est théoriquement vulnérable et donc une faiblesse potentielle.

Et donc, pour un attaquant avec assez d'idées c'est possible. Vous pouvez rendre votre système aussi sûr que possible, mais vous ne pouvez jamais atteindre une sécurité à 100%.

Il est donc important d'évaluer ce qui est possible avec un effort technique justifiable et ce qui vous protège si bien que vous ne pouvez plus travailler vous-même.

Je sais que le mot de passe sudo protège mon ordinateur contre le piratage local par quelqu'un qui y a un accès physique (modifier: en fait, ce n'est pas le cas). Mon mot de passe est assez fort à cet effet, mais je sais qu'il n'est pas assez fort si quelqu'un peut le forcer à distance à distance. Quelqu'un peut-il accéder à mon ordinateur en mode root en utilisant mon mot de passe sudo sans accès physique à l'ordinateur, sur une installation de bureau Ubuntu standard?

Le mot de passe sudo n'est pas uniquement destiné à la protection locale, son but est d'ajouter une couche de sécurité supplémentaire à l'utilisation des privilèges root. Une bonne discussion peut être trouvée ici /superuser//a/771523/467316

Votre mot de passe n'est peut-être pas aussi fort que vous le pensez. En ce moment, je craque 20 à 40% des hachages Active Directory de mon client pour ceux que j'ai vus auparavant, ceux qui ont de mauvaises règles de mot de passe sont craqués à 70%. Je recommande des mots de passe complexes à 16 caractères. Les cartes graphiques oclHashcat et Radeon peuvent faire beaucoup de dégâts. Ajoutez tous les vidages de mot de passe de chaque violation au cours des 5 dernières années et vous avez tendance à obtenir un bon dictionnaire à partir duquel travailler.

Si vous utilisez SSH, faites des ajustements dans sshd_config

sudo nano /etc/ssh/sshd_config

Les MUSTS dès la sortie du portail (le dernier pour désactiver le serveur ftp si vous ne l'utilisez pas).

Protocol 2
X11Forwarding no
PermitEmptyPasswords no
MaxAuthTries 5
#Subsystem sftp /usr/lib/openssh/sftp-server

Enregistrez-le, redémarrez ssh

sudo service ssh restart

Utiliser le chiffrement par clé publique Commencez par créer vous-même une clé sur votre machine distante (en utilisant puttygen ou la saveur de votre système d'exploitation disponible). Copiez la clé publique sur votre machine Ubuntu sous l'utilisateur que vous souhaitez vous connecter en tant que fichier authorized_keys (vous devrez probablement le créer)

sudo nano /home/yourdumbusername/.ssh/authorized_keys

copier la clé publique dans ce format

ssh-rsa 23r0jfjlawjf342rffjfa89pwfj8ewfew98pfrfj8428pfwa9fupfwfcajwfpawf8rfapfj9pf892jpfjpwafj8a where-ever-you-have-your-private-key-for-your-own-notes

enregistrez-le et configurez votre sshd_config pour autoriser la connexion par clé publique

sudo nano /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

enregistrer et redémarrer ssh

sudo service ssh restart

Essayez SSHing sur votre hôte ubuntu à partir de votre ordinateur à clé privée à l'aide du chiffrement à clé publique. Si tout s'est bien passé, revenez à l'hôte ubuntu et désactivez l'authentification par mot de passe.

sudo nano /etc/ssh/sshd_config

PasswordAuthentication no

Enregistrez et redémarrez ssh

sudo service ssh restart

Essayez à nouveau de sshing depuis un ordinateur à clé privée pour confirmer.

Voulez-vous en ajouter davantage? configurez un compte non privilégié, désactivez PermitRootLogin, redémarrez ssh, ajoutez votre clé publique aux clés autorisées du nouveau compte, connectez-vous en tant que compte non privilégié, accédez à votre compte racine ou privilégié lorsque vous devez rooter ou privilégier votre chemin à travers les choses.

Le but de sudo n'est pas lié au mot de passe mais à la place de donner à certains utilisateurs des capacités de root tout en restreignant les autres sur une machine sans les obliger à présenter la connexion root (mot de passe / clé / jeton de sécurité / etc). Par exemple, dans mon travail, les employés au quotidien peuvent uniquement démarrer / arrêter / installer et mettre à niveau leurs stations (à partir d'un référentiel avec droit de veto) via sudo. On ne leur donne pas les autres libertés root telles que supprimer / formater délibérément des périphériques, ajouter et supprimer des utilisateurs, décider quels modules du noyau doivent être mis sur liste noire ou ce qui fonctionne dans crontab (etc, etc, etc). Alors que chez vous, votre sudo permet un accès complet à la machine. En ce qui concerne le mot de passe, c'est en réalité le mot de passe de votre compte utilisateur que sudo requiert (le même que celui que vous utiliseriez pour vous connecter, si la connexion automatique n'est pas activée.

Mauvaise astuce : si vous voulez faire de root un compte régulier sur unix activé sudo (linux / apple osx) exécutez ce qui suit

sudo -s
passwd
Enter your unix password:

À ce stade, root a un mot de passe normal, et vous pouvez simplement vous déconnecter et vous connecter en tant que root avec le mot de passe mentionné de la manière "à l'ancienne".

En ce qui concerne la sécurité, si un programme (par exemple, serveur Web, mysql, démon php, sshd) s'exécute en tant que compte élevé ... par exemple, root et a un exploit connu, les attaquants pourraient ne pas avoir besoin d'informations d'identification de sécurité pour y accéder. Ils peuvent utiliser la vulnérabilité du programme et générer simplement un nouveau shell à partir de ce programme en cours d'exécution en tant que root. Cependant, cela est assez rare car les gestionnaires de distribution sont conscients de problèmes similaires et font un travail remarquable pour créer un environnement par défaut bien pensé et généralement sûr.

Dans l' autre système d'exploitation, une opération similaire à sudo serait un clic droit et s'exécuterait en tant qu'administrateur système (ou le harcèlement des privilèges UAC).