Est-il possible d'empêcher SCP tout en autorisant l'accès SSH?

En utilisant les serveurs Solaris et Linux et OpenSSH, est-il possible d'empêcher les utilisateurs de copier des fichiers en utilisant "scp" tout en autorisant l'accès au shell avec "ssh"?

Je me rends compte que les accès aux fichiers de type "ssh $ server" cat file "'sont beaucoup plus difficiles à empêcher, mais j'ai besoin de voir comment arrêter" scp "pour les démarreurs.

À défaut, existe-t-il un moyen de consigner de manière fiable tous les accès SCP côté serveur syslog?

Bien que vous puissiez modifier votre /etc/ssh/sshd_configpour ressembler à ceci:

ForceCommand           /bin/sh
PermitOpen             0.0.0.0
AllowTcpForwarding     no
PermitTunnel           no
# Subsystem sftp       /usr/lib/openssh/sftp-server
PermitUserEnvironment  no

Je déterminerais plutôt à quoi l'utilisateur est susceptible de l'utiliser. Parce que s'il n'y a que quelques commandes auxquelles vous voulez qu'ils aient accès, je supprimerais plutôt la possibilité pour eux d'invoquer même un sshshell normal .

AllowUsers             root
PermitRootLogin        forced-commands-only

PermitUserEnvironment  no

AllowTcpForwarding     no
PermitTunnel           no

# Subsystem sftp       /usr/lib/openssh/sftp-server
Subsystem smb-reload   /usr/bin/smbcontrol smbd reload-config
Subsystem status       /opt/local/bin/status.sh

ssh root@example -s smb-reload

Si vous trouvez que vous avez vraiment besoin de pouvoir exécuter un shell normal, tout ce que vous pouvez vraiment espérer, c'est de les ralentir et de les rendre plus difficiles.

Comme d'autres l'ont remarqué, vous ne pouvez pas bloquer scp (enfin, vous pourriez:, rm /usr/bin/scpmais cela ne vous mène vraiment nulle part).

Le mieux que vous puissiez faire est de changer le shell des utilisateurs en shell restreint (rbash) et ensuite d'exécuter certaines commandes.

N'oubliez pas que s'ils peuvent lire des fichiers, ils peuvent les copier / coller hors de l'écran. Fichiers binaires? xxd / uuencode / mmencode contournent tout cela.

Je suggère également d'utiliser la comptabilité des processus pour vous aider à suivre l'activité.

Vous ne gagnez rien en arrêtant "scp" lorsque vous autorisez toujours des mécanismes supplémentaires littéralement infinis de transfert de fichiers. Interdire scp mais autoriser d'autres mécanismes de copie de fichiers est une méthode de mentir aux auditeurs. Souvent, les auditeurs demandent à être menti. Habituellement, je vois des auditeurs travailler avec des gestionnaires pour apporter de fausses corrections, afin qu'ils puissent déclarer quelque chose comme "la commande de transfert de fichiers scp a été désactivée, afin que les fichiers ne puissent pas être copiés à partir du serveur en utilisant scp".

Maintenant, un mécanisme de journalisation raisonnable serait bien. Auditd fonctionne peut-être enfin sous Linux. Peut-être que Solaris a finalement ajouté un mécanisme ou que dtrace pourrait être utilisé en toute sécurité. Il est raisonnable de vouloir que le système d'exploitation se connecte à chaque accès à un fichier. Bien sûr, il n'y a pas de différence entre "lire" et "copier". Mais cela peut satisfaire un auditeur et donner une sécurité importante au système. Vos journaux peuvent être si bruyants que les données sont inutiles, ou même que vous êtes obligé de garder une piste d'audit ridiculement courte. (par exemple, vous ne pouvez pas enregistrer chaque read () - et une application qui fait quelque chose de surprenant peut rendre la journalisation de chaque open () un désastre).

En fonction de la raison pour laquelle SSH est nécessaire, vous pourrez peut-être atteindre cet objectif (pour les fichiers non triviaux) en utilisant IPTables pour mettre fin aux sessions si la taille du paquet est supérieure à, disons 1400 octets. Cela signifie que ssh interactif fonctionnera principalement, mais dès que quelque chose essaie d'envoyer un scp de type paquet de 1500 octets pour un fichier plus grand que 1499 octets en supposant une MTU standard de 1500, il mettra fin à la connexion.

Cela empêchera également l'attaque de "catting" que vous mentionnez.

Malheureusement, cela signifie que vous pouvez avoir des problèmes pour modifier certains fichiers avec un éditeur de texte, si l'écran doit dessiner plus de 1400 caractères, ou si vous devez saisir un long fichier ou faire une longue liste de répertoires.

Dans le cas le plus simple, une commande pour ce faire pourrait ressembler à quelque chose comme

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff -j DROP

Nous pouvons améliorer ce fonctionnement en combinant les vérifications de la longueur des paquets avec ipt_recent, de sorte que vous autorisez un nombre limité de paquets supérieurs à 1400 octets dans un délai défini (disons 8 paquets par 5 secondes) - cela permettrait aux paquets jusqu'à 12 Ko de glisser à travers, mais peut vous donner l'interactivité dont vous aurez besoin pour éditer des fichiers, etc. Vous pouvez, bien sûr, modifier le nombre de paquets.

Cela pourrait ressembler à quelque chose

iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --set 
iptables -I OUTPUT -p tcp --dport 22 -m length --length 1400:0xffff \
         -m recent --name noscp --rdest --update --seconds 5 --hitcount 8 \
         -j REJECT --reject-with tcp-reset

Les exemples de règles ci-dessus protègent uniquement contre les téléchargements scp tels que scp myfile.data remote.host:~. Pour vous protéger en outre contre les téléchargements scp tels que scp remote.host:~/myfile.data /local/path, répétez les règles ci-dessus mais remplacez --dportpar --sport.

Un pirate informatique peut contourner ces limitations en définissant un MTU inférieur à 1400 sur sa machine (ou forcer mtu ou similaire). De plus, bien que vous ne puissiez pas limiter cela à certains utilisateurs, vous pouvez le limiter par IP en modifiant les lignes iptables comme il convient !!

À la vôtre, David Go

Votre meilleur pari n'est pas de verrouiller scp, mais d'utiliser un système de fichiers avec des ACL pour empêcher l'accès en lecture. Vous pourriez probablement faire quelque chose avec SELinux pour empêcher certaines applications de lire à partir de certains fichiers.

Non scpet sshfonctionnent sur les mêmes ports et utilisent le même protocole. Si vous ouvrez une sshsession, vous pouvez même partager votre connexion avec les appels scp suivants en utilisant des options comme ControlMaster.

Si vous ne voulez pas que les gens copient des fichiers particuliers hors d'une machine, vous ne devez pas leur donner un quelconque accès shell à la machine.

Il existe un moyen d'utiliser 'scponly' comme shell pour désactiver ssh interactif et autoriser scp, mais je ne suis au courant de rien qui fonctionne de manière inverse.

Vous pourrez peut-être explorer le piratage de la coquille scponly pour effectuer l'inverse.

Ce n'est pas possible en fait après un peu de recherche sur Google.

Consultez cette discussion: http://www.mydatabasesupport.com/forums/unix-admin/387261-how-restrict-ssh-users-block-scp-sftp.html

Pour ce qu'il vaut, le produit commercial CryptoAuditor prétend pouvoir contrôler les transferts de fichiers via SSH, en MITMant la connexion et en utilisant l'inspection approfondie des paquets . Évidemment, aucune solution n'est à l'abri du copier-coller, de l'uuencode / décode, du FISH , etc. Ce qui est bien, c'est qu'il est transparent (à part les erreurs de certificat probables); il n'y a aucun logiciel agent à installer aux deux extrémités de la connexion SSH et aucun portail / proxy à configurer.

Je n'ai pas utilisé le produit, donc YMMV.

Il est impossible de bloquer le transfert de fichiers sans supprimer autant d'utilitaires système que de laisser la machine complètement inutile. Vous devez vous débarrasser de tout ce qui est capable d'afficher le contenu du fichier sur stdout, et tout ce qui est capable d'écrire son stdin sur stdout, et au moment où vous avez supprimé tout cela, il reste si peu qu'il ne sert à rien d'autoriser l'accès au shell du tout.

Je vais donc me concentrer sur votre alternative de journalisation à la place:

Il y a un programme appelé "script" qui est inclus dans pratiquement chaque distribution, et qui devrait être facile à installer sur ceux où il ne l'est pas. Il s'agit d'un enregistreur de session qui enregistre toutes les entrées et sorties d'un shell, éventuellement avec des données de synchronisation afin qu'il puisse être relu et ressembler à ce que vous regardiez par-dessus l'épaule de l'utilisateur quand il l'a fait. (95% de toute façon, il ébranle parfois la sortie lorsque ncurses est impliqué, mais pas très souvent.)

Sa page de manuel comprend des instructions pour le configurer comme shell de connexion du système. Assurez-vous que les journaux vont quelque part où l'utilisateur ne peut pas simplement les supprimer (l'attribut de système de fichiers à ajouter uniquement (configurable via chattr) peut être utile pour cela. Tout comme les ACL ou les scripts inotify)

Cela n'empêche toujours pas les utilisateurs de copier des fichiers hors du système, mais cela vous permet de vérifier ce qui a été fait par quels utilisateurs et quand. Il n'est probablement pas impossible de contourner, mais le contournement se retrouverait presque certainement dans les journaux afin que vous sachiez au moins que quelqu'un n'était pas bon, même s'il parvient à cacher exactement ce que c'était.

Je pense que vous pouvez désinstaller les clients openssh (ou équivalent) sur le serveur.

Je pense que le client scp invoque scp sur le serveur lors de la copie de données, donc si vous vous débarrassez de scp sur le serveur, alors ça devrait aller.

$ scp bla server:/tmp/
...
debug1: Sending environment.
debug1: Sending env LC_ALL = en_US.utf8
debug1: Sending env LANG = en_US.utf8
debug1: Sending env XMODIFIERS = @im=ibus
debug1: Sending env LANGUAGE = en_US.utf8
debug1: Sending command: scp -v -t /tmp/
bash: scp: command not found
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
lost connection