>> On ne veut pas que quelqu'un sur B puisse faire un ssh sur A => Soit tu ne met pas de ssh sur A soit tu met un serveur ssh sur A mais tu bloques le port en provenance de B
Le mieux c'est de bloquer la sortie directement de données sur le port 22 à partir de B, non?
J'ai établi quelques règles de pare-feu pour sécuriser ce cas. Les voici:
- laisser entrer depuis A vers B par le port 22
- autoriser uniquement les sorties de B par le port 22
- interdire toute les sorties depuis B
En fait je garde l'entrée et la sortie sur le port 22 pour permettre au tunnel SSH de fonctionner, c'est impératif non?
Si vous ne voulez pas que les utilisateurs transfèrent des fichiers depuis et vers le serveur ssh, vous devez restreindre l'accès au sftp-server et l'accès scp. Vous pouvez restreindre sftp-server en configurant le bon Subsystem dans /etc/ssh/sshd_config. Cependant, pour restreindre l'accès scp, vous devez :
* soit interdire les connexions d'utilisateurs au serveur ssh (comme décrit ci-dessus par le fichier de configuration ou par la configuration PAM),
* soit ne pas donner de shells valides aux utilisateurs qui ne sont pas autorisés à faire des transferts sécurités. Cependant, les shells fournis devraient être des programmes qui justifieraient la connexion au serveur ssh par eux-même, comme des programmes de menus (ala BBS). Sinon, l'option précédente est préférée."
-> Pour bloquer le sftp, je paramètre /etc/sshd_config avec:
Subsystem sftp /path/vers/autre/chose/que/sftp-server
la question est: vers quel programme?
-> par contre pour scp... Dur dur... sauf en interdisant le ssh de B vers A, en indiquant à sshd_config de A un port différent de 22. Ainsi, en bloquant toute sortie autre que par le port 22 depuis B, ça devrait le faire, vu que le client ne peut se connecter que sur le port que lui donne le serveur.
Non?
[^] # Re: Export du display ?
Posté par ostead . En réponse au message Application par tunnel SSH. Évalué à 1.
Le mieux c'est de bloquer la sortie directement de données sur le port 22 à partir de B, non?
J'ai établi quelques règles de pare-feu pour sécuriser ce cas. Les voici:
- laisser entrer depuis A vers B par le port 22
- autoriser uniquement les sorties de B par le port 22
- interdire toute les sorties depuis B
En fait je garde l'entrée et la sortie sur le port 22 pour permettre au tunnel SSH de fonctionner, c'est impératif non?
Sinon, pour bloquer sftp et scp j'ai trouvé ça (à l'adresse http://www.debian.org/doc/manuals/securing-debian-howto/ch-s(...)
"5.1.3 Interdire les transferts de fichiers
Si vous ne voulez pas que les utilisateurs transfèrent des fichiers depuis et vers le serveur ssh, vous devez restreindre l'accès au sftp-server et l'accès scp. Vous pouvez restreindre sftp-server en configurant le bon Subsystem dans /etc/ssh/sshd_config. Cependant, pour restreindre l'accès scp, vous devez :
* soit interdire les connexions d'utilisateurs au serveur ssh (comme décrit ci-dessus par le fichier de configuration ou par la configuration PAM),
* soit ne pas donner de shells valides aux utilisateurs qui ne sont pas autorisés à faire des transferts sécurités. Cependant, les shells fournis devraient être des programmes qui justifieraient la connexion au serveur ssh par eux-même, comme des programmes de menus (ala BBS). Sinon, l'option précédente est préférée."
-> Pour bloquer le sftp, je paramètre /etc/sshd_config avec:
Subsystem sftp /path/vers/autre/chose/que/sftp-server
la question est: vers quel programme?
-> par contre pour scp... Dur dur... sauf en interdisant le ssh de B vers A, en indiquant à sshd_config de A un port différent de 22. Ainsi, en bloquant toute sortie autre que par le port 22 depuis B, ça devrait le faire, vu que le client ne peut se connecter que sur le port que lui donne le serveur.
Non?
C'est bien compliqué ces histoires LOL
Merci en tout cas.