3

We recently installed one NAS drive (Buffalo LinkStation Pro Duo, LS-WVL, running the most recent Firmware version 1.6 to be precise) in our (small) company network. Currently, there is no encryption and by default the NAS provides anonymous read-write access via Samba. Setting up user/group restrictions is no problem with the web interface, nor is deactivating the integrated media server etc., but encryption is not officially available.

However, since it runs on Linux (see e.g. here) and it is not too difficult getting root access via LAN I can modify the setup to our needs. So here's my idea of our requirements:

  • Encrypt the data on the NAS
    • Decryption must require external information (since anyone with LAN access can hack into the root account abusing the firmware mechanism...), so I can't e.g. simply share an automatically mounted TrueCrypt volume
    • Ideally, no additional steps to the samba authorization would be required

I was also considering setting up and LDAP server on the device while we're at it, so maybe that authorization can be combined with decryption somehow. If that is not possible, having to temporarilly mount the decrypted volume via SSH plus some timeout would also be acceptable.

What is a typical solution to this?

techraf
  • 9,149
  • 11
  • 44
  • 62
Tobias Kienzler
  • 7,658
  • 11
  • 43
  • 68
  • Wow. The real solution would be to ditch the NAS and get one without such a horrific vulnerability! – Polynomial Sep 04 '12 at 08:25
  • @Polynomial I guess as long as the ability to update the firmware (and un-bricking) shall remain available that vulnerability is inevitable (since the flash memory can be overwritten). Though I guess I could deactivate it somehow, I think it's using telnet at some point – Tobias Kienzler Sep 04 '12 at 09:15
  • Normally they prevent such problems by digitally signing the firmware package, so that only official firmwares can be installed. – Polynomial Sep 04 '12 at 09:26
  • @Polynomial I don't know what kind of vulnerability [ACP Commander](http://buffalo.nas-central.org/wiki/ACP_Commander) exploits, but as long as LAN access is required (and thus physical intrustion (I trust my router... enough...) which could just as well result in physically stealing the drive) I'm more concerned about encryption... – Tobias Kienzler Sep 04 '12 at 09:50
  • @Polynomial I gave this some more thought, so I asked a new question on [hardening the LinkStation](http://security.stackexchange.com/q/19727/3272) – Tobias Kienzler Sep 04 '12 at 13:34
  • note to self: http://buffalo.nas-central.org/wiki/Enable_Encrypted_Partitions_for_LS-VL – Tobias Kienzler Sep 04 '12 at 14:49
  • Possible solution: [How to decrypt an encrypted container via ssh without entering a passphrase while requiring some client authentication?](http://unix.stackexchange.com/q/48523/863), if [Is piping a `ssh-agent` signed message as a password secure?](http://security.stackexchange.com/q/23252/3272) works out – Tobias Kienzler Oct 31 '12 at 12:25

2 Answers2

1

Currently, your NAS is on the local network, and thus accessible only from the machines on the local network (you say that you trust your router). Therefore, if you fear anything at all, then, by definition, you are assuming that your local network is at risk, and that an "hostile entity" could plug on that local network.

As a corollary, if having LAN access is sufficient to gain root access on the NAS, then you must consider it as already compromised. Whatever the NAS knows, is known to the attacker. You are also already assuming that the attacker is kind enough not to delete or modify files...

Therefore, if any protection is to be obtained at all, then the data on the NAS must be encrypted with a key that the NAS itself does not know; the authorized clients would know the key, and collaborate in the management of the shared storage area which, from the point of view of the NAS, would be a big bag of opaque bytes. This would not fix the vulnerability with regards to data alteration, though. Also, I do not know of any production-ready implementation of a protocol for that; apparently, some people are working on it:

In addition, we are designing a client-side encryption scheme for NFSv4. This latest version of NFS is intended for use over the Internet, and there are usage scenarios where clients store data on untrusted servers. In our encryption scheme, clients will encrypt data before it is sent to the server. This data will be stored in encrypted form, and will be decrypted by the client when the data is read.

But, really, you should not allow a NAS which can be remotely root-hijacked to be plugged at all on a potentially hostile LAN. You'd better isolate it somewhere, for instance behind a reasonably sturdy router, with which authorized clients would connect with a VPN, e.g. IPsec (which Linux should support natively). Bonus: once you have such a router installed, plug the disk into it, and ditch the NAS altogether.

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • 1
    I trust the LAN to be safe enough that physical access is required, in which case the potential intruder might just as well take the NAS with them. So indeed what I want to achieve is to make sure that someone stealing the NAS will not have enough information to decrypt it. The question is, is there some more sophisticated way than SSH-ing into the NAS to mount an encrypted volume every time I need to access my data? – Tobias Kienzler Sep 04 '12 at 13:00
0

I have a Buffalo Linkstation Pro and with the latest firmware it comes the option that supports AFS file system that is encrypted. That will ensure communications between your PC and NAS are encrypted.

SMB should support NTLMv2 in windows for communications which is encrypted too.

The issue to manage the storage itself to be encrypted it will drive you to create a Truecrypt container in your share NAS and mount as a local drive the container using TrueCrypt

Kirk Steinklauber
  • 1