Comment protéger les bases de données Firebird contre les ransomwares ?
06-décembre-2016, par Alexey Kovyazin
Les attaques par ransomware sont devenues un problème sérieux pour de nombreuses entreprises : au cours de la dernière semaine, nous avons eu 3 incidents chez différents clients dont les bases de données Firebird ont été chiffrées par des virus ransomware. Heureusement, nous avons pu aider tous ces clients, mais l’ampleur du problème ne cesse d’augmenter.
Dans cet article, nous allons examiner comment ces problèmes ont été résolus.
En général, un ransomware n’est pas conçu pour chiffrer spécifiquement les bases de données Firebird ; il chiffre simplement tous les fichiers de l’ordinateur, puis demande une rançon pour fournir le mot de passe de déchiffrement, et même si vous payez, vous pouvez ne recevoir aucun mot de passe de déchiffrement ni aucune réponse (il est également nécessaire de consulter les sites Web des antivirus : ils publient souvent des codes PIN ou même des outils de déchiffrement pour ce ransomware. Par exemple, l’un d’eux : noransom.kaspersky.com/)
Bien sûr, il est nécessaire d’avoir un antivirus fiable (et adapté aux serveurs), mais pouvons-nous faire quelque chose de spécifique pour protéger les bases de données Firebird ?
Il existe différents types de ransomware, examinons leur impact sur les bases de données Firebird.
Les 2 entreprises ont été victimes d’un ransomware qui a partiellement chiffré leurs bases de données Firebird.
Comme vous le savez, le fichier de base de données Firebird est un ensemble de pages de même taille. Les pages de base de données dans Firebird contiennent différents types d’informations : métadonnées, données utilisateur, index, générateurs, etc.

Généralement, ce type de ransomware ne chiffre pas la totalité du fichier de base de données, mais une petite partie de celui-ci - la page d’en-tête et un certain pourcentage de pages de base de données à l’intérieur de la base.
Comme toutes les pages ont des relations étroites, même quelques pages chiffrées rendent la base de données entière illisible par le moteur Firebird. Par exemple, dans une base de données de 10 Go, moins de 1 % des données étaient chiffrées, et les 99 % restants étaient intacts.
Dans ce cas, une telle base de données chiffrée peut être considérée comme un fichier de base de données gravement corrompu, et IBSurgeon FirstAID est l’outil qui peut effectuer l’exportation des données à partir du fichier de base de données Firebird chiffré. La même approche est utilisée pour récupérer des bases de données à partir de disques durs corrompus.
Exportation des données depuis la base de données Firebird chiffrée
IBSurgeon FirstAID peut récupérer des bases de données avec une réparation directe ou avec une extraction de données. La réparation directe est rapide, elle peut corriger rapidement les corruptions directement dans le fichier de base de données. Cependant, dans le cas d’un ransomware, cela ne sera pas utile, car la page d’en-tête et les principales métadonnées sont perdues, donc l’extraction est la seule option.
FirstAID lit le fichier de base de données directement - il n’utilise pas Firebird pour accéder au fichier de base de données, il lit le fichier directement, octet par octet. Comme il se concentre uniquement sur l’extraction des données corrompues et sacrifie les performances, FirstAID peut exporter des données même à partir de bases de données Firebird gravement corrompues. Bien sûr, FirstAID ignore les données chiffrées comme corrompues et n’exporte que les bonnes données.
Si le ransomware n’a pas chiffré les métadonnées critiques, il est possible d’ouvrir le fichier de base de données chiffré avec FirstAID et de prévisualiser les enregistrements : sélectionnez la table dans la liste à gauche et ouvrez l’onglet Aperçu, puis parcourez les pages de données.
Les enregistrements que vous pouvez voir peuvent être exportés vers une nouvelle base de données avec la même structure :

Le montant approximatif des pertes peut être estimé avec le pourcentage de pages endommagées dans l’onglet Résumé des pages pour la base de données :

Le pourcentage de pages endommagées indique combien de pages de base de données ont été chiffrées et leurs données sont perdues.
Ainsi, dans 2 cas, les bases de données ont été sauvegardées à l’aide de l’extracteur FirstAID, qui a exporté les données des bases de données chiffrées.
Ransomware avec chiffrement à 100 %
Malheureusement, les ransomwares chiffrent souvent 100 % des fichiers, et les chiffrent totalement, sans exception.
Généralement, ce type de ransomware injecte un code malveillant dans le chargeur de démarrage du système d’exploitation, puis redémarre l’ordinateur et simule l’exécution de CHKDSK, mais au lieu de vérifier les disques, il chiffre tout.
La seule façon de se protéger contre un tel virus est de disposer d’une sauvegarde de la base de données importante sur un emplacement tiers : dans le cloud ou dans un autre bureau.
Il existe 4 approches possibles de sauvegarde pour les bases de données Firebird :
- Sauvegarde complète vérifiée avec gbak
- Sauvegarde incrémentale non vérifiée avec nbackup
- Sauvegarde au niveau de la machine virtuelle (pour environnement virtuel)
- Warm Standby (miroir de base de données), basé sur la réplication
Quelle méthode de sauvegarde est la meilleure pour se protéger contre les ransomwares ? Examinons leurs avantages et inconvénients sur l’exemple concret d’une base de données Firebird de 50 Go.
| Fonctionnalité | Sauvegarde complète vérifiée (gbak) | Sauvegarde incrémentale (nbackup) | Sauvegarde au niveau de la machine virtuelle | Warm-standby (réplication) |
|---|---|---|---|---|
| Taille à téléverser | ~30 Go chaque jour | 50 Go initialement, puis portions modifiées | ||
| Fréquence maximale de sauvegarde | Chaque jour | Chaque heure | Dépend des paramètres de l’outil de sauvegarde de la machine virtuelle | Chaque minute |
| Dégradation des performances de la base de données | Élevée | Modérée | Faible | Très faible |
| Fiabilité de la méthode de sauvegarde | Élevée | Faible | Faible | Élevée |
| Temps requis pour effectuer la sauvegarde | 2-3 heures (dépend de la vitesse d’E/S) | Initial : 15-20 minutes pour créer le niveau 0, puis 3-4 minutes | Nécessite une capture complète du disque (dépend des E/S et de la taille du disque) | Initial : 15-20 minutes, toujours en ligne |
Sauvegarde complète vérifiée avec gbak
L’outil de sauvegarde (gbak) lit la base de données entière et la stocke dans un format spécial (fbk). Cette méthode de sauvegarde est appelée vérifiée car elle lit chaque enregistrement de la base de données et garantit que la base est saine. C’est une méthode de sauvegarde très fiable.
Cependant, la sauvegarde complète vérifiée n’est pas pratique pour la sauvegarde cloud de bases de données suffisamment volumineuses (comme 50 Go dans notre exemple), car elle nécessite le téléversement de la sauvegarde complète à chaque fois, et elle prend beaucoup de temps à effectuer (c’est le type de sauvegarde le plus lent dans Firebird). Pendant l’exécution de gbak, les performances de la base de données sont faibles en raison des lectures et écritures aléatoires intensives sur le disque.
Sauvegarde incrémentale avec nbackup
La sauvegarde incrémentale est effectuée avec nbackup - un autre outil de sauvegarde de Firebird. Nbackup crée des sauvegardes sous forme d’incréments de modifications : d’abord, il crée une sauvegarde de niveau 0, qui est une copie exacte de la base de données, puis, à l’itération suivante, il analyse la base de données et stocke uniquement les pages modifiées comme niveau 1, niveau 2, etc. Il est possible de définir une sauvegarde complète (niveau 0) une fois par trimestre, des incréments de niveau 1 chaque mois, de niveau 2 chaque semaine, de niveau 3 chaque jour et de niveau 4 chaque heure.
C’est assez rapide, cela crée des sauvegardes presque à la vitesse d’une copie linéaire de fichiers.
Le principal inconvénient de nbackup est l’absence de vérification - si une page de base de données est corrompue, nbackup la copiera dans le fichier de sauvegarde, qui sera également corrompu (contrairement à gbak, qui donnera une erreur dans ce cas). De plus, comme la création de chaque niveau oblige Firebird à analyser toute la base de données (dans Firebird 2.5, la v3 a des améliorations), il n’est pas possible d’exécuter nbackup trop souvent sur une grande base de données.
Comme vous pouvez le comprendre, nbackup nécessite un calendrier assez sophistiqué, mais avec les bons outils, c’est une tâche facile.
La bonne approche est d’utiliser nbackup en combinaison avec gbak : gbak vérifie la base de données chaque jour ou chaque semaine, et nbackup fournit un moyen rapide de sauvegarder la base de données assez souvent.
Ainsi, nbackup semble être un bon choix pour stocker la base de données dans le cloud.
Sauvegardes de machines virtuelles
Qu’en est-il des sauvegardes de machines virtuelles ? Les fournisseurs d’outils de machines virtuelles et de sauvegarde affirment qu’ils prennent en charge la sauvegarde des bases de données, mais ils ne précisent souvent pas quelles bases de données sont prises en charge. La sauvegarde de machine virtuelle nécessite qu’un fournisseur Volume Shadow Service (VSS) pour la base de données spécifique soit installé pour effectuer correctement une sauvegarde en ligne. Pour Firebird, le fournisseur VSS est disponible dans le cadre de la distribution avancée HQbird.
Bien sûr, il n’y a pas de magie dans une sauvegarde de machine virtuelle avec un fournisseur VSS - en coulisses, il utilise nbackup pour mettre la base de données dans le mode approprié à la copie. Sans le fournisseur VSS, le résultat de la sauvegarde au niveau de la machine virtuelle sera comme une copie d’une base de données dans un état similaire à une réinitialisation matérielle : Firebird utilise intensivement la mise en cache des données en RAM, et il est possible que la sauvegarde soit corrompue en raison de modifications non vidées.
Warm-standby
Certaines entreprises ne veulent perdre aucune donnée de la base de données. Les factures récentes avant le crash pourraient être critiques, et la dernière expédition pourrait envoyer une douzaine de camions sur la route. Dans ce cas, même les sauvegardes horaires ne suffisent pas ; la seule solution possible est le warm standby (un miroir en lecture seule) de la base de données, basé sur la réplication native asynchrone.
Native signifie que la réplication ne nécessite pas de déclencheurs ni de modification des métadonnées (la seule exigence est d’avoir des clés primaires ou uniques pour toutes les tables répliquées), et elle fonctionne très rapidement.
Le warm-standby nécessite la création d’une copie initiale de la base de données, son initialisation en tant que réplique, et son téléversement vers le serveur de secours. Ensuite, les modifications de données seront envoyées depuis le maître avec un délai minimal (à partir de 1 minute). Seules les modifications sont envoyées, ce qui ne réduit pas les performances de lecture de la base de données.
Cette option de sauvegarde est très fiable - elle garantit l’existence d’une copie en direct de la base de données sur un autre serveur.
Que peut faire IBSurgeon pour vous ?
Nous proposons un service de support par abonnement pour Firebird, et il inclut des options de sauvegarde cloud et de warm standby. C’est simple et abordable (99 $/mois), et cela inclut les options suivantes :
- Surveillance de la base de données Firebird et automatisation des sauvegardes
- Support par bureau à distance et messagerie instantanée
- Solution Firebird de basculement (warm standby) et sauvegarde cloud
Veuillez lire plus de détails sur le service de support Firebird ici.
Une autre option est d’utiliser HQbird, notre distribution avancée de Firebird, et de mettre en œuvre vous-même la sauvegarde cloud ou le warm standby. Vous pouvez trouver plus de détails sur HQbird ici.
Et, bien sûr, comme dernière chance, FirstAID Extractor.
N’hésitez pas à nous contacter pour toute question !