1. The client interface to the NAS.
2. The 'cloud' services.
Only #1 is actually a deliverable with the Synology NAS. And #2 presents a terribly broken privacy policy...
For myself, I'd much rather be running something that I know is updating from an authenticated and keyyed repo than something which is attempting to make the user believe that somehow the "commercial" NAS is magically different than running a regular GNU/Linux distro...
Your beef is with [email protected], not the Debian project.
There's a limit to how much effort the OpenSSL developers should have to put into stopping people from shooting themselves in the foot, and tracking down lines of code identified only by their line number in an unspecified version of OpenSSL to make sure they do what some random guy on the mailing list thinks they do is way over that limit.
Are you comparing the Synology GNU/Linux distro to Debian or some generic [non-Debian] distro to Debian?
If you are comparing Synology to Debian, then the "trusted" source argument is entirely flawed. The source, meaning both source code and source of software, of software running on Synology hardware is not Synology. Synology only makes the GUI client that runs on your machine that locally interfaces to the NAS box.
As to the Debian 2006 SSL problem... stuff happens... Apple had some silly security problems too, much more recently than 2006. And Android is so full of holes, it's a wonder the platform works at all...
However, when the generalized public buys a NAS product -- the vendor should indicate the potential security problems regarding "cloud" connections in big bold letters on the box and in the manual and have a large red warning that pops up in the user interface. My guess is most users wouldn't care, but it actually is extremely risky to connect these devices to the wild wild west open Internet.
If they don't, they're almost criminally negligent, so you wouldn't want to buy from them anyway.
I used to run as simple Ubuntu server with NFS, but realised I just want the simplicity of a web interface over doing it over ssh.
x86 chips are more then suitable for the application since you're no longer in "ultra ultra low power" territory (and for ZFS, are beneficial because you want those checksum calcs to finish fast).
http://www.zdnet.com/hp-to-begin-charging-for-firmware-updat...
I've been looking at those processors for a while (Intel Avoton C2550). Was there any advantage to going up a few models in that series?
Or do these NAS machines all run some BSD variant?
But I have no idea if they use it or not.
Use FreeNAS if you want ZFS on a NAS though, it is well supported.
- Also, for what it is worth, FreeNAS is amazing, and is open source.
If a consumer device speaks IP and is not designed to survive in a reasonable internet-connected home network, there should be huge warning labels all over it and it should go to some safe-mode with only diagnostic functionality if it detects internet connectivity.
This has been the go-to techie reaction to security problems since the time of dial-up modems. It's a bad attitude [1], but it's not a "meme". It's the only successful strategy an entire generation of technologically-minded people have found and preached in response to a generation's-worth of terrible software security, slow/absent/can't-be-arsed software providers and under-educated users.
Should things be different? Sure. Attitudes should be better and the software should be better. But so long as the latter isn't reflected in reality, there isn't much hope for the former.
[1] It's a bad attitude because blaming the user puts them on the defensive and reduces the chance of any progress being made.
If you want to buy an off-the-shelf "home appliance" you will get just that -- a product where you cannot update firmware/software, reconfigure security and firewall settings, etc. Maybe it's secure the day you buy it -- but in 5 years? With no updates? No way.
If you buy something more enterprise grade -- or, the best option, roll your own with some of the very good options like FreeNAS or OwnCloud, then you will be able to keep it secure and up-to-date. But this takes more effort - and is likely the reason the OP did not opt for one of these very fine options.
> "It's a worrying meme that you shouldn't even expect your internet-connectible devices to survive the internet, and when they break its your fault."
That's not true -- you have an ethernet/network capable device; not an internet capable device -- nowhere on the box does it say "Plug this directly into the open public network in front of your firewall or inside a DMZ. You need to be responsible with your devices. Just because it can serve a web page does not mean it should be accessible over the internet! This is true even with enterprise grade gear.
Saying you want to not worry about security at all but still want to put devices on the public internet that need protection is like saying you want to have a car but don't want to ever change it's oil. Sure, you as an individual can avoid changing oil -- hire a technician. Same goes with your home network.
So no, it's not a bad attitude -- it's irresponsible and/or ignorant home users.
It pretty much does exactly that. It's marketed and designed for you to open ports directly to it for its various first-party packages, like PhotoStation, CloudStation, WebDAV, etc. I think it's reasonable to expect that those packages, which are major selling points for this system, should be reasonable capable of working on the public Internet.
There are secure ways to run things and insecure ways to run things. It's very possible to setup a postfix or exim smtp server as an insecure open relay running on port 25. It's also possible to have either running securely on port 25... And an open port is meaningless by itself. It's the security options applied by the system and application running a service on the port that matter.
The examples you give are just applications that run over http or https... https requires an SSL cert from a trusted CA, and http is a very bad idea for anything that you log into, or that has free access to your home network from the Internet.
I imagine most users skip this step... http://docs.qnap.com/nas/4.0/en/security.htm?zoom_highlights...
Note, the SSL certificate instructions... You can upload a secure certificate issued by a trusted provider. After uploading a secure certificate, users can connect to the administration interface of the NAS by SSL connection and there will not be any alert or error message.
...
The error message referred to here is the web browser message indicating that the SSL certificate doesn't match a trusted CA, and therefore your "secure" NAS connection might be Man-In-The-Middle attacked... And if you don't upload an SSL cert - and connect via http externally - it means that the most amateur of "bad guys" already has your 30 character username and your 45 digit/character/special character password...
We don't have enough information to even guess at what the root problem might be, but I contend that this particular piece of hardware is designed for and meant to live on the open Internet. Yes, that's a very scare place. But it's not unreasonable to think that an up-to-date Unix server should be capable of the job, especially when it's vendor explicitly sales it on the basis that it is.
I'm strongly hoping that the vulnerability turns out to be something already patched in a software update and not a 0-day. That would go a long way toward making me feel better about the situation.
You are right, an up-to-date Unix/Linux server is capable of the job (but still requires routine security maintenance to keep secure!) -- however, this home appliance is far from being up-to-date... by design.
My CentOS boxes at the office update almost every few days... how often does this appliance update? Once a year? Maybe twice if you are lucky. Then how many users are actually applying all updates? Probably very few.
I would further contend that a nas-in-a-box like this can never be secure. The vendor isn't going to update it frequently enough -- not enough users will actually update -- they are likely using old out-dated/insecure versions of various open source projects or worse, crudely hacked together proprietary projects to run the webserver, webui, ssl layer, authentication, etc. By now, the manufacturer has probably already back-burnered this device and moved onto newer models, or will be shortly -- completely abandoning all the current users who will get stuck with a swiss-cheese-in-a-box.
I'll go further and content the only safe and secure way to do this is to go with something like FreeNAS or OwnCloud. Both are current projects with massive user-bases. Both are FOSS projects, and both have a corporate backing if you need support or more enterprise features. Both stay very up-to-date with bugfixes, security fixes, and new features rolling out often. Both have upgrade paths from older versions, etc. Basically, they are much more secure and will stay that way for the life of the project.
About once a month: http://www.synology.com/en-global/releaseNote/model/DS412+
Synology uses the same base distro across all their devices, so everyone gets updates at about the same time. The device emails me when a new software version is available.
I get what you're saying, but in this case it's totally wrong. They're very active about providing updates to add functionality (even to old systems!) and fix stuff.
So back to my original position: this is not an unreasonable thing to expect to be able to run on the Internet. It's a modern Linux box that gets monthly updates, designed with the explicit intention of providing secure services over the public Internet. It would absolutely suck if that proved not to be the case.
Also, what security do you expect SSL to provide on a device with copious remote code execution vulns?
As you said, it is cheap, power consumption is ok and it is ready to go after you plug it in.
These are just best practices, since we don't know anything about this particular piece of malware yet. They should cover most threats and worst-case scenarios.
If you need access to your Synology device from outside your home network, use a VPN or an SSH tunnel.
Best practices only if you do not want to access your data outside of your local network – and that is probably no longer the standard case since data you cannot access from mobile devices etc. is pretty useless. And for compliance and security reasons, many users and companies cannot legally use cloud services and have to therefore to use a 'private cloud', i.e., some local server, for example a NAS accessible from the Internet. A manual configuration is of course recommendable but in the end, a 'private cloud' has to be exposed to the Internet and you have to trust your software vendor. The most you can usually do is to protect your LAN by putting your 'private cloud' in a DMZ (although for consumers, that is usually not an option since consumer routers do not offer a real DMZ).
It doesn't need to forward ports or expose the login system. The BTSync server is still a vulnerability, but it's under it's own user and should give less exposure than the other services like the DSFile that check the login/password. Potential damages on a simple breach (i.e. the sharing key leaked or was guessed) should be limited to the shared folders. I hope.
On iOS, you can use profiles I guess but that is not a standard function.
Use keys and only keys instead...
http://www.chainsawonatireswing.com/2012/01/15/ssh-into-your...
I've had a Synology NAS for almost a year now. I really like the UI, but the software stack they're using under the hood (Apache, PHP, MySQL, etc.) has a massive attack surface, if not routinely kept up-to-date.
Here's an nmap trace from my Synology DiskStation: amber@leysritt ~ % nmap -A <redacted>
It's sad that most of the open-source NAS solutions are so bad compared to their commercial counterparts. FreeNAS (and related forks) sacrifice too much flexibility and don't offer anything that you can't easily do yourself with a Linux/BSD server distro.I'd love to work on an open-source, security-oriented, user-friendly DSM "clone" with the right kind of people. If this sounds like fun or it sounds like something you're currently working on - shoot me an email: [email protected]
I also wish there was such a thing as a nice, inexpensive ARM board (~$100) with plenty of SATA ports and upgradable RAM (so you can run huge ZFS pools on it) that you can install your own OS on...