Today I wanted to address the security of the TrueNAS web server itself. What to pay attention to when configuring, how to avoid threats with simple tips, and some important things to know before we take on our first TrueNAS. Admittedly, I will talk about TrueNAS as an example, but this approach and recommendations are mostly universal and should apply to all types of storage and network drives.
Well, once we have our TrueNAS, freshly installed, is it as it should be? As far as we could make it by default yes, but we should still improve a few things. I am trying to collect and describe a set of general tips for general TrueNAS applications. I will cover how to configure some of them based on TrueNAS-CORE-13.0-U3 current as of November 2022 as I record this material.
I will mention that it is common that each of these solutions will sometimes be overkill due to either a small installation or negligible risk. But each time, the data owner should make a decision on how much risk he can accept. In addition, keep in mind that the listed list of things will never be completely complete enough to say that you are completely safe. New vulnerabilities or new methods of attack are discovered regularly.
WEB administration page
Let's start with the administrative side of the WEB. Such a basic principle we should probably start with is to never expose the administrative side to the Internet. Just as you can sometimes imagine some service being visible directly from the Internet, although I would avoid it as much as possible, I can't imagine a situation where we open access from the Internet to the administration panel. Ideally, the administration panel should be available on a separate network accessible only to the right users behind a firewall or through a VPN. It is worth sticking to the rule that not only the administration panel, but also each service should be assigned a separate IP. This makes it easier later to block and open access to individual services.
Next, it's a good idea to make sure that our admin panel uses encrypted access only, i.e. HTTPS instead of HTTP.
Regarding the administrative root user itself, it is definitely worthwhile for it to have a sufficiently long and complex password and, of course, configured 2FA
If we plan to use SSH console access to our file server then use a key instead of passwords.
It is a good practice to leave only the services you use enabled. If we have fewer less enabled services we are exposed to fewer potential problems that may arise in the future.
SMB
The primary form of protection for the data itself against inadvertent alteration, accidental deletion or by a ransomware data encryption attack is the snapshot setup. These allow you to store both historical versions of files and deleted files.
It is worthwhile to plan datasets well. You can share all of our data on a single network share, and this will probably work well for a small installation. However, it is worth considering creating separate network shares for different departments of the company, groups of people, destination. You can then, depending on the share, grant access rights to the right people, block access from a specific part of the network. In addition, if a file encryption attack happens, it will encrypt only part of the data, not all of it. Then restoring shapshpt from yesterday, for example, will make us lose the day of change only part of our data.
Server disks and more
When creating a Data Pool, consider encrypting the data on the disks. This makes the data stored on the disks worthless if you do not know the encryption password. Further creating our new Pool, it is essential to use a minimum of RAID-Z1 giving immunity to single disk failure. I recommend considering RADI-Z2 giving immunity to failure of two disks. In addition, consider using a SPARE backup disk. This works in such a way that in case of failure of any of the disks belonging to the pool, the SPARE disk automatically takes over the roles of the failed disk and the RAID is immediately rebuilt.
The next threat to our data is power loss. Admittedly, ZFS, thanks to, among other things, the so-called Copy on Write, seems to be highly resistant to data damage during a power failure, but some data may simply get unsaved. To guard against such surprises, it is important to configure the server and the connected UPS to shut down in the event of a power failure.
As we are at the physicality of our server, it is worth considering who has physical access to it and when. Ideally, of course, in a dedicated closed room with air conditioning. Although it is not always possible, it is worth considering whether someone will accidentally disconnect its power supply or pour coffee on it. Although here, to seriously harm the server would probably need more like a small coffee flood.
If we already have our server set up and secure then still, remembering that RAID is not a backup, we need to make sure that our data has a backup. That is, replication of data to another physical server preferably in a different location due to theft fires and other random events. [link to material on replication].
Now coming back to the software for a moment, it is worth updating our TrueNAS well and don't forget to backup the TrueNAS configuration itself - this sometimes gets missed, but it is worth making sure that we backup the configuration well and... keep it not only on our NAS.
Proactive monitoring
When we finish the server configurations and everything is thought out, configured, secured then comes the moment for the daily reality. No one creates IT systems to have more work and then regularly log into them manually, test, check.
The elementary minimum is to set up e-mail on our network drive so that it can notify us on its own that a drive has broken down, that we are running out of space, etc.
It is good practice to monitor an active device. Keep in mind that such an email may not go out or not arrive for many reasons. Especially since, in general, such a server runs quietly for several years without any malfunction. And who will regularly check whether such an email configured several years ago works, sends? That's why it's worth considering some kind of active monitoring to check whether our device is working, whether all disks are working, whether they are not close to overflowing. Because what's the point of having spare drives or power supplies if we won't be informed that we no longer have a supply because something just broke and, admittedly, it still works, but we no longer have any supply and it's high time to get off our asses to replace the drive or power supply.