I’m a new truenas user and i really like how truenas is a very easy backup for my small team. However, i’ve been kinda scared of ransomware and other attacks on my NAS as i’ve read that some people get’s their data leaked very easily. Is there anyway i could prevent this especially since my financial flow is stored in this NAS (only accesible by 4 users and builtin admins).
Congrats on selecting Truenas and ZFS to trust your data with. This is one of the initial steps one must take, if they are serious with their data safety and integrity.
There are always multiple approaches to handle such scenarios to ensure further securiy, but here a non-exclusive list of items that you could follow as a mini guideline.
- Understand how snapshots work
- How snapshots can help data replication
- How backups can be planned
- How to monitor snapshots and backups to ensure they happen in time
- How to verify the above monitoring and backup results remain valid.
- How to do periodic restore tests to ensure the plan still holds good
- And finally, ensure to document the procedures, especially on how to restore.
Hope this gives a good starting point, for you to proceed further.
2 Likes
Rule #1:
Don’t expose NAS directly to the Internet, no exceptions. If you need remote access, use a VPN.
Rule #2:
RAID is not a backup. RAID is resiliency. Have a good 3-2-1 backup strategy.
2 Likes
Beside (offline) backups, resisting ransomware is as simple as taking regular snapshots. Not leaking your data is general network security.
2 Likes
I concur re: snapshots being a good place to start re: ransomware. Think carefully about how often a snapshot should be taken and retained. You can keep multiple, overlapping schedules, etc.
Make sure your users’ have hardened computers with some malware / etc. detection built in. Only allow external access to your server via a trusted VPN like Wireguard, Tailscale, etc.
Don’t disregard possibility of a fire or whatever wiping out the office. Have a remote backup plan. Ideally to another ZFS NAS since replication is incredibly efficient, fast, and 100%.
Occasionally, also make backups that are air-gapped and normally turned off (ie. a small RAID array like a Oyen Mobius 5 to back up onto). Should your primary and backup fail due to a long term worm that slowly eats its way through your data set, these backups can be a lifesaver.
I have RAIDZ2 on my server so that up to two of my eight drives can fail without losing data. I have snapshots enabled so that I can roll back in case of data loss. I also have backups on both external hard drives as well as encrypted backups on Backblaze to help protect against data loss.
Just don’t forget a UPS on your NAS server.
1 Like
so i dont really understand how snapshots work, could you kinda dumb it down a bit for me?
haha i personally use linux but since my team consist of non tech savy people so they prefer windows or mac
im wondering how do you backup to an external harddrive? is there an option directly from truenas?
Welcome to use TrueNAS 
a part of my professional role is cyber security and breach work.
Below are the most common issues that I see customers do which do lead to a breach.
-
Exposing to the internet, as someone already mentioned, never do this.
-
Leaving the NAS/Server on the same VLAN as your corporate network. Have it segmented with proper access control rules setup for it.
-
If you have customers come to your site, make sure your guest wifi is completed isolated from anything corporate or server related.
-
Client (P2S) VPN - Always use one if you’re accessing remotely, use a well designed one, not just a cheap one that comes with your firewall - if you have a sonicwall, do not use their SSLVPN they have an active ransomware issue right now. I suggest you look towards either Azure VPN for Entra ID MFA Protection for a standard stack selection, or maybe Tailscale if you want something more budget friendly.
-
Root Account - this should be your last resort to use account, never allow anyone to have access to this, this password should only be stored in a secure location like a FIDO2 Protected Password Manager (Bitwarden for Example)
-
Breakglass Account - this is your failsafe account, best practice is to have two of these, these passwords ideally will be stored in a completely isolated, offline, secure location. For example written physically on paper and stored in a Safe that only you have - no MFA on this account. Have alerts setup if this account is used.
-
Zero Trust Permission Design - Don’t just give your staff full access just because you’re a small company, always work on a Zero Trust principle.
-
Named Accounts - Never ever, allow your staff to share accounts, ideally you’d use a single truth for user accounts, like an AD with LDAP to the truenas, these names should be clearly defined in structure early on for scale, for example: firstname.lastname.
-
Backups - Make sure you have backups configured using the following as a template default:
30 Daily, 12 Monthly, 1 Yearly
Use the standard GFS (Grandfather, Father, Son) method; have three points of completely different isolated backup. -
At least one of those backup storage locations, should be completely inaccessible from your corporate machines and the general internet - If you need to restore from it, these should be you need to manually adjust your firewall/backup config to allow access outside of the backup manager.
-
Test your backups! Don’t just assume they work!
-
Staff Training - This is the single most important bit, everything above is useless if staff do not have appropriate training for online cyber protection. Conduct: Cyber Required Tests, test phishing emails etc
-
MFA on Everything. By Default. - Your emails for example, if you’re using Microsoft 365, upgrade yourself to a P2 license, use Conditional Access rules to enforce MFA and Risky User/Sign In Policies, make sure Token Protection is also enabled; token theft is one of the biggest reasons I see for breaches. Risky Sign In will help protect against impossible travel and unusual sign in flow.
2 Likes
Fantastic advice from @itsharryshelton.
I would add —
It is very useful to consider alterations to these two strategies depending on your threat model. Storing root credentials in a password vault that is synced to client devices means that somewhere on a client device is your TOTP seed. You can put compensating controls around that in practice — such as not syncing a vault to a client, if your password manager offers those options. However, the first time a client has access to that secret then that secret has been exposed to a client, and that means it could have been accessed by local software, or backed up by backup software. If this exceeds the risk tolerance for your threat model, you can keep the TOTP secret instead on something like a Yubikey. This has its own tradeoffs in managing secrets stored in hardware. Hardware can and does break, sometimes at random. Make sure you have multiple such copies on different pieces of hardware, and it’s best to make sure those are geographicallly disparate.
If you are in a compliance environment that requires MFA on all privileged accounts with no exceptions, the advice @itsharryshelton provides about break glass passwords can be applied to TOTP secrets too.
Some password managers provide auditing, logging, and alerting functions that are useful here.
For ransomware resistant backups, it is also very useful to consider immutable backups. ZFS snapshots are internally immutable, but they can be destroyed or exfiltrated by a sufficiently privileged account/process. In a business environment where you have flexibility and funding, it may be worth considering replicating snapshots intended to serve as backups to another pool on a different system. (Where all the above advice especially around firewalls, Internet connectivity restrictions, etc apply even more so.) Technically, pull-based backups would be best here, but you can also manage ZFS permissions if you must use push replication for some reason. If you do this over SSH you can also restrict the IP address or networks from which your SSH key is accepted.
May I suggest… reading the documentation? 
A snapshot records the state of a dataset at a point in time. ZFS being Copy-on-Write, data in a snapshot can not be deleted or altered, only overlayed with a modified version—hence it would be kept safe from a crypto-locker.
Snapshots are also the basis for ZFS backups, performed by snapshot replication.