Just google “OpenVPN server setup on _____” with the blank replaced with your operating system is a good start.
I use Synology NAS for my DVR and other things. It has a built-in VPN Service that is extremely easy to setup. I use it for my home and office. I personally use OPENVPN but you can use L2TP and PPTP (discontinued by Apple). OPENVPN is harder to setup on the client but worth it. I use both L2TP and OPENVPN for my employees.
I currently do not use the VPN for my DVR Remote Connections but I have a lot of experience with the Synology VPN for my office remote access.
Search Raspberry Pi and OpenVPN
One thing Channels could do is to provide a list of IPs so those of us who are security aware could whitelist them for port 8089. Maybe you could script something that creates a whitelist from DNS lookups, assuming your traffic analysis shows that it's doable.
Personally, I'm not using the remote feature because of the potential security problems.
I don't have the reference at hand, but someone posted a slightly roundabout method of moving from port 8089 to a different port. It's not a substitute for security, but getting it off Splunk's default port may take a little pressure off.
for those of you who are saying "i don't care about someone getting the TV shows on my DVR", the reality is that the attackers don't either. What they do care about are things like: the backup of your computer that includes documents with SSNs, credit card numbers, etc that are also on that NAS; using the DVR to pivot into the rest of your home network and get at the good stuff that's on the other computers; and compromising as many of the devices inside your home network as possible so that they can then be used to attack other systems.
-a sysadmin
2 Likes
The IPs are your own clients. Your client connects directly to your DVR. By default, a separate auth is used, but you don't need to use that. Most clients, especially mobile ones, change IP all the time so a whitelist isn't really going to work easily.
There are published vulnerabilities to many services, but most require a sufficiently motivated attacker to gain anything worthwhile.
If you shut off your internet and disable all NICs on your server, you are secure, barring someone breaking into your house to get your DVR.... but you limit your a lot of the great capabilities of networking.
If you want to run some servers accessible from the internet, ports need to be opened. Keep track of any known vulnerabilities to the software you are using and make sure that a specific service that you require is listening on an open port.
As long as you are using a good authentication mechanism, changing the open port to a different number does not increase security.
-a software engineer
Technically yes, but practically no.
In one instance I ran SSH on the standard port and an obvious alternative port (22 and 22222 respectively) for several weeks and during that test I saw around 100x as many attacks on the well known port.
While authentication is necessary it is not a magic wand. It doesn't matter how good the authentication is if there are software errors (e.g. buffer overflows are the most common) that enable attackers to bypass it.
Moving the port is a pain but it will reduce the number of attacks. It's one layer you can add to your defense, if you know how to use it.
Personally, I would just disable all of the remote access functionality and only use it at home on my network. Just like with my QNAP, I don't use any of their "cloud" functionality because I don't trust it.
It will reduce your log entries. But those aren't targeted attacks. Something like a script-kiddie running some pre-made script they found on darknet that runs a low-level cursory scan on a few known ports for a whole mass of ip space. Changing your port will eliminate these attacks, which were going nowhere anyway. It will reduce your log entries for this type of thing though, which I agree is nice... i don't like them either. I usually just vpn in and open the ssh port when I need it, but I like it at default because I don't need to remember the ports when typing as a shell command.
A targeted attack where an attacker wants something specific that you have is different. They would just run a port scan on your IP and see that you have ssh running on 22222.
Attempts to hide a service by switching the port is often called "security by obscurity", aka: not security at all, and has been proven does not work for a real threat.
2 Likes
The first on the list on shodan today is @Bigriffi 
I think we need a wall of sheep or maybe a wall of lamb.
Wait till you get hit by a zero day. The real threat will probably not be targeting you unless you are an hvi. However partaking as a node in a netbot is not fun. Plus there is enough info on that box to convict you for possession of common sense with ease.
1 Like
Argh, what am I doing wrong?
Lets add a few names to the list -
@alan.cooling @johnfsnow @GeoMan73 @Gonzo @jamiemcconnell
I don't even have an account on shoban ....
@sdust what's the practical way to "not show up on Shoban"? or protect myself, seriously not sure what to do.
@Bigriffi what kind of router or device are you running at 192.168.1.1? did you install manual port forward rules or setup some kind of proxy there?
1 Like
I have an enterprise class Fortinet router with manual port forward rules. I had used Meraki (manual rules) before I joined Fortinet, and it's pretty straight forward. I had turned on the IPS functionality but and lots of scanning/rules my SE suggested, but then Channels didn't work, so I just went with a basic setup and it works fine. If you had my setup, what would you do to protect yourself without breaking the service? I have an FG-60F Fortigate.
I think maybe you need to enable NAT mode on your ipv4 policy? Sounds like this device does a lot of fancy stuff and via doing a lot more than a simple nat port forward like most home routers would.
The issue is that over LTE in a in incognito session if you access your public IP your dvr is wide open. On a normal installation this would not occur.
Clearly we could be doing better to detect these exotic setups and make things more secure by default. It's something we are looking into.
Yeah, NAT is enabled. It's pretty complex, and the more I locked it down, the more I thought Channels wouldn't work. I still have a bunch of rules and inspection/filtering enable that I don't fully understand. Probably time for another session w/my SE.
I am thinking at this point you should be opening your router/firewall only for the IP you are connecting from. I am surprised nobody is asking how were their names obtained ....
Were they obtained by browsing to each shodan-listed IP at port 8089 and having full access to each DVR like I just did? I had to stop after the 3rd one because I felt so gross, like I was breaking into people's homes. I think this may need some work. 
1 Like
Apparently most routers perform not only DNAT but also SNAT which makes the DVR think the connection is local. There should be a separate, ssl only, port for public access.
Bonus points for not showing Channels certificate when connecting by IP.