Secure Remote Access TechInfo - Revision history

Henk at 15:24, 31 July 2011

2011-07-31T15:24:35Z

Henk at 20:36, 20 May 2011

2011-05-20T20:36:29Z

Javier: Undo revision 2342 by Javier (Talk)

2010-04-17T21:06:46Z

Undo revision 2342 by Javier (Talk)

Javier at 21:04, 17 April 2010

2010-04-17T21:04:14Z

LibraSun at 14:29, 2 August 2009

2009-08-02T14:29:16Z

Micasaverde: New page: We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer...

2009-04-09T17:49:34Z

New page: We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer...

New page

We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks. This page provides technical details about the security measures we have implemented so we are subject to peer review. We have provided a 'Security concerns' forum at forum.micasaverde.com for uncensored discussion about security concerns.

Vera listens on 2 network ports: port 80 is the normal web interface, and port 3451 is for a special control protocol. When Vera boots up, if the network settings have not been changed manually, Vera first checks if the IP address is an internal IP address (ie starts with 192.168, 10. or 172.x), and if there is a valid internet connection. Vera does this by pinging a couple common servers, such as google, youtube, and micasaverde, to confirm that it gets unique addresses for each domain name and that at least 2 of the 3 servers respond. If Vera has an internal IP address and a valid internet connection, all 5 ports on Vera go into 'switch' mode, meaning they're effective bridged, and there is no firewall. Thus Vera is open for access from another system on the same home network. If Vera has an external, or routable IP address, Vera goes into 'gateway' mode. The WAN and LAN ports are separated, a firewall is setup, a DHCP servers runs on the LAN ports providing addresses in the 192.168.81.x range, and Vera only accepts incoming connections on ports 80 and 3451 from the LAN ports. Thus, only PC's within the home should be able to access Vera, and nothing external, unless the homeowner changes the network settings or does a port forward on his firewall. Vera's built-in Wi-fi is enabled by default, which would allow users into the system. So we ship Vera with WPA2 encryption turned on, and a random wi-fi password consisting of 2 dictionary words plus a number, which is printed on the bottom of Vera.

Each Vera has 2 unique hardware keys which are stored in the nvram and assigned at the factory along with the serial number and the domain name for the remote access server that Vera will use. Only the remote access server for a particular Vera has a database with the serial numbers and hardware keys. When the user goes to the findvera.com tab on his setup page (ie from within the home) and activates the service, his username and an md5 hash of the password, along with the serial number and hardware key, are sent to the remote access server using https (ssl encryption). The remote access server validates that the serial number and hardware key match, and if so, reply with a port number that the Vera unit can use for remote access.

The Vera then uses ssh with a pre-defined ssh username and shared key to make a connection to the remote access server. The remote access server only accepts incoming ssh connections from that username with that shared key. And ssh is configured on the server so that when a connection comes in, rather than giving the ssh user a console (ie bash), it runs a script that requires the serial number and hardware key be sent in within 10 seconds. If they are, and they match, and the right port number was used, the ssh connection is authorized. If there is a mis-match, a log is filed with the incoming external IP address so we can add a block to this IP in the firewall in case this is a DOS or similar attack. The SSH connection includes a port forward of ports 80 and 3451 using the standard ssh port forward mechanism. This port forward does not allow 'gateway', that is, the ports are only accessible from within the remote access server.

NetworkMonitor runs on Vera and calls a php page on the remote access server using https, passing in the serial number and hardware key, which does a loop back test to ensure the ssh tunnel is active. If it's not, NetworkMonitor shuts it down and re-opens it.

When the user logs in through findvera.com, he is redirected to the remote access server that handles his username. The remote access server only accepts secure, https, connections. When the remote access server validates the username and password, then the php page on the control tab acts, effectively, as a gateway to the customer's Vera. It passes requests between the SSL connection and the ports 80/3451 that are forwarded from the ssh connection on Vera by looking up the ports that are associated with that username.

It should also be noted that we purposely never ask users for their home address so that if the remote access server ever were compromised, nobody would know the address of the Veras.

← Older revision		Revision as of 15:24, 31 July 2011
Line 1:		Line 1:
	[[Category:User Instructions]]		[[Category:User Instructions]]
		+	[[Category:Services]]
	We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks. This page provides technical details about the security measures we have implemented so we are subject to peer review. We have provided a 'Security concerns' forum at [http://forum.micasaverde.com forum.micasaverde.com] for uncensored discussion about security concerns.		We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks. This page provides technical details about the security measures we have implemented so we are subject to peer review. We have provided a 'Security concerns' forum at [http://forum.micasaverde.com forum.micasaverde.com] for uncensored discussion about security concerns.

← Older revision		Revision as of 20:36, 20 May 2011
Line 1:		Line 1:
		+	[[Category:User Instructions]]
	We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks. This page provides technical details about the security measures we have implemented so we are subject to peer review. We have provided a 'Security concerns' forum at [http://forum.micasaverde.com forum.micasaverde.com] for uncensored discussion about security concerns.		We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks. This page provides technical details about the security measures we have implemented so we are subject to peer review. We have provided a 'Security concerns' forum at [http://forum.micasaverde.com forum.micasaverde.com] for uncensored discussion about security concerns.

← Older revision		Revision as of 21:06, 17 April 2010
Line 1:		Line 1:
−	~~[[Category:User Instructions]]~~
	We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks. This page provides technical details about the security measures we have implemented so we are subject to peer review. We have provided a 'Security concerns' forum at [http://forum.micasaverde.com forum.micasaverde.com] for uncensored discussion about security concerns.		We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks. This page provides technical details about the security measures we have implemented so we are subject to peer review. We have provided a 'Security concerns' forum at [http://forum.micasaverde.com forum.micasaverde.com] for uncensored discussion about security concerns.

← Older revision		Revision as of 21:04, 17 April 2010
Line 1:		Line 1:
		+	[[Category:User Instructions]]
	We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks. This page provides technical details about the security measures we have implemented so we are subject to peer review. We have provided a 'Security concerns' forum at [http://forum.micasaverde.com forum.micasaverde.com] for uncensored discussion about security concerns.		We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks. This page provides technical details about the security measures we have implemented so we are subject to peer review. We have provided a 'Security concerns' forum at [http://forum.micasaverde.com forum.micasaverde.com] for uncensored discussion about security concerns.

@@ Line 1: / Line 1: @@
-We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks.  This page provides technical details about the security measures we have implemented so we are subject to peer review.  We have provided a 'Security concerns' forum at forum.micasaverde.com for uncensored discussion about security concerns.
+We have made it a top priority to provide customers a safe way to remotely control their Vera that is easy for the customer, but at the same time is secure and does not expose the customer to hackers and other security risks. This page provides technical details about the security measures we have implemented so we are subject to peer review. We have provided a 'Security concerns' forum at [http://forum.micasaverde.com forum.micasaverde.com] for uncensored discussion about security concerns.
-Vera listens on 2 network ports: port 80 is the normal web interface, and port 3451 is for a special control protocol.  When Vera boots up, if the network settings have not been changed manually, Vera first checks if the IP address is an internal IP address (ie starts with 192.168, 10. or 172.x), and if there is a valid internet connection.  Vera does this by pinging a couple common servers, such as google, youtube, and micasaverde, to confirm that it gets unique addresses for each domain name and that at least 2 of the 3 servers respond.  If Vera has an internal IP address and a valid internet connection, all 5 ports on Vera go into 'switch' mode, meaning they're effective bridged, and there is no firewall.  Thus Vera is open for access from another system on the same home network.  If Vera has an external, or routable IP address, Vera goes into 'gateway' mode.  The WAN and LAN ports are separated, a firewall is setup, a DHCP servers runs on the LAN ports providing addresses in the 192.168.81.x range, and Vera only accepts incoming connections on ports 80 and 3451 from the LAN ports.  Thus, only PC's within the home should be able to access Vera, and nothing external, unless the homeowner changes the network settings or does a port forward on his firewall.  Vera's built-in Wi-fi is enabled by default, which would allow users into the system.  So we ship Vera with WPA2 encryption turned on, and a random wi-fi password consisting of 2 dictionary words plus a number, which is printed on the bottom of Vera.
+Vera listens on two network ports: port 80 is the normal web interface, and port 3451 is for a special control protocol. When Vera boots up, if the network settings have not been changed manually, Vera first checks if the IP address is an internal IP address (i.e. starts with 192.168, 10. or 172.x), and whether there is a valid internet connection. Vera does this by pinging a couple of common servers, such as google, youtube, and micasaverde, to confirm that it gets unique addresses for each domain name and that at least 2 of the 3 servers respond. If Vera has an internal IP address and a valid internet connection, all 5 ports on Vera go into 'switch' mode, meaning they're effective bridged, and there is no firewall. Thus Vera is open for access from another system on the same home network. If Vera has an external, or routable IP address, Vera goes into 'gateway' mode: The WAN and LAN ports are separated, a firewall is setup, a DHCP server runs on the LAN ports providing addresses in the 192.168.81.x range, and Vera only accepts incoming connections on ports 80 and 3451 from the LAN ports. Thus, only PC's within the home would be able to access Vera, and nothing external, unless the homeowner changes the network settings or sets up a port forward through the main router's firewall. Vera's built-in Wi-Fi is enabled by default, which allows users into the system wirelessly. So we ship Vera with WPA2 encryption turned on, and a random Wi-Fi password consisting of two dictionary words plus a number, which is printed on the bottom of Vera.
-Each Vera has 2 unique hardware keys which are stored in the nvram and assigned at the factory along with the serial number and the domain name for the remote access server that Vera will use.  Only the remote access server for a particular Vera has a database with the serial numbers and hardware keys.  When the user goes to the findvera.com tab on his setup page (ie from within the home) and activates the service, his username and an md5 hash of the password, along with the serial number and hardware key, are sent to the remote access server using https (ssl encryption).  The remote access server validates that the serial number and hardware key match, and if so, reply with a port number that the Vera unit can use for remote access.
+Each Vera has two unique hardware keys which are stored in the NVRAM (non-volatile memory) and assigned at the factory along with the serial number and the domain name for the remote access server that Vera will use. Only the remote access server for a particular Vera has a database with the serial numbers and hardware keys. When the user goes to the [http://findvera.com FindVera.com] tab on his setup page (i.e. from within the home) and activates the service, his username and an MD5 hash (security checksum) of the password, along with the serial number and hardware key, are sent to the remote access server using the https: (SSL encryption) protocol. The remote access server validates the connection by checking whether the serial number and hardware key match, and if so, replies with a port number that the Vera unit can use for remote access.
-The Vera then uses ssh with a pre-defined ssh username and shared key to make a connection to the remote access server.  The remote access server only accepts incoming ssh connections from that username with that shared key.  And ssh is configured on the server so that when a connection comes in, rather than giving the ssh user a console (ie bash), it runs a script that requires the serial number and hardware key be sent in within 10 seconds.  If they are, and they match, and the right port number was used, the ssh connection is authorized.  If there is a mis-match, a log is filed with the incoming external IP address so we can add a block to this IP in the firewall in case this is a DOS or similar attack.  The SSH connection includes a port forward of ports 80 and 3451 using the standard ssh port forward mechanism.  This port forward does not allow 'gateway', that is, the ports are only accessible from within the remote access server.
+The Vera then uses ssh with a pre-defined ssh username and shared key to make a connection to the remote access server. The remote access server only accepts incoming ssh connections from that username with that shared key. And ssh is configured on the server so that when a connection comes in, rather than giving the ssh user a console (i.e. bash), it runs a script that requires the serial number and hardware key be sent in within 10 seconds. If they are, and they match, and the right port number was used, the ssh connection is authorized. If there is a mis-match, a log is filed with the incoming external IP address so we can add a block to this IP in the firewall in case this is a DOS (denial of service)&nbsp;or similar attack. The SSH connection includes a port forward of ports 80 and 3451 using the standard ssh port forward mechanism. This port forward does not allow 'gateway', that is, the ports are only accessible from within the remote access server.
-NetworkMonitor runs on Vera and calls a php page on the remote access server using https, passing in the serial number and hardware key, which does a loop back test to ensure the ssh tunnel is active.  If it's not, NetworkMonitor shuts it down and re-opens it.
+NetworkMonitor runs on Vera and calls a php page on the remote access server using https, passing in the serial number and hardware key, which does a loop back test to ensure the ssh tunnel is active. If it's not, NetworkMonitor shuts it down and re-opens it.
-When the user logs in through findvera.com, he is redirected to the remote access server that handles his username.  The remote access server only accepts secure, https, connections.  When the remote access server validates the username and password, then the php page on the control tab acts, effectively, as a gateway to the customer's Vera.  It passes requests between the SSL connection and the ports 80/3451 that are forwarded from the ssh connection on Vera by looking up the ports that are associated with that username.
+When first logging on through [http://FindVera.com FindVera.com], the user is redirected to the remote access server, which only accepts secure (https) connections. Once the remote access server validates the username and password, then the php page on the control tab effectively acts as a gateway to the customer's Vera. It passes requests between the SSL connection and port 80 and port 3451 that are forwarded from the ssh connection on Vera by looking up the ports that are associated with that username.
-It should also be noted that we purposely never ask users for their home address so that if the remote access server ever were compromised, nobody would know the address of the Veras.
+It should also be noted that we purposely never ask users for their home address so that if the remote access server ever were compromised, nobody would know the address of the Vera units.