Remote access from Internet

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

--

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

--

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

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

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

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.

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

That is solid advice.

-- Kind regards, Tarmo Kuuse

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.

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

-- Kind regards, Tarmo Kuuse

Right, OpenVPN server in the Internet serves as bridge (since technician typically also connects from behind a NAT box).

Looking forward to hearing of your solution, Best Regards, Dave

te

ng

ly

ed

re

to

e -

to

Steve

I am interested in your closing statements.

If one were to use, say, DES or AES, maintain secret 128 or 256 bit keys at both ends, sport a reasonable random number generator and use random challenge-response to logon and prepare 256-bit per-session keys, then would you consider it to be dangerous to send messages back and forth encrypted with the session keys?

Further assuming that the port used would be a high port and that the traffic would be light and that the ISP wouldn't lock up the ports, what would be the danger with protecting, say, somewhat personal information, building access accounts, lightly-critical stuff like that with this scenario?

I am very interested in your take on these questions, since having a standalone internet appliance is so much more simple than the server- centric solution that this thread is leaning toward.

Thanks!

Chris Ruff

Steve

I am interested in your closing statements.

If one were to use, say, DES or AES, maintain secret 128 or 256 bit keys at both ends, sport a reasonable random number generator and use random challenge-response to logon and prepare 256-bit per-session keys, then would you consider it to be dangerous to send messages back and forth encrypted with the session keys?

Further assuming that the port used would be a high port and that the traffic would be light and that the ISP wouldn't lock up the ports, what would be the danger with protecting, say, somewhat personal information, building access accounts, lightly-critical stuff like that with this scenario?

I am very interested in your take on these questions, since having a standalone internet appliance is so much more simple than the server- centric solution that this thread is leaning toward.

Hi!

We gave up trying to provide ubiquitous remote access via Ethernet. User is responsible for setting up a VPN or SSH tunnel to remote site. Simply forwarding a public port to web interface is discouraged, but naturally we cannot stop users from doing that.

Idea of a central server was dismissed by client. There are neither time, know-how nor resources to develop that. I was considering a simple demo to change their minds, but the embedded side is no walk in the park. The TCP/IP stack in eCos is a KAME snapshot from 2002 which is supposed to support IPsec. However, documentation and API are effectively missing. I need to be a BSD TCP/IP and IPsec guru to create a minimal proof-of-concept.

Well, actually I started reading Stevens' "Volume 2", but it's mostly to educate myself and prepare for future challenges.

Not all is lost, though. The GSM data call can be used for PPP. The idea is to have the user initiate dial-in from a modem or cell phone. Device accepts the PPP connection and provides minimal service (only access to the web interface).

-- Kind regards, Tarmo Kuuse

This is why we hired an inexpensive 3rd part provider, of which there are many...

Yikes. This is why many of us are using Linux, all this stuff just works, and things like OpenVPN work great with no fuss.

Sorry, you lost me here. Which user initiates the GSM call ? Did you mean the device initiates the GSM call ? How do you get around the various NAT obstacles ?

Thanks again, Best Regards, Dave

I think the client weighs many design decisions by comparing their product with competitors' products. Since those do not sport such a fancy solution, it is not deemed necessary.

A good demo would possibly change that. I love poking and toying, but the agreed work needs doing. Next time, maybe...

Yes. This used to be a small, cheap, real-time subsystem and eCos was a perfect fit. It has grown out of it's shoes.

User desiring remote access initiates the GSM call (or POTS call, if device has a dedicated data call number). Device accepts call, negotiates PPP link and serves web interface. There is no NAT, it's logically a direct link between user and device.

A PPP stack exists in eCos. It's API is designed to call the dial-in service, not accept incoming calls. However, PPP is symmetric and modifying the eCos implementation seems doable.

-- Kind regards, Tarmo Kuuse

I've lost track of the rest of your requirements, but whenever I see "IPsec", I want to run the other way. It causes all sorts of complications, as do most other VPN or package encryption systems. You get trouble with incompatible software (each claiming to be "standard"), routing, NAT, firewalling, MTU differences, etc. OpenVPN uses SSL, which is much easier, as it is only the contents of the packets that are encrypted, not the addresses and headers. Alternatively, use application-level SSL (if you only need one or two protocols and ports, and have control over the application software). Again, it's far easier, and it is secure against all but the most determined professional-level attacks.

Noted.

-- Kind regards, Tarmo Kuuse

Understood - been there. Thanks for the update.

Yell if I can help with an OpenBSD gateway ;).

Steve

--

Thank you for the support :)

-- Kind regards, Tarmo Kuuse