Hi Developers,
Not sure if you and your team have seen my below original post? One of the reasons I purchased the subscription is for smooth remote access, but fixated to port 8089 is posing security issue and concerns. Do you have any comments about this issue? Or am I missing something in the settings?
TIA
Attempted tcp connections are normal for open ports on the internet, and do not consitute a security threat. We have several layers of security which ensure only you can access the DVR over the open port.
Since your firewall is already blocking these connections for you, what is the concern? If you really want to use a different port, you can change the port forwarding on your router to the port of your preference and then use the linked instructions on your first thread which details how to remote connect to a non-standard port.
Thanks for your reply. When Remote Access feature was first introduced, I remembered changing forwarding port was not available. That's why I let port 8089 to be open over a year. Thanks for letting me know. I am going to change the forwarding port then.
BTW, if I use an arbitrary random port, how does Channel DVR know and register with my new port number? Especially, the url https://d1bd07269acd.channelsdvr.net:xxxx.
Furthermore: If you're running something that allows access initiated from an unsafe network (e.g.: The Internet) to a trusted LAN device (e.g.: The PC with which you do, say, your home finances and so on), you're violating a fundamental rule of network security in the first place.
That being said: This brings up an issue for me, @tmm1: Originally I did not concern myself too much about this, because our NAS was purchased solely for use as a DVR. But then I realized it'd make a great surveillance system NVR. Problem is: Channels's code is running with elevated permissions, which means privilege separation on the NAS is straight out the window.
This means using the NAS for anything else is inadvisable, at best, and arguably downright stupid.
It doesn't. You have to enter the port manually and bookmark the url. For apps remote access you must right-click copy url on the Authorize button and replace 8089
This is true of the Synology package. It is one of our oldest packages and is due for a rewrite.
I kinda sorta thought I didn't recall your package wanting to run as root on my Linux box **. I almost certainly wouldn't have installed it if it had.
I know y'all have a lot on your plates, but I'd sure appreciate it if you could put a priority on this. I don't like it, even if the NAS isn't currently doing anything else important atm. If nothing else: Owning it would give a bad guy a launch platform inside my security perimeter.
To be clear: It's not that I don't trust your code or security measures. I don't trust anybody's code or security measures. Not even my own.
** Or did it, and I created channels user and group id's, set the executable to suid/sgid, and manually tweaked all the file and directory perms?
OK. That's what I thought when I wrote my original post last week. Sorry for being not clear in the first place. I have meant to allow to make it a configurable option in the DVR server Web setting page to let user input the configurable port number so that DVR can properly register our actual public IP address/URL and the new configured port number. Plex has been doing it, and the remote access with my arbitrary port is seamless; especially when I travel with my phone. It's not easy for any non-technical folks like my uncle or my mom to do what you just described. Plex, in this aspect, is easy for the user-specified remote access port, but everything with Plex Live TV DVR just sucks big time. That's why I am still sticking with your solution, Channels DVR. My biggest and most wanted wish for the Channels DVR is to allow and properly register the user configurable port to the URL for remote access. Can you please consider to implement it?
You are right, I shouldn't, my firewall is blocking those attacks. But I have already helped installing Channels DVR for some of my best friends, my uncle, and my parents in their homes. They don't have the firewall that I am using, so they are more exposed and vulnerable. Since I was the one who recommended them to buy Channels DVR, I just feel it's my responsibility to inform them or help them to prevent any malicious attacks to the Channels DVR servers. None of them would want to buy or configure or manage a firewall behind their routers. They all want the remote access feature, that's one of the main reasons to go with Channels DVR. I just hope that I have an answer or roadmap before informing them.
I manually installed the DVR software, and have several overrides for the systemd unit used to run Channels. When I update my application server later this month, I'll also break out each app into a separate systemd-nspawn machine.
As an aside, is there any interest in an Arch PKGBUILD? Channels' installer may be fine for most people, but I personally want something that sticks to standards a little more (including sysuser and tmpfile support) than being offered by the installer.
As a retired network security professional that has been managing systems exposed to the Internet essentially ever since the .mil/.edu restrictions were lifted sometime in the early 1990's, all I'm going to say about this entire listening port question is this: Moving things off their well-known ports is regarded by many of my colleagues as being "security by obscurity" at best, and we regard that as no security at all. The ones who don't hold that view feel it's a cure that's worse than the cold, for reasons upon which I'll forgo expounding.
Point taken. I am not defending my posts or arguing with your statement. All of your comments are valid and true and I agree with you 100%. I'm just helping my friends and relatives out. Hope you don't mind I ask the Developers for some alternatives.
Instead of exposing port 8089 to the outside world, why not install a VPN on your premises and then use a vpn client to connect securely into your network to watch your channels dvr content?
You're still exposing a service, either for Channels or the VPN, on whatever port you expose for that service. It's better to just limit what's exposed, but for the things you do expose keep it fully updated and have access limitations like blocking all IPs outside of the country you reside in.
You can run Channels DVR under Docker on Synology if you want better process isolation, it works great!
@tmm1 Will you consider this to be on the roadmap, so that I can communicate this to my friends and relatives? If not, that's ok, they can consider the next step. Just need a confirmation from you. Much appreciated.
I'm confused here. What exactly are you asking for? It seems the original request was to operate on a different port. Then it appeared you were asking for Channels to implement a VPN solution to encapsulate connections from remote clients. So what exactly are you requesting now?
I don't consider these equivalent exposures. One service is a dvr software product, the other a security product. The Channels DVR authors are NOT going to be as good at securing their port as the VPN server authors will be.
No. It's not. This is not about VPN. If it were VPN, it's no longer that you need to use http://my.channelsdvr.net. It's the remote access feature in the DVR. @tmm1 understands what I am asking about. Please don't be confused with remote access vs. VPN. 2 different solutions but yes similar (but not entirely the same result and experience).