salut,
disclaimer avant de continuer:
j'espère que tu as conscience que je ne suis pas un spécialiste en
sécurité. j'ai simplement proposé une stratégie (que j'applique avec bob)
que je trouve etre un bon compromis entre facilité d'usage et réduction
de la surface d'attaque.
je pense que je le simple fait de ne pas exposer un port ssh va
déjà te mettre à l'abris de plein de script kiddies qui veulent juste
de nouveaux zombies pour leurs botnets et je fais confiance
a bob pour la securité de l'accès physique à son portable.
On Sat, Aug 30, 2025 at 12:13:54PM +0200, hamster wrote:
> > il y a donc une idée d'ubunutu qui aura été bonne.
> La il faut que tu détaille. En quoi c’est une bonne idée de pas avoir de
> compte root et de travailler systématiquement avec un compte sudoer?
il existe un compte root et sudo permet de travailler avec un autre uid.
par défaut: celui du root (0).
$ id root
uid=0(root) gid=0(root) groups=0(root)
le fait de ne pas se connecter directement en root (tout ayant la
possibilité d'executer facilement des commandes en temps que root avec
doas) permet au moins 2 choses:
* ca t'évite de passer du temps avec un shell root ce qui est tjrs
dangeureux (parce que les fauses manips coutent bien plus cher en root)
* ca permet de loguer quel compte a fait un acces root. en cas de fausse
manip, je sais qui chercher.
> le choix d’ubuntu mais j’en ai jamais compris l’interet, alors si tu peux
> m’expliquer je suis preneur.
le choix d'ubuntu c'est de mettre le compte que tu crées lors de
l'install directement en sudoer (enfin c'est ce que j'ai compris en te
lisant) et je trouve que c'est une bonne chose parce que ca évite que
les gens ouvrent une session graphique en root pour administrer leur
machine.
> L’inconvénient que j’y vois c’est le cas ou bob autorise un ami de passage a
> utiliser son ordi. Si l’écran est vérrouillé, l’ami va dire "il me demande
> un mot de passe" et en général bob va le lui dire pour qu’il puisse utiliser
> l’ordi.
alors je ne peux plus rien pour bob ... si bob n'en a rien a foutre de
la secu, autant le dire tout de suite mais qu'il ne vienne pas se
plaindre apres.
> En faisant ca, bob ne se rend pas compte qu’il viens de donner son
> mot de passe sudoer.
ah ben non! il faut avoir briefé bob sur le fait qu'on ne communique
jamais son mdp (ou alors on le change direct derrière).
> Le fait d’avoir deux comptes séparés, un pour l’utilisation, un pour
> l’administration, ca permet d’avoir 2 mots de passe différents.
ca rend la vie de bob plus chiante et c'est comme ca qu'il jette
l'éponge avec la secu. dans les scenarii d'attaque de bob qui soient
crédibles, tout ce qu'on a déjà évoqué comme mesure de secu offre déjà
pas mal de protection. tu peux ajouter du nftables.
> > * de lui expliquer pourquoi les 2 autres commandes sont problematiques à
> > mes yeux
>
> Et ben moi ca m’interesse. Est-ce que tu peux développer ?
* su c'est mal parceque tu communiques le mdp root a l'utilisateur
* sudo c'est trop gros et trop compliqué a securiser (j'ai pris
conscience du truc en faisant un challenge de securité genre root-me
ou l'idée était de réussir a contourner une configuration sudo).
du coup doas c'est plus petit, la configuration est bien plus simple
donc le man bien plus clair. et puis comme ca j'ai la meme commande sous
linux et openbsd (j'utilise les outils openbsd des que je peux à defaut
de pouvoir switcher totalement)
> > > que ca le gonfle d’avoir a taper son mot de passe a chaque fois qu’il
> > > démarre son ordi. Et il me demande aussi de virer le verrouillage
> > > automatique quand l’écran se met en veille pour la meme raison.
> >
> > alors je dis "amen mais viens pas te plaindre le jour ou tu te fais
> > pourrir".
>
> Et ben la aussi je veux bien que tu développe. Je ne me suis jamais fait
> pourrir
* si ton pirate est malain et que son but est de récuperer ta machine dans
son botnet, tu ne sauras pas qu'il est rentré.
* comme je disais: je pense que le niveau de securité evoqué ici est
bien suffisant pour protéger l'ordi de bob si bob joue le jeu
* je ne suis pas un expert en securité par contre je me suis rendu
compte qu'ils appliquent la meme methode que nous:
* ils envisagent des scenarii d'attaque
* ils proposent une stratégie qui rend ces script inoppérants
* sachant que
* ssh est le point d'entrée de tous mes services (forwarding
de port si besoin), que pas de root et pas de mot de passe possible
depuis ce canal
* je fais confiance à l'équipe de securité de debian pour avoir des
paquets à jour des CVE
je crois que mon système est résistant à 99% des attaques opportunes
* je ne crois pas que qq1 en veuille à ce point à la machine de bob pour
qu'il envisage une attaque ciblée mais peut-etre que bob a oublié de
me parler de ses centrifugeuses.
> J’ai bien remarqué que les mots de passe au démarrage et au dévérouillage
> sont systématiquement les réglages par defaut dans toutes les distribs mais
> j’ai jamais compris pourquoi, alors si tu peux m’expliquer ca m’interesse.
tout dépend du niveau de confiance que tu accordes aux gens autour de
toi et dans quel contexte tu utilises l'ordi. typiquement un autologin
sur une station de travail à la maison (si j'ai quand meme la
possibilité de me reconnecter en temps que "invité"), ca me va.
par contre pour un laptop ou une machine qui peut etre accessible par
des gens que je connais pas bien (genre une machine dans le salon et
des soirées ou tu connais pas tout le monde), ca te permet de te
protéger de fausse manip.
> Je suis loin d’etre un expert en sécurité, mais il me semble avoir compris
> qu’il y a d’autres moyen que ssh pour arriver a rooter un ordi.
peut être mais pas chez moi :)
j'insiste: aucune règle n'est universelle en secu et il faut que tu
construises ta securité en fonction des scenarii d'attaque.
> Et que si un
> attaquant arrive a passer, fut-ce par un moyen détourné (pièce jointe dans
> un mail, javascript exploitant une faille du navigateur dans une page web,
> etc…), un mot de passe root solide est le meilleur rempart.
ton navigateur ou ton client mail a les memes droits que tous tes autres
programmes donc il peut faire un doas et passer root. c'est vrai.
du coup je vais enlever le nopass chez les bobs et voir si on peut
bloquer le nombre de tentatives de doas.
> J’ai jamais vu un bob a qui j’installe prendre la peine de fermer sa session
> et ouvrir la session invité pour laisser un pote de passage faire une
oui ... c'est comme ca que ma cousine a laissé ses accès à tous ses
réseaux sociaux sur la machine de bob. j'ai bien rigolé en lui
pourrissant sa timeline.
bob apprend de ses erreurs.
> ordi. D’ailleurs le fait d’etre dans une session invité poserait problème
> pour accéder a la vidéo.
ah ? pourquoi ?
> Il y a aussi un bon nombre de bob a qui j’installe pour qui si j’avais a
> leur expliquer ca… houla rien que pour leur faire comprendre c’est la
> galère.
là encore: y'a pas de modèle universel. fais au mieux.
merci de m'avoir fait réaliser que bob utilise thunderbird et est
peut-etre moins regardant que moi à l'ouverture des pj. le nopass va dégager
pour sur (pas génant puisque pas souvent utilisé) et pour le mdp je
commence à me poser la question.
a+
--
Marc Chantreux
Attachment:
signature.asc
Description: PGP signature