Any other paranoid network savvy people out there?

Community Playground General Discussions
#1

I don’t know if there are many other network savvy people out there that are paranoid about security, but if so, I thought I would share the implementation I have decided on for allowing secure access to my Vera from the internet without using Mios servers.

Objective: Securely access the Vera web interface remotely without having to use VPN all of the time, without changing the Vera

Methodology: Setup a server in the web DMZ to proxy the Vera web interface to remote users, after authenticating them

Topology: Vera is in the automation network segment and the Web proxy server is in the web DMZ. My desktops and laptops are on a primary Windows domain network

Firewall rules: Vera can only communicate outbound with specific third parties (for example, wunderground.com) as allowed via content filter on unified threat management gateway. Web server (reverse proxy) cannot initiate connections with anything except to the web interface on the Vera

Additional layers of security to be added (will not be opening it up to internet until these are implemented… I’ll update this post as I do): 1)Publicly signed SSL certificate on web server for connections from internet to encrypt traffic. 2)Client certificate based authentication rather than just password.

Traffic flow: 1)Remote user goes to URL of web server /cmh and is prompted for password (later, user certificate) 2)Web server proxies the web interface of the Vera through itself to the end user (if valid credentials are provided) 3)User interacts with Vera normally

Benefits (with future security additions): 1)Vera unchanged from inside 2)1.5 Factor authentication (client certificate, password… I don’t really care for Client certificates vs smart card or token… hence the 1.5) 3) Vera is never directly exposed to the internet 4)SSL encrypted external communications

Implementation: NginX on Ubuntu server configured as a reverse proxy for the following directories: /cmh/, /cgi-bin/, /port_3480/

Diagram attached

Purpose of this post: 1)Peer review, 2)share information

#2

This solution provides excellent security. Thanks for sharing.

However, implementing this solution and, more importantly, implementing it properly, will require far more network engineering/administration skill than most people I’ve seen on this board could ever have.

Besides complexity, this solution has a couple of other drawbacks, negating specific features that drew me to Vera in the first place. It requires a separate dedicated computer and it eliminates the use of the available smartphone apps.

If I were already running a proxy server for something else, this would be a great/no-brainer solution.

Edit: In fairness, the title does say “network savvy” people.

#3

Good solution. Got it working already like this or is it just a plan?
I wonder how you would give MC access for support.

#4

[quote=“SanderL, post:3, topic:177847”]Good solution. Got it working already like this or is it just a plan?
I wonder how you would give MC access for support.[/quote]
You would (temporarily) open the outbound SSH port from Vera to MCV so that Vera could establish the reverse tunnel that MCV uses for support.

And no offense, but the fact that you don’t know this puts you at high risk of an incorrect and insecure implementation. I suspect that most who try this, not fully knowing what they are doing, will expose the DMZ and the Ubuntu server will be compromised in due course.

#5

Once you get this set up, looks like a good use of a Raspberry Pi. Low power/cost and plenty of CPU for the proxy as well as additional security functions.

#6

Good idea. A Raspberry Pi would indeed be a good choice for this. You’d still have a separate box and the management that goes along with that, but the Pi would reduce the physical space required and the electricity consumption.

#7

[quote=“Z-Waver, post:2, topic:177847”]However, implementing this solution and, more importantly, implementing it properly, will require far more network engineering/administration skill than most people I’ve seen on this board could ever have.

Edit: In fairness, the title does say “network savvy” people.[/quote]
Yes, this isn’t for the basic user, I posted this with the hope that there were some other people here with a networking/security background. I’m a network security engineer by trade (one that loves to tinker with automation/etc…) I would also like to echo your sentiment that if one were to undertake this, they would need to really understand what is going on in this design.

This certainly increases the complexity and does not facilitate the usage of smartphone apps (something I’m still trying to work with). I would rather not have non-VPN access to the Vera via a Smartphone app than use a third-party service or doing something that wasn’t secure.

I have it working with a password (no user certificate yet) and in plain http (not SSL encrypted). I’m hoping to have those things added this weekend. All UI functions are working through the proxy though. I’ll post my NginX configurations once it is done.

Once you get this set up, looks like a good use of a Raspberry Pi. Low power/cost and plenty of CPU for the proxy as well as additional security functions.
Excellent suggestion! I already have virtualization infrastructure in place, so throwing up a Ubuntu box wasn't too big of a deal. I understand this is, by far, not a normal setup for an environment where a Vera would be used.
Good idea. A Raspberry Pi would indeed be a good choice for this. You'd still have a separate box and the management that goes along with that, but the Pi would reduce the physical space required and the electricity consumption.
Yes. I'm still trying to find a balance between security/manageability/usability/etc... I just lean (very) heavy on the security side. I understand this is most likely complete over-kill for a Vera in a home, but networking and security are a hobby of mine.
#8

In a lot of respects you have re-implemented the remote web access system that Micasaverde provides at cpui5.mios.com. It’s secure enough. I’d use it.

For remote app access you will have to do something else, perhaps reimplementing the scary password-in-URL system that MCV invented. But there’s nothing stopping you from having this in addition to your existing secure web interface.

Edit: Vera is a good exercise in learning how to secure a basically insecure system. I’ve learnt lots of networking best practices by trying to close the deliberate open design of Vera. I definitely recommend it to any network engineer.

#9

On my side I also have cut internet access from my vera to MCV (except while updating/installing stuff). I’m not willing to give outsiders access/backdoor to my home either :wink:

Still need to move it in its own vlan though.

However I’m simply relying on my own VPN to access my home/vera when on the go, seems a good, generic, reliable solution to me… And integrates well with my smartphone/tablet.
What was the reason for you not to chose a VPN solution?

#10

[quote=“futzle, post:8, topic:177847”]In a lot of respects you have re-implemented the remote web access system that Micasaverde provides at cpui5.mios.com. It’s secure enough. I’d use it.

Edit: Vera is a good exercise in learning how to secure a basically insecure system. I’ve learnt lots of networking best practices by trying to close the deliberate open design of Vera. I definitely recommend it to any network engineer.[/quote]
It basically provides the same functionality, but without having to provide any access to someone other than users I explicitly authorize. “Secure enough” is always up for debate though. The term has to be defined based on the willingness to accept risk and the relative expense of the mitigation (along with any impacts to usability, maintenance, etc…). For a home system, cpui5.mios.com is, most likely, plenty secure. For me though, the “expense” of the mitigation was minimal due to the infrastructure that was already in place (and actually a great learning experience, as you said!).

[quote=“cedricm, post:9, topic:177847”]On my side I also have cut internet access from my vera to MCV (except while updating/installing stuff). I’m not willing to give outsiders access/backdoor to my home either :wink:

Still need to move it in its own vlan though.

However I’m simply relying on my own VPN to access my home/vera when on the go, seems a good, generic, reliable solution to me… And integrates well with my smartphone/tablet.
What was the reason for you not to chose a VPN solution?[/quote]

It is great to see that I’m not the only one unwilling to open up the Vera to the entire internet!

I agree with VPN being the current best way to go for access to the Vera with apps. I have that setup for my phone already and use it regularly. The main purpose of this was providing a way to access the UI from other computers without having to use VPN. For example, I cannot install the Cisco VPN client on a work computer, but I can certainly provide a client certificate and access the Vera’s web interface through this solution (using a computer not owned by me is not a perfect solution, but risk equation for me yielded that it was ‘secure enough’ in this situation). So, this is a very specific solution to a very specific need. I’m certainly not advocating this as a way to avoid VPN altogether.

This also allows me to expose the ability to expose the URL-based command strings so that the custom built jQuery based web app I built can work remotely without needing to VPN.

As promised, here is the NginX configuration that worked for me:

server {
        listen 443 ssl;
        ssl_certificate /etc/nginx/ssl/public.crt;
        ssl_certificate_key /etc/nginx/ssl/private.rsa;
        root /var/www/veraweb/webroot/;
        server_name [Outside FQDN];

        location /cmh/ {
                auth_basic "Restricted";
                auth_basic_user_file /var/www/veraweb/.htpasswd;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $host;
                proxy_set_header X-NginX-Proxy true;
                proxy_pass http://[vera ip]:80/cmh/;
                proxy_redirect off;
        }

        location /cgi-bin/ {
                auth_basic "Restricted";
                auth_basic_user_file /var/www/veraweb/.htpasswd;
		proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $host;
                proxy_set_header X-NginX-Proxy true;
                proxy_pass http://[vera ip]:80/cgi-bin/;
                proxy_redirect off;

        }

        location /port_3480/ {
                auth_basic "Restricted";
                auth_basic_user_file /var/www/veraweb/.htpasswd;
		proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $host;
                proxy_set_header X-NginX-Proxy true;
                proxy_pass http://[vera ip]:80/port_3480/;
                proxy_redirect off;
        }     
}
#11

Since we’re being paranoid doesn’t the NSA have backdoors for all public cert providers? Maybe better off building a cert server too and issuing your own…

#12

They probably have back doors to the algorithms!
And if not … they have enough compute power to break down any certificate.