The way the DNS-323 handles permissions is a bit weird. I'm starting to understand a bit more but it's still not a very good system. I hope that these flaws can be addressed, because as it stands the device isn't much more than a toy.
By default, the root of the storage volumes on the device give RW permissions to All. Obviously, this isn't secure, but leaving it wide-open makes it easy to access out of the box without forcing the user to do configuration, so I don't mind this choice.
Securing the device is a bit weird. The permissions are share-based. What this means is, if you want to set up permissions for some directory on the storage volume, you are basically creating a share to that directory each time you set another permission rule. This is fairly non-intuitive and un-windows-like.
Finally, no share can be accessed unless All is granted at least Read-Only permissions.
I'll explain how this works a bit better by using an example.
Let's say I want to have a directory on Volume_1 that I want to share out in a secured manner. Here's what I do:
- Make the dir.
- Set permissions rules for the dir:
- Read-only to All
- Read-Write to the user or group that I want to be able to write to the share.
- If I have more than one user or group, one rule for each user or group that I want to add to the share.
What happens is this:
- dir is created on the filesystem of Volume_1
- The following shares are created
- A share to \\dns-323\dir is created with read-only perms assigned to All.
- A second share is created to \\dns-323\dir-1 with RW perms assigned to User.
- Subsequent shares are created to \\dns-323\dir-N with RW perms assigned to the user or group.
Now, if I want to connect to the share, it gets a little complicated. If I browse to \\dns-323\dir I get in, but I have read-only perms because this share grants read-only to All.
Say I want to be able to write to the file, though. To do that, I have to browse to \\dns-323\dir-1 and pass authentication as the user who I granted permissions to. The dir and dir-1 shares aren't really directories, but rather are
shares which
points to dir.
This is where it gets weird. On Windows, if I want to connect to the dir-1 share, the authentication seems to require BOTH Guest AND [User] to be passed to the server in order for access to be granted.
Say I browse to \\dns-323\dir-1 so I can write files. The server challenges me for authentication credentials
twice. First, I'm prompted to authenticate as Guest. Guest's password is blank, and should be authenticated automatically, unless there is no All rule for the share. If All doesn't at least have read-only, you can't get past this point. So there's really no way to deny access to All at the share level. Next, I'm prompted to authenticate as the User who I granted permissions to the dir-1 share. So I type in the password for User, and if I entered it correctly, I'm granted access to the share, and I can read and write files. Yay.
OK, so far so good. But lets say I want to create a share which is
not open to All. I want it secure so that guests on the network can't get in. I can't do this. If Guest doesn't at least have read-only access, I can't proceed to connect to the share. The only way to secure files on the device is to not share it at all, which of course is completely pointless. There's no explicit deny, and to gain access to any share, I have to have read-only for Guest AND read-only or read-write for the User or Group.
This means that the device isn't very secure at all. The only thing protecting it from the outside world is the perimeter firewall on my router. Anyone on the LAN can read and copy files from the system, unless I choose to put them onto a directory that doesn't have any shares associated with it.
It's a little bit better if you're connecting via FTP rather than CIFS/SMB. The DNS-323 allows the administrator to set up FTP Access Lists, and while you can't disable anonymous login for FTP, you can set up an empty default directory for Anonymous login and grant read-only permissions there. Thus, if someone connects to your FTP server anonymously, they're trapped in an empty directory, can't navigate out of it, and can't write files. At that point the only damage they can do is they're taking up one of the available connections to the FTP service, of which you can only allow a maximum of 10. If you get 10 guests logged in, they can cause a Denial of Service condition, making FTP unavailable to any legitimate users until one of those 10 connection slots opens up. The FTP server will time out idle connections after a few minutes, but there's nothing to prevent your attacker from continuously trying to connect to the device, picking up any open connection slots that free up a few milliseconds after they become available.
Additionally, with FTP, while the DNS-323 does support SFTP, it's not at all obvious how to connect securely. Secure FTP is enabled if FTP is enabled, but there's nothing to tell you how to connect via SFTP -- I had to read the user discussion forums to learn how. Worse, there's no way to turn off regular FTP access. So if you choose to have FTP enabled at all, you are open to being attacked by the anonymous DoS exploit. And as long as you connect via regular FTP, your authentication is passing in clear text and thus can be sniffed by malicious eavesdropper on the network, who can then steal your credentials and access the FTP shares. On top of that, there's no logging available, so you have no idea what's going on.
The conclusions I take from this are that the DNS-323 is really a toy device, not something for serious use. I'm not even saying it's a home network device as opposed to a professional or enterprise class device. You really can't use it to store anything that you don't mind sharing out to anyone and everyone who has access to your network. Security is as important to home users as it is to corporate enterprises. It's not like it costs more to implement correct paradigms in access and permissions. These are basic problems that have solutions that are decades old. I'm not sure why they're so badly mangled on this product. Is it really this broken? Or am I missing something?
For the purpose I bought it for, it's not even really well suited. I'm not so concerned about protecting my ripped CD collection against unauthorized access, although I'd really prefer it if I could prevent unauthorized access, but it won't serve FLAC files over its UPnP service, and I'll need to install a 3rd party software hack in order to enable this.
All these problems are solvable, as it's just a matter of improving the firmware to the point where it can secure shares adequately. Hopefully D-Link will address these things in a future revision.
Author
Topic: Wish List for 1.07 Firmware Version (Read 24709 times)