FactoryPMI security

For remote access to a factoryPMI system, if you use the SSL encryption option is there any advantage in also connecting using a VPN (of whatever flavour)?

In theory probably not - in practice, probably. Your VPN connection probably uses a similar transport layer security (SSL/TLS) scheme as FactoryPMI does with secure connections. You’re probably “more secure” using SSL on top of the VPN at the expense of 2 additional layers of overhead.

If I were a betting man against teams of researchers and professional hackers, I’d trust a Cisco VPN client marginally over the FactoryPMI TLS connection. However, either scheme alone is equivalent in strength to what you trust on the Internet with banking and your money.

The only reason I would use SSL and VPN in combination is if you want to require FPMI SSL connection to users that connect locally and your VPN users. A properly configured VPN provides adequate security on it’s own. Try it out and see how it performs.

I have played with scenarios with 3+ tunnels deep. At that point you can create huge problems since you have packets of a fixed size, and each need to create headers. Getting too screwy with this can lead to significant packet fragmentation, which can cause serious performance hits.

Bottom line - either should work fine alone.

Thanks for your reply Nathan. I’ve been looking at this from the point of view of providing customers with remote support to cut down on travelling. I’ll summarise what I’ve found in case it helps others or someone can correct a misapprehension.

Connecting over the web to a FactoryPMI server generally requires a port to be opened in the incoming firewall and traffic on that port forwarded to the FactoryPMI server. Connecting this way in theory exposes data on the Internet and relies on one level of security (a username and password) to keep intruders out of the system. (There is also the possibility of flaws in the FactoryPMI code being exploited, but that is well outside my area of knowledge.)

Using SSL to connect to FactoryPMI reduces your exposure by encrypting data travelling across the Internet. It also can be used to confirm you are indeed connecting to the FactoryPMI server before you enter your username and password, as long as you purchase an SSL certificate from a well-known certificate authority - without this, you will get alarming security warnings about the certificate being invalid (due to being self-signed) when you try to connect.

This configuration will allow you to view your system and (if set up in the Gateway web page) alter FactoryPMI settings. It will not however give you access to the underlying server, and therefore to your database, FactorySQL or your OPC server. You can gain access to your database and FactorySQL by opening other ports in your firewall and forwarding them to the server(s), but there is no easy option to use SSL on those connections. I also don’t know of any easy way of accessing an OPC server remotely - I’ve had horrors with DCOM configuration, although these may be relieved by using the Matrikon OPC Tunneller.

If you need access beyond FactoryPMI on a machine therefore, it would appear necessary to consider implementing a VPN solution. This adds security both in the form of encryption and requirement for confirmation of identity through username/passwords or more advanced means such as security tokens etc.

There are at least 3 flavours of VPN:

  1. PPTP - Microsoft specific, with a built-in client in most (all?) versions of windows. Their implementation had some security flaws earlier on, but these seem to have been fixed.

  2. IPSec - standards based, but requires a 3rd party client to be installed and configured. Colleagues have had good results with the client from http://www.thegreenbow.com.

  3. SSL - The OpenVPN project (http://www.openvpn.net) uses SSL for encryption independently of a web browser. This seems to offer a lot of advantages in terms of simplicity of configuration.

Well, that’s my tiny store of knowledge exhausted. If anyone else can comment or recount their own experiences I would be very interested to hear from them.

You’ve got a pretty good handle on it.

[quote=“AlThePal”]Connecting over the web to a FactoryPMI server generally requires a port to be opened in the incoming firewall and traffic on that port forwarded to the FactoryPMI server. Connecting this way in theory exposes data on the Internet and relies on one level of security (a username and password) to keep intruders out of the system. (There is also the possibility of flaws in the FactoryPMI code being exploited, but that is well outside my area of knowledge.)

Using SSL to connect to FactoryPMI reduces your exposure by encrypting data travelling across the Internet. It also can be used to confirm you are indeed connecting to the FactoryPMI server before you enter your username and password, as long as you purchase an SSL certificate from a well-known certificate authority - without this, you will get alarming security warnings about the certificate being invalid (due to being self-signed) when you try to connect.[/quote]

There’s a lot more to consider than the authentication method (username/password). The system generates a throw away key to encrypt traffic, incorporates datetime stamps, etc. At best case, this proves identities of each party (often requires certificates for that), prevents eavesdropping, “replay”, and “man in the middle” attacks. Note - that we don’t currently use certificates (PKI) to authenticate the client. The current FactoryPMI certificate only provides assurance to the client that the application that they are letting write to their hard drive (just in a temp cache path, not the whole volume) is genuine.

True statements. Providing access to the single port that the FactoryPMI Gateway web server runs on, 8080 by default or 443 for SSL, gives the interface to configure FactoryPMI, but not FactorySQL, your PLC (OPC source), or SQL database. In fact, a more solid enterprise architecture would place the FPMI machine in a DMZ, and the rest further buried in the network. Keep DCOM buried as deep as possible with something like a tunneler - it is impossible to secure on an open network.

[quote=“AlThePal”]If you need access beyond FactoryPMI on a machine therefore, it would appear necessary to consider implementing a VPN solution. This adds security both in the form of encryption and requirement for confirmation of identity through username/passwords or more advanced means such as security tokens etc.
[/quote]

Not necessarily - SQL databases and FactorySQL support remote connections over a single port - you would open these ports in your firewall. However, these fall under administrative functions and I would highly recommend requiring VPN access for remote configuration of these functions. This gives you better security and auditing options.

[quote=“AlThePal”]There are at least 3 flavours of VPN:

  1. PPTP - Microsoft specific, with a built-in client in most (all?) versions of windows. Their implementation had some security flaws earlier on, but these seem to have been fixed.

  2. IPSec - standards based, but requires a 3rd party client to be installed and configured. Colleagues have had good results with the client from .

  3. SSL - The OpenVPN project uses SSL for encryption independently of a web browser. This seems to offer a lot of advantages in terms of simplicity of configuration.

Well, that’s my tiny store of knowledge exhausted. If anyone else can comment or recount their own experiences I would be very interested to hear from them.[/quote]

Good VPN summary. In the network infrastructure world there are many ways of skinning that cat. Many sites interconnect with permanent VPNs between routers and switches, which, in effect, are encrypted BGP tunnels.

Thanks for clarifying these points. I’ve not done much with a DMZ yet - as far as I can understand, this will expose the whole machine, not just the network ports, so you have to ensure that your OS is fully patched. Of course, if someone manages to break into your machine, they then have no access to the rest of your network (except through the ports open to the other servers?).

When providing remote support I generally need access to the whole machine through something like VNC. Without using a VPN, an SSL connection for customers to view their system along with an encrypted VNC connection may fit the bill. I agree that the benefits of a VNC look quite compelling.

If I didn’t think networking was a black art before, one look at your link on Wikipedia convinced me. The number of protocols out there is frightening! I dream one day of understanding the basics… :slight_smile:

Lol - one more point of clarification. Home routers refer to DMZ Hosts, sometimes DMZ, as a host on the internal network with all ports exposed. This isn’t a DMZ by definition. That’s why I used the term enterprise with DMZ. The Wikipedia DMZ definition can clarify better than I.

Huh no kidding. I learn something new every day.