Forum général.général Vive la paranoïa

Posté par .
Tags : aucun
0
12
nov.
2004
Bonjour les gens,

J'ai une légère tendance à la paranoïa et je me demandais comment embêter
encore plus les méchant qui voudraient m'embêter.

Je trouve que la technique OSX de ne pas avoir de compte root valide est pas
mal à condition de créer deux comptes. Un compte qui sert pour l'administration
qui est sudoer et un autre pour le reste. De cette façon, il est plus difficile de
deviner le nom de l'admin. Mais je trouve qu'on pourrait aller beaucoup plus loin.
Une machine de bureau n'a pas pour vocation d'être allumée en permanence.
De plus, l'installation de certains programmes (typiquement une mise à jour du
noyau) nécessite un reboot. Donc, pourquoi ne pas imposer que les partitions
où se trouvent les « binaires » (/bin, /lib, /boot, /usr...) soient en lecture seule.
Il existe, si je me souviens bien, des mécanismes pour que le noyau puisse
perdre définitivement certains droits. De cette façon, l'installation d'un root-kit
devient plus difficile.
Pour installer un programme, on le placerait dans un répertoire /to_install
et au boot, avant de configurer quoi que ce soit (en single user mode) si le-dit
répertoire n'est pas vide, on passe en mode install. Là, la machine demande le
mot de passe de l'administrateur et vérifie si les logiciels qui vont être installés
doivent bien l'être (vous êtes sûr de vouloir installer un programme qui n'est
pas authentifié ou dont la clef n'est pas valide?). Une fois l'installation finie,
on finit de booter.
Au début, c'est un brin lourd mais assez vite, on a tous les programmes dont
on a besoin et le fait qu'installer le moindre petit programme prenne 5 minutes
va décourager l'installation intempestive de programmes débiles et donc
éviter l'installation de spyware et autres virus.

Ceci ne protège pas du virus de macro qui écrase /etc ou qui écrase /home
mais cela protège de beaucoup de choses sans être monstrueusement
contraignant.

Quoi que vous en pensez les gens?
  • # Redémarrer à chaque make install???

    Posté par . Évalué à 3.

    Si j'ai bien compris, il faut redémarrer ma machine à chaque make install......

    Tu es tombé sur la tête???
    • [^] # Re: Redémarrer à chaque make install???

      Posté par . Évalué à 2.

      Euh oui je suis d'accord avec Pascal ........

      A moins que ne soit admin est que les postes aient un nombre limité de logiciels à installer .... et surtout de cette liste de logi ne varie pas ...

      D'autre part pour les mises à jour c'est galere et la meilleur façon de se proteger est encore de faire les maj et d'avoir un bon pare feu dédié sous linux genre ipcop ou smoothwall...
      • [^] # Re: Redémarrer à chaque make install???

        Posté par . Évalué à 2.

        Il faut voir de quoi on parle. Je ne parle pas d'un serveur qui ne doit jamais
        rebooter.

        Pour la machine de beau papa qui installe 2 programmes par an et qui éteind
        religieusement sa machine tout les soirs, ce n'est pas deux reboots de plus qui
        vont l'embêter. Or, il est important de sécuriser aussi la machine de beau papa.

        L'administrateur qui gère 3000 machines ne va pas s'amuser à changer la
        configuration des 3000 machines tous les jours. Il va se contenter de faire les
        mises à jours de sécurité (ce qui demande déjà pas mal de boulot) et il va
        administrer son réseau. S'il n'est pas con, il va aussi s'arranger pour avoir le
        moins de boulot possible. Il ne va donc pas installer apache sur la machine d'une
        secrétaire. Idéalement, il y aura un gros serveur d'application avec des clients
        légés. Dans ces deux cas, l'immense majorité des machines n'auront que peu
        de programmes différents d'installés et donc le nombre de mises à jours de
        sécurité sera faible (en 2004, il y a eu 9 security/advisories pour netBSD dont
        une pour ftpd, une pour CVS, une pour un serveur racoon et une pour un
        problème IPv6).

        Ceci dit, même si notre administrateur doit installer tous les jours une mise à
        jour de tous les programmes de toutes les machines, ce n'est pas génant pour
        autant. Un sysème de mise à jour classique commence par:
        1 récupérer tous les fichiers d'install dans un endroit particulier
        (/var/cache/apt/archives sous debian);
        2 il fait l'install.

        Si on place un reboot entre 1 et 2, je ne vois pas le problème. Biensûr, l'admin
        peut vouloir avoir un minimum d'accès réseau pendant la phase d'install. À la
        limite pourquoi pas. Il place des règles iptables (ou autres) super violentes qui
        interdisent tout sauf un accès très contrôlé depuis un endroit précis et ces
        règles sont relachées après que le système ait perdu les droits d'écriture sur
        les binaires. C'est pas plus long.
  • # Root non valide

    Posté par . Évalué à 1.

    Je trouve l'idee du root invalide assez interessante, est ce que c'est possible a faire sous Linux (ou GNU/Linux comme debatu sur un certain troll caché dans DLFP) ?
    En gros, je pense voir comment creer un autre admin avec les sudo, mais comment enlever tous les pouvoirs de root ? (c'est ptet tout bonnement impossible avec l'architecture actuelle...) des idees ?
    • [^] # Re: Root non valide

      Posté par . Évalué à 2.

      Je ne sais pas comment il faut faire mais la distribution Ubuntu le fait.
      A l'usage c'est très pratique.

      BeOS le faisait il y a 20 ans !

    • [^] # Re: Root non valide

      Posté par . Évalué à 4.

      root, ce n'est personne d'autre que l'utilisateur d'UID 0.

      Rien ne t'empêche de renommer root en zorglub. Globalement, ça marchera pareil
      sauf que certains programmes ont "root" codé en dur.

      Ensuite, la méthode OSX est de déactiver le passwd root et de mettre un
      utilisateur "admin" en sudoer. Par exemle le fichier sudoers suivant donne tous
      les droits à zorglub. La dernière ligne est faire pour qu'il faille TOUJOURS donner
      le passwd.

      User_Alias ADMIN = zorglub
      ADMIN ALL= PASSWD: ALL
      Defaults timestamp_timeout=0

      Ensuite, on utilise un utilisateur normal pour l'utilisation normale.
    • [^] # Re: Root non valide

      Posté par (page perso) . Évalué à 3.

      Pour empécher root de se logguer, suffit de lui donner un mdp invalide. Genre dans /etc/shadow: root:!:12687:0:99999:7:::

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Root non valide

        Posté par . Évalué à 1.

        Ok mais quand même; il vaut mieux eviter d'éditer les etc/passwd et autres etc/shadow a la main, c'est prendre de gros risques pour rien...passwd -l et autres usermod et chsh sont la pour ca !
        • [^] # Re: Root non valide

          Posté par (page perso) . Évalué à 1.

          J'avais complétement oublié le passwd -l

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Quelle solution coup de poing !

    Posté par (page perso) . Évalué à 2.

    Bonjour tous,

    Personnellement, je pense que pour sécuriser le poste de beau-papa, il faudrait, avant de prendre toutes ces mesures, demander à beau-papa de choisir un mot de passe différent de sa date de naissance / nom du chien / nom des enfants... et de même (voire plus) pour le compte root.

    Ensuite, bien vérifier que le PC de beau-papa n'a pas de serveurs qui tournent pour l'exterieur (a moins que ce ne soit indispensable!), et de bien blinder la connexion réseau.

    Si tous les utilisateurs agissaient avec ce minimum de bon sens, on éviterait bien des problèmes. J'ai travaillé dans une entreprise ou un utilisateur sur deux avait noté son mot de passe sous son clavier ou sur le pot de fleur, alors dans ces conditions, a quoi ca sert d'avoir la parition X en lecture seule?

    Maintenant, c'est vrai que changer le nom de root, c'est une sécurité en plus. De toute manière, moi, sous Gentoo, je ne peux pas mettre les partitions système en read-only, emerge aimerait sûrment pas!

    ABE, salut!

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.