Remote access from Internet

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