Port Forwarding is Perfectly Safe... Wait, What...

Several people TRY to drive home points on this forum about securing your network... These arn't people just sitting around wearing tin hats folks...

A friend called me last week because he was having issues with his NVR locking him out a few times a week due to incorrect login attempts but said he was the only one using it and his password was stored in his app on his phone.

At any rate I stopped over yesterday and below is what I found. Around once a week for an hour a day (normally late hours/early hours) his NVR was being pounded for 10 - 20 min with brute force attacks on the admin account as well as other possible user names. The most common IP's were from Russia, China, and the UK.

At any rate folks - PLEASE understand it's your responsibility to secure your network, secure your video feeds, and most of all if you set things up for other people (especially if they pay you...) make sure you are not doing them a disservice by allowing others into their lives unknowingly...

/END PSA

If direct access is possible (no VPN, direct port translation) strong password is the only way to secure access so brute force will be no harm and all system with public internet access are regularly attacked so this is a "standard" behavior I get thousands of attempts per day on all public accessible servers so in that case if the system have no security weakness it is no problem appart from banning the true admin when system is under brute force attck.

But for the best those rules should be applied :

- the system must have no hidden login/password access that may be known and "hard coded" that may be known/tried by the attacker
- the system should have no backdoor... hum...
- the system should implement auto-ban on failed attempts (for example 30 seconds ban after 3 failed login attempts)
- the system should force password to be strong (8 chars minimum for regular users, 10 chars for admin, and all with with Caps+Number+Special)
- if system is well known try to change the default login names if possible (for example if there is a default "admin" account change it to something else if possible)
- the system should have IP filtering especially for high privileges accounts
- the system should implement strong authentication at least for high privileges accounts
- the system should expire passwords every 90 days
- the system should trace all login whenever it is success or fail with originating IP and Timestamp
- the admin of the system should make an account review/extract and remove any useless/expired account
- the system should never expose the reason of the failed login attemps (for example never says login failed because password was wrong but display a more generic message (login or password is wrong)
- the system should never expose it's version number
- the system should never expose precise error message (precise message will be logged only internaly) and expose only a generic error message like "an error occured" with some unic ID that will help to retrieve internal log messages attached to this error
- the system should have no weakness is the code but of course this is teh most difficult thing to find/detect
- the system should be updatable and be able to get security patches and the constructor should provide them regularly

Any system containing personnal and or sensitive data should implement/follow those features but many do not (more or less) and this partly the responsibility of the constructor.

Of course VPN is always better but this is only possible for system that are accessed by a known user's list to which you can send certificates and/or OTP.

If your using OpenVPN client software on your BI machine, don't you still need to port forward? It's only when the vpn is at the router level that port forwarding is no longer need ?

Anyway I have a dedicated network for my cameras and BI machine also I only let certain ip adderss connect, which I was told is worthless. Cuz anyone could fake a ip

@Dodutils, you just described a unicorn..

Sadly his admin password was also only 5 digits - I'm amazed none of the brute force attacks cracked it. Obviously that's since been updated as well.

I just looked at him and said "wtf were you thinking"... his response - "it was just plug and play and all I did was follow the directions, how was I supposed to know?"...

I also since directed him to this forum for some much needed "continuing education"

zero-degrees said:

I just looked at him and said "wtf were you thinking"... his response - "it was just plug and play and all I did was follow the directions, how was I supposed to know?"...

Click to expand...

Yep customers are responsible (partly) but this is exactly an example of the resposibility of the constructor allowing users to enter low secured password and as as he said "how do I know ?", users have low security skills, they must be educated for sure but until then they must be guided and constructor must have safety gates on any action/button/text filed that is involved in security/privacy.

Dodutils said:

But for the best those rules should be applied :

Click to expand...

And despite this commendably large list, the practical reality is that none of it protects you against any exploits of system vulnerabilities that are discovered.
Or the ability of the bad actors to simply examine the published firmware and see how to gain privileged access independent of any user IDs / passwords.
The bottom line is that simply opening up your NVR or camera to the internet is taking a risk.
You can balance that risk against the convenience of doing so versus the value of the data that would be exposed on a compromise.
Or - you can make use of good technology that has been developed to mitigate that risk, and as @nayr has so often advised and documented, set up a VPN 'Virtual Private Network'.

exposing anything to the internet is just ignorant, even your router.. which was designed to be the guardian of your network.. likely has a poor security record.

just go to google and search: YourRouter (Netgear/Asus/Linksys/Motorolla/Dlink/etc) Security Vulnerabilities and see what comes up... If the leading networking professionals cant design a secure system thats been built from the ground up to be internet exposed, no camera manufacturer has a snowball's chance in hell of coming close.

alastairstevenson said:

And despite this commendably large list, the practical reality is that none of it protects you against any exploits of system vulnerabilities that are discovered.
Or the ability of the bad actors to simply examine the published firmware and see how to gain privileged access independent of any user IDs / passwords.
The bottom line is that simply opening up your NVR or camera to the internet is taking a risk.
You can balance that risk against the convenience of doing so versus the value of the data that would be exposed on a compromise.
Or - you can make use of good technology that has been developed to mitigate that risk, and as @nayr has so often advised and documented, set up a VPN 'Virtual Private Network'.

Click to expand...

This is exactly what I said...."the system should have no weakness in the code but of course this is the most difficult thing to find/detect" and "Of course VPN is always better"... but even VPN can have weakness.

The access attempts from remote IPs 10.0.5.78 and 10.211.55.8 are interesting as that's a private IP address range not a public one. I wonder if there's a bug that lets them spoof how the IP shows in the log or if something on the ISPs network has been hacked. I suppose the ISP could also be running automated tests to identify and block vulnerable devices/customers.

Something like widely used VPN software that's passed rigorous security audits and has public source code is going to be a lot more secure than your average ip cam. Too often security is 'bolted on' rather than part of the design from the start. Many PLCs for example are awful in this regard.

tangent said:

The access attempts from remote IPs 10.0.5.78 and 10.211.55.8 are interesting as that's a private IP address range not a public one.

Click to expand...

May be it is the private range used by all other customer that use the same ISP access type and so they can try to hack any customer in the private range if the ISP do not isolate them. I remember a few years ago (Windows XP time) when I worked for an ISP that we had to forbid 135 to 139 ports between each connected customer inside the private MPLS range to avoid I don't remember which trojan that infected a customer to attack other customers.

tangent said:

The access attempts from remote IPs 10.0.5.78 and 10.211.55.8 are interesting as that's a private IP address range not a public one.

Click to expand...

In this case it would be a spoof. His internal network is a 192 routing table via standard router.

zero-degrees said:

In this case it would be a spoof. His internal network is a 192 routing table via standard router.

Click to expand...

Not if the router connect itself to some MPLS that use antoher private range and spoofing TCP is not as easy as spoofing UDP.

zero-degrees said:

In this case it would be a spoof. His internal network is a 192 routing table via standard router.

Click to expand...

could also be a symptom of a hacked router

Dodutils said:

Not if the router connect itself to some MPLS that use antoher private range and spoofing TCP is not as easy as spoofing UDP.

Click to expand...

Generally then you wouldn't be able to port forward in the first place unless they allow UPnP. But if could be something like the cable modem has 2 ip addresses one public an the other for config and misconfiguration is allowing routers with rip v2 enabled to allow this type of thing.

tangent said:

Generally then you wouldn't be able to port forward in the first place unless they allow UPnP. But if could be something like the cable modem has 2 ip addresses one public an the other for config and misconfiguration is allowing routers with rip v2 enabled to allow this type of thing.

Click to expand...

This is an interesting situation, I would recommand @zero-degrees friend to ask its provider how it is possible that private IP range 10.x.x.x can reach its router in TCP mode and ask if this range is something they use/know.

Folks can just get an inexpensive NAS like a Synology or QNAP and OpenVPN into it. NAS have measures to protect against these sorts of attacks.

rnatalli said:

Folks can just get an inexpensive NAS like a Synology or QNAP and OpenVPN into it. NAS have measures to protect against these sorts of attacks.

Click to expand...

Bying a NAS just to run OpenVPN to view remote cameras ? if you have no Linux machine you can use a RasPi or run a small Linux VM under Windows.

is this router good enough for ip cameras and nvr ? thomson tg782i

tangent said:

The access attempts from remote IPs 10.0.5.78 and 10.211.55.8 are interesting as that's a private IP address range not a public one. I wonder if there's a bug that lets them spoof how the IP shows in the log or if something on the ISPs network has been hacked. I suppose the ISP could also be running automated tests to identify and block vulnerable devices/customers.

Click to expand...

This is actually known behaviour in Hikvision units (by "known" I mean I have seen it happen years ago; I do not know if it is by design, or why it works that way).

I used to have "admin" accounts locked to a network IP (192.168.1.x) which is the one I used for my own computer on both at work and at home. So our units at work could only be acceses with the admin account from my own computer at work. For some reason I do not remember once I tried to connect from home, and well, it worked when it should have not worked! I checked at the logs, and found out that the unit was seeing me on the logs with my home network private IP instead of with my public IP, so it was leting me in.