Are these your home cameras you’re trying to secure to be able to access from work, or work cameras?
IP based security, … is not really considered security (by many people).
An inbound (reverse) https proxy + basic authentication is secure enough technically speaking. Basic auth with username/password in plain text is secure enough to pass any kind of us federal government audit, but for 1 or 2 people working it’s at least easy to set up. If you’ve ever setup a webserver - this is childs play. (so not that hard at all).
The question is, is your reolink setup proxyable in that way, ie. does it load any third party resources? You can check with ctrl+shift+j in chrome and reload while looking at the network tab, … or you could install umatrix chrome extension and see what it tells you.
Also, I don’t know how you authenticate to the nvr. Does it have a login screen that gives your browser a cookie? Or does your browser ask for user/pass (https reverse proxy can work with either, just needs a bit of setup for the specific case).
If this sounds feasible to you read on:
… first thing you need is a domain name from a provider you can reasonably trust (alternative, if you don’t trust the domain name is that you’d need client side certificates and that’s just a pain in the ass to install on all devices you use and maintain). For home / small office use e.g. www.duckdns.org is probably trust worthy enough, and in that case you only need server side certs and some basic auth.
… second thing you need, and speaking of server side - you need something like a raspberry pi, or a small VM if you already have some VM setup. or perhaps you can set this up in a container (if you don’t know how, don’t and do it on a raspberry pi to start with … duct tape it to the nvr). What you’d do would be to forward a port from your router to this Raspberry pi (or a vm on prem, or a cloud vm, or to a container or whatever). This port would run nginx, and would terminate the https session, and authenticate you, and forward requests to the less secure nvr. It’d have to have a static ip internally (for router to port forward to). On this raspberry pi, you can have 1 cron that updates your domain name so that it points to your public IP.
And another cron to refresh the cert from letsencrypt and reload nginx, such that it loads a new cert every time it refreshes it (I use acme.sh - other solutions I tried are more work, or used to be back when I tried them)
Your nginx setup would be really simple,
example that works easily with debian that keeps a separate config per domain:
/etc/nginx/sites-available/<DOMAIN>
server {
# this is for certificate renewal, and https redirect ...
# ... I run standard ports 80/443 and a separate subdomain for
# ... each of the services I proxy ...
# ... I'm not sure how acme webroot challenge would work from a
# ... non standard port. There's probably options for that too.
listen 80;
listen [::]:80; # ipv6
server_name <DOMAIN>; # <-- fill in ext domain
# directory that acme.sh uses to answer a challenge ...
# ... when renewing let's encrypt certs, -w flag of acme.sh
location /.well-known/acme-challenge/ {
allow all;
root /home/<USER>/.acme.sh/webroot/; # <-- fill in user
default_type "text/plain";
}
location / { return 301 https://$host$request_uri; }
}
server {
listen 443 ssl;
listen [::]:443;
server_name <DOMAIN>; # <-- fill in ext domain
ssl_certificate /home/<USER>/.acme.sh/<DOMAIN>/fullchain.cer; # <-- fill in user and domain
ssl_certificate_key /home/<USER>/.acme.sh/<DOMAIN>/<DOMAIN>.key; # <-- fill in user and domain
auth_basic "Restricted";
# format for file below, very easy, but password not encrypted.
# user:{PLAIN}password:comment
# user2:{PLAIN}password2:comment2
# ...
# it's possible to store passwords as salted hashes too,...
# ... but this requires a tool to compute and store and edit.
# ... many other non-file based auths or non-basic auths
# ... are also possible, but more complex to set up.
auth_basic_user_file /etc/nginx/htpasswd;
location / {
proxy_pass http://<ENDPOINT_IP_OR_HOST>:<PORT>; # <-- fill in the endpoint behind your firewall
}
}
Now that I look at it, it’s a bit fiddly, (it felt easier when I was setting it up, honestly). there’s the acme.sh certificate renewal tool, and there’s directory permissions, and machine wide nginx settings. Those aren’t hard either solvable. How you manage your passwords, for home/small office, that htpasswd file is good enough, but it’s definitely not best practice. (it’s still better than ip based security thanks to https).
Let me know if want more detail/help on these other aspects, … if this reverse https proxy situation sounds useful to you.
