rssh - En ligne dans le Cloud

PROGRAMME:

Nom

rssh - shell sécurisé restreint n'autorisant que scp et/ou sftp

SYNOPSIS

rssh [ choix... ] [ ]
rssh -v

DESCRIPTION

rssh est un shell restreint pour fournir un accès limité à un hôte via ssh(1), permettant à un
utilisateur dont le shell est configuré pour rssh d'utiliser une ou plusieurs des commandes scp(1),
Sftp(1) cvs(1), rdiste(1), et rsync(1), et uniquement ces commandes. Il est destiné principalement
pour travailler avec OpenSSH (voir http://www.openssh.com), mais peut fonctionner avec d'autres
mises en œuvre.

L'administrateur système doit installer le shell sur le système restreint. Puis le
entrée de fichier de mot de passe de tout utilisateur pour lequel il est souhaitable de fournir un accès restreint
doivent être édités, de telle sorte que leur coquille soit rssh. Par exemple:

luser:x:666:666::/home/luser:/usr/bin/rssh

Si invoqué avec le -v option, rssh signalera sa version et quittera. Tous les autres
arguments à rssh sont ceux spécifiés par la télécommande ssh(1) client, et ne sont pas de grand-chose
préoccupation pour l'utilisateur moyen. Les arguments fournis doivent être ce qu'un shell sur la télécommande
fin recevrait afin de passer le contrôle à scp(1), Sftp(1), etc. Si rssh reçoit
arguments non conformes, il émettra un message d'erreur et se terminera. Si le programme
l'utilisateur essaie d'exécuter n'est pas autorisé ou contient une syntaxe qui tentera d'exécuter un
commande shell (telle qu'une substitution de commande), elle émettra également une erreur et se terminera.

rssh a un fichier de configuration, rssh.conf(5), ce qui permet une partie du comportement de rssh à
être personnalisé. Voir cette page de manuel pour plus de détails.

SÛRETÉ NOTES

Lire ceci. avec une qualité se soucier, or vous Au cours de cette réunion, Matthew a obtenu de précieux conseils et Linda lui a demandé de la tenir au courant de ses progrès. mettre votre Système at risque!

En utilisant rssh avec CVS
Si vous utilisez rssh pour permettre l'accès CVS, il est à noter qu'il n'est pas possible de
empêcher un utilisateur qui connaît très bien CVS de contourner rssh et obtenir une coquille,
sauf si l'utilisateur n'a pas d'accès en écriture dans le référentiel. Évidemment, l'utilisateur doit
avoir un accès en écriture au référentiel afin de le mettre à jour, ce qui leur permet de télécharger
programmes arbitraires dans le référentiel. CVS fournit plusieurs mécanismes d'exécution
de tels programmes arbitraires... Le seul moyen raisonnablement sûr d'utiliser rssh avec CVS ​​est d'utiliser
les installations de prison chroot pour placer le référentiel CVS dans une prison chroot. S'il te plait regarde
ci-dessous et toute la documentation pertinente pour plus de détails sur la configuration des prisons chroot. Noter que
les utilisateurs sera toujours be capable à obtenez coquille accès dans les le prison; la seule protection qui soit
à condition qu'ils ne puissent pas s'échapper de la prison. J'ai été incité à conserver mon soutien
pour CVS car cette protection vaut mieux que pas de protection. Vous avons était averti. Utilisez
CVS at votre propre risque.

Potentiel racine Compromis avec Vieux versions
Avant rssh 2.3.0, si un utilisateur régulier avait un accès shell à une machine où rssh était
installé, un compromis racine était possible en raison de rssh_chroot_helper permettant à un utilisateur de
arbitrairement chroot(2) n'importe où sur le système de fichiers. Il est possible d'atténuer ce
attaque contre les versions affectées de rssh en utilisant des contrôles d'accès stricts aux fichiers, en faisant
s'assurer que l'utilisateur ne peut pas écrire dans un fichier sur la même partition que les exécutables système,
et que toute partition où ils peuvent écrire des fichiers ne permet pas l'exécution de SUID
programmes. À partir de rssh 2.3.0, cette attaque a été prévenue en empêchant
chroot(), if votre prison is set up en toute sécurité. En particulier, assurez-vous que les utilisateurs réguliers
ne peut pas écrire dans les répertoires à l'intérieur de la prison qui contiennent les binaires copiés. Cette
devrait être évident, mais il faut le dire. Bien que cela ne soit pas strictement nécessaire,
pour protéger davantage votre système contre d'éventuelles compromissions, il est également conseillé de suivre
la section ci-dessous, intitulée « Sauvegardes contre le contournement de rssh ».

Sauvegardes Contre Contournement rssh
rssh est conçu pour interagir avec plusieurs autres programmes. Même si rssh est complètement bug-
gratuit, les modifications apportées à ces autres programmes pourraient éventuellement entraîner des méthodes pour contourner le
protection qui rssh est destiné à fournir. It is important pour vous, le Système
administrateur, à restent actuel on le services vous a prendre une disponibles avec rsh, à be sûr
qui ces commandes do pas fournir mécanismes à permettre le utilisateur à courir arbitraire les commandes.
De plus, bien que le but de chaque version soit d'être sans bogue, personne n'est parfait... Il peut
être des bogues non découverts dans rssh qui pourrait permettre à un utilisateur de le contourner.

Vous pouvez protéger votre système de ceux qui profiteraient de telles faiblesses. Cette
n'est pas nécessaire pour rssh fonctionner correctement, mais c'est une très bonne idée. Il y a six
étapes de base :

1. protégez tous les comptes non-administrateurs avec rssh (c'est-à-dire aucun utilisateur régulier
devrait avoir un accès shell au serveur)

2. placez vos utilisateurs dans une prison chroot

3. limiter les binaires qui vivent dans la prison au minimum absolu requis

4. monter leur système de fichiers personnel avec l'option noexec/nosuid (c'est-à-dire utiliser des
partitions dans la prison pour les répertoires personnels des utilisateurs et tous les autres fichiers, si
possible/raisonnable)

5. créer un groupe pour les utilisateurs rssh et limiter l'accès aux exécutables aux binaires
aux utilisateurs de ce groupe.

6. utilisez les autorisations de fichiers standard avec soin et de manière appropriée

Si possible, assurez-vous qu'aucun utilisateur régulier n'a d'accès shell au système
autrement que par rssh. Sinon, les utilisateurs disposant d'un accès shell pourraient potentiellement exploiter
bogues non découverts dans rssh_chroot_helper pour obtenir un accès root au serveur.

rssh donne à l'administrateur système la possibilité de placer les utilisateurs dans une prison chroot. Voir
détails dans la page de manuel pour rssh.conf et dans le fichier CROOT qui est distribué avec le
code source. Si vous voulez vous assurer que les utilisateurs ne peuvent pas exécuter de programmes arbitraires, utilisez un chroot
prison, et assurez-vous de ne pas mettre de programmes autres que ceux qui sont absolument nécessaires pour
fournir le service que vous essayez de fournir. Cela les empêche d'exécuter la norme
commandes système.

Ensuite, assurez-vous que les fichiers de l'utilisateur à l'intérieur de la prison sont sur un système de fichiers distinct de votre
exécutables du système. Si possible dans votre environnement, assurez-vous de monter ce
système de fichiers utilisant le noexec et nosuide options, si votre système d'exploitation les fournit.
Cela empêche les utilisateurs de pouvoir exécuter les programmes qu'ils ont téléchargés sur
la machine cible (par exemple en utilisant scp) qui pourrait autrement être exécutable, et empêche SUID
programmes de respecter les bits SUID. Notez que ces options nécessitent que les utilisateurs
les fichiers sont sur des partitions distinctes des binaires et des bibliothèques qui vivent dans la prison.
Par conséquent, vous aurez besoin d'au moins 2 partitions pour que votre prison le fasse correctement (une pour
les binaires système dans la prison, l'autre pour les répertoires des utilisateurs).

De plus, créez un groupe, par exemple "rsshuser", pour les utilisateurs rssh. Mettez tous vos utilisateurs
qui sera restreint par rssh dans ce groupe. Définir la propriété et les autorisations sur rssh
et rssh_chroot_helper afin que seuls ces utilisateurs puissent les exécuter. Les commandes suivantes
doit illustrer :

# groupeajouter utilisateur
# chown racine:rsshuser rssh rssh_chroot_helper
# chmod 550 rssh
# chmod 4550 rssh_chroot_helper

Enfin, utilisez les autorisations de fichier Unix/POSIX standard pour vous assurer qu'ils ne peuvent pas accéder aux fichiers qu'ils
ne devrait pas pouvoir entrer dans la prison chroot.

Command Gamme Analyseur
À compter du rssh version 2.2.3, le programme doit analyser la ligne de commande complète pour éviter
options de ligne de commande qui provoquent l'exécution de programmes arbitraires (et donc contournent le
sécurité de rssh). Afin de garder le code source du programme sain, l'analyseur est un peu
trop zélé à propos de la correspondance des options de ligne de commande. En pratique, ce ne sera probablement pas
un problème, mais en théorie, c'est possible.

Si vous rencontrez un problème où rssh refuse de courir, prétendant rejeter l'insécurité
options de ligne de commande qui n'ont pas été spécifiées, essayez de modifier votre ligne de commande de telle sorte que
tous court les options sont spécifiées comme des drapeaux d'options à une seule lettre (par exemple -e -p au lieu de -ep)
et assurez-vous de séparer les arguments de leurs options respectives par un espace (par exemple -p 123
au lieu de -p123). Dans pratiquement tous les cas, cela devrait résoudre le problème. Certes, un
une recherche exhaustive n'a pas été effectuée, mais aucun cas problématique n'a été trouvé qui
susceptible d'être commun.

L'alternative aurait été d'inclure un analyseur de ligne de commande complet pour rcp, rdist,
et rsync ; c'était bien en dehors de la portée de ce projet. En pratique, l'existant
l'analyseur devrait suffire. Si, toutefois, vous trouvez des cas où ce n'est pas le cas, veuillez poster des détails
à la liste de diffusion rssh. Les détails sur la façon de publier sur la liste de diffusion peuvent être trouvés sur
la page d'accueil rssh.

OpenSSH versions et Contournement rssh
Avant OpenSSH 3.5, sshd(8) tentera généralement d'analyser les fichiers dans la maison de l'utilisateur
répertoire, et peut également essayer d'exécuter un script de démarrage à partir du $ACCUEIL/.ssh répertoire.
rssh n'utilise en aucun cas l'environnement de l'utilisateur. La commande correspondante est
exécuté en appelant exécutif(3) avec le chemin complet de la commande, comme spécifié à la compilation
temps. Cela ne dépend pas de la variable PATH de l'utilisateur, ou de tout autre environnement
variable.

Cependant, plusieurs problèmes peuvent survenir. Cela est entièrement dû à la façon dont le
Le sshd d'OpenSSH Project fonctionne et n'est en aucun cas la faute de rssh. Par exemple, un
problème qui pourrait exister est que, selon le sshd(8) page de manuel d'au moins certains
versions d'OpenSSH, les commandes répertoriées dans le $HOME/.ssh/rc fichier sont exécutés avec
/ Bin / sh au lieu du shell défini par l'utilisateur. Cela ne semble pas être le cas sur le
les systèmes sur lesquels l'auteur pouvait effectuer des tests ; les commandes ont été exécutées à l'aide de l'utilisateur
shell configuré (rssh), qui n'a pas permis l'exécution. Cependant, si c'est vrai sur votre
système, alors un utilisateur malveillant peut être en mesure de contourner rssh en téléchargeant un fichier sur
$HOME/.ssh/rc qui sera exécuté par / Bin / sh sur ce système. Si des rejets (de
OpenSSH) sont, en fait, vulnérables à ce problème, alors il est très probable qu'ils soient
uniquement des versions anciennes et obsolètes. Tant que vous utilisez une version récente d'OpenSSH, cette
ne devrait pas être un problème pour autant que je sache.

Si votre sshd is vulnérable à cette attaque, il existe une solution à ce problème, cependant
c'est assez restrictif. Le utilisateur Accueil annuaire absolument doit pas be écriture by
le utilisateur. Si c'est le cas, l'utilisateur peut utiliser sftp pour supprimer le répertoire ou le renommer, puis
créez-en un nouveau et remplissez-le avec les fichiers d'environnement de votre choix. Pour fournir
téléchargements de fichiers, cela signifie qu'un répertoire accessible en écriture par l'utilisateur doit être créé pour eux, et ils doivent
être mis au courant de leur incapacité à écrire dans leur répertoire personnel autrement que dans ce
emplacement.

Un deuxième problème est qu'après avoir authentifié l'utilisateur, sshd lit également
$HOME/.ssh/environnement pour permettre à l'utilisateur de définir des variables dans son environnement. Cette
permet à l'utilisateur de contourner complètement rssh par une manipulation intelligente d'un tel environnement
variables comme LD_LIBRARY_PATH or LD_PRÉCHARGER pour lier le binaire rssh contre arbitraire
bibliothèques partagées. Afin d'éviter que cela ne soit un problème, à partir de la version 0.9.3, en
défaut rssh est maintenant compilé statiquement. La solution de contournement restrictive mentionnée ci-dessus
également vaincre ce genre d'attaque.

Depuis OpenSSH 3.5, sshd prend désormais en charge l'option PermisUserEnvironnement qui est mis à "non"
par défaut. Cette option autorise les shells restreints comme rssh fonctionner correctement sans
les obligeant à être liés de manière statique. À partir de rssh version 1.0.1, le script de configuration
devrait détecter qu'OpenSSH 3.5 est présent et désactiver la compilation statique par défaut.

Utilisez rssh en ligne en utilisant les services onworks.net