Remote access to FPMI

Hi all,
I’ve been trying to think of the best way to provide remote access to a FPMI project. As usual, we have the server on an intranet, but the client wants to be able to access it from anywhere. I’ve checked the VPN vs SSL thread for ideas/info as well. Below I’ve listed the current options and I’m hoping to get some feedback on them and some insight into what other people have done. Here are the possibilities I’ve considered so far:

-Citrix XenApp: The client already has this deployed, and running a java applet from it might be possible. I’m leaning away from this because it seems like a lot of work to get going.

-VPN: Theoretically simple and easy, but I’ve been told that their current VPN is flaky at best and that it shouldn’t be used.

-Port forwarding/ TLS/SSL: Probably the simplest to get going. My concern however is that the JNLP file will be accessible to everyone (since the authentication is made after launching the project). A colleague suggested crafting a custom launch page that authenticates user before giving the JNLP which sounds like it might be a nice idea, but I don’t know how without PHP.

-TS RemoteApp: New thing on Server 2008 that supposedly allows clients to run applications remotely. I haven’t seen or played with it enough to know if it is usable, but it’s an option at this point.

Does anyone have a favorite way of securely allowing remote access to FPMI? I think I’d like to go the SSL route if I could get some frontline authentication going, but I don’t really have enough info to make a decision yet.

Thanks,
Charles

FPMI is using a tomcat backend iirc.

edit: nm, tomcat doesn’t do htaccess like apache does apparently.

hmm, tomcat will do host/ip based allow/deny… Wonder if we have access to the config files to set that.

Well, tomcat runs java stuff, so it may be possible to do authentication through a servlet or something. I haven’t played with it yet but hopefully in the next couple days I’ll be able to whip something up or at least know it’s a dead end. I think I’d like to avoid discrimination based on ip/host info since I have no idea ahead of time where operators may wish to login from. I’ve played with the regular apache server but unfortunately I have no experience with tomcat (or servlets or JSP for that matter). When it comes to web programming I’m an html and php type of guy :stuck_out_tongue:

Thanks,
Charles

IMO, VPN is nearly always the way to go.

You can set up “https/SSL” only access to the Gateway, but I’m not sure if you can require authentication in order to view anything (home page and .JNLP file). Carl? Please elaborate on your hesitation there (beyond healthy paranoia). It might be a worthwhile feature request to have the option to tighten that up via the Gateway config page.

Is your current VPN endpoint/concentrator a hardware device or software?

I’ve had positive experiences with the Windows 2003 server VPN “server” (software), provided that you dedicate a NIC as your “WAN” link. The advantage there is that Windows machines already come with VPN client. It’s been easy to use and solid for me. The only “gotcha” is that you want to un-check “use default gateway on remote network” under the “advanced” TCP/IP properties of the client.

Alternatively, you can add a VPN device (like a Cisco ASA) and use that. The disadvantage is that you typically need to install a small VPN client program.

I don’t think remote/virtualized app setups make sense in this case since Java/JWS takes care of remote running. You don’t get any real security benefit from those.

VPN is always good assuming your VPN setup isn’t “flakey”

Port forwarding with SSL is also good. I’m not sure why you’re worried about unauthorized access to the JNLP… there is nothing sensitive in that file.

I would advise against the citrix/TS ideas - they add unnecessary complexity and overhead.

I’ve had good luck with LogMeIn Hamachi. Easy setup (zero config) and encrypted connections.

Thanks for the info and ideas guys. After some discussion I learned that putting the server on the internet was out of the question, so that kicks out the HTTPS/TLS option. Also the issue with the VPN is that they don’t want the users to have access to anything else on the server or the network, but I haven’t been told what VPN setup they have. The bottom line was that they want to have it work in Citrix, but if that is not possible then VPN was the fallback. I’ve contacted Citrix so we’ll see where that goes. I’d rather use VPN, but the customer gets what they want :wink:

  1. Is a port forward “putting the computer on the Internet”?
  2. You can use an ACL (access control list) to ensure that VPN users can only access the FactoryPMI host. A similar concept with a firewall can lock the connection down to a single port.

A Cisco ASA 5500 (10 user version) runs <$500 and will do all of that.

I dont understand the logic of not using HTTPS. You define one port to open to your clients. You can use port forwarding to change the external port. The client gets no internal network access like they could with a VPN.

If you want a good start on this, I use a sweet open sourced router call vyatta. Its an easy to use firewall, and it also uses snort for packet inspection and intrusion prevention. Let me knwo what you think.

Kyle - provided that the setup is configured reasonably, you’re right. Practically speaking, you’re right. Neither is “weak” unless you’re up against an NSA penetration team. The mechanics between establishing an SSL/TLS session and a VPN connection (IPSEC/PPTP) aren’t all that much different. From a “best practices” perspective, here’s why I recommend VPNs (compared to a pre-boxed SSL implementation):

  1. stronger keys and algorithms (the paranoid can crank this up)
  2. certificates or pre-shared keys (stronger integrity).
  3. less potential vulnerability injects - consider just a Cisco ASA versus your external router doing the port forwarding AND the web server - patching is crucial here
  4. ease of configuration - a novice admin is more likely to get the VPN setup “right”
  5. Denial of Service attacks - better to protect yourself at the perimeter than at your server
  6. who you can blame/trust, first it can be in IT (expert) hands instead of industrial control engineers (good thing when discussing networks).
    6a. Are you going to get fired when your “Cisco VPN concentrator” got hacked? No! What about your FactoryPMI box that you exposed from the 'net? It doesn’t carry that same reputation in non-technical terms.

We’re speaking in a highly theoretical context. FactoryPMI runs a tight, specialized version of Apache Tomcat that can be configured to require TLS for any communication, and isn’t listening to anything else.

More importantly, if you’re really paranoid, you can adopt a “defense in depth” strategy and implement one on top of the other.

[quote=“Kyle Chase”]I dont understand the logic of not using HTTPS. You define one port to open to your clients. You can use port forwarding to change the external port. The client gets no internal network access like they could with a VPN.

If you want a good start on this, I use a sweet open sourced router call vyatta. Its an easy to use firewall, and it also uses snort for packet inspection and intrusion prevention. Let me knwo what you think.[/quote]