How to access a DVR remotely without opening ports?

thecomputerguy

Well-Known Member
Reaction score
1,407
Client has a camera system which is accessible via a mobile app as well as a web browser. Ports are required to be opened to make this work... specifically (Vitek Cameras).

TCP/UDP 5000
TCP/UDP 443
TCP/UDP 8000
TCP/UDP 631

Client was complaining that their internet was intermittently dropping. I started troubleshooting and when sifting to logs I was seeing that their DVR was getting pummeled due to the open ports. Every time their internet cut out the DVR uploaded a massive amount of data which shut them down. See the graph below:

All purple spikes are the DVR sending data and then the internet drops hence the red outage.

1741309858791.png

What is the correct way to do this these days. I know this is an old school setup and open ports = BAD.

I've since disabled the port forwarding.

Is this a VPN in and then accessing the cameras that way type of situation?
 
Last edited:
VPN has to happen on both ends. So that also requires open ports. The only time that ports aren't opened is when a LAN device makes an outside call. Are these IP cameras or coax?

Edit: just occurred to me you could use a remote access app. like Anydesk, etc, etc. Install on a local workstation and use that browser.
 
IMO would be worth upgrading that old style DVR to one that supports a cloud based proxy service that doesn't require port forwarding. Sometimes it's just a firmware upgrade. Other times...swapping out the DVR/NVR to a newer model.

The old style like this is a big security risk.

While technically a VPN would allow those ports to be closed, thus the DVR wouldn't be under attack/probing/grinding all the time, VPNs for camera viewing just make it a complicated process. Should be able to quickly just pull up the viewing app on the smart phone.

I'm not sure about the cause of the massive upload spikes. Could be...the DVR is already compromised and being used as a bot army member to participate in attacks. Hikvision had a weak firmware which allowed them to easily be taken over..(thanks to port forwarding)...and used bot army members to launch one of our bigger internet DDoS attacks....against many DNS servers, I think that was in 2016? Maybe earlier.
 
Last edited:
If the customer doesn't require remote viewing just pull the connection the DVR has to the net. I had some cheap Chinesium (Sricam) security cams for a long time until I got a note from Charter (my ISP) that they were accessing the net (I forget how Charter put it) and I didn't even have remote viewing set up. They could turn on UPnP and open ports on the router.
 
I've since disabled the port forwarding.

Has it stayed disabled? Have you checked? (Run a port scan.) I turned off port forwarding several times but every time I checked it was on again and traffic was to the IP of one of the cameras.

As @YeOldeStonecat mentioned, on online cloud-based system is what is typically used these days for remotely viewing your security system.
 
Interestingly ...

Even after disabling the port forward the device was still mass uploading causing outages. The only way I am able to stop it is to create a firewall rule that denies all internet activity inbound and outbound.

I contacted the installer of the cameras and he remembers changing the default login but can't remember it.

He reccomended I call Vitek ...

UGHHHHHHHHHHHHHHHHHHHHHHHHHHH

It's almost like the device is compromised and mass uploading data to a cloud service like dropbox or something ... all of the data my Ubiquiti UDM will give me is that all the compromising traffic is EVERYWHERE for this device.

March 7th is when I disabled all inbound/outbound internet traffic. I disabled that rule today and the issue re-occurred at 12:22

1741490220949.png

I wonder if I can do something here that would block these ... I currently have it set to notify only ... maybe I need to change it to Notify and BLOCK ... I honestly am not sure how I should be dealing with the items on this page

1741490308605.png

I'm going to change it to notify and block and disable my inbound/outbound rule and monitor.
 
Last edited:
Digging around it looks like the initial intrusion occurred In February from Iran which executed something which compromised the DVR. This was done over one of the required open ports to access the cameras remotely through a web browser using [PUBLIC IP]:8000

More than likely the camera installer left the login credentials as default.

1741555971802.png
 
I believe the issue is that the DVR was compromised and I don't think it was uploading images. I believe it basically just became part of the bot network and was being using to troll IP's and ports.

The plan moving forward is either factory reset the current DVR, Firmware it, then only open the port for mobile access. This risk being that the Purple drives in the DVR are 7 years old, and that it this issue could re-occur.

The other option is a new DVR that uses login based access as opposed to open ports. My wiring professional recommended these DVR's (https://www.lumasurveillance.com/). My client is completely open to this 90% chance this is the route were going to take.

Just expensive because he has 24 cameras so we'd need a 32 channel DVR.

The bonus is my wiring guy is going to do all the work so I don't have to.
 
I believe the issue is that the DVR was compromised and I don't think it was uploading images. I believe it basically just became part of the bot network and was being using to troll IP's and ports.
I think that probability is 99.9999% accurate. Nuke and pave is always a possibility but you have to look at it closely. Almost certain the OS is some *nix version. My experience with these is many, if not most, of these OEM's don't provide certified patches for their devices. That Apache server version is maybe 4-5 years old. I doubt that the OEM will have published updates. Even if they had I'd not try to kludge together the system by manually installing updates. Could take hours and still not have any certainty of security success.
 
Back
Top