L'approche netcat de Caspar est géniale pour sa simplicité, mais il peut y avoir des situations où vous ne voulez pas envoyer des fichiers non chiffrés sur le réseau.
Pour bien faire les choses, vous devriez probablement utiliser une solution mature telle que scp SFTP, samba, ou vortex magique (un outil vraiment cool, mais qui, au moment où nous écrivons ces lignes, n'est malheureusement pas idéal pour envoyer des dossiers volumineux).
Mais en considérant que vous êtes dans cette situation :
- vous ne voulez pas créer un compte d'utilisateur pour l'autre partie, ou vous ne savez pas comment le configurer pour que l'autre personne ne puisse pas exécuter des commandes Shell sur votre PC (donc SCP/SFTP est hors de question)
- les frais de configuration de FTPS/samba sont également trop élevés pour un transfert ponctuel.
- vos dossiers sont trop grands pour le vortex magique
- et vous ne vous attendez pas à ce que des attaquants sérieux
La solution suivante peut être intéressante :
使用方法 gpg -c pour le cryptage
Mode de traction :
serve (host): tar -cz . | gpg -c --cipher-algo AES256 | ncat -lp 8000
fetch (client): ncat HOST 8000 --recv-only | gpg -d | tar -xz
(ici, en utilisant la fonction de nmap ncat mise en œuvre. Pour les autres, voir ci-dessous )
Mode poussée :
Dans le cas où il est plus facile de se connecter au récepteur qu'à l'expéditeur, vous pouvez facilement inverser leurs rôles en modifiant les commandes netcat dans le pipeline :
send (client): tar -cz . | gpg -c --cipher-algo AES256 | ncat HOST 8000
recv (host): ncat -lp 8000 --recv-only | gpg -d | tar -xz
Le site hôte doit toujours être exécutée en premier.
Mot de passe via la ligne de commande :
Si vous voulez, le mot de passe peut être fourni aux deux extrémités en utilisant
-
gpg [...] --batch --passphrase-fd 3 3<<<'PASSWORD' ou
-
gpg [...] --batch --passphrase-file <(cat <<<'PASSWORD') ou simplement
-
gpg [...] --batch --passphrase PASSWORD . Cependant, cette forme doit être évitée dans la plupart des cas, notamment sur les systèmes multi-utilisateurs.
Attention :
D'après ce que j'ai compris, GPG authentifie le texte chiffré par rapport au mot de passe, mais cela se produit très tard, de sorte que le mot de passe n'est pas utilisé. tar Le processus d'extraction peut déjà être impossible à annuler et pourrait avoir écrasé des fichiers dans votre répertoire local si une partie du texte chiffré a été remplacée ou transmise de manière incorrecte. C'est la raison pour laquelle, toujours cd dans un nouveau répertoire vide avant de faire cela.
Notez que je ne suis pas un expert en GPG/crypto et que je ne peux pas promettre que cette méthode n'est pas immensément dangereuse à d'autres égards également.
Vous pouvez également essayer
OpenBSD netcat
Je pense que ça marche, mais sans garantie :
Mode de traction :
serve (host): ENCRYPT | nc -lNp 8000
fetch (client): nc -d HOST 8000 | DECRYPT
Mode poussée :
send (client): ENCRYPT | nc -N HOST 8000
receive (host): nc -ldp 8000 | DECRYPT
GNU netcat
En théorie, cela pourrait fonctionner :
Mode de traction :
serve (host): ENCRYPT | nc -clp 8000
fetch (client): nc HOST 8000 | DECRYPT
Mode poussée :
send (client): ENCRYPT | nc -c HOST 8000
receive (host): nc -lp 8000 | DECRYPT
Cependant, lors de mes essais, il a souvent échoué en raison de la fermeture de la connexion avant que tous les octets aient été envoyés/reçus.
Cela peut être atténué soit en ne spécifiant pas l'option -c (dans ce cas, vous devez fermer la connexion manuellement en utilisant Ctrl+C, lorsque vous pensez qu'elle est terminée), ou en prévoyant un délai du côté de l'expéditeur :
(ENCRYPT; sleep 10s) | nc -clp 8000
Différentes implémentations de netcat sur client/serveur
Ça devrait marcher.
Cryptez le flux en utilisant openssl enc
Servez les fichiers :
tar -cz . | openssl enc -e -aes-256-ctr -pbkdf2 | ncat -lp 8000
Récupérer les fichiers :
ncat HOST 8000 --recv-only | openssl enc -d -aes-256-ctr -pbkdf2 | tar -xz
openssl vous demandera le mot de passe. Vous pouvez également fournir le mot de passe à l'aide de la fonction -k PASSWORD aux deux extrémités, ou sur les systèmes multi-utilisateurs, en utilisant l'option de ligne de commande -pass file:<(cat<<<PASSWORD) .
Attention, cela ne no fournissent un cryptage authentifié, ce qui signifie qu'il n'y a aucune garantie que le flux ne soit pas altéré. Ainsi, quelqu'un pourrait vraiment mettre le bazar dans votre système de fichiers s'il modifie quelques octets. Bien que vous disposiez de contrôles de redondance de base dans l'archive gzip activée par l'option -z cette option ne vous protégera pas de manière fiable. C'est probablement une bonne solution pour protéger une lettre d'amour contre vos amis, mais ne l'utilisez pas s'il y a quelqu'un de plus malfaisant dans le réseau !
Malheureusement, la version d'openssl enc ne supporte aucun mode de cryptage authentifié.
使用方法 zip pour le cryptage
Serveur :
tar -cz . | zip -e -Ppassword | ncat -lp 8000
Client :
ncat HOST 8000 --recv-only | funzip -password | tar -xz
Cela semble fonctionner, mais l'erreur suivante s'affiche :
funzip error: invalid compressed data--length error
(pas à cause d'erreurs de réseau, j'obtiens la même erreur en appelant funzip dans un tuyau local, comme echo text | zip | funzip .)
