Table des matières

Burp

Paramétrer le logiciel n'est qu'une part de la sauvegarde.

Il faut aussi passer du temps à voir quels dossiers sauvegarder.

Si vous avez des bases de donnée, pensez à réaliser un petit script qui va les sauver (dump) dans un dossier sauvegardé par Burp.

Les principes généraux de la sauvegarde d'un serveur sont dans l'article Processus de sauvegarde sur un serveur.

Trop de blabla ? La version courte de cet article est sur Burp rapide.

Burp, le logiciel de base

Installation de Burp

Le même paquet permet de faire client et serveur.

Sur Debian

sudo apt install burp

C'est le paramétrage des fichiers de configuration qui va faire que Burp agit en serveur, en client, ou les deux.

  • Le client est sur le serveur à sauvegarder, il va préparer les sauvegardes et les envoyer là où on lui demande.
  • Le serveur est à paramétrer où on va stocker les sauvegardes. Les clients se connectent à lui et lui envoient les sauvegardes. Le serveur gère combien de temps il archive le bazar.

Le serveur est aussi une autorité de certification pour les clients, les échanges se font en SSL.

Il faut toujours paramétrer un client sur le serveur, même s'il ne servira pas ensuite ; sinon il y a des soucis pour lire les sauvegardes.

Pour la suite de l'article, nous avons deux serveurs d'exemple :

  • Blanu, le serveur qu'on veut sauvegarder (soit “le client”, mais cette terminologie risque de prêter à confusion vu qu'on a des fichiers de configuration de client des deux côtés)
  • Xunre, le serveur qui va stocker les sauvegardes (soit “le serveur”, et ça prête déjà à confusion…)

En lojban, Blanu veut dire “bleu” et Xunre “rouge” ;-)

Astuce n°2 : Un backup, c'est trop peu !

Si, dans ce tutoriel, on va surtout détailler comment Blanu est sauvegardé sur Xunre, nous allons aussi envisager qu'un autre serveur de backup existe, Crino (“vert” en lojban). Crino fera aussi une sauvegarde de Blanu, en utilisant les mêmes mécanismes que Xunre. Mais comme il y a envoi de deux copies à deux serveurs, cela demande d'adapter l'architecture pour s'y retrouver !

Ainsi, la configuration dans Blanu pour l'envoie vers Xunre sera dans /etc/burp/xunre, et celle pour Crino dans /etc/burp/crino.

Paramétrer les fichiers de client

La partie client se configure avec le fichier /etc/burp/burp.conf.

Burp permet beaucoup de choses et ce fichier, abondamment commenté, donne un aperçu des possibilités.

Sur Blanu, nous allons copier ce fichier dans le dossier /etc/burp/xunre/burp.conf.

Nous allons faire simple et modifier uniquement les lignes suivantes :

Sur la machine client (Blanu), nous allons mettre le certificat dans notre dossier /etc/burp/xunre/ (ils seront automatiquement généré au premier contact avec xunre). Donc, modifiez les lignes suivantes :

ca_burp_ca = /usr/sbin/burp_ca
ca_csr_dir = /etc/burp/xunre/CA-client
ssl_cert_ca = /etc/burp/xunre/ssl_cert_ca.pem
ssl_cert = /etc/burp/xunre/ssl_cert-client.pem
ssl_key = /etc/burp/xunre/ssl_cert-client.key
# Attention celui-ci doit être le même nom côté serveur et client !
ssl_peer_cn = xunreserver

C'est tout pour le moment sur Blanu, il faut configurer un peu Xunre pour aller plus loin.

Ports, hyperviseurs, etc

Il y a aussi des indications de port (port = 4971 et status_port = 4972). Ne touchez pas à ça sans nécessité. Si vous êtes dans une configuration standard (deux serveurs dédiés, chacun son ip/nom de domaine) ça marchera simplement. Ne touchez pas à iptable !

Cas de deux VM sur le même hyperviseur

La bonne pratique d'une sauvegarde consiste à envoyer les données sauvegardées dans un autre lieu physique (de préférence distant de plusieurs centaines de kilomètres). Ainsi, si le datacenter crame, vous n'avez pas tout perdu.

Mais diverses raisons peuvent amener à sauver une VM sur une autre, sur le même hyperviseur. Si vous savez ce que vous faites…

Si Xunre et Blanu sont deux VM sur le même hyperviseur, elles communiqueront très bien avec ces ports par défaut, sans toucher à iptable. Par contre, l'adresse de Xunre (nom de domaine) va poser souci. Il faut passer par les ip internes.

On peut faire mentir le DNS, en ajoutant l'ip par rapport au nom de domaine.

Par exemple, dans /etc/hosts de Blanu (mon client), j'ajoute l'ip interne de Xunre.

192.168.20.13 xunre.khaganat.net

Si ce n'est pas fait, lors d'une sauvegarde, on aura l'erreur suivante :

2019-06-09 08:18:19: burp[24782] Could not find ssl_cert /etc/burp/xunre/ssl_cert-client.pem: No such file or directory
2019-06-09 08:18:19: burp[24782] Could not find ssl_key /etc/burp/xunre/ssl_cert-client.key: No such file or directory
2019-06-09 08:18:19: burp[24782] Could not find ssl_cert_ca /etc/burp/xunre/ssl_cert_ca.pem: No such file or directory
Cas d'un client envoyant vers un serveur dans une VM

Dans le cas où Blanu est sur un dédié, et que Xunre est sur un autre dédié MAIS dans une VM, il y a aussi un problème, lié au fait que le nom de domaine ne va pas forcément renvoyer sur la VM. Pour être plus précis, ici on ne passe pas par Apache.

À ce moment, on va bidouiller iptable. Plus précisément, on va faire que les deux ports en question de l'hyperviseur renvoie sur ceux de la VM. Dans l'exemple suivant, remplacez 192.168.20.16 par l'ip interne de votre VM servant à la sauvegarde :

iptables -t nat -I PREROUTING -p tcp --destination-port 4971 -j DNAT --to 192.168.20.16:4971
iptables -t nat -I PREROUTING -p tcp --destination-port 4972 -j DNAT --to 192.168.20.16:4972

iptables-save > /etc/iptables/iptables.rules

Paramétrer la partie serveur

Sur Xunre, qui va stocker les sauvegardes, le client doit aussi être configuré, comme indiqué au dessus, mais on va aussi en plus paramétrer /etc/burp/burp-server.conf.

Paramétrez “keep” (comment on garde les sauvegardes). On créé autant de lignes “keep = ” à la suite que nécessaire. Le code suivant se lirait : une sauvegarde par jour pendant 7 jours, puis une par semaine pendant 4 semaine, puis une par quatre semaine pendant 6 périodes de quatre semaines. Donc 6 mois de conservation maximum, mais en éliminant des redondances au fil du temps.

keep = 7
keep = 4
keep = 6

On peut aussi modifier où sont stockées les sauvegardes. C'est le paramètre suivant (et sa valeur par défaut) :

directory = /var/spool/burp

On peut aussi modifier les valeurs du CA. Laisser la configuration par défaut est aussi simple et évitera des erreurs par la suite :

ca_conf = /etc/burp/CA.cnf
ca_name = burpCA
ca_server_name = burpserver
ca_burp_ca = /usr/sbin/burp_ca

Si le client a comme valeur

ssl_peer_cn = xunreserver

Alors le serveur doit avoir la valeur

ca_server_name = xunreserver

Déclarer les clients

Toujours dans ce fichier, pour pouvoir restaurer d'autres clients que le local, indiquer leurs noms (autant de ligne que de clients) :

restore_client = xunre
restore_client = blanu

Enregistrez.

Il faut encore déclarer ailleurs les détails du ou des clients à sauver. Chaque client est représenté par un fichier dans /etc/burp/clientconfdir/, sur le serveur (Xunre). On crée donc un fichier /etc/burp/clientconfdir/Machin, dans lequel on renseigne la même chose que pour cname et password dans la config des clients. Attention, il faut paramétrer le client local sur Xunre; même si on n'a pas prévu de s'en servir ; ici, ce sera le fichier /etc/burp/clientconfdir/xunre, en plus de /etc/burp/clientconfdir/blanu.

sudo nano /etc/burp/clientconfdir/blanu

Le contenu minimal du fichier ressemble à ça (en mettant le bon mot de passe) :

cname = blanu
password = abcd

Lancer les sauvegardes, contrôler que tout marche

Sur le serveur Xunre, lancer la commande suivante, qui va générer les certificats SSL :

sudo burp -c /etc/burp/burp-server.conf

Sur chacun des serveurs, lancer la commande suivante, qui va vérifier que tout se passe bien, sans rien écrire (cela liste les sauvegardes, aussi, quand il y en a) :

sudo burp -c /etc/burp/xunre/burp.conf -a l

S'il n'y a pas d'erreur SSL ou autre, c'est le moment de faire un backup à la main (à lancer dans screen/tmux parce que ça peut être long !) :

sudo burp -c /etc/burp/xunre/burp.conf -a b

Explication :

Pour vérifier les sauvegarde d'un client externe, par exemple, sur Xunre, vérifier qu'on a bien les sauvegardes de Blanu :

sudo burp -a l -C blanu

Réaliser les sauvegardes régulières

Cela fonctionne juste avec cron.

Côté client (Blanu)

Si tout va bien, il est temps de paramétrer des sauvegardes régulières.

Sur votre client Blanu, créez les règles suivantes dans le cron de l'utilisateur root (crontab -e en tant que root).

Pour le client :

20 4 * * * /usr/sbin/burp -c /etc/burp/xunre/burp.conf -a t -q 1200 >>/var/log/burp-client 2>&1

Si vous envoyez les sauvegardes à un second serveur, vous pouvez ajouter la ligne suivante :

20 4 * * * /usr/sbin/burp -c /etc/burp/crino/borg.conf -a t -q 1200 >>/var/log/burp_2sauvgarde 2>&1

Voici à quoi devrait ressembler votre cron pour la partie concernant Burp :

# CLIENT Burp
20 4 * * * /usr/sbin/burp -c /etc/burp/xunre/burp.conf -a t -q 1200 >>/var/log/burp-client 2>&1

# Si vous avez du mysql ou autre BDD, pensez au script 
00 1 * * * /home/user/script/mysqlbackup.sh

Retrouvez le superbe script de sauvegarde des bases de donnés sur cette page.

Côté serveur (Xunre)

Votre crontab reprend les mêmes éléments côté client mais ajoute des éléments côté serveur pour s'assurer que tout va bien (pensez à changer l'email et à vous assurer que votre serveur sait envoyer des mails) :

# SERVER Burp
# Envoie un résumé à 6h (donc, tous les jours).
0 6 * * * /usr/sbin/burp -a S | mail -s "Résumé des backup" admin@mon email.com

# The following will run file deduplication over all client storages every
# Saturday at 8 in the morning. Again, if your server is using a different
# config file to /etc/burp/burp-server.conf, change that argument.
#0 8 * * 6 /usr/sbin/bedup -l -c /etc/burp/burp-server.conf >>/var/log/burp-bedup 2>&1

Cette partie serait à améliorer : envoyer un mail s'il y a un souci, plutôt ?

La déduplication, j'ai pas tout compris, et ça semble plutôt se paramétrer dans le fichier de conf, mais je laisse le code (commenté) pour qui pourra comprendre.

Restaurer une sauvegarde

Si on veut contrôler, on peut décompresser une archive dans un dossier temporaire sur le serveur (option -d /chemin/).

sudo burp -a r -b 0000001 -d /home/user/burptemp/

Pour décompresser une archive venant d'une autre machine, on ajoute -C Nomduclient :

sudo burp -a r -C blanu -b 0000001 -d /home/user/burptemp/

Les options :

Restauration simplement dans le client

burp -ar -C nom_du_client

Sauvegarder sur un deuxième serveur

Faire une copie du fichier de configuration client pour le deuxième serveur, Crino :

cp /etc/burp/burp.conf /etc/burp/crino/burp.conf
nano /etc/burp/crino/burp.conf

Changer l'adresse du serveur, le mdp, peut-être le nom du client pour ne pas s'emmêler les pinceaux ? Ainsi que l'emplacement du certificat.

server = crino
password = *******
cname = blanucrino

ca_burp_ca = /usr/sbin/burp_ca
ca_csr_dir = /etc/burp/crino/CA-client
ssl_cert_ca = /etc/burp/crino/ssl_cert-client_ca.pem
ssl_cert = /etc/burp/crino/ssl_cert-client.pem
ssl_key = /etc/burp/crino/ssl_cert-client.key

ssl_peer_cn = crino

Crino (côté second serveur, donc), doit avoir son nom en rapport pour le certificat :

ca_server_name = crino

Lancer la commande de vérification depuis Blanu :

burp -c /etc/burp/crino/burp.conf -a l

Pour lancer une sauvgarde manuellement:

burp -c /etc/burp/crino/burp.conf -a b

Burp-ui , interface web

L'interface web peut simplifier certaines opérations et c'est plus visuel. Cependant il faudra quand même paramétrer proprement Burp en amont.

Cette partie n'est pas assez testée, on n'a pas encore fait marcher ce truc.

Installation de Burp-ui

Voir https://burp-ui.readthedocs.io/en/latest/installation.html

En root :

apt install python3-pip
pip3 install burp-ui

Pour voir si tout fonctionne :

burp-ui --

Par défaut, le fichier de configuration se trouve dans /usr/local/share/burpui/etc/burpui.sample.cfg. Renommez-le en burpui.cfg (ou plutôt, créez un fichier burpui.cfg avec juste les infos utiles).

Si vous testez juste “si ça marche”, le couple login/mot de passe par défaut est admin/admin.

burpui.cfg

Changez la partie concernant les identifiants. Il y a plusieurs possibilités, y compris LDAP. Cf https://burp-ui.readthedocs.io/en/latest/advanced_usage.html#authentication (doc à améliorer ici).

bloc à faire : paramétrer un fichier de conf idéal, commenté, et le partager ici.

configuration service

bloc à faire : expliquer comment faire que burpui soit en prod, donc toujours lancé.

configuration web

Apache2

 

Nginx :

Sur le serveur où est installé burp-ui :

server {
    listen 80;
    server_name burpui.example.com;
 
    access_log  /var/log/nginx/burpui.access.log;
    error_log   /var/log/nginx/burpui.error.log;
 
    location / {
 
        # you need to change this to "https", if you set "ssl" directive to "on"
        proxy_set_header   X-FORWARDED_PROTO http;
        proxy_set_header   Host              $http_host;
        proxy_set_header   X-Forwarded-For   $remote_addr;
 
        proxy_read_timeout 300;
        proxy_connect_timeout 300;
 
        proxy_pass http://localhost:5000;
    }
}

Si la VM où est burp-ui est elle-même derrière un proxy, la VM-proxy doit contenir un fichier de configuration de ce genre :

server {
    listen      192.168.20.35:443 ssl http2;
    server_name "burpui.example.com";

    location / {
        proxy_set_header    Host $host;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass          http://192.168.20.40/;
    }
}

Erreurs diverses

Sur le serveur

main socket: network read problem

L'install de base a foiré, vous avez purgé le paquet, recommencé, et vous avez cette erreur :

2020-12-16 09:43:46 +0000: burp[6400] Connecting to localhost:4971
2020-12-16 09:43:46 +0000: burp[6400] main socket: network read problem in asfd_do_read_ssl: 1 - 0=Success
140108238101952:error:1409441B:SSL routines:ssl3_read_bytes:tlsv1 alert decrypt error:../ssl/record/rec_layer_s3.c:1544:SSL alert number 51
2020-12-16 09:43:46 +0000: burp[6400] This is probably caused by the peer exiting.
2020-12-16 09:43:46 +0000: burp[6400] Please check the peer's logs.
2020-12-16 09:43:46 +0000: burp[6400] problem with auth

Faites

sudo ps -A | grep burp

Et tuez le processus, puis relancez les commandes.

could not connect to x:4971

Après un reboot, j'ai eu ceci lors d'une quelconque commande avec burp :

sudo burp -c /etc/burp/burp.conf -a l
2023-07-28 06:05:20 +0000: burp[10783] Connecting to (adresse ip):4971
2023-07-28 06:05:20 +0000: burp[10783] could not connect to (adresse ip):4971

Simplement, le démon de burp sur le serveur ne s'est pas rallumé…

Pour le lancer :

sudo burp -c /etc/burp/burp-server.conf

Sur le client

Peer exiting

On a changé le serveur où sauver les choses, et là, burp nous dit ça côté client :

burp -a l
2020-12-16 10:10:40 +0000: burp[7295] Could not find ssl_cert_ca /etc/burp/ssl_cert_ca.pem: No such file or directory
2020-12-16 10:10:40 +0000: burp[7295] Connecting to nuxru.khaganat.net:4971
2020-12-16 10:10:40 +0000: burp[7295] main socket: network read problem in asfd_do_read_ssl: 1 - 0=Success
140426189172160:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:../ssl/record/rec_layer_s3.c:1544:SSL alert number 48
2020-12-16 10:10:40 +0000: burp[7295] This is probably caused by the peer exiting.
2020-12-16 10:10:40 +0000: burp[7295] Please check the peer's logs.
2020-12-16 10:10:40 +0000: burp[7295] problem with auth

Ici aussi, tuez le processus ET supprimez le certificat actuel :

sudo rm /etc/burp/ssl_cert*

En relançant la commande, cela le régènerera.

unexpected command in authorise_client

burp -c /etc/burp/nuxru/burp_nuxru.conf -a l
2020-12-16 10:53:00 +0000: burp[1190987] Could not find ssl_cert /etc/burp/nuxru/ssl_cert-client.pem: No such file or directory
2020-12-16 10:53:00 +0000: burp[1190987] Could not find ssl_key /etc/burp/nuxru/ssl_cert-client.key: No such file or directory
2020-12-16 10:53:00 +0000: burp[1190987] Could not find ssl_cert_ca /etc/burp/nuxru/ssl_cert_ca.pem: No such file or directory
2020-12-16 10:53:00 +0000: burp[1190987] Connecting to nuxru.khaganat.net:4971
2020-12-16 10:53:00 +0000: burp[1190987] unexpected command in authorise_client(): e:001D:unable to authorise on server

Avant de trop s'exciter… Simplement vérifier que côté serveur, le client a été renseigné dans /etc/burp/clientconfdir/monclient et que la ligne restore_client = monclient est ajoutée dans /etc/burp/burp-server.conf.

Sources, Liens utiles

Voir aussi :