Question de sécurité

[RobertG]

Bonjour,

Suite au problème d'impossibilité de transfert sortant de fichiers de sauvegarde Akeeba par ftp avec ou sans curl depuis les serveurs N0C de PlanetHoster, j'ai créé un script PHP pour récupérer ces fichiers sur un serveur avant de les renvoyer sur mon serveur de backups.
Le processus est

PlanetHoster-->import dans un sous-domaine Nuxit contenant le script PHP-->export vers le serveur de backups Nuxit (sans PHP)

Le sous-domaine utilise un nom constitué d'une multitude de chiffres et lettres (pointant sur un dossier à même nom complexe), le fichier de script a lui aussi un nom du même type.
Ce script récupère dans un autre dossier du serveur un fichier ini comportant les infos d'accès aux serveurs sortant et entrant. Ce dossier a lui aussi un nom du même type.
Les dossiers comportent un fichier index.html vide, le .htaccess principal du serveur interdit le listing des dossiers.
J'envisage un .htaccess dans chaque dossier (script et infos serveurs) contenant ce type de code (mon serveur ayant sa propre IP)

order deny,allow
deny from all
allow from IP du serveur​

Mon souci est que ces infos d'accès aux serveurs sont en clair, mais je ne vois pas comment gérer un cryptage réversible.
L'adresse est de ce type : est-elle assez sécurisée ?

https//ls42VEChBnGJ5DNH.domaine.tld/client_d7YMh0ToVmJzImSU.php

Merci de vos conseils,

[roland_d_alsace]

Hello.
Tu bosses pour la cia ?
Si j’ai bien compris ton script de transfert testé déjà l’ip du demandeur avant de commencer le transfert.
Sinon tu peux encore ajouter un jeton.
Du type à chaque lancement le script génère un nouveau jeton nécessaire au lancement suivant.
Comme Joomla le fait pour la sécurité des formulaires html.

[RobertG]

Merci Roland !

Non, mais je ne voudrais pas que quelqu'un puisse récupérer les identifiants d'accès aux serveurs des sites de mes clients concernés et à mon serveur de backups.

Le script ne teste pas l'IP ; je ne sais pas comment faire, sinon en utilisant le .htaccess, quant au jeton, pas mieux.

Ce script est lancé par une tâche planifiée une fois par semaine.

Au départ, l'idée d'un tel script répondait à un projet : dupliquer les sauvegardes depuis un serveur de stockage vers un autre serveur de stockage, partant d'une discussion où il avait été rappelé par jfque qu'un intrus ayant accès à l'administration pourrait supprimer toutes les sauvegardes. Mais pour le moment je n'en ai qu'un et la modification du pare-feu PlanetHoster fin mars a bloqué toutes les sorties ftp envoyées par PHP, dont celles d'Akeeba ou de scripts spécifiques, ce qui a accéléré les choses.

[Fred2FR3]

Ton problème est que tes backups sont accessibles via une URL ou une admin quelconque si j'ai bien compris ?

Si mon visu de la situation est juste et que tu possède un serveur dédié, suffit de créer un dossier inaccessible au protocole ftp ou http(s) avec une configuration pour l'acces au dossier en question via un protocole SSH, pourquoi pas avec clé public/privée.

[RobertG]

Les backups sont accessibles depuis la gestion d'Akeeba, dans l'administration du site, où on peut les supprimer, que ce soit ceux locaux ou ceux à distance.
Le risque est donc qu'un pirate accédant à l'administration puisse totalement détruire site et sauvegardes (sauf celles de l'hébergeur, s'il en fait et les met à disposition de son client).

[Fred2FR3]

Oui, j'ai donc bien compris. Tu trouveras sur internet des scrip shell (.sh) qui se lancent via Cron directement du serveur. Ca te met ca quelque par dans un dossier (meme distant) de ton choix et cela sera invisible en back-off

[RobertG]

Merci Fred, mais je dois dire que j'ai du mal à te suivre. Le codage et moi ça ne fait pas deux, mais presque, et la gestion de serveur, c'est pire...

Mon serveur de backups n'est qu'un serveur de stockage, sans aucune gestion possible (pas de PHP, pas de tâches cron, etc.).
Mon besoin actuel est de transférer les sauvegardes Akeeba depuis le(s) serveur(s) N0C PlanetHoster de mon/mes client(s) (puisque sa/leur sécurité bloque les envois par ftp/curl depuis un script PHP, ce qu'utilise d'Akeeba, et que j'ai confirmé par un script maison) vers mon serveur de stockage.

A ce propos, je n'ai pas trouvé de solution avec PHP pour transférer directement du serveur d'origine à celui de destination.
Je suis donc obligé d'utiliser un script PHP placé dans un sous-dossier de mon serveur de sites et accessible avec une adresse de sous-domaine du type de celle citée plus haut.
Les infos d'accès aux serveurs sont donc sur le même serveur que le script PHP.

Un tel script pourra aussi être utilisé pour un transfert de sauvegardes Akeeba non plus depuis le serveur du site du client, mais entre deux serveurs de backups, lorsque j'aurai fait mon choix pour le second.

La question de sécurité concerne le cas où quelqu'un accéderait à mon serveur et plus précisément au dossier contenant les informations d'accès au serveur du client et au serveur de stockage.
J'ai jeté un œil au cryptage réversible que je pourrais utiliser au moins pour le mot de passe, mais je dois dire que je n'y ai rien compris.

[roland_d_alsace]

Ton problème est que tes backups sont accessibles via une URL ou une admin quelconque si j'ai bien compris ?

Si mon visu de la situation est juste et que tu possède un serveur dédié, suffit de créer un dossier inaccessible au protocole ftp ou http(s) avec une configuration pour l’accès au dossier en question via un protocole SSH, pourquoi pas avec clé public/privée.

Il est sur qu'un script shell lancé par un cron avec un mysqldump /chaque db, ceci sur chaque serveur de prod, puis un rsync lancé par cron sur un autre serveur dédié "sauvegardes" (chez moi j'utilise un vieux PC sous linux) et l'affaire est réglée, mais besoin d'akeeba backup.
Mais il me semble qu'il y a déjà une discussion sur le sujet..., et que RobertG avait dit que cela ne convenait pas...

[RobertG]

Pour compléter ma précédente réponse à Fred, les sauvegardes Akeeba sont accessibles depuis l'administration du site (et une URL permet de les récupérer depuis le serveur distant avec kickstart d'Akeeba).
Depuis l'administration d'Akeeba backup, on peut supprimer les sauvegardes locales mais aussi celles distantes. C'est ce qui a motivé mon autre discussion : copie des sauvegardes distantes vers un autre serveur inaccessible depuis l'administration du site.

Actuellement, c'est le blocage des sorties par PlanetHoster qui m'oblige à faire ces manipulations entre les sauvegardes locales et mon serveur de backups.

Je ne crois pas que je pourrais utiliser rsync en cron chez PlanetHoster. L'exemple donné dans la gestion utilise wget et une URL, ou encore

Exemple général php -q /home/djdaeqtk/modules/cron.php >/dev/null 2>&1

donc ouverture d'un fichier dans les deux cas.
Chez Nuxit, c'est également une URL qui est utilisée par la tâche.

Par ailleurs, récupérer chez moi les sauvegardes n'est pas pensable, car faute de fibre, renvoyer celles-ci en cas de besoin de restauration ou de tests sur un autre serveur serait une perte de temps considérable.
Je n'oublierai jamais, à l'époque où j'utilisais le mini-PC pour ça, le vidage complet et inexpliqué de tous les dossiers d'un site hébergé alors chez Gandi, à une époque où je n'utilisais pas Akeeba, et le temps infini que ça m'a pris, le site étant lourd.

[Fred2FR3]

Salut,
J'ai lu rapidement la fin de l'ancienne conversation. roland_d_alsace, on a un peu pres la meme facon de travailler, sauf que je ne m’embête plus avec du local, au prix d'un Kimsufi en raid 1 qui ne coute meme pas le prix en electricité que consomme un serveur a la maison + l'espace de sauvegarde offert chez OVH + une sauvegarde via ISPConfig, mes clients ne risquent pas de perdre quoi que ce soit. J'offre en plus un espace owncloud sur le(s) Kimsufi qui permet aux clients d'en faire ce qu'ils en veulent tout en profitant de leur sauvegarde

Bref pour ce qu'il en est du probleme ici présent, interdire le dossier de sauvegarde en lecture ne serait il pas une solution simple et efficace ?

Source : https://www.tuteurs.ens.fr/unix/droits.html

[edit] Oup's tu as répondu entre temps Robert !

[RobertG]

Merci Fred pour cette idée, même si je ne suis pas certain de pouvoir l'appliquer aux dossiers du serveur de backup (par défaut en 770).

Et si j'applique un CHMOD 700 au dossier ou 600 au fichier contenant les infos des serveurs distants, ça ne me protégera pas si un indésirable arrive à accéder au contenu du serveur.
Sur mon serveur Nuxit où se trouve le script de transfert, j'ai souvent des sites de tests et je crains de parfois les oublier et donc de prendre le risque de rater des mises à jour, donc de les fragiliser.

[Fred2FR3]

Peux tu lancer un cron sur le serveur de backup ? Genre un .php qui pourrait travailler sur la sauvegarde ?
Une copie, un renommage du dossier casserait le lien a partir de l'admin Joomla et la lecture du .php sur le serveur 1 n'y changerai rien puisque les accès auront changés en amont. Tu pourrait même créer des .htpassword a la volée en plus !
Bref, tu pourrais faire ce que tu veux

[RobertG]

Non, le serveur de backups n'est qu'un hébergeur de fichiers.
Et compliquer au nveau de ce serveur rendrait impossible la récupération des fichiers en cas de besoin.

[Fred2FR3]

J'ai épuisé toutes mes idées, je crois que tu es a la limite de ce qu'un mutualisé peu offrir en terme de sauvegarde automatisée. Après j'ai pas la science infuse et le temps ou j'utilisais du mutu est lointain. J'espère qu'un autre membre te donnera d'autres pistes.

Je te suggère vivement d'essayer un petit dédié ou un VPS pas cher pour découvrir, ne serai ce que pour des tests persos. Ca peut paraitre compliqué, mais en fait non, il existe des panels d'admin très efficaces et de surcroit complètement open source.

Regardes, juste pour tester : https://www.ovhcloud.com/fr/vps/

La petite doc pour installer ISPConfig : https://www.howtoforge.com/ispconfig...debian-ubuntu/

Et tu es le roi du monde, une fois installé, plus besoin de ligne de commande (bien qu'il soit tout de meme recommandé de faire les MAJ en ligne de commande, mais ISP peu le faire via son interface). Backup automatisé et sécure.

[RobertG]

Merci Fred !

Ah non, je me suis essayé deux fois avec des VPS, avec plusieurs années d'intervalle, et la gestion de serveurs n'est pas mon truc. J'ai hésité ces derniers temps en cherchant un deuxième serveur de stockage, mais j'ai encore renoncé.

Pour ce qui est de la ligne de commande, j'ai tellement souffert avec DOS il y a une bonne trentaine d'années que je ne peux plus imaginer l'utiliser.
Mon premier programme perso a été une gestion horodatée de sauvegardes utilisant les exécutables ZIP et LhArc, au début des années 90, en Basic...

Et le problème n'est pas la sauvegarde elle-même mais le transfert de fichiers de serveur à serveur, et plus précisément aujourd'hui "comment sécuriser au mieux les infos d'accès aux serveurs" qu'utilise mon script.
Akeeba backup Pro a l'avantage de la simplicité des sauvegardes et restaurations, je ne l'abandonnerai pas.