In the modern world where hacking is so prevalent, I can’t imagine the default setting for SyncThing package on Synology is to broadcast its availability to the internet at large while having no need to authenticate for access. I am referring to the warning at the top of the setup page, “Danger! The Syncthing admin interface is configured to allow remote access without a password. This can easily give hackers access to read and change any files on your computer. Please set a GUI Authentication User and Password in the Settings dialog.”
Here is my question: a couple of years ago I installed SyncThing via the Synology package manager intending to set it up to back up one of my USB drives. I never did. Today, while culling unused packages I read the concerning warning mentioned above. DOES THIS MEAN I HAVE BEEN UNWITTINGLY SERVING UP ALL OF MY NAS FILES FOR THE LAST TWO YEARS to anyone who cared to browse them? If so, how can I tell if this happened?
Not necessarily, unless your network and the device in question itself is exposed to the world and can be connected into. Syncthing by default doesn’t allow remote access, unless you modify the GUI address, but I’ve no idea how the Synology package works.
Having access to Syncthing doesn’t mean that someone can just browse files through it, but yes, they could easily share and sync the files with their own devices.
On a Synology, restricting access to the “local” machine itself is not sensible because you can never run a web browser on it. So the package is configured to allow network access to the GUI by default. It depends on your network configuration what that means. If you’re on a LAN behind a router, anyone on that local network could have accessed the GUI without authentication. But unless you configured a port forwarding of some sort, access from the internet at large was not possible.
The warning of course refers to anybody having the ability to configure shared folders for other devices. If that is not the case currently, then either nobody used the access possibility or they made sure to remove their modification to hide traces.
That’s borderline euphemistic: Exposing the Syncthing GUI/API to the internet without authentication does expose all your data (where “all” may be restricted by the user Syncthing is running as, but both realistically and from a “assume the worst”/being prepared standpoint it is most likely all the data).
Does that mean that the Synology package by default listens on 0.0.0.0 and does not have a mechanism to restrict access (install step to setup auth, or firewall rule set by default, …)?
If yes we (the Syncthing project) should demand a change to that immediately. That would be a terrible practice that would put our users data and thus our reputation at risk (through the shared name).
Can someone with experience with Syncthing on Synology please confirm/refute that a default install sets the listen address to 0.0.0.0 without authentication or other measures to restrict access?
(And if there are measures, what are they?)
And general clarification for anyone that may drop by and read this: There are multiple “distribution channels” for Syncthing. Many of them are controlled by the Syncthing project, but a lot are not. For example Synology packages are not provided officially by the project. We do expect 3rd party providers to exert their own good judgement in line with the project goals (that e.g. has “Secure against attackers” as goal 2. after “Safe from data loss”). Given the nature of open source, it’s necessary that users of such 3rd parties react to problematic practices and report them to those 3rd parties to be fixed.
I can quickly confirm this is the case. The default configuration installed before first starting Syncthing looks like this:
Being a headless system, I guess that was the only reasonable way to make it configurable at all, relying on the big fat red warning in Syncthing’s GUI itself to alert users of this insecure setup.
There are some firewall rules installed by the SynoCommunity Syncthing package. But afaik they only define named “applications” for the default ports used, and do not restrict access at all. The builtin firewall needs to balance between making the GUI accessible for initial setup and providing tools for granular access when in a DMZ network environment.
So you propose to have the user set up initial credentials during package installation?
Actually, it’s not quite as bad I think. The Syncthing process runs under its own “service user” which by default does not have access to the data and needs to be granted permissions using the ACL system first.
Yes. Options I see are a step during installation, having simple UI controls to configure auth/listen address in whatever Synology is using to configure itself (which I hope is authenticated) or exposing all of the Syncthing UI through that Synology interface. I have no idea which is the most feasible, in my opinion it’s just plainly hazardous to install Syncthing like this. It’s possible not an ideal practice even in a properly firewalled, private network, and that’s not guaranteed. It should assume the device is fully exposed by default.
Ah, good. That lessens the risk significantly. It at least requires the user to take a manual step (setting ACLs) before the data becomes exposed. And hopefully they first notice Syncthing’s large red banner about missing auth. Still auth should be set up by default in my opinion.
My package does the same thing, for the record. (Which, despite the obvious potential for confusion, is also third party packaging, it’s just that I’m also involved in the third party.)
This would be really bad UX in my opinion. There’s a lot users need to know before they manage to do SSH port forwarding. Synology’s DSM even has SSH access disabled by default and when enabled, it works only for an admin user. Key-based SSH authentication is even harder, because of the obnoxious default UNIX permission bits on $HOME folders, as they are usually managed by Synology’s own ACL system by default. Been there, done that, not a pleasant experience.
I’m working on the setup wizard thing for the SPK package as time permits. Any thoughts about what default user name (or also password) should be suggested? Should we allow to keep it empty or should the setup force the user to enter credentials?
Kind of related: Do you think enabling tls="true" by default would also make sense? I think most users will be logging in from LAN to set things up and the HTTPS connection is available regardless. So I’m a bit reluctant to force-enable it by default, possibly causing unexpected certificate warnings.
For what it’s worth, I think it’s safer to have no password and have the warning as at present than to set defaults which are less likely to be changed.
I was talking about defaults as in having something pre-filled in the text entry fields in the setup wizard. If they are allowed to be empty, authentication can be disabled by just clicking “Next”. But whatever the user enters here is their choice, I wouldn’t set any defaults that give a false sense of security because they might be shared between hundreds of Syncthing installations.
Suggestion: Pre-fill the user name field with user, leave the password empty. If nothing is changed, authentication stays disabled, but a warning was displayed right there. If only a password is entered, the user name will still be user, which might be unexpected, but also looks like an invitation to be replaced with something custom (at least for me).
Unfortunately I could not make the wizard do any “complex” validation, only isolated rules per field. E.g. if a password is entered, but the username left blank, authentication will not take effect, but the password is still saved. An extra warning in that case would be in order, but the SPK UI stuff is rather limited.
Unless someone has a more compelling argument for something else.