Je viens d'installer chez moi un petit NAS domestique (Qnap TS-101),
qui va me servir à plusieurs choses:
1) mettre mes données volumineuses (photos, musiques, videos...)
dessus
2) faire un backup des documents personnels importants situés sur le
PC
3) donner des accès FTP/HTTP à des gens de l'extérieur pour échanger
facilement des fichiers
4) accéder à mes documents personnels depuis l'extérieur (FTP ou HTTP)
Le NAS est derrière la box/routeur, et j'ai ouvert juste les ports
nécessaires. Les accès ne sont pas sécurisés (pas SSL).
Je sais bien que dès qu'on ouvre les accès vers l'extérieur, il y a
des risques. Mais j'aimerais évaluer ces risques:
Est-ce que 3) pose un problème par rapport à 2) ? Les partages et
droits d'accès isolent en principe mes données perso du reste, mais
est-ce qu'une connection FTP avec un compte présente le risque de
permettre d'accéder à d'autres comptes sur le même serveur ?
1) mettre mes données volumineuses (photos, musiques, videos...) dessus
Peux-tu avoir la garantie absolue qu'il n'y aura jamais le moindre fichier copyrighté là-dessus ? Si la réponse est "non", un cryptage SSL est le minimum vital, avec la loi Hadopi qui se prépare.
D'une manière générale, sur un système privé, on chiffre tout par défaut ; on n'utilise une connexion en clair que si on a de bonnes raisons pour faire ce choix.
On 01 Dec 2008 10:02:25 GMT, pehache-tolai <pehache.7@gmail.com>:
1) mettre mes données volumineuses (photos, musiques, videos...)
dessus
Peux-tu avoir la garantie absolue qu'il n'y aura jamais le moindre
fichier copyrighté là-dessus ?
Si la réponse est "non", un cryptage SSL est le minimum vital, avec la
loi Hadopi qui se prépare.
D'une manière générale, sur un système privé, on chiffre tout par
défaut ; on n'utilise une connexion en clair que si on a de bonnes
raisons pour faire ce choix.
1) mettre mes données volumineuses (photos, musiques, videos...) dessus
Peux-tu avoir la garantie absolue qu'il n'y aura jamais le moindre fichier copyrighté là-dessus ? Si la réponse est "non", un cryptage SSL est le minimum vital, avec la loi Hadopi qui se prépare.
D'une manière générale, sur un système privé, on chiffre tout par défaut ; on n'utilise une connexion en clair que si on a de bonnes raisons pour faire ce choix.
pehache-tolai
On 1 déc, 12:42, Fabien LE LEZ wrote:
Peux-tu avoir la garantie absolue qu'il n'y aura jamais le moindre fichier copyrighté là-dessus ? Si la réponse est "non", un cryptage SSL est le minimum vital, avec la loi Hadopi qui se prépare.
Je me suis sans doute fait mal comprendre : la partie publique (ou quasi publique) du serveur FTP (donc 3) ne contiendra rien de copyrighté. Les fichiers avec copyrights éventuels (donc 1) seront dans la partie privée, accessible que par moi (ou tout au plus par des personnes sélectionnées, avec login+pass personnels).
D'une manière générale, sur un système privé, on chiffre tout par défaut ; on n'utilise une connexion en clair que si on a de bonnes raisons pour faire ce choix.
La bonne raison c'est que le NAS se supporte pas de chiffrement.
-- pehache
On 1 déc, 12:42, Fabien LE LEZ <grams...@gramster.com> wrote:
Peux-tu avoir la garantie absolue qu'il n'y aura jamais le moindre
fichier copyrighté là-dessus ?
Si la réponse est "non", un cryptage SSL est le minimum vital, avec la
loi Hadopi qui se prépare.
Je me suis sans doute fait mal comprendre : la partie publique (ou
quasi publique) du serveur FTP (donc 3) ne contiendra rien de
copyrighté. Les fichiers avec copyrights éventuels (donc 1) seront
dans la partie privée, accessible que par moi (ou tout au plus par des
personnes sélectionnées, avec login+pass personnels).
D'une manière générale, sur un système privé, on chiffre tout par
défaut ; on n'utilise une connexion en clair que si on a de bonnes
raisons pour faire ce choix.
La bonne raison c'est que le NAS se supporte pas de chiffrement.
Peux-tu avoir la garantie absolue qu'il n'y aura jamais le moindre fichier copyrighté là-dessus ? Si la réponse est "non", un cryptage SSL est le minimum vital, avec la loi Hadopi qui se prépare.
Je me suis sans doute fait mal comprendre : la partie publique (ou quasi publique) du serveur FTP (donc 3) ne contiendra rien de copyrighté. Les fichiers avec copyrights éventuels (donc 1) seront dans la partie privée, accessible que par moi (ou tout au plus par des personnes sélectionnées, avec login+pass personnels).
D'une manière générale, sur un système privé, on chiffre tout par défaut ; on n'utilise une connexion en clair que si on a de bonnes raisons pour faire ce choix.
La bonne raison c'est que le NAS se supporte pas de chiffrement.
-- pehache
mpg
Le (on) lundi 01 décembre 2008 12:42, Fabien LE LEZ a écrit (wrote) :
Peux-tu avoir la garantie absolue qu'il n'y aura jamais le moindre fichier copyrighté là-dessus ?
J'aime bien le raccourci copyrighté = illégal. Sans même parler des licences libres de type copyleft, ça arrive aussi des fois d'avoir le droit de stocker sur son disque dur des trucs dont la diffusion n'est pas libre...
Manuel.
Le (on) lundi 01 décembre 2008 12:42, Fabien LE LEZ a écrit (wrote) :
Peux-tu avoir la garantie absolue qu'il n'y aura jamais le moindre
fichier copyrighté là-dessus ?
J'aime bien le raccourci copyrighté = illégal. Sans même parler des licences
libres de type copyleft, ça arrive aussi des fois d'avoir le droit de
stocker sur son disque dur des trucs dont la diffusion n'est pas libre...
Le (on) lundi 01 décembre 2008 12:42, Fabien LE LEZ a écrit (wrote) :
Peux-tu avoir la garantie absolue qu'il n'y aura jamais le moindre fichier copyrighté là-dessus ?
J'aime bien le raccourci copyrighté = illégal. Sans même parler des licences libres de type copyleft, ça arrive aussi des fois d'avoir le droit de stocker sur son disque dur des trucs dont la diffusion n'est pas libre...
Manuel.
Fabien LE LEZ
On 01 Dec 2008 17:49:26 GMT, mpg :
J'aime bien le raccourci copyrighté = illégal.
La notion de "légalité" est du ressort d'un juge. Étant donné que Hadopi peut couper ta connexion à Internet de façon automatique, copyrighté = problèmes potentiels.
On 01 Dec 2008 17:49:26 GMT, mpg <mpg-news@elzevir.fr>:
J'aime bien le raccourci copyrighté = illégal.
La notion de "légalité" est du ressort d'un juge.
Étant donné que Hadopi peut couper ta connexion à Internet de façon
automatique, copyrighté = problèmes potentiels.
La notion de "légalité" est du ressort d'un juge. Étant donné que Hadopi peut couper ta connexion à Internet de façon automatique, copyrighté = problèmes potentiels.
pehache-tolai
"Fabien LE LEZ" a écrit dans le message de news:
On 01 Dec 2008 17:49:26 GMT, mpg :
J'aime bien le raccourci copyrighté = illégal.
La notion de "légalité" est du ressort d'un juge. Étant donné que Hadopi peut couper ta connexion à Internet de façon automatique, copyrighté = problèmes potentiels.
Encore une fois rien ne sera copyrighté sur la partie publique, le problème n'est donc pas là.
On pourrait revenir à mes questions :-) ?
-- pehache http://pehache.free.fr/public.html
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news: s009j4lp9euhej19ls5q50t4nfgbn6u4lf@4ax.com
On 01 Dec 2008 17:49:26 GMT, mpg <mpg-news@elzevir.fr>:
J'aime bien le raccourci copyrighté = illégal.
La notion de "légalité" est du ressort d'un juge.
Étant donné que Hadopi peut couper ta connexion à Internet de façon
automatique, copyrighté = problèmes potentiels.
Encore une fois rien ne sera copyrighté sur la partie publique, le problème
n'est donc pas là.
La notion de "légalité" est du ressort d'un juge. Étant donné que Hadopi peut couper ta connexion à Internet de façon automatique, copyrighté = problèmes potentiels.
Encore une fois rien ne sera copyrighté sur la partie publique, le problème n'est donc pas là.
On pourrait revenir à mes questions :-) ?
-- pehache http://pehache.free.fr/public.html
patpro ~ patrick proniewski
In article , "pehache-tolai" wrote:
"Fabien LE LEZ" a écrit dans le message de news: > On 01 Dec 2008 17:49:26 GMT, mpg : > >> J'aime bien le raccourci copyrighté = illégal. > > La notion de "légalité" est du ressort d'un juge. > Étant donné que Hadopi peut couper ta connexion à Internet de façon > automatique, copyrighté = problèmes potentiels.
Encore une fois rien ne sera copyrighté sur la partie publique, le problème n'est donc pas là.
On pourrait revenir à mes questions :-) ?
Pour moi, le FTP est un protocole d'un autre age. Je suis un fervent partisan "du bon protocole pour le bon usage", c'est à dire que par défaut pour du transfert de fichier je conseillais FTP. Maintenant, je conseille plutôt des choses comme scp/sftp (à la rigueur ftp+ssl), ou comme WebDAV sur https.
il *semble* que le NAS en question est capable de faire du https. Au minimum pour la partie administration. Si il est capable de faire du https pour la partie publique, peut être aurais-tu intérêt à te tourner vers une solution d'échange de fichiers sur https.
Sinon pour la question sur la sécurité du FTP, cela dépend complètement de l'implémentation utilisée par QNAP. On sait juste que c'est un linux embedded mais les version des logiciels et les détails de leur configuration sont inconnus.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <6pk8imF8i9alU1@mid.individual.net>,
"pehache-tolai" <pehache.7@gmail.com> wrote:
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news: s009j4lp9euhej19ls5q50t4nfgbn6u4lf@4ax.com
> On 01 Dec 2008 17:49:26 GMT, mpg <mpg-news@elzevir.fr>:
>
>> J'aime bien le raccourci copyrighté = illégal.
>
> La notion de "légalité" est du ressort d'un juge.
> Étant donné que Hadopi peut couper ta connexion à Internet de façon
> automatique, copyrighté = problèmes potentiels.
Encore une fois rien ne sera copyrighté sur la partie publique, le problème
n'est donc pas là.
On pourrait revenir à mes questions :-) ?
Pour moi, le FTP est un protocole d'un autre age. Je suis un fervent
partisan "du bon protocole pour le bon usage", c'est à dire que par
défaut pour du transfert de fichier je conseillais FTP.
Maintenant, je conseille plutôt des choses comme scp/sftp (à la rigueur
ftp+ssl), ou comme WebDAV sur https.
il *semble* que le NAS en question est capable de faire du https. Au
minimum pour la partie administration. Si il est capable de faire du
https pour la partie publique, peut être aurais-tu intérêt à te tourner
vers une solution d'échange de fichiers sur https.
Sinon pour la question sur la sécurité du FTP, cela dépend complètement
de l'implémentation utilisée par QNAP. On sait juste que c'est un linux
embedded mais les version des logiciels et les détails de leur
configuration sont inconnus.
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
"Fabien LE LEZ" a écrit dans le message de news: > On 01 Dec 2008 17:49:26 GMT, mpg : > >> J'aime bien le raccourci copyrighté = illégal. > > La notion de "légalité" est du ressort d'un juge. > Étant donné que Hadopi peut couper ta connexion à Internet de façon > automatique, copyrighté = problèmes potentiels.
Encore une fois rien ne sera copyrighté sur la partie publique, le problème n'est donc pas là.
On pourrait revenir à mes questions :-) ?
Pour moi, le FTP est un protocole d'un autre age. Je suis un fervent partisan "du bon protocole pour le bon usage", c'est à dire que par défaut pour du transfert de fichier je conseillais FTP. Maintenant, je conseille plutôt des choses comme scp/sftp (à la rigueur ftp+ssl), ou comme WebDAV sur https.
il *semble* que le NAS en question est capable de faire du https. Au minimum pour la partie administration. Si il est capable de faire du https pour la partie publique, peut être aurais-tu intérêt à te tourner vers une solution d'échange de fichiers sur https.
Sinon pour la question sur la sécurité du FTP, cela dépend complètement de l'implémentation utilisée par QNAP. On sait juste que c'est un linux embedded mais les version des logiciels et les détails de leur configuration sont inconnus.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
pehache-tolai
On 2 déc, 09:57, patpro ~ patrick proniewski wrote:
Pour moi, le FTP est un protocole d'un autre age. Je suis un fervent partisan "du bon protocole pour le bon usage", c'est à dire que par défaut pour du transfert de fichier je conseillais FTP. Maintenant, je conseille plutôt des choses comme scp/sftp (à la rigueur ftp+ssl), ou comme WebDAV sur https.
vi, mais concernant ftp, ni sftp ni ftps ne sont possibles.
il *semble* que le NAS en question est capable de faire du https.Au minimum pour la partie administration.
Oui.
Si il est capable de faire du https pour la partie publique, peut être aurais-tu intérêt à te tourner vers une solution d'échange de fichiers sur https.
En fait j'ai découvert hier qu'il était capable de faire du https non seulement pour l'administration, mais aussi pour la gestion et l'échange de fichiers.
Mais l'HTTP est quand moins pratique que le FTP...
Ce qui certain c'est que pour accéder à mes données perso, ce sera HTTPS et rien d'autre. A voir si je laisse l'accès FTP pour les comptes moins sensibles...
Sinon pour la question sur la sécurité du FTP, cela dépend complètement de l'implémentation utilisée par QNAP. On sait juste que c'est un linux embedded mais les version des logiciels et les détails de leur configuration sont inconnus.
mouais... et il n'y a pas bcp plus de renseignements dans la doc du NAS.
-- pehache
On 2 déc, 09:57, patpro ~ patrick proniewski
<pat...@boleskine.patpro.net> wrote:
Pour moi, le FTP est un protocole d'un autre age. Je suis un fervent
partisan "du bon protocole pour le bon usage", c'est à dire que par
défaut pour du transfert de fichier je conseillais FTP.
Maintenant, je conseille plutôt des choses comme scp/sftp (à la rigueur
ftp+ssl), ou comme WebDAV sur https.
vi, mais concernant ftp, ni sftp ni ftps ne sont possibles.
il *semble* que le NAS en question est capable de faire du https.Au
minimum pour la partie administration.
Oui.
Si il est capable de faire du
https pour la partie publique, peut être aurais-tu intérêt à te tourner
vers une solution d'échange de fichiers sur https.
En fait j'ai découvert hier qu'il était capable de faire du https non
seulement pour l'administration, mais aussi pour la gestion et
l'échange de fichiers.
Mais l'HTTP est quand moins pratique que le FTP...
Ce qui certain c'est que pour accéder à mes données perso, ce sera
HTTPS et rien d'autre. A voir si je laisse l'accès FTP pour les
comptes moins sensibles...
Sinon pour la question sur la sécurité du FTP, cela dépend complètement
de l'implémentation utilisée par QNAP. On sait juste que c'est un linux
embedded mais les version des logiciels et les détails de leur
configuration sont inconnus.
mouais... et il n'y a pas bcp plus de renseignements dans la doc du
NAS.
On 2 déc, 09:57, patpro ~ patrick proniewski wrote:
Pour moi, le FTP est un protocole d'un autre age. Je suis un fervent partisan "du bon protocole pour le bon usage", c'est à dire que par défaut pour du transfert de fichier je conseillais FTP. Maintenant, je conseille plutôt des choses comme scp/sftp (à la rigueur ftp+ssl), ou comme WebDAV sur https.
vi, mais concernant ftp, ni sftp ni ftps ne sont possibles.
il *semble* que le NAS en question est capable de faire du https.Au minimum pour la partie administration.
Oui.
Si il est capable de faire du https pour la partie publique, peut être aurais-tu intérêt à te tourner vers une solution d'échange de fichiers sur https.
En fait j'ai découvert hier qu'il était capable de faire du https non seulement pour l'administration, mais aussi pour la gestion et l'échange de fichiers.
Mais l'HTTP est quand moins pratique que le FTP...
Ce qui certain c'est que pour accéder à mes données perso, ce sera HTTPS et rien d'autre. A voir si je laisse l'accès FTP pour les comptes moins sensibles...
Sinon pour la question sur la sécurité du FTP, cela dépend complètement de l'implémentation utilisée par QNAP. On sait juste que c'est un linux embedded mais les version des logiciels et les détails de leur configuration sont inconnus.
mouais... et il n'y a pas bcp plus de renseignements dans la doc du NAS.
-- pehache
Stephane Gregoire
Salut, Le Tue, 02 Dec 2008 10:43:25 +0000, pehache-tolai a écrit :
En fait j'ai découvert hier qu'il était capable de faire du https non seulement pour l'administration, mais aussi pour la gestion et l'échange de fichiers.
D'après cette page, on peux installer un client/serveur SSH : <http://scratchpad.wikia.com/wiki/ Open_Turbostation:TS101#Installing_new_packages> ou lien court : <http://scratchpad.wikia.com/wiki/Open_Turbostation:TS101>
Mais comme je n'ai jamais utilisé de NAS, je ne sais pas si c'est trivial de mettre à jour le firmware.
-- <http://pasdenom.info/fortune>
Salut,
Le Tue, 02 Dec 2008 10:43:25 +0000, pehache-tolai a écrit :
En fait j'ai découvert hier qu'il était capable de faire du https non
seulement pour l'administration, mais aussi pour la gestion et l'échange
de fichiers.
D'après cette page, on peux installer un client/serveur SSH :
<http://scratchpad.wikia.com/wiki/
Open_Turbostation:TS101#Installing_new_packages>
ou lien court : <http://scratchpad.wikia.com/wiki/Open_Turbostation:TS101>
Mais comme je n'ai jamais utilisé de NAS, je ne sais pas si c'est trivial
de mettre à jour le firmware.
Salut, Le Tue, 02 Dec 2008 10:43:25 +0000, pehache-tolai a écrit :
En fait j'ai découvert hier qu'il était capable de faire du https non seulement pour l'administration, mais aussi pour la gestion et l'échange de fichiers.
D'après cette page, on peux installer un client/serveur SSH : <http://scratchpad.wikia.com/wiki/ Open_Turbostation:TS101#Installing_new_packages> ou lien court : <http://scratchpad.wikia.com/wiki/Open_Turbostation:TS101>
Mais comme je n'ai jamais utilisé de NAS, je ne sais pas si c'est trivial de mettre à jour le firmware.
-- <http://pasdenom.info/fortune>
Jean-Marc Desperrier
patpro ~ patrick proniewski wrote:
[...] Pour moi, le FTP est un protocole d'un autre age. [...] Maintenant, je conseille plutôt des choses comme scp/sftp (à la rigueur ftp+ssl), ou comme WebDAV sur https. [...]
Malheureusement en ce qui me concerne, scp pose souvent de catastrophiques problèmes de perf qui contraignent à passer par autre chose (et souvent ftp aussi regrettable que ce soit au niveau sécurité) pour les fichiers faisant plusieurs dizaines de méga. Je ne sais pas si c'est un problème de l'implémentation de OpenSSH ou du client ...
patpro ~ patrick proniewski wrote:
[...]
Pour moi, le FTP est un protocole d'un autre age. [...]
Maintenant, je conseille plutôt des choses comme scp/sftp (à la rigueur
ftp+ssl), ou comme WebDAV sur https. [...]
Malheureusement en ce qui me concerne, scp pose souvent de
catastrophiques problèmes de perf qui contraignent à passer par autre
chose (et souvent ftp aussi regrettable que ce soit au niveau sécurité)
pour les fichiers faisant plusieurs dizaines de méga.
Je ne sais pas si c'est un problème de l'implémentation de OpenSSH ou du
client ...
[...] Pour moi, le FTP est un protocole d'un autre age. [...] Maintenant, je conseille plutôt des choses comme scp/sftp (à la rigueur ftp+ssl), ou comme WebDAV sur https. [...]
Malheureusement en ce qui me concerne, scp pose souvent de catastrophiques problèmes de perf qui contraignent à passer par autre chose (et souvent ftp aussi regrettable que ce soit au niveau sécurité) pour les fichiers faisant plusieurs dizaines de méga. Je ne sais pas si c'est un problème de l'implémentation de OpenSSH ou du client ...
xavier
Jean-Marc Desperrier wrote:
Je ne sais pas si c'est un problème de l'implémentation de OpenSSH ou du client ...
C'est un problème d'implémentation. Il serait facile de ne chiffrer que la session d'authentification, et pas la session DATA, mais l'Autorité Suprême a décidé que non, malgré les requêtes faites sur la ML openssh
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Je ne sais pas si c'est un problème de l'implémentation de OpenSSH ou du
client ...
C'est un problème d'implémentation. Il serait facile de ne chiffrer que
la session d'authentification, et pas la session DATA, mais l'Autorité
Suprême a décidé que non, malgré les requêtes faites sur la ML openssh
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
Je ne sais pas si c'est un problème de l'implémentation de OpenSSH ou du client ...
C'est un problème d'implémentation. Il serait facile de ne chiffrer que la session d'authentification, et pas la session DATA, mais l'Autorité Suprême a décidé que non, malgré les requêtes faites sur la ML openssh
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
