portforwarding risks

[Patrick Browne]

Hi,

Just wanted to ask, I have set up port forwarding to view my camera set up, requests come in to IP:8087 and get forwarded to my local machines server internal ip:8765 (running in docker).

I the basics, but is there anything I should be worried about with having this set up ? That internal IP with motion on docker has private information etc and network access to local files.

Just worried I know enough to cause issues, the bad part of dunning kruger.

[Dewey]

I am a far ways from an expert, so this is worth exactly what you are paying for it.  Now with that said ... a lot of people will tell you that port forwarding is dangerous and it should be avoided at all costs and to use a VPN instead.  I have used port forwarding for YEARS, and say that it's only real danger is the security of the destination where the port is forwarded.  In the case of MotionEye/MotionEyeOS, can an intruder get forwarded to your ME/MEOS box and break it to the point where they get to the command line and possibly do more danger?  The only real thing that I am aware of that is exposed from a ME/MEOS command line is the user password, which is stored in plain text.  So if your ME/MEOS user password is used in other places on your home network, yea, you may have a problem.  The admin password is stored in a hashed format, so it would take grabbing the admin password and cracking the hash before anyone gets that, even so, you can keep that unique to your ME/MEOS as well.  That is doable IF the intruded can get to the ME/MEOS command line, but does add layer of cracking the hash complication.  The only other potential problem that I am aware of is if the intruder is able to actually log into your ME/MEOS system, in which case, they will see what your cameras see.  So with all that said, yea, there's a danger, but personally, I think it's blown up worse than it really is.  SOMEONE PLEASE CORRECT ME IF MY THINKING IS FLAWED.

My extra layer of security is that I run Netgear routers and I have them email me logs daily at midnight every night.  I habitually look at those logs, which takes less than five minutes, and see port scans where people are out on the 'net looking for an easy target, but I have yet to have it go anything further than that.

Dewey

[StarbaseSSD]

I am not an 'expert' and cannot tell you what specifically in the Python2.7 codebase is able to be compromised, especially in the past 2 years plus. I portforward, but I do not leave it up 24/7, only as long as I need it up. I have it isolated to a one way vlan (anything from the home vlan and the port forward can get in, but motionEye or motionEyeOS cannot initiate any traffic to the internet or to the home network. A couple of the cameras can, because they are cloud based. It would take your average hacker a while to figure it out, I hope, and there's a couple of honeypots to trigger, too. If you can, check how hard your internet IP address is being scanned, run tools like GRC.com's port scanner, and see what they show. Safety is YOUR number one concern, and no one else can tell you what is "acceptable" risk.

@dewey, you got it pretty much on target...

[Dave Bukowski]

I don't do much reverse engineering, or development, but operationally in security I have a few things here that are of context.  I manage the firewall and other security devices at a college, so have a bit of insight into this and also do incident response as well.

1)  If there is a compromise of the code, for example RCE (remote code execution) it would be at the same permissions as the process owner.  If you are running as root, it will be run as the root user (which is very bad).  This is why many programs ask to run as a non-privileged account and only gain root access to initiate the port being opened, but run everything else as the NPA.  You are as vulnerable as the code and the libraries within the code.  Remember all the panics across the Internet because of OpenSSL being exploited?  It is because a lot of code uses OpenSSL libraries and were either compiled in the code or had the library as a shared/dynamically linked library.  So the library had to be updated, and if it was compiled within the actual program statically, then that code within was likely vulnerable.  So a lot here comes down to Python and the vulnerabilities within Python and any libraries involved.  Then the code.  Is there overflows from inputs.  Maybe areas you are not expecting inputs but some function does accept input that can be exploited.  So port forwarding is dangerous, but less dangerous if you maintain your code and make sure to test both your environment.  Firewalls in enterprise environments are essentially port forwarding.  Usually though it is a 1:1 NAT/port-forward where one external IP maps to one internal IP.  This is different than your typical home router which you are many to one for out and then forward only certain ports to multiple devices based on the port requested for inbound.

So some things you can do to help protect your internal network.

First if you can set up a VPN (OpenVPN is a great solution for this and readily available on many devices including pfSense firewalls).  You can also set up OpenVPN on a pi and then port forward the OVPN port to that device.  

You can also use "port knocking".  If your firewall/router supports it, take advantage of it.  It is more secure than just an open port forward.  Google that term if you don't know what it is.  Top level, it is basically a port or couple of ports you need to "knock" before you can access the intended port.  Think of Hagrid opening up the wall to Diagon Alley from the access in the Leaky Cauldron.  Only the correct combination opens the port for you to access.

Then the next level you can choose is set up a proxy web server.  Depending on your use case, if you just want to observe cameras but not interact, set up to the proxy to connect to the streaming video/photo link, but not the admin interface.  This is much more secure.  You can also set up the proxy server to allow certain IP addresses and or use a port knock for this as well, AND also set up some sort of authentication (basic web auth is better than no auth).  Remember encryption does not encrypt "Basic web auth".  You can have something like Apache or NGINX run as the front-end proxy server with authentication and encryption.  A lot of APIs use a proxy of some sort to protect the API from attacks.  This offloads things like encryption to the API.

Then there is the port forward to the device directly.  Remember unless the page itself is using encryption, username/password are in plain text.  If you log in with admin, your admin password floats through the ether and even wireless unencrypted. WPA2 Personal was compromised years ago, so your wireless network at home nearby users can figure out the PSK to access your network and sniff your traffic then including your admin password.  So if possible use encryption wherever you can.  Make sure the site is also encrypted.  One of my biggest pet peeves is these "VPN" commercials that claim it protects you from hackers.  Not really.  If the site is being monitored the traffic from the VPN gateway to the site is still unencrypted if the site is not configured correctly.  Just your traffic from your device to the VPN gateway is encrypted.  So sort of false advertising on their part by excluding some details as to how the VPN works.  I have a personal VPN not for protection, but to test my home and work network for access from a "remote" location.  When you have multiple ISPs at work, you need to test traffic flow from multiple paths to make sure things are working right.

But anyways, checking logs nightly really isn't good enough.  If you can have a log parser in to look for discrepancies.  Could be in python, perl, C, C++, etc.  Especially pay attention to port scans.  Also check out Shodan and see what services are showing for your IP.  It may have scanned you before and then hackers can check shodan instead of actively going against your device(s) until they are familiar with the target.  

This is not a complete answer, but just some things to keep on the back of your head when thinking about opening up ports to the Internet.  Main thing is keeping everything exposed (as in the services/daemons running on those ports) as updated as possible.  

-Dave