loader image

Being confident in network and data security is critical to an integrator and is a part of the ‘contract of trust’ that an integrator enters into with the customer.

 

What we are talking about here is specifically IP port security with respect to KNXMonitor, and how leaving router external ports ‘open’ is understood to be inherently insecure, but to what level of risk?

Available port numbers may range from 0 to 65536, and only ports numbers 0 to 1024 are reserved for privileged services and designated as well-known ports. This list of well-known port numbers specifies the port used by the server process as its contact port, as well as ports reserved by organisations. They are assigned by IANA for specific service upon application by a requesting entity. On most systems, registered ports can be used without superuser privileges.  Port 3671 is registered by the KNX Association for use by KNX devices, though we are not required to use that number.

First of all the real world case of the recent attacks on KNX installations through unprotected WAN (Wide Area Network on the ‘outside’ of a router’s connection to the internet) port 3671 is perhaps unsurprising as it is pretty easy to scan a range of IP addresses to see if port 3671 is open, and, if it is, to expect that the port is redirecting to a KNX IP interface or gateway.  From there, if the network is not employing KNX Secure or other security then it’s a fairly easy to duck in and take control of the KNX bus traffic, to perform actions in the building; see what actions are being performed; or to reprogram devices so they cannot be used (which is what happened in the network breach cases that were reported). 

If, for nefarious reasons, a ‘hacker’ is searching for ‘open’ ports leading to a KNX system, to access a network, they must scan all the ports of a router’s external WAN address (ie. 144.33.45.78:0 to 65536)  Due to the processing power, internet bandwidth and router reponse speed necessary, the time taken to do this for single network connection, let alone systemically for a range of WAN addresses makes this unfeasible.  More likely the hacker will just scan for port 3671 on a range of WAN connections, and can reasonably expect if they are ‘open’ that they are forwarded to a KNX device.  So, don’t make it easy for the hacker, choose a different port address somewhere else in the range (eg. a random port number like 54634).

If a network router has the firewall function to limit traffic to that from specific IP addresses through a port, then listing the IP addresses of the servers being connected to means that the ‘hacker’s’ IP address (which is not going to be on that list) will not be allowed to communicate through the firewall and into the LAN unless they are able to ‘spoof’ the correct IP address.  Our KNXMonitor global server addresses are fixed and can be added to the router’s  firewall to take advantage of the added security.

Network security and KNX system integrity is important, and though we cannot be 100% safe whilst ports are open, the two methods above, either together or individually, add a high degree of security without the need for hardware solutions.  If required the integrator can explain how these mitigate the risks to the customer, and can be confident that the KNX network monitoring is happening significantly more securely than a wide-open KNX port.

In summary – 

  1. NAT your port to a different number than 3671, and 
  2. Whitelist the IP addresses allowed to connect to that port. e.g. for KNXMonitor these are 164.92.128.194,  161.35.151.228 & 34.87.218.178