Security and Remote Access

As per design is assumed that you should run your Souliss network in a secure and trusted network, this because by default Souliss doesn't carry security mechanism at network level. Reading the following statements you may became scared about, don't be, because nothing is really secure.

Secure and Trusted Networks

If you have a Souliss system you probably have multiple networks (Ethernet/WiFi, Wireless RF, RS485) and all of them can be point for an external attach, generally the most common entry point is the Ethernet/WiFi network. Your network is considered trusted by default, so once there is access to the network any device is allowed to communicate with all the others.

Wired Networks A wired network is considered secure by default, because if someone has access to your Ethernet or RS485 network is because is yet in your home. If you are running cables outside, that is a potential security problem.

Wireless Networks A wireless WiFi network is considered secure if protected with WPA2 and a strong password, rather for a wireless RF network that works in peer-to-peer without a point to point encryption cannot be considered secure.

Suggestion for a Secure Network

Based on the previous discussion, the following suggestion give you an high security degree

Use a dedicated Ethernet/WiFi network for your devices In a large system a physically dedicated network is suggested, rather in small installation you can use Home Routers (like openWRT based ones) that allow VLAN to create different network in the same device. The user interface shall be hosted on a different network and connected through a software/hardware firewall to the Souliss Gateway, apply MAC and IP filtering.

You should always consider that an allowed user interface (e.g.: Android smartphone) if compromised can be a trojan-horse.

Limit the use and the network paths for Wiriless RF The Wireless RF devices like Chibiduino, nRF24L01 and Moteino are a point of attach, because using a similar device someone can try to access your network from that door. If you don't have any sensitive control on the Wireless RF (like the disable command of the security system) then is enough to don't allow communication to sensitive nodes.

Be aware, in this case broadcast is your enemy.

Remote Access

You can gain remote access in three different way:

• Access via an external cloud-based system : This is actually achievable via myOpenHAB cloud services and require an openHAB server with the Souliss binding.
• Access via VPN : You need to setup a VPN to get a secure access to your local network, once connected to a VPN your devices will be on your local network even if connected from abroad.
• Port forwarding : Portforwarding of UDP/230 to the Gateway combined with a Dynamic DNS or a static Public IP address give an unsecure access from remote.

User interface Lockdown

A protection to avoid that a device (e.g.: Android smartphone with SoulissApp) connected to your network can take control is the use of Lockdown. If the Lockdown is enabled, in the first five minutes from boot any user interface is allowed to record its access to the Gateway, once elapsed this time no additional user interfaces are accepted till a reboot.

Once locked-down, the user interfaces are recognized through their vNet address, so anyone that know that address is allowed to access. An user interface that guess a vNet address has its IP address black-listed till a reboot.

To use the Lockdown just add the configuration file:

#include "conf/UserinterfaceLockDown.h"

This by default saves in EEPROM the allowed user interface, to have them persistent across a reboot and have them configured at run-time. If you want to define the allowed user interfaces at compile-time use in the setup(),

SetUserInterface(addr);

The addr is the address combining the User Index (from 0x01 to 0x64) and Node Index (from 0x01 to 0xFE) and is an unique identifier for each user interface. In SoulissApp this is defined at firstboot and is available in the Network menu, rather for openHAB are defined in .\openhab\configurations\openhab.cfg.

In this case you can disable the saves in EEPROM using #include "conf/DisableEEPROM.h", so that at reboot all entries out of the once defined with SetUserInterface are cleared.