1 votes

Quels utilisateurs devraient avoir accès à sudo (node, php, ftp...) ?

Avant de commencer, n'hésitez pas à suggérer un meilleur titre pour cette question.

Je me suis inscrit sur Digitalocean et j'ai installé une pile LEMP. C'est la première fois que je configure un serveur à partir de zéro. Même si j'ai choisi l'option LEMP, je veux aussi héberger des applications de nœuds.

Ma principale préoccupation est que je ne sais pas quels utilisateurs je dois créer, et lesquels doivent avoir des privilèges d'administrateur. De plus, je veux utiliser des clés SSH chaque fois que cela est possible.

  • Pour le chargement et le déchargement de fichiers, j'utilise Filezilla. Lorsque j'ai installé la pile LEMP, on m'a demandé si je souhaitais générer un mot de passe pour le compte de root ou utiliser des clés SSH. J'ai choisi la dernière option. En ce moment, je peux ssh root@domain.com et utiliser mon mot de passe SSH. J'ai installé ProFTPd et SFTP activé . /etc/proftpd/authorized_keys/root contient les clés SSH que j'utilise pour me connecter via ssh ou Filezilla, au serveur. Ni l'un ni l'autre ssh ni Filezilla ne demandent root Le mot de passe de l'entreprise.

    Comme je suis le seul à accéder par SFTP, je pense que je peux m'en sortir avec cette méthode. Si j'ai besoin de quelqu'un d'autre, je créerais un utilisateur pour lui, j'associerais ses clés SSH et lui donnerais accès à certains dossiers.

    Cela ne me pose pas de problème, mais j'ai pensé que je devais le mentionner et voir si quelqu'un pense que c'est une mauvaise pratique.

  • Je veux être capable d'exécuter des applications Node. Comme root J'ai installé node, npm et pm2 pour maintenir mes applications en vie à tout moment. Tous ces éléments se trouvent dans /usr/local/bin détenu par root:root . J'ai créé un utilisateur appelé www et comme je stocke mes applications dans /var/www , chown -R www:www /var/www . Dois-je vraiment créer www ou puis-je utiliser www-data qui est celui que Nginx utilise ?

    Jusqu'à présent, je n'ai pas vraiment besoin d'ajouter www à sudoers, jusqu'à ce que je veuille utiliser pm2 startup y npm install :

    • PM2 nécessite pm2 startup (qui génère les scripts pour exécuter PM2 après chaque démarrage du système) à utiliser par l'utilisateur qui va exécuter pm2 start (qui démarre l'application node et la surveille). Cela ne doit être fait qu'une seule fois. Cela vous donne une commande qui doit être exécutée avec sudo . Donc usermod -aG www sudo et exécuter ladite commande. Tout va bien.
    • npm install exige également sudo . Le truc avec celui-là, c'est que Je ne veux pas qu'on me demande un mot de passe. . J'essaie d'utiliser un hook Git post-receive, donc à chaque fois que je pousse vers le serveur, je veux que ceci soit exécuté ( /var/repo/nodeapp.git/hooks/post-receive ):

      #!/bin/sh
      git --work-tree=/var/www/nodeapp --git-dir=/var/repo/nodeapp.git checkout -f && cd /var/www/nodeapp && sudo npm install

      Si je le fais git push à partir de mon terminal, je n'aurais aucun problème à ce qu'on me demande un mot de passe lorsqu'il essaie de sudo npm install mais il m'arrive d'utiliser Github pour Windows/Mac et il n'y a aucun moyen pour moi de fournir ce mot de passe. Permettez-moi de noter que je configurerais les clés SSH pour me connecter en tant que www via le terminal ou l'application Github.

    J'ai d'abord pensé à mettre www comme propriétaire pour npm y pm2 car je pensais que de cette façon, on ne me demanderait pas d'exécuter la commande avec sudo . J'avais tort (j'espère que vous ne riez pas). Ensuite, j'ai pensé, puisque www est un sudoer, je pourrais rendre certaines commandes disponibles pour qu'il puisse être utilisé avec sudo. Donc je visudo et j'ai ça au milieu du fichier :

    # User privilege specification
    root    ALL=(ALL:ALL) ALL
    www     ALL=(ALL:ALL) NOPASSWD:/usr/local/bin/npm

    Ce que j'essaie de faire, c'est de "laisser l'utilisateur www utiliser sudo npm install sans que l'on vous demande un mot de passe". Est-ce la voie à suivre ? Existe-t-il un moyen de dire "ne laissez pas cet utilisateur utiliser sudo avec toute autre commande, même s'il fournit le bon mot de passe". Disons que je fais sudo rm file.txt comme www et file.txt appartient à un autre utilisateur : puis-je le désactiver ? Je veux seulement www (ou tout autre utilisateur que je crée) à pouvoir utiliser sudo avec npm .

    Jusqu'à présent, ça ne marche pas pour moi. Aussi, existe-t-il un moyen de réaliser tout cela sans ajouter de www aux sudoers ?

  • D'après ce que je comprends, je ne devrais pas laisser le root l'utilisateur se connecte via ssh . Est-ce vital ? Digitalocean ne fournit pas d'interface graphique pour configurer le serveur. ssh comme root est mon seul moyen de configurer des choses comme les paramètres de Nginx.

  • Nginx est exécuté par root pour qu'il puisse écouter le port 80, mais ensuite il sert les sites en tant qu'autre utilisateur ( www-data Je crois). Dois-je configurer quelque chose ici ? Je ne sais rien de cet utilisateur : permissions, mot de passe, clés autorisées Devrais-je configurer user www; en /etc/nginx/nginx.conf ?

    Que se passe-t-il lorsque je crée un site en utilisant PHP et qu'un visiteur accède au site ? Quel utilisateur exécute réellement les choses, www-data par défaut ?

  • Dois-je avoir un utilisateur pour mes sites PHP et un autre responsable de l'exécution de choses comme node index.js ?

  • Si je mets AllowUsers someusername anotherusername en /etc/ssh/sshd_config Est-ce que cela s'applique uniquement lorsque l'on essaie d'accéder par le biais de l'interface utilisateur ? ssh ou également lorsque j'essaie de pousser les modifications en utilisant Github pour Windows/Mac ?

  • Si je mets PasswordAuthentication no en /etc/ssh/sshd_config Quel mot de passe dois-je introduire lorsqu'une commande avec sudo me le demande ?

0voto

harisibrahimkv Points 6996

Seuls les comptes interactifs auxquels vous avez l'intention de vous connecter doivent avoir les droits sudo ou root. Le nombre de scénarios dans lesquels un service pourrait légitimement disposer des privilèges sudo ou root est extrêmement limité : sauvegardes, antivirus, prévention des intrusions dans l'hôte.

Je ne recommande pas l'utilisation de sudoers pour accorder aux comptes de service des droits d'administration restreints. Il est très difficile de contenir l'ensemble des actions autorisées. Sudoers fonctionne très bien avec des collègues raisonnables qui ne veulent pas nuire intentionnellement à votre système. Un serveur web compromis n'est pas un détenteur compétent de tels privilèges et vous voulez limiter les dommages qu'il pourrait causer.

Le risque de sécurité lié à l'autorisation de l'installation de npm par root est assez important. L'installation de npm ne nécessite pas de droits root. Cela dit, permettre à votre application web de s'auto-modifier en réponse aux demandes des utilisateurs est assez risqué, à moins d'être extrêmement prudent.

Si vous souhaitez pouvoir mettre à jour votre application Web, utilisez un service ou une tâche cron distinct(e) qui effectue cette opération, puis reconfigure et redémarre Apache. Ce service pourrait avoir les droits d'exécuter git y npm install et cela devrait être limité au niveau de l'utilisateur npm install plutôt qu'au niveau du système. Il est très probable que les privilèges suffisants soient uniquement au niveau du système de fichiers et qu'ils puissent être limités à vos dossiers d'applications, de sorte que l'utilisateur de la mise à jour puisse modifier les choses pendant que l'utilisateur de la mise à jour les modifie. www-data ne peut pas.

Les choses les plus importantes à faire pour durcir nginx sont de désactiver les modules que vous n'utilisez pas et de faire en sorte que les server_tokens affichent des informations de version moins détaillées. Il est possible de durcir beaucoup plus nginx en fonction de la sensibilité du système ou du service.

N'autorisez pas la connexion de root par SSH. Connectez-vous à votre instance en tant qu'utilisateur non root et utilisez sudo pour exécuter des commandes ou sudo su -l de s'enraciner et de le faire.

Devriez-vous avoir des utilisateurs et des privilèges distincts pour des choses différentes ? Dans l'idéal, oui. Plus vous pouvez compartimenter les composants de cette manière, plus votre système est sécurisé. Il est également plus facile d'ajouter ou de supprimer des autorisations, car chaque utilisateur a un rôle très étroitement défini dans le système avec un accès au moindre privilège.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X