Quels users devraient avoir access à sudo? (nœud, 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 stack LEMP. C'est la première fois que je configure un server à partir de zéro. Bien que j'ai choisi l'option LEMP, je souhaite également héberger des applications de nœud.

Ma principale préoccupation est que je ne suis pas sûr de ce que les users devraient créer, et ceux de ceux qui devraient avoir des privilèges administratifs. De plus, je veux countr sur les keys SSH quand c'est possible.

  • Pour download / décharger les files, j'utilise Filezilla. Lorsque j'ai installé la stack LEMP, on m'a demandé si je voulais générer un mot de passe pour la root ou utiliser des keys SSH. J'ai choisi l'option suivante. En ce moment, je peux ssh root@domain.com et j'utilise mon mot de passe SSH. ProFTPd installé et activé SFTP . /etc/proftpd/authorized_keys/root contient les keys SSH que j'utilise pour se connecter via ssh ou Filezilla au server. Ni ssh ni Filezilla ne requestnt le mot de passe de la root .

    Puisque je suis le seul à accéder via SFTP, je pense pouvoir sortir avec cette méthode. Si j'ai besoin de quelqu'un d'autre, je crée un user pour lui, associe ses keys SSH et lui donne access à certains dossiers.

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

  • Je souhaite pouvoir exécuter des applications Node. En tant que root , j'ai installé node, npm et pm2 pour garder mes applications en vie à tout moment. Tous ceux se trouvent dans /usr/local/bin appartenant à root:root . J'ai créé un user appelé www et depuis que je stocke mes applications dans /var/www , chown -R www:www /var/www . Est-ce que j'ai vraiment besoin de créer www ou est-ce que je pourrais utiliser www-data , c'est-à-dire ce que Nginx utilise?

    Jusqu'à présent, je n'ai pas vraiment besoin d'append www aux sudoers, jusqu'à ce que je voulais utiliser pm2 startup et npm install :

    • PM2 nécessite le pm2 startup (qui génère les scripts pour exécuter PM2 après chaque démarrage du système) à utiliser par l'user qui va exécuter pm2 start (qui démarre l'application nœud et le surveille). Cela ne doit être effectué qu'une seule fois. Il vous donne une command qui doit être exécutée avec sudo . Donc usermod -aG www sudo et exécuter ladite command. Tout bon.
    • npm install nécessite également du sudo . La chose à propos de cela est que je ne veux pas requestr un mot de passe . J'essaie d'utiliser un crochet Git post-receive, donc chaque fois que je /var/repo/nodeapp.git/hooks/post-receive le server, je veux que cela 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 fais git push de mon terminal, je n'aurais aucun problème à requestr un mot de passe quand il essaie de sudo npm install , mais parfois j'utilise 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 keys SSH pour me connecter en tant que www via terminal ou l'application Github.

    D'abord, j'ai pensé à configurer www user comme propriétaire pour npm et pm2 , car je pensais que je ne serais pas invité à exécuter la command avec sudo . Je me suis trompé (j'espère que vous ne rirez pas). Ensuite, j'ai pensé, puisque www est un sudoer, je pourrais mettre certaines commands disponibles pour qu'il soit utilisé avec sudo. Donc je visudo 'd et je l'ai au milieu du file:

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

    Ce que j'essaie d'atteindre c'est "laisser l'user www utiliser sudo npm install sans avoir demandé un mot de passe". Est-ce la voie à suivre? Existe-t-il un moyen de dire "ne laissez pas cet user utiliser sudo avec n'importe quelle autre command, même s'il fournit le mot de passe correct". Disons que je fais sudo rm file.txt comme www et file.txt appartient à un autre user: puis-je le désactiver? Je veux seulement que www (ou tout autre user que je crée) puisse utiliser sudo avec npm .

    Jusqu'à présent, ça ne fonctionne pas pour moi. De plus, y a-t-il un moyen de réaliser tout cela sans append www aux sudoers?

  • Dans la mesure où je comprends, je ne devrais pas laisser l'user root connecter via ssh . Est-ce une chose essentielle? Digitalocean ne fournit aucune interface graphique pour configurer le server, donc ssh ing comme root est mon seul moyen de configurer des éléments comme les parameters Nginx.

  • Nginx est exécuté par root pour pouvoir écouter le port 80, mais il sert les sites comme un autre user ( www-data je crois). Devrais-je configurer quelque chose ici? Je ne sais rien de cet user: permissions, mot de passe, keys autorisées … Devrais-je configurer l' user www; dans /etc/nginx/nginx.conf ?

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

  • Devrais-je avoir un user pour mes sites PHP et un autre chargé d'exécuter des choses comme node index.js ?

  • Si je définissais AllowUsers someusername anotherusername dans /etc/ssh/sshd_config , cela s'applique-t-il uniquement à la tentative d'access via la command ssh ou aussi lorsque j'essaie de pousser les modifications à l'aide de Github pour Windows / Mac?

  • Si je définis PasswordAuthentication no dans /etc/ssh/sshd_config , quel mot de passe est-ce que je /etc/ssh/sshd_config introduire quand on le request par une command avec sudo?

Seuls les counts interactifs auxquels vous avez l'intention de vous connecter doivent avoir des droits sudo ou root. Le nombre de scénarios où un service peut justifier des privilèges sudo ou root est extrêmement limité: sauvegardes, antivirus, prévention de l'intrusion hôte.

Je ne recommand pas d'utiliser les sudoers pour accorder aux counts de service des droits d'administrateur restreints. Il est très difficile de contenir l'set des actions admissibles. Sudoers fonctionne bien avec des collègues assez sensés qui ne veulent pas nuire intentionnellement à votre système. Un server Web compromis n'est pas un détenteur compétent de ces privilèges et vous souhaitez limiter les dégâts pouvant causer.

Le risque de security de permettre l'installation de racine npm est assez important. L'installation npm ne nécessite pas de droits racine. Cela dit, permettre à votre application Web de se modifier automatiquement en réponse aux requests des users est assez risqué, sauf si cela est extrêmement pris en count.

Si vous souhaitez mettre à jour votre application Web, utilisez un service ou un service Cron séparé qui le fait, puis reconfigure et redémarre Apache. Ce service pourrait avoir le droit d'exécuter l' installation git et npm et cela devrait être limité à l' installation npm au niveau de l' user plutôt qu'au niveau du système. Il est très probable que des privilèges suffisants soient uniquement des filesystems et pourraient être limités aux dossiers de votre application, de sorte que l'user de mise à jour puisse changer les choses alors que www-data ne peut pas.

Les choses les plus vitales à faire lorsque Hardgin nginx désactive les modules que vous n'utilisez pas et que le server_tokens affiche des informations de version less détaillées. De plus, le durcissement de Nginx est possible en fonction de la sensibilité du système ou du service.

Ne pas autoriser la connection racine sur SSH. Connectez-vous à votre instance en tant qu'user non root et utilisez sudo pour exécuter des commands ou sudo su -l pour devenir root et le faire.

Devriez-vous avoir des users distincts et des privilèges pour des choses séparées? Idéalement oui. Plus vous comparez les composants, vous pouvez pratiquer de cette façon, plus vous protégerez votre système. Il est également plus facile d'append ou de supprimer des permissions, car chaque user a un rôle très étroitement défini dans le système avec un access au privilège minimal.