Snapshot replication : déclencher la réplique depuis le Nas distant

[nicodep]

Hello,

Après une cyber attaque au bureau ... je suis un peu beaucoup parano !

Un serveur Veeam sauvegarde des VM sur un premier Nas1 en local, puis via Snapshot replication, réplique vers un second Nas2 sur un site distant via Internet

Serveur VPN installé sur le Nas1, je déclenche une connexion Openvpn via un script sur le Nas2 et attend que la tâche de réplication se déclenche sur le Nas1 .... puis déconnecte le VPN à une heure fixe via script.

Problème : le temps des backups Veeam est variable, du coup la connexion VPN est soit trop tôt, soit se coupe trop tôt; le but est d'être connecté juste le temps de la réplique !

Y a t'il un moyen pour déclencher a réplique depuis le Nas distant ? et d'exécuter une tache avant/après la réplique ?

Merci 😉

 

[.Shad.]

@nicodep Il y aurait sûrement moyen de le faire en ligne de commande via des tâches prédéfinies, mais pourquoi ne pas faire l'inverse ? client VPN sur NAS1, serveur sur NAS2, tu crées une tâche pour la connection et la déconnection (ou tu combines si tu es à l'aise en shell) avec une tâche utilisant la commande synosharesnap pour déclencher tes tâches de réplication.

Mais honnêtement ça m'a l'air complexe. Dans Snapshot Replication, de ce que je vois, tu peux chiffrer la connexion, tu pourrais donc passer en direct plutôt que de passer par un VPN en limitant les connexions entrantes pour le port 5566 à l'IP (si elle est fixe) du site de NAS1. Tu peux aussi créer sur NAS2 un utilisateur dédié à Snapshot Replication (avec des credentials forts) aux droits administratifs et permissions limités sur les dossiers partagés.

[nicodep]

Merci pour ton retour .Shad.

J'avais bien pensé à ton schéma, mais risque si le Nas1 est hacké, le hackeur peut déclencher la connexion client VPN et atteindre le Nas2 pour le véroler !

L'idée était justement l'inverse, par défaut le Nas2 est offline, c'est lui qui déclenche la connexion client VPN vers le Nas1 ... et idéalement lancer la réplication, mais comment lancer à distance cette commande ? cette fonction manque dans SnapReplication

Autre chose qui est idiot, lors de l'appairage entre les 2 Syno lors de création de la tâche de réplication, il faut atteindre DSM et se loguer avec un compte admin ! pourquoi ?

D'ailleurs je n'arrive pas à passer en 5001, uniquement en 5000 ?!

Ton idée d'un user dédié est intéressante, j'avais essayé mais blocage, sait tu quels droits sont nécessaires ?

😉

 

 

[.Shad.]

Il y a 4 heures, nicodep a dit :

J'avais bien pensé à ton schéma, mais risque si le Nas1 est hacké, le hackeur peut déclencher la connexion client VPN et atteindre le Nas2 pour le véroler !

Tu ne véroleras rien avec un utilisateur dédié aux droits limités, d'autant si tu as mis en place une politique de rétention des instantanés, tu pourrais récupérer des données saines. Maintenant tu dis qu'il faut te connecter avec un compte administrateur à l'établissement du lien ?

Parce qu'Hyper Backup demande aussi de se logger mais avec un compte non admin dédié au backup ça fonctionne.

Il y a 4 heures, nicodep a dit :

D'ailleurs je n'arrive pas à passer en 5001, uniquement en 5000 ?!

Est-ce que tu as coché l'option pour chiffrer le transfert des données ?

Il y a 4 heures, nicodep a dit :

Ton idée d'un user dédié est intéressante, j'avais essayé mais blocage, sait tu quels droits sont nécessaires ?

A minima les droits d'écriture sur le dossier dans lequel tes instantanés sont stockés et le droit d'utiliser Snapshot Replication. Peut-être DSM aussi si ça ne suffit pas.

[nicodep]

A minima les droits d'écriture sur le dossier dans lequel tes instantanés sont stockés et le droit d'utiliser Snapshot Replication. Peut-être DSM aussi si ça ne suffit pas.

Bref il faut donner les droits majeurs ! un hackeur sera en mesure de se connecter ... avec les droits admin ... et d'effacer les données !!

Pas très secure ce module Synology, il serait temps de revoir la méthode, je vais ouvrir un ticket chez eux

😉

 

[.Shad.]

il y a 24 minutes, nicodep a dit :

Bref il faut donner les droits majeurs ! un hackeur sera en mesure de se connecter ... avec les droits admin ... et d'effacer les données !!

Donner accès à DSM ne donne pas les droits administrateurs, je ne sais pas pourquoi tu dis ça.
Et si tu comptes uniquement sur tes snapshots pour te protéger c'est qu'il y a une faille dans ton plan de sauvegarde.
Tu peux par exemple t'inspirer de la méthode 3-2-1.

[nicodep]

C'est le cas pour la méthode 3-2-1

1- Une VM Veeam Backup sauvegarde la ferme de VMs sur un Synology local en NFS

2- USB Copy miroir vers un disque USB qui est éjecté automatiquement en fin de copie (rotation sur 2 disques externes)

3- Première réplique avec Snapshot Replication vers un autre NAS Synology local (liaison directe en RJ45 entre les 2 NAS)

4- Deuxième réplique avec Snapshot Replication vers un autre NAS Synology distant ==> et c'est cette copie là que je souhaite sécuriser au max en la rendant visible que le temps de la réplique

@.Shad. : tu voit une meilleur ou autre solution pour mieux sécuriser ?

😉

 

[.Shad.]

@nicodep Ca me semble ok, mais il n'empêche que ce que tu as dit plus haut est faux, donner l'accès à DSM ne donne pas accès à des droits majeurs. Ci-joints les droits de mon groupe backup :

 

Et le bureau de DSM se résume à ça :

[Mic13710]

@.Shad. tu peux même supprimer l'accès à DSM. Dans ce cas, tu n'as strictement rien dans la dernière vue puisque tu n'as plus d'accès avec ce compte 😉

[.Shad.]

@Mic13710 Je n'ai autorisé l'accès à DSM que pour montrer à @nicodep qu'accès DSM != droits admins