Thanks my friend. I'll do some experimenting and see what works best for me.
Any internet service can be disrupted if someone is willing to put in enough time and resources. But security measures are put in place to make things more difficult for a malicious intruder. Why is someone so interested in your DVR on port 8089?
They’re interested because it’s a web service with an open to the world via https. I can see in my IDS/IPS logs, mostly foreign countries making 1000s of attempts a day against the open port 8089. It doesn’t help that the default Splunk management port is 8089. Splunk is an enterprise class log collection tool. Gold mine if you can break into it and get to the data. It’s also the email rules port on a variety of Mac OSX server versions.
I can also see it supports TLS v1, v1.1 and v1.2. TLS v1 is not longer considered secure, the Payment Card Industry removed approval for use in June 2018. Here we sit almost 2020 and ChannelsDVR is still using it. TLS v1.1 also has known security vulnerabilities and is recommended to be disabled.
So, when folks are running this on their server, desktop or NAS, we have a risk with the security of the system and service using an port open for the world to brute force attack for eternity. Escape out of the service via some exploit and get access to the local system, hard disk storage or maybe jump to the remainder of the network. Without testing and review no one can be sure what vulnerabilities exist.
I can likely craft fancy firewall rules to limit access once I understand the data flows, which would mitigate some of this risk, but better documentation around what the service should be doing, what security protocols are in place, and other details would be helpful.
Thanks
I think you are a bit paranoid. The service is Channels DVR. I have access logs too, but don't have 1000s of attempts on port 8089 every day. Thats crazy. I think something is wrong with your network or you are misidentifying the IPs. I do have a separate auth on my Channels DVR, though.
Maybe you should consider changing the "external" port and forward that to 8089?
I don't think he's paranoid. Yes, OAuth tokens protect us from unauthorized access but I also like to minimize my attack surface with as few ports open as possible.
Have you ever queried your IP address against Shodan? Hackers use this to target servers with open ports. It'll show even port 8089. Enter your IP address to see what I mean:
https://www.shodan.io/
For example, here's a list of servers with 8089 open running the Channels DVR service:
https://www.shodan.io/search?query=channels+dvr
Those of us that also run Plex servers face the same concern.
1 Like
I am unsure what the relevance of 8089 is. If Channels DVR is listening on 8089, the DVR is the only service that can be connected to.
What port would you rather use?
Install a better firewall if you are that worried, run something like the Unifi Dream Machine and enable IPS and disable all access from foreign IPs.
Well, icsfsedod is correct. You may think of it as "only a DVR", but if compromised, everything on your network can be compromised. That said, anything exposed to the Internet should be locked down as much as possible, but still no guarantee.
2 Likes
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)
2 Likes
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?
2 Likes
@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