Ricard a écrit :



Pas cool quand on héberge son propre serveur web par contre.









Ricard a écrit :



Ca permet surtout de pouvoir s’auto-héberger facilement sans débourser un centime ;)  





 

" />

 

Ca n'a rien à voir avec un serveur web ; c'est juste l'ajout de la possibilité d'accéder à l'interface d'administration de la box à distance, avec désormais du HTTPS au lieu du HTTP.     

Et PS: s’auto-héberger coûte de l’argent: EDF, coût d’achat de la machine, etc… Quand tu vois que tu as des VPS à louer pour moins de 1.50 euro par mois maintenant, le calcul de ‘rentabilité’ n’est pas si évident que ça.

blackdream a écrit :



Pour les cas plus spécifique, un Pi ne fera pas forcément beaucoup mieux. 

 





La box serveur est équipée d’un ARM9 1.2GHz avec 512Mo de RAM. Je suis pas spécialiste en ARM, mais je pense que c’est mieux que ce que propose un raspi B+

 

Le player (qui tourne lui aussi, même quand la box est en veille) est quant à lui équipé d’un Atom CE4100.

 

blackdream a écrit :



Comment tu utilises la back-up chiffrée pour l’upload ? 

  Pas sûr d'avoir compris ta question.     

Perso, je monte sur le dédié une partition truecrypt quand je veux y accéder, et je la démonte ensuite. Dans mon cas, le chiffrement me sert pour protéger mes données en cas de piratage du serveur à cause d’un défaut de sécurisation de ma faute (ce qui est à mes yeux le risque le plus probable).

         


 Je pourrais en plus faire que le volume ne soit pas monté sur le serveur mais monté sur mon client et que le serveur me relaie les données 'brutes' chiffrées (si j'avais moins confiance en mon hébergeur, par exemple).     

   

Meewan a écrit :



Une autre solution (bourrin) qui ne serait que pour protéger es accidents physiques (innondation etc…) serait simplement d’utiliser le chiffrement fournit par le noyau linux et de monter le serveur de backup en sshfs (ou par un autre moyen pour monter de manière sécurisé des volumes distants) puis de faire tes backup avec des scipts.



Dans ce cas le chiffrement n’est la que pour protéger les backups mais ne sert a rien si le serveur principal est compromis.





Tu refais la même chose sauf que tu remplaces ton block de données ‘non protégé’ sur le serveur par un gros fichier style truecrypt, et tu as la totale.



Fut un temps, j’avais cru comprendre que LTSPFS pourrait aider dans cette tâche, mais j’ai jamais pris le temps de m’y plonger vraiment.

 

Meewan a écrit :



Du coup sachant que ta clef ssh (ou tout autre moyen de monter la partition distante) est présente sur le serveur a backupper, si ce dernier est compromis ton backup l’est aussi :s







Non:

• dans mon cas actuel, je lance un backup client (ordi perso) => serveur via un script (executé sur le serveur et lancé via une connexion SSH) auquel je fournis la clef en input à chaque lancement ; le clef sert à monter le volume, un coup de rsync push les changements dans le backup et on démonte le tout une fois le rsync fini. La clef est donc stockée sur mon client, mais le chiffrement/déchiffrement se fait sur le serveur et je lui file la clef à chaque run ; la clef traine donc quelque part dans la RAM du serveur juste le temps que le volume chiffré est monté.
  
  
  


• la solution plus avancée dont je parlais: le serveur stocke le volume chiffré et le client fait un montage de ce volume comme si c’était un volume local sur le client. Sauf qu’au lieu d’accéder à ce fichier local, il accède au fichier via le réseau.
  
  
  
  Pour la solution 2, le serveur ne voit donc jamais la clef ni de près, ni de loin. Le chiffrement/déchiffrement se fait uniquement sur le client. Le serveur sert uniquement de stockage de données chiffrées qu’ç aucun moment il ne déchiffre. C’est un peu le même principe que le site web ‘mega’ de Kim Dotcom.
  
   
  
  
  
  Nit a écrit :
  
  
  
  Ça un avantage d’utiliser truecrypt au lieu d’un volume luks ?
  
  
  
  
  
  Aucune idée, je ne connais pas luks (mais maintenant que je connais le nom, je vais regarder ;))