A community dedicated to the profession of IT Systems Administration
No generic Lemmy issue posts please! Posts about Lemmy belong in one of these communities:
[email protected]
[email protected]
[email protected]
[email protected]
If your backups are visible from the targeted systems, you are doing it wrong. Done right, a backup utility at most only uses an agent on the systems to be able to contact them to get the data and the backups are not reachable.
Have a look at how BackupPC works, not even an agent, it accesses network shares to get the data:
I'll check out backupPC. What is the most common/best practices way to make sure the backup medium isn't accessible from any endpoints on the network?
Unplug it after the backup.
Immutable/offline backups. If you backup to local physical media (HDD/tape), physically disconnect/eject it and store it somewhere safe. If you back up to cloud storage (S3, etc), many of them have immutability options. If configured properly nobody (not even you) can delete or modify the backups (within the specified time period).
Backups serve different purposes and if encryption by malware is a threat, you have to do backups differently, as opposed to, for example, hardware failure, where your NAS is a valid approach. To protect against encryption malware, you must make your backups inaccessible. One example are read-only backup media like DVD-ROMs. Another example is to make regular backups on tapes or HDDs and lock them up somewhere. You only take them out after you have wiped all computers that were affected by malware.
What about simulated air gaps? So a backup system that turns off its own networking abilities once its done with the current backup and only turns its networking back on when it's ready to start backing up again?
Look into the 3-2-1 strategy. Also: At least one Backup should be taken offline after the backup is done. This might be done via Tapes on a Tapelibary, where you would put your Used tapes into a fireproof safe (certified for Tape fire protection - ask me if you dont know what that means). Those backups that are not connected to a network are most reliable in such a scenario. Most encrypters encrypt right away and thus offline/archived backups are most likely not already affected.
If your trojan was keeping itself silent for a couple of months (some specialised do that) even your archives are at risk. In such a situation mostly the only solution is to build from fresh.
The backups are on a separate system with different credentials. One copy of the backups is sent to online storage that is immutable. You set a retention policy and then you can't delete, overwrite, or change the backups.
3-2-1 standard is what saves you.
If you want an automated system that can protect against ransomware your backups need to be hosted in some way where the backup server has control of the retention and not the client (NAS, local disk, etc are not sufficient). If your NAS supports automated snapshots that can't be deleted by the backup user it can mostly fill this gap but may need to be checked for how it handles snapshots when the disk fills.
For self-hosted solutions I've used BURP, Amanda, and Borg backup in the past but have switched to Proxmox backup server as my VMs all run in Proxmox. You still need to consider full disaster recovery scenarios where both your primary and backup system fail. For this PBS sports both tape and remote server replication.
There are also many cloud solutions that do this automatically. For cloud I would always use them in tandem with some kind of local backup.
For all of these they should have an admin account that has strong protection and doesn't share credentials with any of the primary systems.
Its actually fairly simple. You just setup a backup server that connects to a network share and reads data.