Remote access from Internet

On Mar 24, 10:19=A0am, Tim Wescott <t...@seemywebsite.com> wrote:

> > 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, bu=
t
> > all it serves up is a Java application that runs in the client- side
>
> Then you need an easily-remembered yet unguessable password for the user
> to type in, to get access.

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)

Tim Wescott wrote:
> IIRC, the $150 home-class router here supports VPN, at least in theory.  
> I've thought about using it, but never turned it on.

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

Tarmo Kuuse wrote:
> Tim Wescott wrote:
>> IIRC, the $150 home-class router here supports VPN, at least in 
>> theory.  I've thought about using it, but never turned it on.
> 
> WRT firware gives even a $60 router VPN capability. I've also thought 
> about using it but there has never been urgent need...
> 

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.

Tim Wescott wrote:
[snip]
> 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?

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

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

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.

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

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.

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

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

On Mar 24, 12:39=A0pm, Tarmo Kuuse <tarmo.ku...@mail.ee> wrote:

> > hypothetical client's ISP. =A0I know that mine specifically disallows
> > putting a server up out here. =A0If that's checked automagically at the=
 ISP
>
> Good point. I hope it's not a common policy.

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.

zwsdotcom@gmail.com wrote:
> 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.

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

On Mar 24, 1:14=A0pm, Tarmo Kuuse <tarmo.ku...@mail.ee> wrote:

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

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


> Pros: no incoming connections, NAT and dynamic public IP become
> transparent, no web security problems
>
> Cons: need relay server, need tunneling protocol.

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.

zwsdotcom@gmail.com wrote:
> On Mar 24, 12:39 pm, Tarmo Kuuse <tarmo.ku...@mail.ee> wrote:
>>> hypothetical client's ISP.  I know that mine specifically disallows
>>> putting a server up out here.  If that's checked automagically at the ISP
>> Good point. I hope it's not a common policy.
> 
> 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.
[snip]

Ouch.

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

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

On Mar 24, 7:36=A0am, Tarmo Kuuse <tarmo.ku...@mail.ee> 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
> =A0 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

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

On Mar 24, 2:23=A0pm, DRN <d...@nadler.com> wrote:

> Service is initiated by sending a text message, whereupon the box
> starts openvpn... Works great ! openvpn's well-know port is not

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