Add to that Channels DVR runs as root on some installations, so compromising a server as root, not good...
(That's why I don't allow Channels DVR Remote Access)
1 Like
If you're that paranoid you're already running your pertinent servers as non-root users in a single purpose container with only the single port opened. You are also probably maintaining your firewall to ensure only the necessary ports are open, and are probably running some sort of DPI and maybe something akin to fail2ban on your packet filter to maintain your blacklist, right?
1 Like
@racameron
I'm not paranoid, just a cautious user of the Internet.
No open holes/DMZ.
Evil Maids have access to your physical property and bad guys all over have access to your Internet security holes and may know your Evil Maids.
Not saying you shouldn't use Channel DVR Remote Access, that would be paranoid.
This thread may be a bit paranoid, but there are some good points here.
- Disable or allow to be disabled older cypher suites (SSL, TLS 1.0)
- Allow end user control over the port used for port forwarding
I have had ports open for servers on my home network for about 25 years now. I have ssh access to various systems, sftp, multiple https web servers, secure vpn access, unifi controller access, edgerouter access, synology dsm access, channels dvr, and more all on various ports. I also have ports open for multiple video surveillance systems on synology and raspberry pi servers. I have both onsite and offsite backups of my all my data. Shutting off my access from the internet for the miniscule chance that someone is willing to spend time and money in order to break into the TV recordings that I have on my NAS is ridiculous. If someone does break in, I can and will fix it. Its just not something that people should ruin their whole channels experience over.
Do I have a firewall on my edgerouter? Yes
Is a specific service listening on every port I have open? Yes
Do I have logins and secure passwords set up for every service I am running? Yes
Are brute force attempts blocked from successive retries? Yes
And thats good enough. Unless you are doing something highly illegal, storing classified information, or have something proprietary worth huge amounts of money on your dvr, this is all you really need to feel confident and not be so tentative with operating servers on your own network.
Maybe I'm wrong, but I think you missed the whole point of this thread.
It's not about you and how you view your usage of this service.
It's about the Channels DVR service and security for everyone that uses it.
I think the original question was more along the lines of:
Q: Is my Channels DVR secure enough for remote access?
And the answer to that is basically (assuming my previous speculation is correct):
A: As much as you trust the OAuth 2.0 standard, which is what Google uses to secure millions of Gmail accounts.
This thread has devolved into:
Q: How does Channels handle all API requests and which vulnerabilities exist?
Which is answered by:
A: If you need to ask this question, then either do your own pentesting to satisfy yourself, because otherwise you'll never be satisfied by anyone else's answer, or just don't use Channels' native remote access feature.
1 Like
Right. And the service is secure enough for what it is. Port 8089 is no different than any other registered port. Only one service can be accessible on any given port at a time, in this case it is a DVR.
A better architectural design would be to have channels local initiate a session to Channels' servers first. That way, no inbound ports are ever needed.
1 Like
The Channels server is your DVR.
Wrong, the Channels server redirects to your server where the DVR lives. You can see the redirect happen. Sticking ones head in the sand and pretending itās not going to happen may be OK for some, but not for me.
To the other questions, yes, I have enterprise gear properly designed and configured. As I said, more information would be helpful. If I know what the service is supposed to be doing and what data flows should look like then I can build rule sets to block traffic outside the norm.
Iāll most certainly do my own pen testing. Early tests already show the use of known vulnerable encryption protocols for the https traffic between the client and server. Iām sure there is more to be found if those items havenāt been addressed over a year after the rest of the world moved on from them.
Peace, out.
1 Like
TLS 1.0 & 1.1 have been disabled in the latest build of the DVR. This would only have been a problem if:
(a) you were using a client that connected using TLS 1.0/1.1 (which most browsers don't use, nor do the Channels apps),
(b) you were on an untrusted network, and
(c) there was a malicious actor on that network sniffing the TLS 1.0/1.1 connection and trying to crack the encryption used
Nevertheless, there's no reason for us to have those protocols enabled anymore so they have been turned off. Thanks for brining this to our attention.
As stated by others, if you're not comfortable using our remote access feature you can simply leave it off (which is the default), and instead use your own VPN or other mechanism for connecting remotely.
Note that if you setup your own reverse proxy in front of the DVR, it is crucial that you set up some type of authentication whether it is IP-based, basic http auth, or something more involved. Since the reverse proxy itself sits on your network, the DVR will think that a local client is connecting to it and will not trigger its own authentication scheme. You can also configure your proxy to inject the X-DVR-ForceAuth: true header which will enforce the DVR oauth prompt.
2 Likes
Is there a way for the client apps to connect using a reverse proxy? If so it may be beneficial for my use case with multiple DVRs using different ports.
Example: 2 DVR servers with a reverse proxy.... "https://mywebsite.com/dvr1" points to 192.168.1.2:8089... "https://mywebsite.com/dvr2" points to 192.168.1.3:8089.
I assume the DVR would need some way of defining the URL base for this to function, as would the apps trying to authenticate, correct?
Not real knowledgeable on cyber security, but I hope the changes will stop the attacks I have been getting for the last month. It seems to be about 2-3 times a week. Someone at 89.248.174.x or 89.248.162.x has been attacking my 8089 port. This last Sunday (12/15) I must have had 125 attacks over the course of the day (+ 12 hours). The good thing is that Ubiquiti's IDS/IPS seems to have prevented each attach. So, I can attest that there have been times when I have received 100's of attacks on my 8089 port.
Just run a VPN rather than use their service? While I haven't done this with Channels yet as I haven't been international in a while, I use to do this with Plex and SageTV without issue.
Hello. I have NordVPN service, and they donāt allow port forwarding unfortunately. Would I still be able to set things up the way you mentioned? If so, do you have a link? I remember I couldnāt get Plex to play nice with that setup before. Well, as far as remote access was concerned. Thanks.
I don't connect to any other server than my DVR. I use an nginx reverse proxy and have ports open. No serious issues in decades of open ports. If done right, it can be done easily and set up without serious repercussions in the event of an attempted breach. If something did happen, I have the skills to fix it quickly.
I am sorry that this is difficult for you to set up broadcast TV in a way feel comfortable about.
When I use my own home built VPN service my remote computer thinks itās on the home network. You donāt use remote access features once you have VPNād in to your home network. The only real possible issues are latency and bandwidth (limited by your home upload rate usually)
I did a quick search and only found one Channels server open to the internet that I got on without authentication, but that was only about one minute of work. As with everything on the internet, you need to take whatever security measures you feel comfortable with. If you use your own VPN, youāre still opening a port to the internet for the VPN. Thatās on you to trust the VPN service over the Channels service.
I have Fios Gigabit service so Iām not worried about the down/upload speeds. Any links on how to go about creating a vpn with your home network?