Journal Burp-UI rend vos backups sexy

44
4
sept.
2015

Bonjour Nal,

Aujourd'hui, je voudrais te parler d'un petit projet que j'ai démarré il y a environ 1 an et demi.

Ce projet se nomme Burp-UI, et comme son nom l'indique, il s'agit d'une interface au merveilleux programme de sauvegarde Burp. Je ne reviendrais pas sur ce dernier car il a déjà fait l'objet d'articles ici et .

Ce qu'on peut dire rapidement néanmoins, c'est que bien que simple dans son architecture, Burp ne dispose pas d'une interface très user-friendly, et je trouve cela malheureux, car la sauvegarde/restauration est quelque chose qui devrait être accessible au plus grand nombre.

J'ai donc décidé de me lancer dans le développement d'une interface qui permette de rendre l'utilisation de Burp plus simple/user-friendly. Il s'agissait là du premier défi, car je ne suis pas vraiment designer dans l'âme !
Le second défi que je me suis lancé avec ce projet était de le réaliser en Python, langage que je n'avais jamais utilisé auparavant.

Le projet me semble aujourd'hui présentable, c'est la raison de cet article. En effet, la dernière version stable (0.0.7) est sortie il y a environ une semaine. Voici l'annonce officielle (en anglais)

Le site officiel du projet se trouve ici.

Voici une liste non exhaustive des fonctionnalités présentes aujourd'hui :

  • différentes vues de reporting : statistiques par serveur, par client et par backup
  • possibilité d'administrer plusieurs serveurs via la même interface
  • possibilité de restaurer un/des fichier(s) directement depuis l'interface web (génération d'une archive téléchargeable)
  • support des backups chiffrés (ie. possibilité de restaurer depuis l'interface web des backups chiffrés côté client)
  • différents modules d'authentification (Basic ou LDAP)
  • support d'ACL (à ce jour il n'y a qu'un backend Basic)
  • possibilité d'éditer la configuration du serveur Burp depuis l'interface : ajout/suppression de clients, durées de rétentions, etc.
  • support des versions 1 et 2 de Burp

La documentation se trouve ici.

Il y a encore du chemin à parcourir et surtout des améliorations à faire sur l'UI en général (car ce n'est vraiment pas mon point fort), mais ça viendra avec le temps ;-)

N'hésitez pas à me faire part de vos questions et/ou remarques.

  • # YOLO

    Posté par . Évalué à -5.

    Ton site perso est crado' mais le projet est sexy !

    Merc..Burp' !

  • # Projet réussi :)

    Posté par . Évalué à 4.

    En effet, je pense que tu as accompli le but que tu t'étais fixé ici : ça donne envie de l'essayer ! Même si je n'ai pas besoin de soft de backup aujourd'hui, ça peut être utile à l'avenir…

    Par ailleurs, comment as-tu réalisé le gif sur ton site officiel ? Ça traîne sur pas mal de projets github, et ça m'intéresse si tu utilises un outil qui fait tout tout seul :) (oui je peux utiliser convert pour générer le gif… mais on est sur un journal user-friendly).

    • [^] # Re: Projet réussi :)

      Posté par (page perso) . Évalué à 6.

      En effet, je pense que tu as accompli le but que tu t'étais fixé ici : ça donne envie de l'essayer ! Même si je n'ai pas besoin de soft de backup aujourd'hui, ça peut être utile à l'avenir…

      Merci !

      Par ailleurs, comment as-tu réalisé le gif sur ton site officiel ? Ça traîne sur pas mal de projets github, et ça m'intéresse si tu utilises un outil qui fait tout tout seul :) (oui je peux utiliser convert pour générer le gif… mais on est sur un journal user-friendly).

      Mon projet a pour but de rendre accessible au plus grand nombre un projet qui peut sembler complexe, mais cela ne veut pas dire que je sois moi-même allergique au Principe_KISS ou à la ligne de commande ;-)

      Pour réaliser le gif j'ai donc utilisé convert comme suit :

      convert -delay 200 -loop 0 -dispose Background *.png output.gif
      
      • [^] # Re: Projet réussi :)

        Posté par . Évalué à 2.

        La ligne de commande me satisfait aussi très bien en général pour ce genre d'outil. Par contre c'est vrai qu'une interface web c'est souvent agréable pour le reporting quand on n'a pas envie de se polluer de mails mais qu'on veut regarder de temps en temps si tout va bien.

  • # Nouvel utilisateur de burp

    Posté par (page perso) . Évalué à 2.

    Je tiens a annoncer que je rechercher une solution de sauvegarde. Je comptais installer backuppc pour mes quelques machines chez moi, mais j'ai testé burp suite à ce journal et j'en suis content.

    J'ai également installé l'interface graphique.

    A mon sens, il me manque 2/3 choses pour être complètement heureux:
    * la suppression des entête VSS quand on restaure sous linux, j'ai du faire strip_vss = 1 pour résoudre le problème, mais du coup je dois préciser -x sous windows en plus de perdre ces entêtes.
    * je trouve l'interface graphique un peu lente (désolé) pour parcourir les 150Go de la backup dans une arborescence.
    * On a aucune information dans l'interface graphique de ce qu'économise bedup. D'ailleurs une fois que le script à tourner n fois dans un cron, on ne sais plus ce qu'on gagne.
    * Il manque une restauration dans un dossier en utilisant librsync. Le but serait de restaurer la dernière sauvegarde régulièrement dans un dossier (disque USB), en ne restaurant que les derniers fichiers modifiés. Du coup j'ai regardé du coté de burpfs mais il n'a pas fonctionné sur mon serveur :'(

    • [^] # Re: Nouvel utilisateur de burp

      Posté par (page perso) . Évalué à 2.

      Salut,

      • la suppression des entête VSS quand on restaure sous linux, j'ai du faire strip_vss = 1 pour résoudre le problème, mais du coup je dois préciser -x sous windows en plus de perdre ces entêtes.

      Est-ce que tu parles de Burp-UI ? En principe, je strip les fichiers contenants des en-tête VSS avant de générer l'archive lorsque tu utilises le bouton "Download" depuis Burp-UI.
      Si ça n'est pas le cas, c'est un bug et dans ce cas j'aimerais en savoir un peu plus sur la marche à suivre pour le reproduire. (N'hésite pas à ouvrir une issue sur le tracker du projet ou à m'envoyer un mail)

      Su tu parles de Burp par contre, via la commande "burp -a r -b X …", je ne peux que te conseiller de contacter l'auteur de Burp (via la mailing list du projet par exemple).

      • je trouve l'interface graphique un peu lente (désolé) pour parcourir les 150Go de la backup dans une arborescence.

      Je n'ai effectivement pas encore eu à traiter un volume conséquent de données (je n'ai qu'une dizaine de clients avec une volumétrie moyenne de 50Go par client).
      À quel(s) niveau(x) de l'interface rencontres-tu ces lenteurs ?
      Il faut savoir que j'essaie d'être le moins intrusif possible avec Burp-UI et j'essaie de traiter un maximum avec le status-port de Burp. La limitation peut donc également venir de ce dernier.
      Néanmoins, j'ai prévu dans ma roadmap d'ajouter un peu de caching par-ci par-là afin d'améliorer les performances de l'UI.
      Je réfléchis également à faire du pré-chargement en tâche de fond par exemple au niveau du browser car l'interface charge les informations petit à petit à chaque fois qu'on déroule un noeud.

      • On a aucune information dans l'interface graphique de ce qu'économise bedup. D'ailleurs une fois que le script à tourner n fois dans un cron, on ne sais plus ce qu'on gagne.

      Je ne comprends pas la question, mais encore une fois, il faut bien comprendre que Burp et Burp-UI sont deux projets totalement distincts gérés par deux personnes différentes. Je ne travaille "que" sur Burp-UI, même si j'échange assez régulièrement avec l'auteur de Burp.

      bedup n'est donc aucunement géré dans Burp-UI. Il peut s'agir ici d'une demande de feature, mais il faudrait que tu me détailles ton besoin car je n'ai malheureusement pas compris ta demande.

      • Il manque une restauration dans un dossier en utilisant librsync. Le but serait de restaurer la dernière sauvegarde régulièrement dans un dossier (disque USB), en ne restaurant que les derniers fichiers modifiés. Du coup j'ai regardé du coté de burpfs mais il n'a pas fonctionné sur mon serveur :'(

      Idem, je n'ai pas compris la demande. De plus, burpfs n'est pas un projet supporté par le développeur de Burp (pas plus que Burp-UI d'ailleurs).

      • [^] # Re: Nouvel utilisateur de burp

        Posté par (page perso) . Évalué à 3.

        Bonjour,

        Désolé, j'ai fait un peu un amalgame au niveau de mes réponses, car je me suis mis à utiliser tous les outils en même temps. Je vais essayer de répondre ci-dessous.

        la suppression des entête VSS quand on restaure sous linux, j'ai du faire strip_vss = 1 pour résoudre le problème, mais du coup je dois préciser -x sous windows en plus de perdre ces entêtes.

        Est-ce que tu parles de Burp-UI ? En principe, je strip les fichiers contenants des en-tête VSS avant de générer l'archive lorsque tu utilises le bouton "Download" depuis Burp-UI.
        Si ça n'est pas le cas, c'est un bug et dans ce cas j'aimerais en savoir un peu plus sur la marche à suivre pour le reproduire. (N'hésite pas à ouvrir une issue sur le tracker du projet ou à m'envoyer un mail)

        Su tu parles de Burp par contre, via la commande "burp -a r -b X …", je ne peux que te conseiller de contacter l'auteur de Burp (via la mailing list du projet par exemple).

        Mon besoin :
        * Je veux faire des sauvegardes incrémentales, avec un historique, et de façon complètement transparente (je ne veux pas surveiller en continu, je ne veux pas le lancer manuellement). Sur ce point burp fonctionne parfaitement. En cas de besoin burp-ui est là pour fouiller dans l'historique et voir si tout se passe bien.
        * Je veux également faire faire une sauvegarde externalisée. Le principe que j'utilise : Je copie tout sur un disque dur USB que je dépose régulièrement dans la famille en rotation avec un second disque. J'ai toujours un disque à la maison et le second dans la famille. Je fais une rotation toutes les semaines.

        Pour ce dernier point je fais une copie toutes les semaines du contenu de la dernière sauvegarde sur le disque dur USB. Jusqu'ici sans burp, un bête rsync me permettait de mettre à jour le contenu du disque dur USB avec la dernière version des 6 PC (environ un total de 900Go contenant des photos, énormément de petits fichier PSD/EPS, des sites en PHP contenant des frameworks volumineux de plusieurs milliers de fichiers …).

        Pour synchroniser la derniers sauvegarde burp avec le disque dur je pensais copier le dossier contenu du lien symbolique "current" avec le disque dur USB. Mais comme dans ce répertoire les fichiers ont un entête VSS pour windows et sont compressés, j'ai écarté cette idée. Je souhaite que le fichier soit facilement récupérable.
        La seconde solution est d'utiliser burp (dans un cron) et dans lancer la commande "burp -a r -C client -d /disqueUSB". Le problème est que si les fichiers sont déjà présents j'ai plein de warnings m'indiquant que les fichiers existent et ne sont pas écrasés, et si je force l'écrasement, ou si j'efface le disque, tous les fichiers sont copiés (900Go).
        Du coup contrairement à un rsync, la copie des fichiers est très longue. Une expérience de restauration dans un dossier m'a pris plusieurs dizaines d'heures. De plus la restauration de sauvegarde windows sous linux laisse l'entête VSS si l'option strip_vss n'a pas été positionnée..
        Je me suis alors tourné vers une solution telle que BurpFS qui m'aurait permis de représenter les sauvegardes sous la forme d'un système de fichiers lisibles afin de pouvoir faire un rsync entre la dernière version de burp et celle du disque USB, mais BurpFS n'a pas fonctionné.

        Pour l'instant j'en suis à ce stade, je n'ai pas encore de bonne solution à mon goût pour mettre à jour les sauvegardes présentes sur le disque USB.

        je trouve l'interface graphique un peu lente (désolé) pour parcourir les 150Go de la backup dans une arborescence.

        Je n'ai effectivement pas encore eu à traiter un volume conséquent de données (je n'ai qu'une dizaine de clients avec une volumétrie moyenne de 50Go par client).
        À quel(s) niveau(x) de l'interface rencontres-tu ces lenteurs ?
        Il faut savoir que j'essaie d'être le moins intrusif possible avec Burp-UI et j'essaie de traiter un maximum avec le status-port de Burp. La limitation peut donc également venir de ce dernier.
        Néanmoins, j'ai prévu dans ma roadmap d'ajouter un peu de caching par-ci par-là afin d'améliorer les performances de l'UI.
        Je réfléchis également à faire du pré-chargement en tâche de fond par exemple au niveau du browser car l'interface charge les informations petit à petit à chaque fois qu'on déroule un noeud.

        Là c'est bien au niveau de l'interface graphique Burp-UI : L'affichage est globalement rapide sauf lors de l'affichage des fichiers. Lorsque je veux afficher les fichiers d'une sauvegarde il faut une dizaine de secondes pour afficher la page (ie : http://server:8000/client-browse/pc-xxx/12).
        Ensuite je déplie le 1er nœud, il me faut 8 secondes pour afficher 3 répertoires. Puis une dizaine de secondes pour encore le noeud suivant, … . Je me doute bien que derrière Burp-UI est tributaire de Burp et attend que ce dernier lise le manifest à chaque fois pour en filtrer la liste des fichiers.
        Le fichier manifest de la dernière sauvegarde fait 16M gzippé et 119M dégzippé.

        On a aucune information dans l'interface graphique de ce qu'économise bedup. D'ailleurs une fois que le script à tourner n fois dans un cron, on ne sais plus ce qu'on gagne.

        Je ne comprends pas la question, mais encore une fois, il faut bien comprendre que Burp et Burp-UI sont deux projets totalement distincts gérés par deux personnes différentes. Je ne travaille "que" sur Burp-UI, même si j'échange assez régulièrement avec l'auteur de Burp.
        bedup n'est donc aucunement géré dans Burp-UI. Il peut s'agir ici d'une demande de feature, mais il faudrait que tu me détailles ton besoin car je n'ai malheureusement pas compris ta demande.

        La 1ère fois que j'ai lancé bedup, ce dernier m'a sorti qu'il avait pu libérer quelques Go en dédupliquant certains fichiers. Du coup j'ai mis ce dernier dans une tâche cron. Par contre je n'ai aucune info sur l'efficacité de bedup dans le temps sauf à envoyer des mails à chaque cron (pas de joli graphe).
        Même si je comprends bien que le programme est un peu à l'écart de burp, en tant qu'utilisateur je trouve ça dommage. A une époque j'avais utilisé backuppc. Ce dernier affiche quelques stats le nombre et la taille des fichiers dans le pool qui sont mutualisés.

        Il manque une restauration dans un dossier en utilisant librsync. Le but serait de restaurer la dernière sauvegarde régulièrement dans un dossier (disque USB), en ne restaurant que les derniers fichiers modifiés. Du coup j'ai regardé du coté de burpfs mais il n'a pas fonctionné sur mon serveur :'(

        Idem, je n'ai pas compris la demande. De plus, burpfs n'est pas un projet supporté par le développeur de Burp (pas plus que Burp-UI d'ailleurs).

        Pas de soucis, je cherchais juste une solution à mon problème de copie de sauvegarde sur disque USB.

        Sinon, je trouve Burp et Burp-UI très bien et c'est pour ca que je l'ai est choisi.

        • [^] # Re: Nouvel utilisateur de burp

          Posté par (page perso) . Évalué à 1.

          Mon besoin :
          * Je veux faire des sauvegardes incrémentales, avec un historique, et de façon complètement transparente (je ne veux pas surveiller en continu, je ne veux pas le lancer manuellement). Sur ce point burp fonctionne parfaitement. En cas de besoin burp-ui est là pour fouiller dans l'historique et voir si tout se passe bien.
          * Je veux également faire faire une sauvegarde externalisée. Le principe que j'utilise : Je copie tout sur un disque dur USB que je dépose régulièrement dans la famille en rotation avec un second disque. J'ai toujours un disque à la maison et le second dans la famille. Je fais une rotation toutes les semaines.

          Burp fournit un script qui devrait répondre à ton besoin. Je n'utilise pour éxternaliser mes sauvegardes en réseau, mais il doit être modifiable pour répondre à un besoin local.
          Regarde dans /etc/burp/offsite-backup (ou ici).
          C'est un script basé sur rsync avec gestion des hardlink. Ça devrait te permettre d'éviter de recopier tous tes backups à chaque fois.

          Là c'est bien au niveau de l'interface graphique Burp-UI : L'affichage est globalement rapide sauf lors de l'affichage des fichiers. Lorsque je veux afficher les fichiers d'une sauvegarde il faut une dizaine de secondes pour afficher la page (ie : http://server:8000/client-browse/pc-xxx/12).
          Ensuite je déplie le 1er nœud, il me faut 8 secondes pour afficher 3 répertoires. Puis une dizaine de secondes pour encore le noeud suivant, … . Je me doute bien que derrière Burp-UI est tributaire de Burp et attend que ce dernier lise le manifest à chaque fois pour en filtrer la liste des fichiers.
          Le fichier manifest de la dernière sauvegarde fait 16M gzippé et 119M dégzippé.

          Burp-UI ajoute forcément une petite latence puisqu'il doit parser le retour de Burp afin de générer un document JSON, mais Burp doit lui aussi reparser son Manifest à chaque fois. Avec Burp2 les performances ont été améliorées avec l'ajout d'un cache (la conséquence c'est une consommation accrue de RAM). Et j'essaierai également d'ajouter un peu de cache par la suite. Mais dans tous les cas, la première exécution de l'instruction ne pourra pas être grandement améliorée, seuls les appels futurs le seront.

          La 1ère fois que j'ai lancé bedup, ce dernier m'a sorti qu'il avait pu libérer quelques Go en dédupliquant certains fichiers. Du coup j'ai mis ce dernier dans une tâche cron. Par contre je n'ai aucune info sur l'efficacité de bedup dans le temps sauf à envoyer des mails à chaque cron (pas de joli graphe).
          Même si je comprends bien que le programme est un peu à l'écart de burp, en tant qu'utilisateur je trouve ça dommage. A une époque j'avais utilisé backuppc. Ce dernier affiche quelques stats le nombre et la taille des fichiers dans le pool qui sont mutualisés.

          Une telle fonctionnalité sous entendrait que Burp-UI serait en charge d'exécuter régulièrement bedup afin de tenir des statistiques. Avec Burp-UI j'ai voulu créer un programme simple dans son fonctionnement et dans son architecture. Cette demande apporterait beaucoup de complexité. De plus, je pense que bedup ne sera plus nécessaire avec Burp 2 puisque ce dernier procédera à de la déduplication en ligne.

          Maintenant, si tu veux savoir la place théorique qu'occupe un backup sur le disque, il y a 2 reports qui peuvent t'aider dans Burp-UI. Le premier est le report "global" qui te donnera la place utilisée par tel ou tel client. Le second est le report "par client", qui peut t'indiquer le volume de données reçu par backup.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.