Forums

Remote access from Internet

Started by Tarmo Kuuse March 24, 2009
Hi all,

A residential/light-industrial power device has a simple web interface 
which allows monitoring and configuring it, upgrading firmware etc. The 
usual stuff.

Device is running eCos and web interface is powered by ATHTTPd with tcl 
scripting.

Users do not feel warm and fuzzy dragging their bones to site, hooking 
up a laptop and then clicking away whilst standing or sitting on a hay 
pack. Neither do the service techs.

In a flash of brilliance we recognize the need for remote access.

We assume site is connected (naturally), but the Internet connection is 
shared (device has private IP, router does NAT). We also assume the user 
  installing it is not tech-savvy (i.e. blissfully oblivious of TCP/IP 
networking), but is able to follow clear instructions.

My first idea was having the device ask the router to forward port 80 
using UPnP. That will expose the web interface directly to the Internet. 
Unfortunately neither the app or ATHTTPd are mature security-wise. It'll 
be like dropping a shrink-wrapped steak in jungle and hoping it won't 
get eaten.

IMHO the safest method would be a VPN between site and client. The 
client, however, does not wish to hire an expensive IT admin to set it up.

How would you design remote access in this condition?

Ideal solution involves plug-and-play with 3-step instruction and no 
software installed into client's computer (WinXP or Vista). Oh, and 
flying porcupines :)

--
Kind regards,
Tarmo Kuuse
On Mar 24, 7:36=A0am, Tarmo Kuuse <tarmo.ku...@mail.ee> wrote:

> Unfortunately neither the app or ATHTTPd are mature security-wise. It'll > be like dropping a shrink-wrapped steak in jungle and hoping it won't > get eaten.
LOL, I love it :)
> IMHO the safest method would be a VPN between site and client. The > client, however, does not wish to hire an expensive IT admin to set it up=
. Not sure why the client needs to hire anyone other than you. This would appear to be a simple situation... though perhaps not cheap. And by cheating I can put it into three steps for you: 1. configure two routers to support a VPN between their WAN-side connections. 2. take one router out to site, install between equipment and big nasty internet (snuggle it in hay if you feel it necessary) 3. take other router out to customer, plug it into his network, when he wants to talk to the hay barn he plugs his laptop into one of the LAN ports on the router. I think you should find all the instructions you need in the Cisco IOS Cookbook (amazon.com). But I repeat this scenario probably won't be real cheap; I'm not sure what the cheapest router supporting this would be as the ones I've used are big and extremely expensive. There are more exotic solutions. For example you could put a GSM module in the device and have it issue session keys via SMS to a hardcoded number, which an attacker would not be able to hijack.
On Tue, 24 Mar 2009 05:25:15 -0700, zwsdotcom wrote:

> On Mar 24, 7:36&nbsp;am, Tarmo Kuuse <tarmo.ku...@mail.ee> wrote: > >> Unfortunately neither the app or ATHTTPd are mature security-wise. >> It'll be like dropping a shrink-wrapped steak in jungle and hoping it >> won't get eaten. > > LOL, I love it :) > >> IMHO the safest method would be a VPN between site and client. The >> client, however, does not wish to hire an expensive IT admin to set it >> up. > > Not sure why the client needs to hire anyone other than you. This would > appear to be a simple situation... though perhaps not cheap. And by > cheating I can put it into three steps for you: > > 1. configure two routers to support a VPN between their WAN-side > connections. > 2. take one router out to site, install between equipment and big nasty > internet (snuggle it in hay if you feel it necessary) 3. take other > router out to customer, plug it into his network, when he wants to talk > to the hay barn he plugs his laptop into one of the LAN ports on the > router. > > I think you should find all the instructions you need in the Cisco IOS > Cookbook (amazon.com). But I repeat this scenario probably won't be real > cheap; I'm not sure what the cheapest router supporting this would be as > the ones I've used are big and extremely expensive. > > There are more exotic solutions. For example you could put a GSM module > in the device and have it issue session keys via SMS to a hardcoded > number, which an attacker would not be able to hijack.
IIRC, the $150 home-class router here supports VPN, at least in theory. I've thought about using it, but never turned it on. -- http://www.wescottdesign.com
Tarmo Kuuse wrote:
> Hi all, > > A residential/light-industrial power device has a simple web interface > which allows monitoring and configuring it, upgrading firmware etc. The > usual stuff. > > Device is running eCos and web interface is powered by ATHTTPd with tcl > scripting. > > Users do not feel warm and fuzzy dragging their bones to site, hooking > up a laptop and then clicking away whilst standing or sitting on a hay > pack. Neither do the service techs. > > In a flash of brilliance we recognize the need for remote access. > > We assume site is connected (naturally), but the Internet connection is > shared (device has private IP, router does NAT). We also assume the user > installing it is not tech-savvy (i.e. blissfully oblivious of TCP/IP > networking), but is able to follow clear instructions. > > My first idea was having the device ask the router to forward port 80 > using UPnP. That will expose the web interface directly to the Internet. > Unfortunately neither the app or ATHTTPd are mature security-wise. It'll > be like dropping a shrink-wrapped steak in jungle and hoping it won't > get eaten. >
Forget UPnP. If the user is remotely tech-savvy and security concious, he'll be using a router that has UPnP disabled. UPnP probably has its place (though I can't think what that might be), but having a firewall which opens a port whenever an application asks is not exactly what I call "secure".
> IMHO the safest method would be a VPN between site and client. The > client, however, does not wish to hire an expensive IT admin to set it up. > > How would you design remote access in this condition? > > Ideal solution involves plug-and-play with 3-step instruction and no > software installed into client's computer (WinXP or Vista). Oh, and > flying porcupines :) >
I'm not sure where the porcupines fit in, but far and away the most convenient and flexible vpn solution I know of is openvpn. Unfortunately, it does not support eCos (can't you switch to Linux?), so you need an external router to handle it. I'd go for something like a cheapo home NAT router with openwrt support and install openwrt and openvpn, but there are various alternative small linux (or bsd) based router firmware that will handle openvpn. The openvpn client should then connect to your openvpn server through the NAT box.
On Mar 24, 9:29=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:

> I'm not sure where the porcupines fit in, but far and away the most
Depends on how enthusiastically they are inserted, really. Have you ever/do you currently work for a large company?
It's good to receive feedback from pragmatic people. However, I forgot 
to emphasize volume and diversity.

In my post "The client" refers to the proverbial client. There will be 
quite a few of them, if the sales dept get their way. Home or business 
owners, farmers, anyone with 100 square meters of roof or land.

The device is a solar panel inverter. It'll be sold in over half a dozen 
countries in southern Europe.

zwsdotcom@gmail.com wrote:
>> IMHO the safest method would be a VPN between site and client. The >> client, however, does not wish to hire an expensive IT admin to set it up.. > > Not sure why the client needs to hire anyone other than you. This > would appear to be a simple situation... though perhaps not cheap. And > by cheating I can put it into three steps for you: > > 1. configure two routers to support a VPN between their WAN-side > connections. > 2. take one router out to site, install between equipment and big > nasty internet (snuggle it in hay if you feel it necessary) > 3. take other router out to customer, plug it into his network, when > he wants to talk to the hay barn he plugs his laptop into one of the > LAN ports on the router. > > I think you should find all the instructions you need in the Cisco IOS > Cookbook (amazon.com). But I repeat this scenario probably won't be > real cheap; I'm not sure what the cheapest router supporting this > would be as the ones I've used are big and extremely expensive.
Custom IT work on site is not feasible. Clients are expected to set it up following (simple) printed instructions. Naturally they receive phone support when needed but this is a non-trivial expense (even more so because of the multi-lingual market). People who install solar panels do not know anything about VPN. Neither do most of the support or service techs :). Local network is OK - it's domesticated by zeroconf (automatic IP assignment and address resolution). Remote access, on the other hand, is a real wild beast. I wish I could port Hamachi to eCos.
> There are more exotic solutions. For example you could put a GSM > module in the device and have it issue session keys via SMS to a > hardcoded number, which an attacker would not be able to hijack.
As it happens, GSM module is offered as an extra. It does add some interesting options, but GSM should not be required for remote access. -- Kind regards, Tarmo Kuuse
On Mar 24, 10:03=A0am, Tarmo Kuuse <tarmo.ku...@mail.ee> wrote:

> Local network is OK - it's domesticated by zeroconf (automatic IP > assignment and address resolution). Remote access, on the other hand, is > a real wild beast. I wish I could port Hamachi to eCos.
There are various methods employed, though not so popular in this day and age. One method is to use a proprietary and encrypted protocol tunneled over port 80. Your embedded device is visible to the world, but all it serves up is a Java application that runs in the client- side browser and communicates using an encrypted data stream. That is fairly transparent to end-users insofar as the "software installation" happens as soon as they navigate to the device's page.
On Tue, 24 Mar 2009 07:15:36 -0700, zwsdotcom wrote:

> On Mar 24, 10:03&nbsp;am, Tarmo Kuuse <tarmo.ku...@mail.ee> wrote: > >> Local network is OK - it's domesticated by zeroconf (automatic IP >> assignment and address resolution). Remote access, on the other hand, >> is a real wild beast. I wish I could port Hamachi to eCos. > > There are various methods employed, though not so popular in this day > and age. One method is to use a proprietary and encrypted protocol > tunneled over port 80. Your embedded device is visible to the world, but > all it serves up is a Java application that runs in the client- side > browser and communicates using an encrypted data stream. That is fairly > transparent to end-users insofar as the "software installation" happens > as soon as they navigate to the device's page.
Then you need an easily-remembered yet unguessable password for the user to type in, to get access. -- http://www.wescottdesign.com
On Tue, 24 Mar 2009 13:36:03 +0200, Tarmo Kuuse wrote:

> Hi all, > > A residential/light-industrial power device has a simple web interface > which allows monitoring and configuring it, upgrading firmware etc. The > usual stuff. > > Device is running eCos and web interface is powered by ATHTTPd with tcl > scripting. > > Users do not feel warm and fuzzy dragging their bones to site, hooking > up a laptop and then clicking away whilst standing or sitting on a hay > pack. Neither do the service techs. > > In a flash of brilliance we recognize the need for remote access. > > We assume site is connected (naturally), but the Internet connection is > shared (device has private IP, router does NAT). We also assume the user > installing it is not tech-savvy (i.e. blissfully oblivious of TCP/IP > networking), but is able to follow clear instructions. > > My first idea was having the device ask the router to forward port 80 > using UPnP. That will expose the web interface directly to the Internet. > Unfortunately neither the app or ATHTTPd are mature security-wise. It'll > be like dropping a shrink-wrapped steak in jungle and hoping it won't > get eaten. > > IMHO the safest method would be a VPN between site and client. The > client, however, does not wish to hire an expensive IT admin to set it > up. > > How would you design remote access in this condition? > > Ideal solution involves plug-and-play with 3-step instruction and no > software installed into client's computer (WinXP or Vista). Oh, and > flying porcupines :)
How extensive will this remote access be? If they're just checking status, and it's not anything that a user is going to get hot about the world knowing, could you just have a read-only web page? Or are you concerned about the web server that you're proposing to use having security problems? It seems like that could be solved by choosing one that's too dumb to write. Of course, if your required access includes a button that automatically burns the barn down, they may not like that being exposed to all and sundry. Come to think of it, you may also be in for a problem with the hypothetical client's ISP. I know that mine specifically disallows putting a server up out here. If that's checked automagically at the ISP it could cause problems. -- http://www.wescottdesign.com
David Brown wrote:
> [snip] > Forget UPnP. If the user is remotely tech-savvy and security concious, > he'll be using a router that has UPnP disabled. UPnP probably has its > place (though I can't think what that might be), but having a firewall > which opens a port whenever an application asks is not exactly what I > call "secure".
Well, most average people choose to not know and not care. UPnP (along with all it's vices) is for them. People who are smart enough to disable UPnP also know how to forward ports manually. Forwarding a port is not that hard. It's the daemon in that port that troubles me :)
>> [snip] >> Ideal solution involves plug-and-play with 3-step instruction and no >> software installed into client's computer (WinXP or Vista). Oh, and >> flying porcupines :) > > I'm not sure where the porcupines fit in,
When I find a solution that matches the criteria above, I will look up and expect to see pigs cruising by :) I just wanted to say I'm fresh out of ideas and gladly accept compromises, shortcuts and rough corners. > I'm not sure where the porcupines fit in, but far and away the most > convenient and flexible vpn solution I know of is openvpn.
> Unfortunately, it does not support eCos (can't you switch to Linux?), so > you need an external router to handle it. I'd go for something like a > cheapo home NAT router with openwrt support and install openwrt and > openvpn, but there are various alternative small linux (or bsd) based > router firmware that will handle openvpn. > > The openvpn client should then connect to your openvpn server through > the NAT box.
Switching to Linux was discussed at start, but the idea was dropped (good old "legacy" argument never seems to fail). I'll strongly suggest it for the next version. Suggestions from both you and zwsdotcom@gmail.com are solid. External VPN is the right way to solve it. However, I'm cheap and don't want to do it for reasons given in <gqap7b$17n$1@news.motzarella.org>. Maybe there is an easier way? -- Kind regards, Tarmo Kuuse