Ransomware attacks became the serious problem for many companies: during the last week, we had 3 incidents from different customers which had their Firebird databases encrypted by ransomware viruses. Luckily we were able to help all of them, but the scale of the problem definitely increases.
In this article, we will consider how these problems were solved.
In general, ransomware is not designed to encrypt specifically Firebird databases; it just encrypts all files on the computer, and then asks for the ransom to provide the password for decrypting it, and even if you pay, you may not get any decryption password or response at all (also, it is necessary to check antivirus websites: they often publish pin-codes or even decryption tools for that ransomware. For example, one of them: noransom.kaspersky.com/)
Of course, it is necessary to have reliable (and suitable for servers) antivirus, but can we do specifically to protect Firebird database?
There are different types of ransomware, let's consider their impact on the Firebird databases.
The 2 companies were hit with ransomware which has partially encrypted their Firebird databases.
As you know, Firebird database file is a set of pages of the same size. Database pages in Firebird database contain different type information: metadata, user's data, indices, generators, etc.
Usually, such ransomware encrypts not the whole database file, but the small part of it – header page and some % of database pages inside the database.
Since all pages have strong relationships, even few recent of encrypted pages make the whole database unreadable by Firebird engine. For example, in 10Gb database there was encrypted less than 1% of data, and other 99% were fine.
In this case, such encrypted database can be considered as a heavily corrupted database file, and IBSurgeon FirstAID Extractor is the tool which can perform the export of the data from the encrypted Firebird database file. The same approach is used to recover databases from corrupted HDDs.
FirstAID Extractor reads the database file directly –it does not use Firebird to access database file, it reads database file directly, byte by byte. Since it focuses only on the extraction of the corrupted data, and sacrifices performance, FirstAID Extractor can export data even from the heavily corrupted Firebird databases. Of course, FirstAID skips encrypted data as corrupted and export only good data.
If ransomware did not encrypt the critical metadata, it is possible to open encrypted database file with FirstAID Extractor and preview records: select the table in the list on the left and open tab Preview, and then browse data pages.
The records you can see can be exported to the fresh database with the same structure:
The approximate amount of losses can be estimated with Bad pages percent on the Pages Summary tab for the database:
The percent of bad pages shows how many database pages were encrypted, and their data are lost.
So, in 2 cases the databases were saved using the FirstAID Extractor, which has exported data from the encrypted databases.
Usually, such ransomware injects malicious code into bootloader of the operation system, then reboot the computer, and simulate CHKDSK execution, but instead of disks checking it encrypts everything.
The only way to protect from such virus is to have a backup of the important database at some third party location: in the cloud or in another office.
There are 4 possible backup approaches for Firebird databases:
What backup method is the best for the protection from the ransomware? Let's consider their pro and contras on the live example of Firebird database 50Gb in size.
|Feature||Full verified backup (gbak)||Incremental backup (nbackup)||Backup at VM level||Warm-standby (replication)|
|Size to upload||~30Gb every day||50Gb initially, then changed portions|
|Max frequency of backup||Every day||Every hour||Depends on VM backup tool settings||Every minute|
|Database performance degradation||High||Moderate||Low||Very low|
|Reliability of backup method||High||Low||Low||High|
|Time required to perform backup||2-3 hours (depends on the IO speed)||Initial is 15-20 minutes to create level 0, then 3-4 minutes||Requires to make full snapshot of the disk (depends on IO and size of the disk)||Initial is 15-20 minutes, always online|
However, full verified backup is not convenient for cloud backup of big enough databases (like 50Gb in our example) since it requires uploading of the full backup every time, and it requires a lot of time to be performed (it is the slowest backup type in Firebird). During the gbak execution, the database performance is low due to intensive random disk read and writes.
It is pretty fast, it creates backups almost with the speed of linear file copying.
The main disadvantage of nbackup is the absence of verification – if database page is corrupted, nbackup will copy it to the backup file, which will be also corrupted (unlike gbak, which will give an error in this case). Also, since creating of each level makes Firebird scan whole database (in Firebird 2.5, v3 has improvements), it is not possible to run nbackup too often on the big database.
As you can understand, nbackup requires a pretty sophisticated schedule, but with proper tools, it is an easy task.
A correct way is to use nbackup in combination with gbak: gbak verifies the database every day or every week, and nbackup provides the fast way to backup database pretty often.
So, nbackup looks like a good choice to store database in the cloud.
Of course, there is no magic in a backup of VM with VSS provider – behind the scenes, it uses nbackup to turn the database into the mode suitable for copying. Without the VSS provider, the result of VM level backup will be like a copy of a database in the state similar to hard reset: Firebird intensively uses caching of data in RAM, and it is possible that backup will be corrupted due to unflushed changes.
Native means that replication does not require triggers or change of metadata (the only requirement is to have primary or unique keys for all replicated tables), and it works very fast.
The warm-standby requires creating an initial copy of the database, initializing it as a replica, and uploading it to the standby server. After that changes of data will be sent from the master with the minimal delay (from 1 minute). Only changes are sent, so it does not suppress read performance of the database.
This backup option is very reliable - it guarantees the existence of the live copy of the database on another server.