P2P 'Fail To' 'Quick And Steady Access' - Hikvision Defends Port Forwarding

By: IPVM Team, Published on Apr 02, 2018

Following criticism of Hikvision's ongoing port forwarding recommendation (e.g., Hikvision Hardening Guide Recommends Port Forwarding and Hikvision HQ Contradicts Cybersecurity Director), Hikvision has issued a new document entitled About "Port Forwarding" defending the use of the practice. Hikvision's defense is:

This is a fascinating defense considering Hikvision has been actively promoting their own P2P service, HikConnect, for more than a year. On the other hand, it is understandable since Hikvision has ongoing customer complaints about slow and unreliable HikConnect access (e.g., Broken Hikvision App Exposes Hypocrisy).

In this new document, Hikvision does acknowledge the dangers of port forwarding and not to directly connect, with an exception:

*** *** '******* ****** purposes' ********* ** ********* that (*) ********* ****** make ***** *** ******* provide ***** *** ****** access *** (*) *** many ** ***** ******* *** too ***** ** *********** improficient ** *** ** VPNs.

**** *** *** **** option *** ********. **** a *** *******, *** are ********* ** *** security *** *************** ** the *** ********.

Defense ********* ********* **********

********* ******************* ** *** *** priority:

** **** ***** *** true, ********* ***** *** recommend **** ********** ** all *******, ** **** ********** explain ** *** *** document's ***** ****:

*******, *** ********** ** selling **** ******** ** unsophisticated ******* *** ***** is, *************, * ****** priority than *************.

Comments (44)

Ethan Ace

IPVM | 04/02/18 08:08pm

Hikvision now recommends IP address filtering as a security measure for using port forwarding but it is not practical.

Allowing ranges for entire ISPs or mobile providers is hardly secure, as they may literally contain millions of IP addresses.

Second, if you're attempting to reach your home or business system remotely from a hotel, a coffee shop, a friend's house, etc., you'll be unable to connect. And that will require a service call to the integrator each time this happens, etc.

IP address filtering is great in a closed, local network where devices are static addressed. But for remote access, except in very well defined circumstances, it's likely to be unusable.

Jeff Gack

IPVMU Certified | In reply to Ethan Ace | 04/02/18 11:51pm

Is there no possible way that a network can be setup to minimize risks of using port forwarding for remote access to NVR and or camera?

Joshua Hendricks

Milestone Systems
In reply to Jeff Gack | 04/03/18 12:02am

Using a DMZ is a good approach. Here's a diagram from a Google search and for our purposes let's pretend DMZ 2 is actually just the main home or business network.

DMZ

In this case, between the Internet and the "Web Servers" which could be cameras, NVR's, or a VMS for example, you would forward only the ports needed by those services.

Then the firewall between DMZ 1 and the rest of the network wouldn't have any ports forwarded. You should still be able to access the devices in the DMZ from the main network because you're making an "outbound" connection through the second firewall into the DMZ network.

If the services in the DMZ are compromised, they could still lose access to cameras/video, be spied on by anonymous internet goers, etc. And those systems could still be used in a botnet that you may never be aware of. But in theory the main network remains a lot more secure than without a DMZ.

Unfortunately DMZ isn't a magic bullet. If a service in the DMZ is compromised, an attacker could then intercept communication between the client on the network and whatever service is in the DMZ. That means they could grab passwords, or take advantage of exploits in whatever protocols are used to potentially get through the second firewall into a vulnerable client PC.

Sean Nelson

Nelly's Security
04/02/18 09:42pm

Thanks for the "Fair and Balanced" reporting on Hikvision....... (Late) April Fools!

John Honovich

IPVM | In reply to Sean Nelson | 04/02/18 09:49pm

Sean, do you have a counterargument or are you just defending your ride of the Hikvision money train to obscene profits?

I would genuinely like to hear if you could mount a coherent counterargument defending Hikvision's position here.

Sean Nelson

Nelly's Security
In reply to John Honovich | 04/02/18 09:58pm

I'm just a lowly passenger of the train, you are the lead engineer driving the train at the caboose.

I'm still waiting on your reporting on the positive press release news on the transparency center. Understandably, you are are still "evaluating" it.

Given your excellence in fairness, how long did it take you to evaluate this press release before you reported on it?

Undisclosed #1

In reply to Sean Nelson | 04/02/18 10:10pm

press release news on the transparency center

The appointment-only one in CA that is limited to government employees?

That is about as "transparent" as this headlight:

John Honovich

IPVM | In reply to Sean Nelson | 04/02/18 11:18pm

I'm still waiting on your reporting on the positive press release news on the transparency center.

You've asked about this, we debated this at length here. I think there are a number of important unopen questions - e.g., what the NDA does or does not include? how can the evaluator verify it is the same source code that is in production? how much time do they really get? how can Hikvision make it more conducive to doing the review without being holed in a hotel room in City of Industry, CA for weeks, etc.?

ISC West is next week. Hikvision has hired a new global PR head. I am trying to talk to them to see if anyone will answer questions.

Sean, my commitment to you is this, the week after ISC West we will either publish a report on it or I'll let you know that Hikvision has agreed to answer questions and I'll give a date for publication, with their response (which is what I prefer - it could be positive but they do need to answer some questions to maximize how positive it might be).

Undisclosed #3

In reply to Sean Nelson | 04/02/18 11:24pm

Hey Sean,

Why do you think Hikvision opened a 'transparency center' to begin with?

Nobody else feels the need to do so....

I wonder why that is?

Sean Nelson

Nelly's Security
In reply to John Honovich | 04/02/18 10:04pm

Ok i will answer your question coherently as well.

I totally agree with you, they should have said this:

Press Release
Title: Top 3 ways to get remote viewing

#1) Use VPN, if that don't work...
#2) Use P2P, if that don't work....
#3) There is no #3, you are totally screwed if you can't figure the other 2 out. I mean sure, there is another way, but it would be totally stupid of us to mention it. So no, really there is no other way, you are screwed.

I think that satisfy your requirements yes?

John Honovich

IPVM | In reply to Sean Nelson | 04/02/18 11:21pm

Why does a VPN 'not work'? It's not like it's deep learning NVR... VPNs are a mature technology. The only issues are technical competence in setting it up and the willingness to spend the extra few hundred to do it.

If P2P does 'not work' that is on Hikvision. Seriously, Hikvision should proudly stand behind HikConnect and say "no, we only recommend using VPN or HikConnect." Agree/disagree?

Undisclosed #2

In reply to John Honovich | 04/02/18 10:28pm

What customers use for remote connection with Genetec,Milestone,Avigilon and etc..?

John Honovich

IPVM | In reply to Undisclosed #2 | 04/02/18 11:12pm

#2, good question. Let's clarify what manufacturers, including Hikvision, are and are not responsible for.

The sheer act of port forwarding is not necessarily the manufacturer's responsibility.

The manufacturer's responsibility is what they direct their customers to do. And Hikvision, for years and until today, continue to tell their customers that port forwarding is acceptable, both in writing and when you call support (we have tested this repeatedly over the last 6 months).

A good contrast is what an integrator said about Axis today when he called and asked for support port forwarding:

Support said port forwarding is a security issue

That's reasonable for Hikvision to do the same, yes/no?

Undisclosed #2

In reply to John Honovich | 04/02/18 11:26pm

"The sheer act of port forwarding is not necessarily the manufacturer's responsibility"

In any manufacture's VMS manuals you can find info about ports for remote connection

Yes/No?

John Honovich

IPVM | In reply to Undisclosed #2 | 04/03/18 12:01am

#2, 'any'? I am sure there are some out there as there are many VMSes in the world.

I don't know of any hardening guide where a VMS or IP camera manufacturer recommends port forwarding. Hikvision is so far unique there.

I applaud you for attempting to defend Hikvision but wouldn't it better for Hikvision to simply stop recommending it? Then you would have even a stronger case to go after companies that 1/100th Hikvision's size.

Undisclosed #2

In reply to John Honovich | 04/03/18 12:12am

I am sure you know how to "Google":)

Yes, any manufactures in their manual provide info about which ports to be open for remote communication

Do you want me to help you? :)

John Honovich

IPVM | In reply to Undisclosed #2 | 04/03/18 12:14am

Yes, please help. I am sure you have some manufacturers in mind so please share. In the future, you can post immediately. The drama of the setup is appreciated but unnecessary.

Undisclosed #2

In reply to John Honovich | 04/03/18 12:19am

Ok,

after googling for few sec

Digital Watchdog!

LAN SETUP: • Connect the DVR to the router • Enter the NETWORK menu • Change the Network Type to DYNAMIC and press IP DETECT This will pull the IP information from the router: IP address, Subnet, Gateway • After the progress bar reaches 100 percent, change the Network Type back to STATIC • You can now change the IP to be outside the Router’s DHCP range If you wish to keep the same IP you will have to reserve the IP to the DVR’s MAC ADDRESS on the router • Change DNS SERVER1 to: 168.126.63.1 • Change DNS SERVER 2 to: 168.126.63.2 You can find these DNS servers in the HELP MENU of the DVR. • Enable UPNP and AUTO Private IP , then SAVE AUTO Private IP will open the PORTS if the unit is connected to a basic router going to a basic modem. • After the progress bar reaches 100 percent, go to the DDNS tab. • Check the box to Use DDNS • Select the DDNS server Note: dwddns.net and dwddns2.net are hosted by Digital Watchdog. Dyndns.com is a third party service used only if you are unable to successfully register with DW. • Create a DVR NAME (no caps, no spaces) then click START to register the name with our DDNS service (Do not enter a User and Password on this tab. These options are only used when dyndns.com is selected) • Once you get “SUCCESS” for the registration, click on SAVE. (if it shows “FAILED” or no message at all, reboot the unit and try again.) ***Test the remote connection to see if the Auto Private IP function work*** Note: If you fail to connect then you must open the ports on the Router or Firewall. ROUTER SETUP: • Now you will have to open the ports on the router. The ports to be opened are under the NETWORK tab of the DVR. You may have to change the web port to 8245 as it is often blocked by the provider. TCP port 9010 needs to be opened as TCP /UDP • You can get port forwarding assistance by going to www.portforward.com , contacting the Router manufacturer’s tech support or you may call our technical support line at 1-866-446-595 • Once the ports have been opened you will then be able to connect remotely using the new DDNS address, which is the name you created plus the DDNS server. EX: johndoe.dwddns.net If you changed the web port, you must add it to the address when connecting in Internet

Undisclosed #2

In reply to Undisclosed #2 | 04/03/18 12:20am

More may be later:)

By the way I expect my Acc to be extended for few thousand years:)

Undisclosed #2

In reply to Undisclosed #2 | 04/03/18 12:24am

Security Center Installation and Upgrade
Guide
5.4 SR2

page 43

Default ports used by Security Center
After installing Security Center, you must ensure that all the correct ports are open and redirected
for firewall and network address translation purposes, so all the Security Center components can
communicate properly.
During the Security Center installation, you are given the option of allowing Security Center to create
firewall rules for its applications. If you select this option, all Security Center applications are added as
exceptions to the internal Windows firewall. However, you still must make sure that all the ports used
by Security Center are open.
You can configure different port numbers than the ones that are used by default.
Common communication ports
The following table lists the default network ports used by Security Center applications:
Computer Inbound Outbound Port usage
Main server TCP 5500 Directory connection requests
Client workstations
(Security Desk and Config
Tool)
TCP 5500 Directory connection requests
Client workstations
(Config Tool)
TCP 443 Communication with GTAP for SMA validation/
sending feedback
TCP 5500 TCP 5500 Communication between servers
TCP 4502 TCP 4502 Backward and Silverlight communication
All servers
HTTP 80 Connection via Server Admin
Servers upgraded from an
earlier version
TCP 4503 TCP 4503 Communication with servers of an earlier
version
Intrusion Manager TCP 3001 TCP 3001 Bosch intrusion panels
REST service TCP 4592 TCP 4592 Communication between System Availability
Monitor Agent (SAMA) and Directory server

Undisclosed #2

In reply to Undisclosed #2 | 04/03/18 12:25am

In 60 min I will check my Acc!

expect to see chage:)

John Honovich

IPVM | In reply to Undisclosed #2 | 04/03/18 12:40am

Good work, you will surely receive your rewards at Tao next week ;)

I've reached out to both vendors to ask for a response (the same as we did with Hikvision until they refused to speak to us). By end of tomorrow, we will update appropriately including criticism as warranted by their response.

Undisclosed #2

In reply to John Honovich | 04/03/18 12:47am

Here is idea for you!

if you really willing to help integrator's

find some really easy VPN setup

and create course

instead lots of Bla Bla:)

John Honovich

IPVM | In reply to Undisclosed #2 | 04/03/18 12:50am

We have a VPNs for Video Surveillance Guide that explains how to find a low-cost VPN, set it up, etc. I just made it public to help more integrators.

And if we can add to that, happy to do so. Thanks #2.

John Honovich

IPVM | In reply to John Honovich | 04/04/18 12:28am

Update: I have preliminary responses from both as they are both reviewing their documentation. They and I are checking on some things with further follow up tomorrow.

Undisclosed #3

In reply to Undisclosed #2 | 04/03/18 12:29am

holy crap! this may the worst-written technical documentation I've read in a while.

Undisclosed #3

04/03/18 12:37am

yes, but Hikcentral streamlines surveillance management...

"The system is designed with a high level of scalability and can scale up to a centralised management application– in HQ for example – and can in turn scale down to regional or branch level. This is made possible using RSM servers. With both single-spot and multi-spot storage backup, using RAID and hybrid SAN, the system has a large amount of contingency. It is also integrated with technology from high availability solution provider, Rose Replicator Plus, to give the solution a high level of reliability. These work to give users peace of mind in times of crisis."

John Honovich

IPVM | In reply to Undisclosed #3 | 04/03/18 12:44am

The brand new HikCentral hardening guide also recommends port forwarding:

Alex Gonzalez

IPVMU Certified | 04/04/18 12:30pm

I always use port forwarding procedure, I never felt that I can trust any of those P2P services and I don’t even use Hikvision products. Is there anyway to setup a private P2P server? Again I don’t trust any of the manufacturers p2p. What are your recommendations?

thanks

Jon Dillabaugh

Pro Focus LLC
04/04/18 12:40pm

I’m not sure if you are aware of this (or maybe we were misinformed), but HikConnect is limited to a five to ten minute timeout. It’s not intended for extended usage or access.

We were told this at a recent Hikvision Roadshow event. While we don’t generally use HikConnect, I did think it was similar to the P2P offering in that you could use it continuously. Knowing that it’s really just to pop in and take a peek once in a while severely limits it’s usefullness.

It would also explain why port forwarding is still required. The Hik technician that assisted in the Roadshow explained that we should never use standard ports and that security thru obscurity was the best option. He had a nice story about a 40 year old script kiddie in his moms basement that was itching to hack you just for the lulz. At which point, the sales guy insinuated that the Hikvision tech was said person in the basement. Laughter ensued.

Rob Kilpatrick

IPVM | IPVMU Certified | 04/04/18 06:55pm

I’m not sure if you are aware of this (or maybe we were misinformed), but HikConnect is limited to a five to ten minute timeout. It’s not intended for extended usage or access.

We were told this at a recent Hikvision Roadshow event. While we don’t generally use HikConnect, I did think it was similar to the P2P offering in that you could use it continuously. Knowing that it’s really just to pop in and take a peek once in a while severely limits it’s usefullness.

I looked into this today and couldn't find aything in their documentation about a timeout. I even called tech support to ask about this and the tech told me that it is a viable way to view cameras and he was clear that there is no timeout after a certain amount of time, although there are better options (iVMS).

To test this I have a phone with Hik-Connect on in live view of a camera that has been running for ~1 hour now and it still hasn't timed out.

Jon Dillabaugh

Pro Focus LLC
In reply to Rob Kilpatrick | 04/04/18 06:58pm

I will reach back out to the Hikvision reps that held the Roadshow for clarification and follow up with their response.

Jon Dillabaugh

Pro Focus LLC
In reply to Rob Kilpatrick | 04/04/18 07:15pm

I found another site where people were complaining about the 5 min timeout

Jon Dillabaugh

Pro Focus LLC
In reply to Rob Kilpatrick | 04/04/18 07:42pm

Here is a link to the Hik-Connect datasheet where you can find the 5 min timeout. So, if you are NOT using port forwarding, meaning using their P2P service, there is a 5 min timeout for live viewing. If you are using port forwarding, NOT using P2P, it is unlimited.

Rob Kilpatrick

IPVM | IPVMU Certified | In reply to Jon Dillabaugh | 04/04/18 08:05pm

I will reach back out to the Hikvision reps that held the Roadshow for clarification and follow up with their response.

Thanks, curious to hear what he has to say since tech support told me otherwise.

I found another site where people were complaining about the 5 min timeout

Looks like people are saying that it happens randomly? I have never seen this happen before. Currently added 4 cameras to live view through p2p service running for ~30 minutes with no timeouts.

Here is a link to the Hik-Connect datasheet where you can find the 5 min timeout. So, if you are NOT using port forwarding, meaning using their P2P service, there is a 5 min timeout for live viewing. If you are using port forwarding, NOT using P2P, it is unlimited.

I am using the P2P service to view these cameras and I have yet to see a timeout happen.

Jon Dillabaugh

Pro Focus LLC
In reply to Rob Kilpatrick | 04/04/18 08:07pm

Here is his response:

When you connect through the cloud portion of hik connect, there is a 10-minute timeout. This is for people that leave their phones connected inadvertently.

If you connect through the hik connect ddns there is no time out

John Honovich

IPVM | In reply to Jon Dillabaugh | 04/04/18 09:33pm

To clarify, HikConnect DDNS = port forwarding? I am curious then how many are using the 'full' HikConnect P2P vs HikConnect DDNS / port forwarding?

Undisclosed End User #4

In reply to John Honovich | 04/09/18 03:27pm

>HikConnect DDNS = port forwarding

no, HikConnect DDNS is simply a service for keeping track of a DVR’s public IP address (which may change depending upon their Internet provider ). DDNS= Dynamic domain name system .

You don’t have to use Hikvision ddns, but with or without it you do still need to use port forwarding.

( Port forwarding is how your local router knows that a request to 63.32.2.4:80 should be “forwarded” to local device 192.168.1.7:80 , as an example ) . Without port forwarding, your local router does not know where a public ip request to port 80 should be directed to locally.

With a P2P or cloud-based service, you don’t have to use either (assuming hik’s p2p / cloud is online/working)

John Honovich

IPVM | In reply to Undisclosed End User #4 | 04/09/18 03:30pm

That's my point, that using HikConnect DDNS, like other DDNS services, effectively requires using port forwarding. I apologize for the unclarity.

Ethan Ace

IPVM | In reply to Rob Kilpatrick | 04/04/18 08:03pm

I can confirm I've been looking at a camera in iVMS and on my iPhone via Hik-Connect, no port forwarding, for about 20 minutes now.

Jon Dillabaugh

Pro Focus LLC
04/04/18 07:19pm

Here is another nugget I found. Solution #3 is my all time fav!

How to deal with error ‘receiving data from device timed out’ appearing in iVMS-4500?

May 26, 2016 Views:1346

Answer

[Possible reasons]

1. Poor network condition

2. Incorrect port forwarding

3. Firewall blockage

[Solutions]

1. Try changing to wifi or other mobile telecom operator

2. Make sure the port forwarding is correctly configured and that the server port is active. Sometimes the port might be blocked or occupied. Users can try changing to other ports, for example, HTTP port changing to 81, server port changing to 8001, RTSP port changing to 1554, etc.

3. Turning off the firewall of the modem/router

Undisclosed End User #4

04/08/18 08:05pm

This post/scenario reminds me of a discussion I had over on the Plex forms (Plex is a media server , not cctv related , but its server requires port forwarding, and to even use Plex , you need a server - ergo open ports. )

Granted these users may not be knowledgeable users or not security focused, but I was surprised at the amount of backlash I got in pushing for a cloud/P2P (or using a firewall hole punching technique) alternative or option to the mandatory port forwarding. Legit Plex clients that would be using the port forwarding , usually come from random IPs addresses (thus just about ruling out ip ACL‘s on those ports that you must forward ) .

Anyway here is the link if anyone’s interested (the short of it is users were citing the risk of Plex or a nefarious after getting control of the Plex cloud/P2P system and then having the ability to access or direct the millions of servers that were using this system , vs Port forwarding using port forwarding where users maintain control - Horrible, almost invalid, points in my opinion.)

Allow firewall hole punching to increase security

Also a much related link is the technique of firewall hole punching that I’ve seen used in various scenarios ( I found this during my discussion above) :

TCP hole punching

Undisclosed #5

In reply to Undisclosed End User #4 | 04/09/18 02:36pm

I've never thought the value exceeded the risk with Plex's cloud based authentication and remote access. It doesn't seem wise to trust a closed-source third party with the keys to the network when most of their users are hosting large volumes of illegally acquired copyrighted material.

My preference would still be VPN or perhaps an nginx reverse proxy if I'm feeling daring.

Undisclosed End User #4

In reply to Undisclosed #5 | 04/09/18 03:15pm

Good points.

It’s worth noting, that you don’t have to use their cloud authentication (at all) + you can set your server up to white list local IP ranges (Ie only the subnet of your local network, and/or the IP range/subnet of your VPN clients). Of course you may then deal with performance issues, but it’s nice they give you that option.

Also imo, the value in their product ( your local plex server) is its ability to transcode video in real time depending on what the streaming device *can* support. (Ie store your videos in any format , The server will organize them and deal with the client devices format/streaming needs. EXample: playing a .avi stored video in Safari browser on an iOS device , which only supports mp4 video , plex server will transcode in real time into that MP4 format )

(btw for those unfamiliar with plex and wondering what does any of this have to do with CCTV- very little to nil: it was mainly in regards to the similarity of their open ports versus P2P/cloud accessibility and (lackof)security as it relates to the exact same issue with ip cameras)

Read this IPVM report for free.

This article is part of IPVM's 6,533 reports, 880 tests and is only available to members. To get a one-time preview of our work, enter your work email to access the full article.

P2P 'Fail To' 'Quick And Steady Access' - Hikvision Defends Port Forwarding

Comments (44)

Ethan Ace

Jeff Gack

Joshua Hendricks

Sean Nelson

John Honovich

Sean Nelson

Undisclosed #1

John Honovich

Undisclosed #3

Sean Nelson

John Honovich

Undisclosed #2

John Honovich

Undisclosed #2

John Honovich

Undisclosed #2

John Honovich

Undisclosed #2

Undisclosed #2

Undisclosed #2

Undisclosed #2

John Honovich

Undisclosed #2

John Honovich

John Honovich

Undisclosed #3

Undisclosed #3

John Honovich

Alex Gonzalez

Jon Dillabaugh

Rob Kilpatrick

Jon Dillabaugh

Jon Dillabaugh

Jon Dillabaugh

Rob Kilpatrick

Jon Dillabaugh

John Honovich

Undisclosed End User #4

John Honovich

Ethan Ace

Jon Dillabaugh

How to deal with error ‘receiving data from device timed out’ appearing in iVMS-4500?

Undisclosed End User #4

Undisclosed #5

Undisclosed End User #4

Read this IPVM report for free.

Member Login

Related Reports

Recent Reports