Remote access from Internet

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


Tarmo,

Did you ever consider the risks of connecting that inverter to a network by
anything else but glass fiber?
Solar panels tend to be risk points for lightning, and are often very well
protected themselves.
But connecting them, even using (slightly galvanically isolated) Ethernet
cabling is a risk factor. And sometimes users use 'the best cabling' they
can get, using STP (screened) cable which may directly connect the frame
ground of your inverter to the frame ground of the router or modem.

Regards,
Arie de Muynck

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:49c8dfac$0$14781$8404b019@news.wineasy.se...
> 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.

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

I'd echo OpenVPN. However, I'd also suggest using a dedicated gateway 
machine running e.g. OpenBSD to separate the insecure LAN from the Internet. 
If you have that, then you also have other options (such as https) and 
auth'ed access etc etc etc... But OpenVPN works well and is easy to 
configure. And a decent Windows GUI client exists.

I've come across this situation fairly often. This need (to keep the LAN 
gear simple, but have a single industrial-strength gateway rather than 
trying to - ineffectually - strengthen the LAN gear) is not in the least 
unusual. And sadly, often overlooked. It's scary how insecure some of the 
kit connected directly to the 'net is. SCADA hacks, anyone? Very topical 
right now...

Steve
--
http://www.fivetrees.com 

"Tarmo Kuuse" <tarmo.kuuse@mail.ee> wrote in message 
news:gqb4ed$18l$1@news.motzarella.org...
> 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.

Further to my earlier post re manful gateways: again, I've run into exactly 
this (no extra cost/infrastructure on site allowed), and what you described 
is how we fixed it. A relay (management) server actually opens up a lot of 
possibilities: look on it as added, centralised value - you can do far more 
there than you can at each remote site, including logging, account 
management, upgrades, etc etc etc.

However: you still need to ensure that the comms from the remote sites to 
the relay server(s) are secure. In our case we used dial-up - i.e. point to 
point, and not public: the remote site dialled in, and was not externally 
accessible (it was a while ago). If you're using the Internet, then you 
probably need to block all ports *except* for one that you actively manage - 
ideally by something strong like SSH. I'm sure you know not to be tempted to 
try to be secure through obscurity, or to try to write your own...

Steve
--
http://www.fivetrees.com 

<zwsdotcom@gmail.com> wrote in message 
news:e43ae27a-a172-4991-9110-6aa7c786ac07@w35g2000yqm.googlegroups.com...
>> 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. <<

I routinely do exactly this with PF on OpenBSD - I block SSH attacks by a 
velocity rule which detects three unsuccessful login attempts in a (very) 
short period. The logs of my (many, not just fivetrees) public servers are 
enlightening - *any* publicly-accessible machine is subject to continuous 
scripted attacks. This is normal.

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

Absolutely (see my other replies). A centralised server offers the 
opportunity to "leverage" (I hate that term) the infrastructure. Also it 
means that the web interface can be centralised, and the comms to the remote 
sites can be proprietary sockets - they're not public, and don't want to be 
public - ideally over SSH.

As I've said elsewhere, I've done exactly this a few times. Works well. The 
centralisation means the entire public system can be routinely upgraded 
and/or hardened and/or prettified without having to worry about upgrades at 
remote sites - assuming that the basic server-remote comms are secure and 
stable.

Steve
--
http://www.fivetrees.com

Arie wrote:
> Did you ever consider the risks of connecting that inverter to a network by
> anything else but glass fiber?
> Solar panels tend to be risk points for lightning, and are often very well
> protected themselves.
> But connecting them, even using (slightly galvanically isolated) Ethernet
> cabling is a risk factor. And sometimes users use 'the best cabling' they
> can get, using STP (screened) cable which may directly connect the frame
> ground of your inverter to the frame ground of the router or modem.

I don't know anything about inversion circuits but I assume an inverter 
has no place in a power grid unless it's properly isolated and grounded. 
I'll ask the power engineers.

--
Kind regards,
Tarmo Kuuse

Steve at fivetrees wrote:
> "Tarmo Kuuse" <tarmo.kuuse@mail.ee> wrote in message 
> news:gqb4ed$18l$1@news.motzarella.org...
>> 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.
> 
> Further to my earlier post re manful gateways: again, I've run into exactly 
> this (no extra cost/infrastructure on site allowed), and what you described 
> is how we fixed it. A relay (management) server actually opens up a lot of 
> possibilities: look on it as added, centralised value - you can do far more 
> there than you can at each remote site, including logging, account 
> management, upgrades, etc etc etc.
> 
> However: you still need to ensure that the comms from the remote sites to 
> the relay server(s) are secure. In our case we used dial-up - i.e. point to 
> point, and not public: the remote site dialled in, and was not externally 
> accessible (it was a while ago). If you're using the Internet, then you 
> probably need to block all ports *except* for one that you actively manage - 
> ideally by something strong like SSH. I'm sure you know not to be tempted to 
> try to be secure through obscurity, or to try to write your own...
> 

As a side note on ssh security, there is no need to put ssh on port 22 
(the same applies to other protocols as well).  A server with ssh open 
on port 22 is going to get hammered with dictionary attacks on a fairly 
continuous basis.  You need to make sure your user names and passwords 
are secure (i.e., don't allow root ssh login - make the attacker guess 
the username as well), and you might want to use fail2ban or similar 
automatic blockers.  But if you put your ssh server on port 32412, the 
only traffic you'll ever see is your own logins.

David Brown wrote:
> Steve at fivetrees wrote:
[snip]
>> However: you still need to ensure that the comms from the remote sites 
>> to the relay server(s) are secure. In our case we used dial-up - i.e. 
>> point to point, and not public: the remote site dialled in, and was 
>> not externally accessible (it was a while ago). If you're using the 
>> Internet, then you probably need to block all ports *except* for one 
>> that you actively manage - ideally by something strong like SSH. I'm 
>> sure you know not to be tempted to try to be secure through obscurity, 
>> or to try to write your own...
>>
> 
> As a side note on ssh security, there is no need to put ssh on port 22 
> (the same applies to other protocols as well).  A server with ssh open 
> on port 22 is going to get hammered with dictionary attacks on a fairly 
> continuous basis.  You need to make sure your user names and passwords 
> are secure (i.e., don't allow root ssh login - make the attacker guess 
> the username as well), and you might want to use fail2ban or similar 
> automatic blockers.  But if you put your ssh server on port 32412, the 
> only traffic you'll ever see is your own logins.

Yes, I've administered some minor public boxes. Reading the logs was a 
real eye-opener. Script kiddies run rampant out there :)

The "--limit" match in iptables is a very simple and effecive medicine 
against brute forcing. Unfortunately it's a bit too simple and 
effective, blocking all connections to service. Legitimate users could 
suffer.

--
Kind regards,
Tarmo Kuuse

Tarmo Kuuse wrote:
> David Brown wrote:
>> Steve at fivetrees wrote:
> [snip]
>>> However: you still need to ensure that the comms from the remote 
>>> sites to the relay server(s) are secure. In our case we used dial-up 
>>> - i.e. point to point, and not public: the remote site dialled in, 
>>> and was not externally accessible (it was a while ago). If you're 
>>> using the Internet, then you probably need to block all ports 
>>> *except* for one that you actively manage - ideally by something 
>>> strong like SSH. I'm sure you know not to be tempted to try to be 
>>> secure through obscurity, or to try to write your own...
>>>
>>
>> As a side note on ssh security, there is no need to put ssh on port 22 
>> (the same applies to other protocols as well).  A server with ssh open 
>> on port 22 is going to get hammered with dictionary attacks on a 
>> fairly continuous basis.  You need to make sure your user names and 
>> passwords are secure (i.e., don't allow root ssh login - make the 
>> attacker guess the username as well), and you might want to use 
>> fail2ban or similar automatic blockers.  But if you put your ssh 
>> server on port 32412, the only traffic you'll ever see is your own 
>> logins.
> 
> Yes, I've administered some minor public boxes. Reading the logs was a 
> real eye-opener. Script kiddies run rampant out there :)
> 
> The "--limit" match in iptables is a very simple and effecive medicine 
> against brute forcing. Unfortunately it's a bit too simple and 
> effective, blocking all connections to service. Legitimate users could 
> suffer.
> 

I usually set the ssh port limiting to 1 per minute with a burst of 3 
which is a reasonable compromise.  But using a non-standard port makes a 
huge difference - it's a bit like an extra layer of passwording 
(attackers must guess the port before guessing the username and 
password) with minimal resource impact on the server.  It's easy enough 
to specify a non-standard port at the client side, so there is nothing 
to lose.

Steve at fivetrees wrote:
> Further to my earlier post re manful gateways: again, I've run into exactly 
> this (no extra cost/infrastructure on site allowed), and what you described 
> is how we fixed it. A relay (management) server actually opens up a lot of 
> possibilities: look on it as added, centralised value - you can do far more 
> there than you can at each remote site, including logging, account 
> management, upgrades, etc etc etc.

That is logical and supports what others have posted.

I've been involved in a similar middleware software project previously. 
The rewards are considerable but it's also a non-trivial burden to 
develop and maintain a dedicated public service, especially for a 
product with a 20 year lifespan.

This leaves the scope of our discussion, but my employer develops and 
produces big gray expensive boxes, not software or services. They would 
probably need a new department to pull it off. Or maybe find an outside 
partner. The project, however, is supposed to include a quick and simple 
implementation of basic networking. My current task is finding said 
quick and simple solutions or, as Estonians say, baking a bread from dung.

It's OK. I'd probably be bored stiff if my road was paved with standard, 
high-quality, proven solutions :). Project manager will get my analysis 
and recommendations and we'll work out a solution (perhaps it's not the 
right time to bring in advanced networking).

> However: you still need to ensure that the comms from the remote sites to 
> the relay server(s) are secure. In our case we used dial-up - i.e. point to 
> point, and not public: the remote site dialled in, and was not externally 
> accessible (it was a while ago). If you're using the Internet, then you 
> probably need to block all ports *except* for one that you actively manage - 
> ideally by something strong like SSH. I'm sure you know not to be tempted to 
> try to be secure through obscurity, or to try to write your own...

That is solid advice.

--
Kind regards,
Tarmo Kuuse

DRN wrote:
> 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 me see if I understood correctly. Your box contains a VPN client and 
connects to an OpenVPN server in the Internet?

That sounds outrageously nice. A fleet of remote devices, full-blown 
local networking, flexible segmenting and architecture, single point of 
control.

> Let us know how you do it with eCos !

I hope it will not end up being too embarrassing to publicly post it ;)

--
Kind regards,
Tarmo Kuuse