[résolu] Problème restauration

[Ze Runner]

Bonjour,

J'ai un petit souci de restauration de mon ipcop. J'ai une sauvegarde fichier.dat. Quand je la restaure, il me crie dessus en disant qu'il ne peut décrypter l'archive.

Je souhaite utiliser la sauvegarde sur la même machine que je viens de réinstaller. Je pense que j'ai oublié de prendre un fichier ou de faire un truc lors de l'export de la sauvegarde.

Y a-t-il une solution pour récupérer cette sauvegarde. Pour corser le tout, la sauvegarde contient 78 Certificats de VPN qui se connectent avec Zerina et Openvpn.

Merci de vos retours.

Ze runner!

[Ze Runner]

Pour info:

Ipcop v1.4.18
Zerina v0.9.7

[Gesp]

Si tu n'as pas le fichier /var/ipcop/backup/key d'origine ayant créé le .dat ou un export par l'interface web de la clé cryptée par le mot de passe backup, il n'est pas possible de récupérer le contenu du .dat.

A la réinstallation, un nouveau fichier key a été créé et le nouveau key ne peut pas décrypter ce que l'ancien a créé.

[Ze Runner]

Bonjour,

Merci pour cette réponse qui confirme mes recherches.
J'ai donc du réinstaller et reconfigurer tout le firewall et les VPNs. Ca m'apprendra à faire correctement les sauvegardes!

Merci encore.

Ze Runner

[Franck78]

je ne me souviens pas d'une raison particulière pour crypter la sauvegarde. Un mot de passe qu'il aurait été simple de ne pas inclure dans la sauvegarde peut être?

En tout cas ,j'ai toujours été contre l'idée qu'un IPCop 'neuf' n'accepte pas d'utiliser n'importe quelle sauvegarde.
Par contre, protéger un IPCop actif d'un sauvegarde qui n'est pas la sienne, OK.

Mais bon, c'est ainsi fait maintenant. Compliqué à souhait

Je rappelle que la raison de cette modif était un proof of concept sur un façon de restaurer(installer) une vérole dans IPCop à partir d'une sauvegarde.
Un IPCop actif n'a besoin QUE de s'assurer qu'il restaure bien une sauvegarde de lui ET intègre (donc signée).


bye

[Gesp]

je ne me souviens pas d'une raison particulière pour crypter la sauvegarde. Un mot de passe qu'il aurait été simple de ne pas inclure dans la sauvegarde peut être?

C'est un peu un pb d'oeuf et de poule, tout en tenant compte que l'on partait d'une situation existante ou les .dat existaient.

La sauvegarde étant chargeable à partir de l'interface web, elle ne doit pas pouvoir être lue sans un niveau de protection élevé (la sauvegarde contient le hash des mots de passe de la machine, le login vers l'ISP, les mdp des VPN...).
Je sais qu'il y a déjà le mot de passe demandé pour accèder à l'interface web.

L'autre idée est de limiter la possibilité pour l'utilisateur 'nobody' de modifier la sauvegarde.
La sauvegarde étant crypté, et n'ayant pas accès à la clé, 'nobody' ne peut pas l'ouvrir (mais il pourrait changer de nombreux fichiers de conf en direct sous /var/ipcop s'il arrivait à obtenir un accès au shell (normalement il ne peut pas accèder au shell).

Je suis d'accord que c'est trop compliqué, en petite partie parce que la modification a été réalisé en gardant la compatibilité avec l'existant des sauvegardes en .dat, en grande partie parce que l'interface et la document sont très largement perfectibles.

Pour pouvoir restaurer à l'installation sans clé de sauvegarde, il faudrait avoir une sauvegarde non cryptée. Il ne semble pas très raisonable de laisser une sauvegarde non cryptée accessible indéfiniment par l'interface web, surtout sachant que certains ouvrent leur IPCop à l'administration du coté Internet (ce que je ne conseille pas vraiment).
Peut-être serait-il suffisant d'exporter une sauvegarde non cryptée comme actuellement la clé cryptée par le mdp backup, c'est à dire les données ne sont pas écrites sur le disque local avec un lien qui pointe dessus pour la charger mais forcer à l'enregistrement d'un fichier sur la machine distante?
La protection serait alors limitée à l'absence de faille de l'authentification par l'interface web.

Comme pistes d'amélioration, il y a bien sur avoir une interface meilleure pendant l'installation permettant la sélection d'un fichier key et d'un fichier .dat. Actuellement la sélection est implicite à partir d'un format à respecter et du nom donné à la machine.
Il pourrait y avoir aussi plus d'explications sur la page de backup:
- par exemple un avertissement quand un .dat est créé mais que le fichier key crypté n'a jamais été exporté.

Il pourrait aussi y avoir un avertissement à l'installation avant le formatage du disque qu'il est nécessaire pour restaurer d'avoir :
- le mot de passe backup,
- le fichier key crypté,
- le fichier .dat

[Franck78]

La sauvegarde étant chargeable à partir de l'interface web, elle ne doit pas pouvoir être lue sans un niveau de protection élevé (la sauvegarde contient le hash des mots de passe de la machine, le login vers l'ISP, les mdp des VPN...).

Moi je pense que la protection des données d'IPCop à l'extérieur d'IPCop n'est pas de la responsabilité d'IPCop.

Ont peut sauvegarder et signer.
Ont peut sauvegarder et crypter comme actuellement.
Un IPCop neuf n'a pas à se poser de question sur une sauvegarde (c-a-d signature inconnue etnon crypté par exemple).

La compatibilité avec les anciens .dat peut maintenant être oubliée (ainsi que 1.3). Il faut savoir trancher et ne pas trainer des boulets pour trois péquins qui seraient encore avec un vieil IPCop.

[Gesp]

La compatibilité avec les anciens .dat peut maintenant être oubliée (ainsi que 1.3).

Vu que cela a été inclu en 1.4, non pas tant que la prochaine version n'est pas prète.

Moi je pense que la protection des données d'IPCop à l'extérieur d'IPCop n'est pas de la responsabilité d'IPCop.

Peux-tu dire d'un fichier écrit sur le disque IPCop et chargeable par une URL depuis son interface web qu'il est à l'extérieur?

[Franck78]

Peux-tu dire d'un fichier écrit sur le disque IPCop et chargeable par une URL depuis son interface web qu'il est à l'extérieur?

A partir de l'interface web, tu obtiens et modifie toutes les données. Par définition. Donc crypter ou pas, aucune différence.
Je comprend mal ta question.
Maintenant si tu veux dire 'public' donc accessible par une URL sans authentif, bien sur c'est mauvais.


La compatibilité avec 1.3 était seulement utile à la sortie de 1.4. Cinq ans après c'est une fonction obsolète qui ne doit pas devenir un boulet.

[Gesp]

A partir de l'interface web, tu obtiens et modifie toutes les données. Par définition.

Non pas celles qui sont protégées par un accès root exclusif.
Je pense qu'il pourrait y avoir peut-être plus de données de conf pour lequelles nobody n'aurait pas nécessairement un accès en écriture (comme par exemple /var/ipcop/ethernet/settings).

La compatibilité avec 1.3 était seulement utile à la sortie de 1.4.

Cela n'a rien à voir. La compatibilté des .dat, c'est en 1.4 (je pense que c'était seulement un add-on en 1.3)