We have 2 Uniview IPC262ER9 cameras and we changed the HTTP, and RTSP ports so they are different
When I use Internet Explorer I can log into one camera using port 80 and get to LPR 1. When I try to get to port 120 LPR2, it takes me back to LPR 1
I know both cameras are up since I can see them in the Smart PSS. I also can see the port #'s in Smart PSS, so I know these are right. The client opened the ports on their router. is it possible they opened all the ports to the same IP?
is it possible they opened all the ports to the same IP?
Yes, highly likely. Or, they setup a DMZ to the first IP, which forwards all incoming requests without an explicit rule to that IP address.
Either way, this sounds like a router config problem.
I agree with Brian. I would speculate that they do not have their router/firewall rules set correctly.
Some routers you have to specifically enable a rule after creating it.
It is recommended to use ports higher than 8000. Low ports, such as 120 are not always supported in some browsers.
Make sure they did port forwarding (80 > 80, 8000 > 8000), and not port mapping. The external port should point to the same port on the internet network side, for ease of understanding.
It definitely sounds like a router config issue. Also, some cameras use RTSP port for streaming, which is usually 554, but you may need to specify a different port in the camera.
Technically ALL ports up to 1024 are supposed to be reserved for approved services (22 for SSH, 23 for FTP, 445 for RTSP, etc.) so any self-defined services using non-standard ports should be above 1024.
So when we do multiple NVRs, we may do 88,89,90 for HTTP.
For the Uniview cameras we do forward HTTP and RTSP since the live view comes over RSTP. We may do 88,89,90, 554,555,556.
Are you saying when we change these port #'s on the camera/NVR we should just change everything to be above 1024? I figured since there was nothing else on the network, it really didn't matter which ports we used.
these do use RTSP, and we changed the RTSP and HTTP for each camera.
We use DynDNS
when we do http://client.com:88 IE changes it to client.com and I get the right camera
If we use http://client.com:120 the address stays that way and we get the wrong camera
Waiting on the engineer to email back if the ports are configured properly
Just for reference: List of TCP and UDP port numbers
you opened up a camera to the outside world. Have a good time with that. Tell us what it's like when you find out you show up in Shodan.
Not everyone wants to pay for VPNs, or server based systems where we can run team viewer.
We need to adjust the camera at night so we can see the effects on tags etc in real time, and not have to roll a truck. How do you propose we do that when the client does not want to set up a VPN or pay for a workstation?
It is my understanding that as long as you have an individual port set to each IP of your camera(s) and the camera password(s) are secure(changed from default), then there really shouldn't be a problem with using port-forwarding. It would seem that the issue is not with port-forwarding itself but rather the security of the device that is targeted.
Just in doing a quick search, I came up with this:
https://portforward.com/is-portforward-safe/
Greg -
The issue with port forwarding is that it opens a device up to a direct connection from random/unknown outside entities. Take the Hikvision Backdoor Exploit for example, the vulnerability there was so severe because it circumvented admin passwords/password strength and allowed anyone who could connect to the camera to take full control of it.
It would seem that the issue is not with port-forwarding itself but rather the security of the device that is targeted.
This is correct, if you keep in mind that overall device security is both a factor of how the device is setup and put online, and a factor of vulnerabilities and weaknesses hard-coded by the manufacturer. Sometimes, as Hikvision and others, have demonstrated, a certain amount of diligence on the part of the user/installer can be easily undone by system vulnerabilities.
A VPN on the other hand, by nature, drastically limits the ability for random people to connect to the device, limiting you to internal threats instead of external threats. A weak device on a VPN is still undesirable, but it is at least a massive leap forward from a weak device on a public connection.
I would check UPnP Settings to make sure the second camera is not just auto configuring to any open ports it seen on the router.
Why couldn't you just use the Uniview EZCloud service? It's free.
Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.
