Actually,
The malware only poses as ransomware.
Because it destroys Linux databases (not encrypting), there is no way to recover content when the ransom is paid.
Is a hybrid malware,
Although the article says it’s only been found on a relatively few Linux machines, it has the ability to compromise and replicate across other OS like Windows and MacOS.
It also has a bitcoin mining component, so if your network is infected it’s going to make money off you in various ways
Mitigation: Use strong passwords not on anyone’s “Top 100” list on all your applications.
Beware that it’s common for instance to deploy redis and memcache nodes with no passwords if in a protected network, so if you’re managing one of these evaluate how protected your network really is.
And, sometimes we don’t always secure our applications… So, for instance if you install MariaDB/MySQL, are you really running the “secure database” script all the time? In the past, If you’re not granting remote access, this wasn’t thought to be necessary, but maybe should be re-considered?
The content of the Backup media has to checked by means of a stand-alone machine – a machine which is not connected to any form of network and, has a reliable, filtered, independent power supply …
Backups have to be rotated.
Audits in the form of check lists are required – data amount, data content lists, checksums, etc., etc., etc. …
A portion of the Backups have stored at a secure remote (at least 100 miles remote) site – possibly a bank vault …
Magnetic Tape is still, possibly, a preferred, viable, choice for Backup media …
For private usage and, small amounts of “critical data”, DVD-RAM is (IMHO) still a viable Backup media alternative.
A NAS is not a reliable Backup media – it’s attached to a network and is therefore excluded from the list of “serious” Backup media …
For quite awhile now,
Backup presentations I’ve seen no longer recommend tape… There are numerous potential issues related to tape not the least is the unreliable medium. Tape will stretch, deform, is vulnerable to environmental factors like heat, and magnetic fields.
And, particularly with today’s enormous storage capabilities (relatively speaking), from a practical perspective disks are far faster and lower cost per unit storage and physical storage space.
So, the current recommendation is to backup by disk but apply “Best Practices” to address disk drawbacks… like
Rule of 3’s. Each method and physical instance you implement should be in triplicate. This would include the application used to backup, each instance of a backup, backup medium, more.
AFAIK DVD and BR are considered good media for long term storage. Do <not> use CDROMs which do not sandwich the dye (which is manipulated by the laser to represent the data) because the dye is only applied to one side of the plastic disk so is exposed to environmental elements. IIRC estimated lifetime is >10 years.
Or course,
Do your own research, there is plenty of info on the Internet about disk backups… and everything else.
Choice of backup media depends on context. The threat is supposedly greatest against databases. Which in turn are usually not hosted on desktop computers at home but in a data centre. Small DBs can be backed up to disk but I work on database in the two digit TB range. There, tape (meaning data centre tape solutions) is still a cost effective solution.
Back to the threat descriptio,. it does help a lot to heed the most basic stuff for databases: no internet exposure, host based access restricted to local net, outside firewall, inside firewall, long pw stored in a vault service (meaning they can be truly random), have audit logs and store them on a separate host. And, of course, backups, full and incremental with multple copies, but that is a no-brainer. As are security updates to host and server software. Edit, adding: Surely no web based admin frontends. Half of all script attack tries against my servers look for phpWhateverAdmin.
One can still attack the application host because most apps still dump db passwords to config file on disk but simply trying out weak pw on an exposed db server will not work.