Securing Loxone

[sk]

I am currently getting my house wired for loxone and my partner has given me the mini server in advance to try and setup some of the config.

One thing I am not happy about is the external access of the app. I don't like not using SSL to connect back to my home network and I also really dislike the idea of exposing my mini server to the outside world.  Imagine if somebody decided to run  denial of service attack using pings - The low compute power of the mini server could be quickly overwhelmed and then it not be able process data/events from the sensors and switches. 

So I am working on the following:

--- https connection from Loxone App. ----

------Home Network Router Firewall--------

Apache Reverse proxy for web and sockets and SSL (on a raspberry pi)

Miniserver (internal IP)

Under this setup any denial of service attack or unwanted traffic would hit the pi but not the miniserver. 

So...

Step 1. Setup the Pi with Apache (loads of guides out there)

Step 2. Get reverse proxy working without SSL

Assumptions - you have setup apache default to run on port 80. Feel free to tweak as necessary.

Enable mod_wsproxy_tunnel on apache.

Apache config:

<VirtualHost *:80>
        ProxyRequests Off
        ProxyPreserveHost On
        ProxyVia On

        #192.168.1.xx is the address of my miniserver

        ProxyPass /ws ws://192.168.1.xx:80/ws
        ProxyPassReverse /ws ws://192.168.1.xx:80/ws

        ProxyPass / http://192.168.1.xx:80/
        ProxyPassReverse / http://192.168.1.xx:80/

        CustomLog /var/log/apache2/access_reverser.log Combined
        ErrorLog /var/log/apache2/error_reverser.log

</VirtualHost>

It is vital that the ws rule is before the http rule for apache to work correctly. If you place the ws rules after then you will see the mini server login page but it will just say poor connection because the socket connection is routed incorrectly.

Also note that sub directories don't work with the loxone app. It assumes you are hitting the server directly.

Step 3: Test it internally first

Hit the ip address of your raspberry pi on port 80. Hopefully you should see the loxone mini server page, can login and do stuff.

Step 4: Register for a dynamic DNS URL

Step 5: Register a certificate on your ip.

Step 7: Configure the external URL to use SSL in apache config

<Working on the detail of this step - will update once it is working>

Step 8: Test locally with SSL

Step 9: Enable a NAT rule on your firewall to point say port 6633 at your Pi IP and apache port

Step 10: Test on your mobile without wifi enabled!

-- Then you are done!

You can add more rules for the Pi to redirect traffic to cameras, network devices and loxone intercom.

Hope it helps and I will update as soon as SSL is running but for now putting the Pi in between is one step closer to a more protected home!

[smartbusinesstools.be]

Hi sk,

I don't understand how you would get the Loxone App to use SSL to communicate to the SSL proxy. Would that work by just entering the https URL as External Address in the config?

I use an SSL VPN which is provided by my router. That's the only type of VPN that works over (almost) any public and private network. 

The only problem is that I can not set it to  'Aways on' VPN on Android as it uses a non-native client (app), so I need to press a button to re-active the connection after having switched networks.

Maybe Tasker can do this for me, but I would want to keep it simple.

Would your solution allow to keep the app's connection open when switching networks, e.g from a wifi hotspot to 4G?

Filip

[sk]

Hi Filip, I am not 100% sure about the SSL compatibility in the app yet. I am aiming to explore this more at the weekend. 

The problem with VPN is:

1. that its not very user friendly on iOS.. settings -> connect to vpn -> wait for connection -> then open app

2. sustaining a connection on mobile isn't easy and as yet iOS doesn't reconnect.

3. if Loxone decided to make something more of the app by using background services etc then the app could periodically connect to the mini server for updates/alerts. If VPN is disabled this wouldn't work.

4. Depending on the VPN connection implementation they may involve poor implementations that could leave your network less secure.

Ideally, if SSL coupled with a reverse proxy works then you only need one port open for cameras, loxone, intercom etc and yes it would enable a permanent connection when shifting networks.

[smartbusinesstools.be]

On Thursday, September 10, 2015 at 10:53:49 PM UTC+2, sk wrote:

Hi Filip, I am not 100% sure about the SSL compatibility in the app yet. I am aiming to explore this more at the weekend. 

That's an important question. Let us know if that works. An indication that it might work is that an SSL connection to an IP camera from the Door Controller does work, which I tested.

 

The problem with VPN is:

1. that its not very user friendly on iOS.. settings -> connect to vpn -> wait for connection -> then open app

2. sustaining a connection on mobile isn't easy and as yet iOS doesn't reconnect.

3. if Loxone decided to make something more of the app by using background services etc then the app could periodically connect to the mini server for updates/alerts. If VPN is disabled this wouldn't work.

You need an 'always-on' VPN. Maybe there is an app that manages this. I asked the developer of my router to add this feature to their app, or at least control the app via Tasker (which only exist on Android).

 

4. Depending on the VPN connection implementation they may involve poor implementations that could leave your network less secure.

It should have a level of quality so you can trust it. The advantage of having the SSL VPN server in the router, is that the router's firewall can restrict the connections from the VPN.

 

Ideally, if SSL coupled with a reverse proxy works then you only need one port open for cameras, loxone, intercom etc and yes it would enable a permanent connection when shifting networks.

That would be ideal if that works for everyhting without too complex configuration per case. Let us know how it goes.

[sk]

So - I nearly made it - All works fine on http but SSL is another story.

I established an SSL connection which gets me to the miniserver and begins loading the script pages. However, annoyingly there is something inside the javascript of the loxone miniserver website app that has a hardcoded connection to http for the api calls (/jdev/cfg..). error is below:

 XMLHttpRequest cannot load http://192.168.1.xx/jdev/cfg/api?_=xxxxxxxxxx. Origin https://192.168.1.xx is not allowed by Access-Control-Allow-Origin.

vendor.js:6:4638

Looks like the javascript has been minified and I cannot easily identify where it is happening but my best guess is that when the xmlhttprequest object is made something is telling it to use http. If http was left off the url the browser would make its own determination and stick to https and therefore not cause a CORS error in the browser and keep the payload encrypted.

Option 1: There maybe some more apache magic that could be done to redirect the http request back to https/some other header tricks with CORS.

Option 2: Raise with Loxone and pray that they might fix it. 

for now I am stuck for time to experiment.

[sk]

I have found the line of javascript in the web app and submitted a ticket with Loxone. I am hoping that they won't reject it as it will help everyone secure their miniservers behind SSL.

[sk]

Loon are discussing my fix. Hope to hear more soon, if they accept it I would imagine it wouldn't make it until the next mini server update.

[Beat]

Am Montag, 14. September 2015 23:07:16 UTC+2 schrieb sk:

I have found the line of javascript in the web app and submitted a ticket with Loxone. I am hoping that they won't reject it as it will help everyone secure their miniservers behind SSL.

Hi,
I do not believe that you get any help on this from Loxone. They simply ignore the need for secure IoT. Don't wait for them!
found this thread because i have the same problem. SSL Reverse Proxy ran under Version 6 flawlessly. Under 7x everithing seems to be a bit more complicated. There was a good article in the loxone forum. There where some additional tasks, where you have to get some files and modify them. Then you get them locally from rev.proxy.

This ran until 7.x:

</Proxy>

ProxyPass       /login.js  !
ProxyPass       /internal.min.js  !


ProxyPass       /ws     ws://172.a.b.c/ws/
ProxyPass       /       http://172.a.b.c/
ProxyPassReverse /      http://172.a.b.c/


<Directory /usr/local/www/apache24/data/lox>
        Options FollowSymLinks
        Require all granted
</Directory>
</VirtualHost>

But i am not able to debug minified js. Maybe this helps.

I think that /scripts/scripts1.js and /scripts/vendor.js needs to be touched...

[sk]

Hi,

I will take a look at the article tonight. As for loxone apparently they are looking at my fix to see what knock-on/implications it may have which sounds promising. If all goes well then the javascript changes should be in the next mini server update.

[sk]

So... using the approach above I got it all to work on https in chrome sometimes - But it doesn't work with safari and appears to work intermittently in chrome.

In the meantime this is what I did:

1. Setup apache SSL with a cert.
2. Setup the config as follows

ProxyPass /scripts/scripts1.js !
ProxyPass /scripts/vendor.js !
Alias /scripts/scripts1.js /var/www/scripts/scripts1.js
Alias /scripts/vendor.js /var/www/scripts/vendor.js

ProxyPass / http://192.168.1.xx:80/
ProxyPassReverse / http://192.168.1.xx:80/

<Directory /var/www/scripts/>
Order allow,deny
Allow from all
</Directory>

3. head to /var/www/scripts
sudo wget http://miniserverip/scripts/script1.js
sudo wget http://miniserverip/scripts/vendor.js

4. Edit script1.js
Replace http in the _sendRequest js method to https
Replace ws with was in "new WebSocket("ws

5. Edit vendor.js
Replace http with https in ("http:"===h[1]?"80":"443")) in two locations in the file.

6. Bounce apache and try https.

I just need to get it to work in safari. I am not certain but it might be because I am not using a real cert on apache. Will come back once it is working safari as this will mean it will work on the iPhone/ipad.

[sk]

Sadly, whilst testing and tailing the log files on apache I have also realised that the loxone app on the iPhone appears to cache the html, java script and css locally so even if I changed the script files on apache it will not work within the app. The work around is easy though - adding a short cut via https: to web site till loxone have a solution.

[Beat]

Am Dienstag, 22. September 2015 08:31:51 UTC+2 schrieb sk:

Hi,

I will take a look at the article tonight. As for loxone apparently they are looking at my fix to see what knock-on/implications it may have which sounds promising. If all goes well then the javascript changes should be in the next mini server update.

Hi,
any news on this? Are You still optimistic for a fix?

[sk]

Hi not yet, I will follow up. So the fix does need to touch a couple of files, but if I switch them over to wss and https, it will take loxone longer as the need to cater for both ssl and non ssl.

[Beat]

Am Samstag, 24. Oktober 2015 10:06:54 UTC+2 schrieb sk:

Hi not yet, I will follow up. So the fix does need to touch a couple of files, but if I switch them over to wss and https, it will take loxone longer as the need to cater for both ssl and non ssl.

New tutorial (not verified yet):
https://www.loxforum.com/forum/faqs-tutorials-howto-s/10918-howto-miniserver-per-https-erreichbar-machen-apache-reverse-proxy

[NickDD]

Hi,

Tried it today but it is for the classic (former) web interface.
+ as mentioned here as well the mobile app comes bundled with the script files, so then that breaks.

sigh.