Sauvegarde & réflexions sur la sécurité / backup and security concerns

Discuss
, ,
1

Discuss

Je regarde pour préparer un plan de sauvegarde.
Je ne suis pas dans la sécurité, mais je me dis que la sécurité n’a pas de prix et que, tant qu’à utiliser un système, autant le protéger comme il faut et disposer d’un plan de sauvegarde efficace.
Donc dans l’idée d’un plan de sauvegarde basé sur le fameux 3-2-1-1-0 (3 copies distinctes, sur au moins 2 supports différents, et au moins 1 copie hors site, et au moins 1 copie hors réseau et 0 erreur sur les sauvegardes / restauration), lorsque je regarde, toutes les sauvegardes distantes sont réalisées par la machine elle-même.
Si l’on part de Yunohost, c’est l’outil de sauvegarde qui est installé sur Yunohost qui déclenche la sauvegarde et la copie sur le serveur distant.
Mais j’ai un problème de sécurité : si c’est ma machine Yunohost, qui est forcément exposée à Internet, qui déclenche les sauvegardes à distance, ça signifie que toutes les informations de connexion aux stockages distants sont enregistrées sur ma machine Yunohost et que donc, dans le cas d’une compromission de ma machine Yunohost, l’attaquant dispose des informations de connexion à mes autres serveurs (au moins de sauvegarde).
Je vais déjà essayer de ne pas déléguer la connexion aux serveurs distants à la machine Yunohost, mais plutôt faire appel à un service pour rendre les fichiers de sauvegarde accessibles aux autres serveurs.
Mais je me demandais s’il n’existait pas un moyen de “lancer” une sauvegarde de la machine Yunohost, depuis un serveur qui n’est pas ma machine Yunohost, et de récupérer les données de la sauvegarde sur ce serveur.
backup-server => envoie la commande à Yunohost de lancer une sauvegarde => Yunohost lance la sauvegarde => Yunohost informe le demandeur que la sauvegarde est terminée => backup-server rappatrie le fichier de sauvegarde
Ainsi, il n’y a que le serveur de sauvegarde qui connait la machine à sauvegarder.

[English]
I’m preparing a backup plan for my Yunohost install.
I’m not a security specialist, but I consider that security is priceless, and if you’re gonna use a system, you might as well protect it properly and have a working backup plan.
Therefore, I’m preparing a backup plan, having in mind the famous 3-2-1-1-0 backup plan.
But all the backup for distant storage are initiated by the server to be backuped.
That mean, that if my Yunohost server has to be backuped, it should launch the backup process, and connect itself to distant storages in order to transfer the data.
And the problem is there : my Yunohost server has to be exposed to the Internet. If my Yunohost server is compromised, the attacker has all the information to access my distant storage.
My first action will surely to ensure the transfer of the backup data by the distant server, and maybe using a service to expose those backup-data.
But my question is : Is there a solution to a distant server to launch a backup process on the Yunohost server, and to retrieve the backup data on this distant server ?

2

Hi there,

(English version below)

Mais j’ai un problème de sécurité : si c’est ma machine Yunohost, qui est forcément exposée à Internet, qui déclenche les sauvegardes à distance, ça signifie que toutes les informations de connexion aux stockages distants sont enregistrées sur ma machine Yunohost et que donc, dans le cas d’une compromission de ma machine Yunohost, l’attaquant dispose des informations de connexion à mes autres serveurs (au moins de sauvegarde).

Certaines techniques de sauvegarde (comme Borg, mais aussi Restic je dirais) prévoient un accès à la machine distante de manière restreinte si on configure correctement la machine de sauvegarde, ne permettant de manipuler que les fichiers sauvegardés et de ne pas avoir accès aux autres fichiers.

Dans ce genre de configuration, les informations de connexion sont stockées sur la machine à sauvegarder (qui est de ce fait le client) mais leur fuite n’implique pas une compromission de la machine de sauvegarde (qui est le serveur Borg, Restic, …).

Dans le cas d’outils comme Borg, qui supporte la déduplication des sauvegardes, il y a aussi la question de la rétention (qui fait que par exemple un fichier supprimé sur la machine sauvegardée reste disponible un certain temps sur la machine de backup). Pour libérer de l’espace, il faut procéder à de l’élagage (du pruning en anglais), et cela se fait autorisant la suppression au client. Deux options :

  • on autorise la machine sauvegardée à élaguer elle-même (risqué : si la machine de sauvegarde est compromise, possiblement on perd les sauvegardes aussi)
  • on autorise seulement le fait de pousser des sauvegardes à la machine sauvegardée et on laisse un autre client faire l’élagage, possiblement en requérant la saisie d’un mot de passe (dans le cas de Borg, ça se fait au moyen d’une clé SSH avec saisie d’une phrase de passe). C’est plus sécurisé mais plus contraignant car ça nécessite une action humaine. Et possiblement ça peut se faire sur une machine tierce, comme un poste de travail.

Il y a beaucoup de choses à rajouter, la question des sauvegardes est loin d’être simple. Je m’arrête ici pour l’instant.

Quelques liens :

But all the backup for distant storage are initiated by the server to be backuped.
That mean, that if my Yunohost server has to be backuped, it should launch the backup process, and connect itself to distant storages in order to transfer the data.
And the problem is there : my Yunohost server has to be exposed to the Internet. If my Yunohost server is compromised, the attacker has all the information to access my distant storage.

Some backup techniques (like Borg, but also Restic I would say) provide access to the remote machine in a restricted way if you configure the backup machine correctly, allowing you to manipulate only the saved files and not have access to the other files.

In this type of configuration, the connection information is stored on the machine to be backed up (which is the client) but their leak does not imply a compromise of the backup machine (which is the Borg server, Restic, …).

In the case of tools like Borg, which supports the deduplication of backups, there is also the issue of retention (which means that for example a deleted file on the saved machine remains available for some time on the backup machine). To free up space, it is necessary to proceed with pruning, and which implies the client has the right to delete backups on the server. Two options :

  • the saved machine is allowed to prune itself (risky: if the backup machine is compromised, possibly the backups are lost too)
  • we only allow to push backups to the saved machine and we let another client do the pruning, possibly by requesting entering a password (in the case of Borg, it can be done by protecting the SSH key with a passphrase). It is more secure but more restrictive because it requires the action of a human. And it can be done on a third-party machine, like a desktop.

There are a lot of things to add, the issue of backups is far from being simple. I stop here for now.

Some links:

2 Likes
3

Hello,

(English version below)

Tout d’abord, merci beaucoup pour ta réponse.

Je suis conscient qu’en réglant parfaitement le logiciel de sauvegarde et l’accès sur le serveur distant, on peut limiter les dégâts en cas de compromission du serveur Yunohost.

Cependant, étant donné que les droits sont donnés en écriture du serveur Yunohost vers le serveur distant, si le serveur Yunohost est compromis, l’attaquant peut effacer toutes les sauvegardes sur le serveur distant.

Mais, encore une fois, on peut contourner le problème en faisant tourner un script de mise à jour des droits sur le serveur distant, ou bien en déplaçant les sauvegardes dans un espace inaccessible depuis le serveur Yunohost.

J’en suis conscient.

Mais la logique de sauvegarde est toujours la même : c’est la machine à sauvegarder qui a les informations de connexion au serveur distant, qui a les droits d’écriture sur le serveur distant, et donc, qui facilite, potentiellement, l’attaque. Que l’on soit sur Borg, sur Restic ou bien sur Archiviste (cassé pour l’instant).

Ma question, c’est d’inverser cette logique, pour que le serveur distant “commande” les sauvegardes à distance, et les récupèrent dès qu’elles sont disponibles.

=================

Thank you very much for your answer.

Of course, after fine tuning both the backup system and the distant server, it is possible to reduce the impact of an intrusion.
But, since the authorization are given to the Yunohost server to write data on the distant server, if there is an intrusion, the attacker could erase all the backups.
And yes, of course, it is possible to protect the backup data with a script that that modify the rights of the Yunohost server / backup system on complete backup files, or to move those files to a different folder, unaccessible to the Yunohost server / backup system.

With every solutions described, Borg or Restic, this logic is identical : the server to be backuped know the credentials of the distant server, and has a “full” access to this server.

But my main question is about to reverse the responsability : I wanna find a solution that launch a backup order, maybe on the Yunohost server, maybe on another server, and this “solution” retrieve the backup file that is the result of the backup order.

4

Si j’ai bien suivi, du coté de Borg on peut limiter un compte pour qu’il ne puisse QUE envoyer des données. Et pas les lire ou en supprimer.

Et ça se gère sur le serveur qui va recevoir les données, pas sur ton serveur a sauvegarder.

Pour ce qui est de la récupération des données, là ou on est différent des autres serveurs, c’est qu’il y a tout un système intégré pour sauvegarder tout ce qu’il faut, et pas que les fichiers (le contenu des bases de données par exemple est beaucoup moins facile à gérer). Ces scripts permettent ensuite de restaurer des applications entières, voir même le serveur complet.

Du coup tu peux faire qu’un serveur distant ouvre une connexion SSH avec un compte ayant uniquement le droit de lancer une sauvegarde, puis d’attendre la fin de la sauvegarde pour la récupérer, puis éventuellement la supprimer.

Mais perso je vote pour Borg.

1 Like
5

Alors, Borg permet le push, mais aussi le pull.

Du coup, c’est exactement ce que je cherchais, le pull.

Le serveur qui contiendra les sauvegardes dispose du Borg Server.
Yunohost dispose de Borg client.

Borg server ouvre une connexion SSHFS vers Yunohost et lance une sauvegarde de la machine Yunohost vers le serveur de sauvegardes.

Youpi, merci !!!

1 Like