Library

How to protect Firebird databases from ransomware?

06-December-2016, by Alexey Kovyazin
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 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.

Exporting data from the encrypted Firebird database

IBSurgeon FirstAID can recover databases with a direct fix or wth data extraction. The direct fix is fast, it can quickly fix corruptions directly in the database file. However, in a case of the ransomware, it will not help, since the header page and main metadata are lost, so extraction is the only choice.

FirstAID 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 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 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.

Ransomware with 100% encryption

Unfortunately, ransomware often encrypts 100% of the files, and encrypt them totally, without exception.

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:

Full verified backup with gbak
Incremental unverified backup with nbackup
Backup at VM level (for virtual environment)
Warm Standby (database mirror), based on the replication

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

Full verified backup with gbak

The backup tool (gbak) reads the whole database and stores it in a special format (fbk). This backup method is called verified due to the fact that it reads every record in the database and ensures that database is fine. It is a very reliable method of backup.

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.

Incremental backup with nbackup

Incremental backup is done with nbackup – another backup tool from Firebird. Nbackup creates backups as increments of changes: first, it creates level 0 backup, which is the exact copy of the database, and then, on the next iteration, scans the database and stores only changed pages as Level 1, Level 2, etc. It is possible to set full backup (Level 0) once per quarter, Level 1 increments every month, Level 2 every week, Level 3 every day, and Level 4 every hour.

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.

VM backups

What about virtual machine backups? The vendors of VM and backup tools claim that they support backup of the databases, however, they often don't specify which databases are supported. VM backup requires Volume Shadow Service (VSS) provider for the specific database to be installed to perform online backup correctly. For Firebird VSS provider is available as part of HQbird advanced distribution.

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.

Warm-standby

Some businesses do not want to lose any data from the database. The recent invoices before the crash could be critical, and the last shipment could send a dozen of trucks to the road. In this case, even the hourly backups are not enough; the only possible solution is warm standby (a read-only mirror) of the database, which is based on the asynchronous native replication.

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.

What can IBSurgeon do for you?

We offer the subscription-based support service for Firebird, and it includes cloud backup and warm standby options. It is the easy and affordable ($99/month) , it includes the following options:

Monitoring of Firebird database and automation of backups
Remote desktop and instant messenger support
Failover Firebird solution (warm standby) and cloud backup

Please read more details about Firebird support service here.

Another option is to use HQbird, our advanced distribution of Firebird, and implement cloud backup or warm standby yourself. You can find more details about HQbird here.

And, of course, as the last chance, FirstAID Extractor.

Please feel free to contact us with any questions!