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

Reply to
Tarmo Kuuse
Loading thread data ...

LOL, I love it :)

.

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.

Reply to
zwsdotcom

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
Reply to
Tim Wescott

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".

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.

Reply to
David Brown

Depends on how enthusiastically they are inserted, really. Have you ever/do you currently work for a large company?

Reply to
zwsdotcom

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 >> IMHO the safest method would be a VPN between site and client. The

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.

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

Reply to
Tarmo Kuuse

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.

Reply to
zwsdotcom

Then you need an easily-remembered yet unguessable password for the user to type in, to get access.

--
http://www.wescottdesign.com
Reply to
Tim Wescott

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
Reply to
Tim Wescott

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 :)

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.

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 snipped-for-privacy@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 . Maybe there is an easier way?

-- Kind regards, Tarmo Kuuse

Reply to
Tarmo Kuuse

t

It's more usual to have an impossible-to-remember "password" (or more usually, crypto key) stored in a local file on the client. But I have not seen this method used for quite a long time, I guess other techniques have become more popular (or people just don't care, since there are so many other weak links in everything now that we can basically assume that any hardware and software you can buy off the shelf is wide open and unprotectable)

Reply to
zwsdotcom

WRT firware gives even a $60 router VPN capability. I've also thought about using it but there has never been urgent need...

-- Kind regards, Tarmo Kuuse

Reply to
Tarmo Kuuse

I use openwrt on LinkSys WRT54LG routers. You need to be willing to read a bit and type a bit to get it working and to get the best out of it, but it has big advantages over "standard" home router firmware:

You can configure and firewall or bridge each Ethernet port (and the wireless port) independently, thus giving you isolated networks (so that the teenage kid's malware infestations stay on they PC's and don't migrate to your one).

You can set up as many openvpn tunnels as you like, either as client or server, and connect these to the Ethernet ports you want.

You can firewall and route with all the power of Linux networking.

You get a real ssh for access rather than just a web interface.

You can chose your own DHCP and DNS setups.

You can run other small services such as NTP.

If you have a bigger router, you can do things like print serving or connect a USB harddisk or flash disk. Then you can configure shared storage, mail filtering, web proxying, or whatever else you fancy.

Reply to
David Brown

Tim Wescott wrote: [snip]

Web interface is not read-only. It lets the user change lots of internal parameters. Some are harmless, some are not.

AFAIK it's an exotic embedded web server which has not been audited, tested or hardened from security perspective so I assume it's swarming with vulnerabilities.

Service technician has access to safety and operational parameters which must not be exposed, and firmware update.

User and service tech are granted different access levels, but the implementation is not nearly bulletproof.

Good point. I hope it's not a common policy.

There is not much we can do about that in advance.

-- Kind regards, Tarmo Kuuse

Reply to
Tarmo Kuuse

ISP

It is routine in the United States but the ISP's countermeasure is typically simply to block the well-known ports and - on a rolling basis - other ports if they are receiving large numbers of inbound connection attempts.

Some ISPs enforce these rules, some don't, but all specifically mention "no servers" in their terms of service because they sell more expensive access packages that do allow servers. I wouldn't worry about this for your application though.

I happen to work for a company that has a very large number of installed remotely-communicating embedded systems connected through every possible ISP you can imagine (in the USA), and in all cases the way they get around this and other problems is by routing all communications to a central server. The devices all check into/ register with the central server using outbound connections. If the end-user wants to talk to his device, he logs into his account on that central server, and pushes data back down the "outbound" pipe from the node.

For customers who don't want to rely on our central server, we sell an application (used to be a dedicated box, but is now just PC software I think) that lets them run their own server.

Reply to
zwsdotcom

An initial proposal was to implement the entire user interface as a Java applet and use a simple back-end protocol to move data. Traditional web interface seems to be a more robust solution so Java was dropped.

Anyway, it occurs to me that device could open a connection to Internet instead of waiting for an incoming one.

Device opens a TCP connection to a public relay server. They authenticate each other and the connection is kept alive indefinitely.

The user who desires access connects to relay server with a browser and logs in. The server then relays all HTTP requests to device (via existing TCP connection) and passes the HTTP responses back to client.

Pros: no incoming connections, NAT and dynamic public IP become transparent, no web security problems

Cons: need relay server, need tunneling protocol.

Hmm, gotta think some more.

-- Kind regards, Tarmo Kuuse

Reply to
Tarmo Kuuse

yes, see my other reply to you in this thread... this is the way my employer does it.

pros: you can sell advertising space on the relay site (don't laugh). you can also have the option of providing paid-for subscription services on that relay site.

Reply to
zwsdotcom

[snip]

Ouch.

Thanks, that is also an enlightning reply.

Time will tell if I can lobby this idea to the brass (they sometimes worry about core business more than working solutions).

-- Kind regards, Tarmo Kuuse

Reply to
Tarmo Kuuse

.

I just finished solving *almost* this problem a couple months back. Almost because our box:

- runs Linux, and

- has GSM (receives text messages and runs GPRS)

Service is initiated by sending a text message, whereupon the box starts openvpn... Works great ! openvpn's well-know port is not blocked by the telecom providers NAT boxes (this system is using GPRS for the connection, no hardwired access available).

Let us know how you do it with eCos !

Best Regards, Dave

Reply to
DRN

That's exactly how our GSM-only products work (ThreadX based).

Reply to
zwsdotcom

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.