P2P is the worst protocol to have been introduced in IP camera systems, regarding security. It's purposefully designed to punch through safety/control measures. Some may say ONVIF is worse, but I digress. :D
NOTICE: This comment was moved from an existing discussion: Hikvision Hardening Guide Recommends Port Forwarding
I made this its own topic since I think it's an interesting issue to discuss.
There is no doubt that this is true, since it is by design: "purposefully designed to punch through safety/control measures". I am curious how many people see that as an overall net negative?
Here's a poll:
There is no doubt that this is true...
But you don’t really believe it’s worse than port forwarding, do you?
I would argue P2P is worse than port forwarding because it can be done without knowledge. At least port forwarding requires the user/installer to know what ports need to be opened. P2P just has the user/installer scan a QR code and tells them everything is golden.
At least port forwarding requires the user/installer to know what ports need to be opened...
Actually it doesn’t when UPnP is present, which is how many, if not most home routers ship.
#2, good question. Port forwarding is riskier in the sense that it allows anyone to have access.
On the other hand, P2P can undermine the general security measures put in place by an organization's IT department in that it can be deployed without knowledge or permission of the IT department, yes/no?
John,
Why would "anyone" have access? Forgive me, I assumed we'd be MAC/IP filtering, or something. I'd kind of like to speak in general for a bit, from an IT System Administrator perspective. I'd kind of like to get some feedback on my ramblings and see what the general consensus is regarding all of this.
Port forwarding/triggering is a metaphorical front door, only and is not a lock/control measure. It's where ALL data should flow through. It's then up to us to control/secure it. If we want to be able to access an admin page from ANY browser, then ANY person COULD connect to it. Same with any protocol. However, we are expected to limit ports/applications/REMOTE ACCESS. Even if you set up a VPN, you will already have forwarded the ports as required and then you should still set up MAC/IP Filtering/something so that you are not visible to the WWW.
There are routers that have the capability to authenticate or "route" per source address, destination address, type of traffic, characteristics of the Layer 4 communications sessions, which interface the packet came from: (Sec. 2.2, NIST Guidelines on Firewalls and Firewall Policy).
I want to state that if we do not enable MAC/IP filtering, on some level (whether at the firewall or application layer), your services are exposed to the WWW and are therefor enumerable and fingerprintable for exploitation. However, if you enable MAC filtering, your devices will still be accessible from the WWW, but you are (ideally) hidden from bots/hackers.
Consider this scenario:
1) You set up a NVR with SSL and the admin page is https://IP:PORT.
2) You forward PORT on your router to your NVR, exposing it to WWW.
3) If you leave it there, anyone in the world can access the webpage in their browser, wget, netcat, telnet, whatever, via https://IP:PORT and you are indexable by search engines/Shodan etc. The NVR returns a "200" HTTP status code to any browser or application that tries to connect and the browser displays the page. That status code is what's most commonly used to begin enumerating targets and fingerprinting services for exploitation.
4) If you set a MAC filtering rule (stating this because MAC filtering is probably one of the easiest control methods, not the only one. You can set rules in Apache for example, sorry rambling on and may as well ramble a little more.) in your firewall that only permits access from your devices, when other people try to connect they receive a different code which is normally received by an attacker as a "nothing to see, move along" signal. They don't even see the login page when they connect from a browser, they get an error. This prevents enumeration of vulnerable targets on a larger scale.
Whatever we do, if we enable any remote access (VPN, SFTP, SSH, Telnet, etc.) and have the ability to limit access, do so as it not only limits access as expected, it prevents hackers from knowing you are there in the first place, if configured properly.
I'm going to go on record (anonymously lol..) and state that port forwarding to an SSL enabled admin page, with MAC filtering is a VERY secure method to present an admin interface. It is infinitely more secure than P2P and it this configuration has a shot at making it in an enterprise/government environment (if a IP CCTV system is even permitted). They likely have access control policies in place and would likely gladly take over the remote access, porting, and admin configuration. That's actually their job. :)
We should familiarize ourselves with NIST, however due to the lapse in funding the website is not available. Seriously.
Why would "anyone" have access? Forgive me, I assumed we'd be MAC/IP filtering, or something.
IP filtering is impractical to configure for most users because it too heavily restricts the user and puts too much of a burden on the installer.
Common video surveillance scenario is a small business who wants to view their cameras remotely. If you do IP filtering, any time the IP address changes (the person uses their phone on the road, at their relative's house, etc.), that new IP address is now blocked and they cannot view their system. The customer is angry, calls the installer, the installer now has to manually add a new IP address for every new place the customer wants to view their cameras. It becomes impractical.
If you set a MAC filtering rule (stating this because MAC filtering is probably one of the easiest control methods, not the only one. You can set rules in Apache for example, sorry rambling on and may as well ramble a little more.) in your firewall that only permits access from your devices, when other people try to connect they receive a different code which is normally received by an attacker as a "nothing to see, move along" signal.
How are you proposing to do this for devices across the public Internet? For example, customer is at a restaurant and wants to see their cameras at their office? How would the office router / firewall be able to see the MAC address of the device attempting to connect on the port forwarded? MAC addresses are layer 2 and not 'shared' across the public Internet, e.g. Is your MAC address revealed when you hit up a website?, MAC filtering the internet traffic?
John,
Reading back, I may have insinuated MAC filtering can be used to filter WAN traffic, it can't. I was referring to IP/Mac filtering a little too loosely and may have confused myself! I should have stated "IP" rather than "MAC" filtering under bullet 4.
I am not trying to speak of the "challenges" of configuring such a network for installers etc. I'm trying to state that browser based admin, facilitated by port forwarding is infinitely more secure than P2P can be, as you forfeit all trust in a P2P network.
You forfeit trust (in a different way) using DDNS however you can set up your own.
What's the better option?
It is incomparably worse to use P2P than even what you are call "port forwarding" configurations.
Not digging at anyone but let's make sure we know the vendors implementation of P2P before we recommend it.
P2P is not a program, it's a vendors proprietary blend of protocols that are mostly undocumented and likely pretty well veiled in corporate secrecy.
TCP, SSL/TLS, as used with "port forwarding" configurations are the best that humanity has yet devised and implemented for a secure and redundant transport layer. It's what the web is built on and if it weren't for vendors horrid software practices, I'd have a hard time being convinced of it's negative connotations in this usage. I don't think you realize how much you actually DO trust this technology compared to P2P as you know probably know nothing about vendors implementation of P2P. Weird paradox here where we trust a known quantity "port forwarding" configurations, moreso than the hodgepodge of protocols vendors call P2P.
I'd be glad to discuss all of this in detail but I just don't know how to in one post. It's easier to understand IT risks etc, when you stop using words like "Internet" and "Cloud" because they don't exist (whut) and vendors explanations that "we use Cloud/P2P/Nat Traversal/Zeroconfig technology" explains NOTHING about the systems at all and should immediately raise red flags. Again, there is a high likelihood that vendors are not using standard libraries --if they even exist-- to support their cloud/P2P etc implementations.
Port Forwarding: Feel free not to trust it if you like but it's a known quantity. TCP, TLS/SSL are battle-tested industry standards and their libraries are likely obtainable, reviewable, editable, deployable, hallelujah FOSS.
P2P: I spent a few hours reviewing a vendors literature regarding their P2P implementation and it doesn't explain at all how it's achieved, as expected; not in a bad way but nevertheless, as expected. I don't want to call them out but they all seem to say something similar to: "We use Nat Traversal to achieve a zeroconfig P2P connection". It doesn't explain if they, for example, deploy SOCKS/STUN/ICE for NAT Traversal and some may consider that very important to know. :P
Liability: This is all key when you consider your liability from, let's say a data breach. If someone hacked your system, it's probably better to go with industry standards. P2P isn't a standard, no more so than the "Internet", or the "Cloud" is a standard. Just as we'd want to know how Grandma is getting to Christmas dinner, we want to know the transport method used to authenticate and achieve P2P with our "secure" data.
Paradox: The underlying protocols (TCP, TLS/SSL, others) that drive the browser based admin web page are well known, we all know them, they are taught in school, and are standardized. The underlying protocols (X, Y, Z?) that drive each vendors implementation of P2P are not published, not understood, and any modicum of trust if forfeited to the 3rd party, likely in China (cough). Yet there is a seemingly large consensus that "port forwarding" is bad. Again, compared to what and please s/internet/TCP/i etc.
The underlying protocols (TCP, TLS/SSL, others) that drive the browser based admin web page are well known, we all know them, they are taught in school, and are standardized.
P2P implementations use all the above. Did your school not teach UDP and it’s relation to the TCP/IP protocol stack?
If you said P2P implementation "can" use all the above, then I'd be tracking with you. As it stands, I'm confident that you can not adequately, for example, explain DW Spectrums "Cloud" implementation. Not unless you get the info out of them somehow, potentially signing an NDA. They could be sending packets from their "Blackjack" server via Telnet/SSH/IRC!/Courier pigeon, you don't know and if you did, I'm guessing you wouldn't tell me.
It is a fact that vendors have and likely still continue to implement P2P methods that incorporate transmission of credentials over UDP. Any protocol that does credentialing over UDP shouldn't be used and in the very least it should elicit an warning to the client.
Do we understand the inherent risks of using UDP for that matter?
U1.
I work for the team which does the software.
Since in our design we use this principle Kerckhoffs's principle, there is nothing to hide. So feel free to ask.
This is how the connection between client and server is established.
1) first we try to use NAT traversal technics(UDP hole punching more specifically, STUN servers are used). The success depends on providers, routers models etc and not guaranteed. If "UDP connection" is established, we use UDT library(which allows us to use TCP over UDP, which allows us to use HTTPS over UDP). Practically since this point, we have secured connection between client and server.
2) If NAT traversal does not work, we use a simple proxy(I guess it cannot be considered as P2P).
We believe practically this scheme is more secure than port forwarding, since if you have port forwarding: the intruder by scanning ports can find which software do you use, which port it's running on and then do DDOS attack or something.
A lot of software including(skype and teamviwer wolu be be 2 examples)use absolutely the same technics.
Lastly, all traffic is done trough and only through:
dwspectrum.digital-watchdog.com
TCP - ports: 80, 443
option I:
*.vmsproxy.com
option II:
relay.vmsproxy.com
relay-ny.vmsproxy.com
relay-fr.vmsproxy.com
relay-la.vmsproxy.com
relay-sy.vmsproxy.com
mediator.vmsproxy.com
TCP Port : 80, 443.
Thank you very much for the input. I'm truly impressed with the effort you've put in to transparency. I never meant to "call out" DW (or Dahua, I made a reference about them as well) but I felt compelled to use real life scenarios to try to hammer home my concerns about P2P.
My problem or "fear" (I should say), is that we keep advocating P2P usage based on misconceptions of the underlying technology. I don't want to cast a shadow on P2P or anything else. P2P can be made secure enough for TEMPEST systems I suppose, but at present P2P is a ghost am I'm just trying to throw a sheet over it so we can see it..
I believe this insight may be the best glimpse in to a P2P implementation I've seen published by a vendor. With that said, I feel this is the type of information we need to begin logically analyzing risk.
UM5's comment makes me want to ask more questions than not, but I don't think it's fair to inquire about config specifics as one tweak in a configuration file could give you the edge over competitors etc. However, since DW is talking, I'm hoping UM5 could answer a few general questions that may help the industry as a whole:
UM5,
1) When a person enables P2P as we would in our application, is it true that the P2P provider has the ability to control and monitor the systems? This to me is obvious but I think some people need to hear it. P2P relies on the integrity of the vendor and its implementation.
2) Do you have any recommendations to spot weak P2P implementations? Maybe throughout your product development you've discovered a few technical no-nos. Is there anything in particular we should look out for from vendors across the board?
3) Would you recommend using OTHER companies P2P implementation over port forwarding, without having first made an attempt to understand their implementation?
Thanks again!
U1, in general, I agree with your point.
Sorry for the delay I missed a notification.
To answer your questions:
1) I cannot talk for others. With our product, the answer is no. We can't access the system, we cannot control it. This is a design choice - we choose to do it so, that even we hacked as an organization - no traces to the customers' systems. This way it's just less responsibility on our shoulders.
Though, I cannot say about other p2p providers in general.
2) nothing I can think of what could be done by end users or integrators. I would suggest asking: how do you make sure your solution is secured? (Obviously, it's not a QA job to catch security issues). We, for example, have a couple of security specialists, but most importantly we opensource our code for 3rd party cybersecurity company to check. And they do find things for us to fix. A good question would be: How often such 3rd parties audit is done?
3) Depends on the volume and risks. Practically very few organizations would do any checks. If security is deadly critical to them - they would not connect the system to the internet at all.
So if we advise to ask the questions I gave on 2) ..nobody cares. Hik has backdoors. So what, it still on the store shelf...
I accidentally voted "Disagree" when I meant "Agree". There is no valid argument IMO that a P2P connection between a client device and a cloud based service is not "a security risk". The question is whether there is greater, or lesser risk, and what kind of risk that is.
I still think a P2P connection is less risky than using port forwarding. Assuming the protocol(s) used to maintain the P2P connection itself are reasonably secure, then you're putting your security in the hands of a company who (hopefully) has significantly more resources than you do to manage security and keep infrastructure up to date. It's certainly possible that the P2P provider could have a breach, but they should be quick to react and patch - probably quicker than 99.9% of their customers would be to update firmware.
If your preference for port forwarding is because the manufacturer isn't trustworthy, then the argument falls flat since the manufacturer could easily implement a back door enabling them to find and access devices over the internet without P2P.
There is risk with both. I would probably lean toward P2P for smaller installations where there is limited damage a person could do if they got access to the camera network, and VPN for anything else, while doing my best to ensure that sensitive resources on the network are insulated in both cases. And of course the first step is to choose products and manufacturers you feel like you can trust in the first place.
P2P is still punching a hole through the firewall to gain access to the cloud server. At best it is security though obscurity. At worst it is an unauthorized breach in the firewall.
In a technical sense, it's not "punching a hole" since it's acting no different than a client PC making an outbound connection to the internet and communicating with a web server. From the firewall's perspective it is indistinguishable from normal internet activity and there's no way for a random netizen to initiate an inbound connection. But it does invite the P2P provider into your network if they've designed their firmware to allow remote code execution.
If a user is doing this without IT approval then yes, I agree it would be unauthorized. Otherwise, if you're making a conscious choice, then it's effectively an authorized VPN connection between your network and the P2P service provider.
Ideally it should never be enabled by default, and uPnP port mapping should not be enabled out of the box. But I still think P2P is the better choice when compared to port forwarding from a security perspective.
I don't agree P2P is security by obscurity (non-default ports would be), but I do agree that there is risk and it needs to be planned for. It's not like port forwarding is insecure and P2P is the perfectly secure alternative.
I would always use VPN when possible, and it's usually possible - just not always preferable due to cost and/or inconvenience.
Josh, I read the first comments and can now see how some will not understand IP network without training and more training.
And you are so right on every comment.
P2P to me is pear 2 pear connection with a server and is just as secure as port forwarding or dynamic Name hosting.
And yes make sure every password is set on your VMS or NVR.
VPN connections for your customers app or PC is the best and most secure solution.
Or no remote access is the most secure! lol
So in my mind you have 3 types of setups options for every customer.
And you have to make it known to them that access to cameras is a risk, do they want it or not, and at what level of security do they want.
1. accessible
2. Private network accessible
3. No access
My thought is if they want in to hack your network a pass-code will not stop them.
Backup everything every day.
I can see where anything you or I say can be argued but I was board and wanted to post!
In no way is P2P more secure than a "half" attempt at securing an SSL/TLS browser based admin page. If you can, please explain what vendor's P2P implementation you are familiar with.
They don't do it the same.
NAT Traversal which facilitates the P2P connection is pretty much defined as "punching a whole through the firewall". There is even a method called TCP Punching.
I'm not sure I'm tracking here.
It seems like we are suggesting that port forwarding is bad. Is that the consensus, or it the thought that port forward only configurations are bad?
Everything required port forwarding, even VPNs. Can't access a VPN without configuring ports. Unless you set up a remote shell in the manner that P2P/UPnP does, then you HAVE to, right?
Nothing wrong with port forwarding at all. Outside of a VPN, followed by SSH (if available), a SSL connection to the admin page is the next best way to go. The only problem with this is that Security companies SUCK at software. The HTTPD software (likely Apache?) that runs the admin page is out of date before you install the device. The whole world operates this way. When you connect to google.com or what-have-you, you are access it via TCP, not P2P so I'm not sure where all the concerns come from and I'll explain a bit more in detail why I feel there is less of a concern regarding port forward only configuration.
The problem isn't port forwarding in the first place. The problem is again, security companies SUCK at software. If you need a GUI, we are stuck with Apache for now. With that said, we are susceptible to browser attacks. However, if we all had trust that these security vendors keep their hardware up to date then why would you consider it different than running any other web page? Accessing a web page over SSL is one of the best ways to go.
Because the admin page is accessible in a browser, does not mean it raises the attack surface. Just because "Kevin" can access https://ipadminpage.com in Chrome means relatively nothing considering you have to authenticate somehow. How else to you expect to authenticate? SSH? Telnet? In the browser it's over SSL, which we have trust in, right?
These are what I fear the real concerns are regarding using port forward only configurations:
1) Security companies SUCK at providing updates, essentially making us question the integrity of the front facing admin page.
2) Because these companies are not adding "noindex" or "robots.txt" files to their configuration, some pages get indexed by browsers and are dorkable, leading to a moderate risk of large scale enumeration. If IPVM want's to make a quick and effective impact on the security across the board, it could recommend to all the vendors to add these options so reputable search engines don't index them. That would easily be able to do this and I'm sure they'd all like to add a nice bullet point in their future release notes. It should be noted that enumeration is potentially much worse with P2P systems and in onw effort, could reveal all devices from all clients connecting to a companies P2P servers. Please read up on P2P vulnerabilities, I try to do my own research but you can read up on Krebs thought regarding P2P.
With all of this said, what do you guys recommend?
I have about 10 years direct experience administering government IT systems and I'm not sure exactly what we are advocating here, if anything. In government or commercial (when they have an actual IT department), VPN and port forwarding is likely the only "remote access" you get. There is likely a security policy in place to where they monitor all traffic coming in and out and they can't do that if you do shit like NAT Traversal via P2P. With that said, you may may face some tough questions from the IT Architect/Admin and if you can't answer them, they'll likely have you building your own network.
To be clear, all IP camera hardware is a threat to the integrity of IT systems. Every camera you put up is potentially a trojan horse. We all fear HikHua etc but you are installing devices that "Kevin" the neighbors kid can hack into and if they can't now, they can when an 0day becomes available as vendors suck at software.
For those wondering, no, P2P is infinity worse than any a port forwarding configuration. You are trusting third parties and hackers named "Kevin" to stay out of your system. The use of it lowers the expectation of integrity and it's use should elicit a warning to your clients.
Please consider speaking with Network Engineers about this stuff. They have a different take in this that is likely very valuable from the IT security standpoint.
Thanks John for moving this to its own topic. I think it merits further discussion. It would be nice to contact vendors about adding noindex and robots.txt to their config and request them to explain their P2P implementations a bit more in detail. (If you are still out there listening, lol)
Actually it's better then using port forwarding. Open ports directly to a DVR is a lot more risky IMO. P2P isn't perfect, but a lot better if you ask me. Sure, we may never know exactly what network route it takes, but the alternative is worse.
I don't want to come of as being obtuse, but can you explain DW Spectrum's P2P implementation? I researched it for a few hours the other day and as I expected, it doesn't explain how they implement P2P other than "NAT Traversal bypasses port forwarding to provide a direct peer-to-peer connection". That is all I need to know that I don't know anything about it.
P2P and UPnP are the worst things you can enable security-wise. Whoever manages the P2P network, essentially owns your system. I think we understand that and this is vexing my if I'm honest.
P2P is passing the buck to someone else (those running the services) and hoping that they will take the proper measures to ensure security. Have you ever asked those responsible for maintaining these P2P services about what data is being gathered, where it is being stored, what it is being used for, etc? I've asked one of the big 2 providers is they could provide us with data from P2P services for marketing purposes since it was being used as a free service and was offered a blank stare in response. Nobody wants to dig too deeply into how P2P works and whether or not it is being properly secured and maintained because it's just "so easy" to use.
Port forwarding is absolutely no perfect solution either, but it lets you have control to make it more secure with more effort. You can used HTTPS/SSL with proper certificates, you can use non-standard ports, you can use white/black listing for IP addresses, you can implement VPN solutions, you can set up security only DMZ networks, etc. P2P was another cheap solution to BYPASS security efforts to make it easier. The worst part is that you have no idea what is really happening with it. The only worse thing in my opinion was the abortion of UPnP.
Just my opinion.
Thank you for your input. I think you explain this much better than I. I fear this could turn ugly in regard to people misconceptions of P2P.
Do not use or solicit P2P as being "secure". Please.
While I agree with you on certain parts, how many of your DVR installations did you actually setup your recorder with a SSL Cert from a a trusted CA?
How many do you check on a regular base to see if the latest secure firmware is installed?
Sure you can implement a VPN, and that's do-able for small-medium sized businesses, but how many home consumers would actually do that when it brings extra costs?
DMZ on a consumer router doesn't work like an actual firewall DMZ either.
And of course a VPN is a better solution, nobody is going to argue about that, but port forwarding a recorder with most likely weak passwords and out dated firmware is a very big issue.
P2P isn't perfect, far from it. But it somewhat shields you from certain risks.
Take for example Wyze:
https://www.reddit.com/r/wyzecam/comments/7upxsn/why_wyze_chose_to_use_a_3rd_party_throughtek_to/
Second comment is from an actual Wyze Employee:
"We chose ThroughTek for multiple business reasons, but nothing related with the other service like Kalay surveillance. We used ThroughTek only for establishing P2P connection. All alert videos were directly transmitted between our cameras and AWS. ThroughTek knows nothing about our customer's alert videos, nor do they know anything about our user's information (like username and password). Hope that explains. Thanks!"
If implemented corretly there's a huge benefit to using P2P. P2P traffic is also encrypted most of the times. Sure, we can never be certain of backdoors, especially with Dahua and Hikvision, but at least P2P prevents a recorder from being visible for the entire internet.
Just my 2 cents
!
"We chose ThroughTek for multiple business reasons, but nothing related with the other service like Kalay surveillance. We used ThroughTek only for establishing P2P connection.
Clients trusting a security installer to trust Wyze to trust ThroughTek with their NAT Traversal. Sounds like a whole lot of trust going on.
It's not completely clear from the quoted paragraph (although it became clear in subsequent discussion and from other posts), but Wyzecam was trying to make the point that they do NOT trust ThroughTek. The client still does have to trust Wyze's cloud of course.
What Wyze gets from ThroughTek is simply a way for a client app to connect to a camera if it knows the uuid of the camera, just like any client can connect to a port-forwarded camera if it knows the ip address and port that the camera is available on. The contacted Wyzecam still requires authentication information, known only to Wyze (and not to Throughtek), before it will talk to the client - just as a port-forwarded camera might require a username and password to access the UI.
The fact that P2P NAT traversal was part of the communication path didn't inherently make the camera less secure than a port-forwarded camera. One might argue that it's a little bit more secure if Throughtek makes it harder to enumerate the uuid space than it is to enumerate IPs.
Unfortunately, there are a number of camera makes that use Throughtek or other similar P2P infrastructure and (unlike Wyzecam) have a default user name and password that the user may not have changed. Since these cameras establish a mechanism by which the outside world can contact the camera w/o the user's consent, they really do make the camera more insecure, to about the same extent the camera is insecure it automatically establishes a port forwarding for itself via uPnP.
Forgive me for not being able to directly cite the incident, but wasn't there a recent report of someone's P2P service being insecure in that all you had to do was change something in the string of the URL and you could connect to someone else's setup at will? If I recall correctly there were no login credentials needed if you logged into one unit and just changed the URL string.
The premise of this type of operation is nice for its ease of use, but again, you are at the mercy of whoever sets it up and runs it to do the right thing. But I guess as long as someone can just point at someone else and say "they told me it was secure" then it's okay.
Don't get me wrong, I completely agree with you. All I wanted to point out is that when P2P is setup correctly, it's IMHO a better alternative to port forwarding.
Take a look for example at Axis, they've given it a different name, but they as well provide a P2P service with their Companion line-up.
https://www.axis.com/technologies/axis-secure-remote-access
I'm not sure about the provider they are using, might as well be their own P2P like servers, but you probably get the point :-)
I'm afraid we're starting to think bad about P2P because of Dahua and Hikvision etc, P2P services are in fact used for a lot more than just security cameras.
It's not P2P itself which is unsecure, but the way it's implemented in most CCTV cases.
P2P is a widely used protocol, not just in surveillance. Its very interesting to debate what is more secure and what method should be used.
But speaking in a down to earth sort of way, if you want the easiest method to get your device connected for remote viewing, P2P is the way to go right now.
For device manufacturers, making things easy should be and normally is a top priority and P2P is a go to method for making things easier.
Port forwarding for years was the recommended way to get set up for remote viewing, but with it came a huge tech support pain point for both end users and dealers alike. P2P was a God Send for folks who werent comfortable configuring routers.
Its also suggested on here that a VPN connection is the best choice for remote viewing. This is great but not practical at all. Can you imagine end users and even some dealers trying to setup a VPN just to view their surveillance. You may be thinking "Sean, this is easy" . However, if you are saying that, it is obvious you have never worked in tech support with all sorts of different people.
So while debating this topic is fun and all, but with all things weighed, the fact of the matter remains that P2P is our best option and progresses us forward.
As far as security goes, I still feel like we are in the wild west of cyber security. Maybe we need a regulatory agency to hand out licenses for this type of connection with certain guidelines to be followed and occasionally checked upon. Much like the taxman, but for cyber security.
Sean,
When you enable P2P on a Dahua device, it first connects to an ATM machine in Florence Italy, before being routed over FTP to servers in Guangzhou. It then connects to a Garmin Express server to sync health data before being printed out in binary; hand carried to the P2P server by trained monkeys.
This is Dahua's implementation of P2P.
Can you prove me wrong?
P2P is not a protocol. It's an architecture or methodology to achieve a direct connection. There is no P2P.exe or "stack" that vendors share. Napster implemented P2P differently from emule, differently than DW Spectrum, differently than Dahua.
I hope no one is questioning what is more "secure". P2P is the PCP of the IP CCTV industry- feels too good to admit it's a bad idea. P2P is less secure, however it's too easy to use to consider configuring the network properly.
I hope it's obvious that that is in no way Dahua's implementation of P2P. :D
Sorry for using the incorrect term when I said Protocol. Nonetheless, its still the easiest way to setup cameras for remote viewing for the masses. And it is leaps and bounds easier than configuring port forwarding or VPN for the masses as well. Matter of fact, its a game changer.
Thats the point I was trying to make.
Yay or Nay?
I was wondering when a question like this would be asked.
Wasnt saying that at all but eventually we have to get to the point of taking a risk (if thats what you want to call it) to progress as an industry and take the manufacturers word for it that it is safe. Whether it is or not, I dont know, but when do we get past the point of contemplating if it is or isnt and actually use it. Fact is, P2P is much easier and way more convenient than any other method. Its good for society if you will.
Or you can go to the exact extreme opposite end of the spectrum and completely unplug your recorder from the internet completely.
I understand now where you're coming from, but this needs a note.
eventually we have to get to the point of taking a risk (if thats what you want to call it) to progress as an industry
Thing is, that can be dangerous.
A few years ago, I was a web developer. There were some large shifts in the web development community during that time. HTML5, CSS3, Responsive Web Design, node.js, etc. I was using Gulp.js for running build tasks before (and after) Gulp.js was cool. I remember browsing NPM and being in awe of every last thing that Sindre Sorhus did.
It seemed like node.js and NPM was going to conquer the world. Yeah, there were some naysayers, but everything was so incredibly easy. If you wanted antigravity, you could get it with a simple "npm install antigravity".
Then left-pad happened. And then event-stream happened.
As it turns out, yeah, those naysayers were probably right. All the micromodules and interrelated dependencies make it disgustingly easy to slip malware into a huge number of projects.
But with the massive growth, the amount of inertia is incredible. The whole NPM ecosystem is still there. A lot of companies depend on it. It will take time and budget (that most don't have) to switch. All they can feasibly do now is use auditing services ala Snyk as a band-aid.
And that's why I wouldn't be surprised if something much, much bigger than event-stream broke in the next year.
So, yes, easy things can drive progress, but sometimes it just gets everybody into an "evolutionary dead-end" faster. As you, say, it's a risk.
Pardon me while I go dig a deeper fallout shelter.
I do understand and respect your point Sean, but on the other side it gets very dark. You are wanting to trust manufacturers in an industry that have a terrible, terrible track record for network security. They seem to have no working knowledge of it (until it's brought to their attention in the press by a major incident) and then they duck and dodge and maybe come out with a patch at some point.
Our company has been burnt by one of the big two offering to set up a P2P server for us on AWS, that we paid for, and due to their not maintaining it and seemingly not knowing how it works we got charged massive bandwidth fees when it was used for a DDoS attack against a network in Hangzhou, China. At another time, a different manufacturer had their P2P service crash and had no back ups, so we had to try to appease very angry customers and tell them to go back and create their accounts all over again. Add these to the Mirai botnet, weekly hack reports and it just never stops.
I have to take any new "features" from these companies with a very hefty grain of salt and question their attempts at security at every turn because they don't seem to consider it as important at all. We are the ones that pay the price, they may get a little beat up in the press, but that's okay, they'll just have another 20% off sale and everyone will let it go once again.
It is quite easy to trust a manufacturer if they are lining your pockets with green. Honestly, if I was in Sean's shoes it is tempting. Just sayin.
When you enable P2P on a Dahua device, it first connects to an ATM machine in Florence Italy, before being routed over FTP to servers in Guangzhou. It then connects to a Garmin Express server to sync health data before being printed out in binary; hand carried to the P2P server by trained monkeys.
No, on a Dahua device this happens whether P2P is enabled or not.
Just wondering, could you set us up with the report where you read this about Dahua?
U1, will you support P2P if there is a IEEE spec?
Nope(IEEE, UL) just no. Adding a digital prosthetic certification to comfort the negligent is not an answer I could support. Installing an NVR on a customer's corporate network with no security, internet access and freeware is a *#*#ing joke. There are many that cannot afford the Rolls Royce VMS or IT services needed to implement security. They still have to at least understand the risks of the lower end systems what can be done to stay informed on securing their network inbound and outbound connections.
The way all this Hikua is going might as well use mDNS publicly and wake up every script kiddie on the block!
I support P2P now I suppose. I don't have anything against any piece of code. I'm just concerned that were getting a little carried away suggesting something that no one has put eyes on before.
If someone says P2P is "secure" or "securer than" or "sec*", I would have an expectation that the person knows the methods to facilitate P2P, or they are volunteering misinformation which is dangerous in this instance, I feel.
One vendor's method may be super-secure, the other may transmit credentials clear-text over UDP.
I support P2P now I suppose.
Ironically, I don’t support P2P anymore, U4 et al make some good points.
Lets just disagree to agree ;)
Best implementation:
Customer's WAN shall be in a separate VLAN from security network and on its own public IP.
Assign a different Public IP dedicated for access to the NVR/recorder, and pass through the firewall/router in its own VLAN.
Implement ACLs (policies) that allow authorized personnel access from the corporate network segment to bridge to the security VLAN. That takes care of internal access.
If remote access is required, provide a VPN connection (preferably IPSec, not PPTP) for only authorized users that allows access to the security VLAN. Log all connections (successful and failed) and check the logs regularly.
On all endpoints in the security VLAN make sure to change the default passwords (cameras, recorders, switches, etc.). admin, admin is insecure, right? Make sure the reset button is hidden and locked if possible.
For access to the servers always implement random and lengthy passwords. See here: https://www.random.org/passwords/?mode=advanced
Change passwords on a schedule the users can live with, just not never.
Keep firmware and software up-to-date on all devices on the network.
Even with P2P you still have a unique serial number for the device and a password (providing you change this from default) to provide a secure connection. The question is how secure is the server that these point too?
One other point that I don't see mentioned: what are the P2P service providers doing with the information they gather???
Today's world rotates around the obtaining/selling of information, even more so for that of personal information. When your customer signs up for this free service provided by the manufacturers "out of the goodness of their hearts" they are providing them with several bits of data, not the least of which is a valid contact address. Do you honestly believe that in some point that this will not be exploited in some fashion? If hikua decides to focus a huge campaign on America to sell directly, do you think they will hesitate for even a millisecond to start sending out mailers to every single person using this service? Do you think they will care that they bought product through ENS or Nelly's or will they just decide to cut them out and swoop in bombard the end user with direct sales material?
Using this manufacturer P2P service is giving them the opportunity and consent to contact every single one of your customers that uses it.
Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.
