7

I'm deploying a web-based ERP system for a customer, such that both the server and the client machines will be inside the customer's intranet. I was advised not to allow the server machine to connect to the internet, but the clients won't have this restriction. However, I need access to both to provide support, so I'm planning to use TeamViewer to access the client (to assist users directly upon request) and SSH from the client machine to the server machine (to perform updates, for instance).

[my machine] ---TeamViewer---> [customer's client] ---SSH---> [customer's server]

My question is: is this setup as bad as just accessing the server directly through SSH? I see some advantages in the indirect connection (it will only be accessible when a customer's employee opens TeamViewer, he'll be sitting there seeing everything that happens and can even type the passwords for me, so they don't get transmitted through the internet ever), but I wonder if there are drawbacks I can't foresee.

If both approaches are equally (in)secure, I'll just allow direct SSH to the server, since it's simpler. And if, for any reason, this indirect setup makes everything less secure, I can go a step further and advise the customer to block SSH access from the machine(s) where TeamViewer is installed.

Update: seeing the answers/comments below, I think I need to clarify myself a bit. My goal here is to make the server more secure than the clients. The exact setup is my customer's responsibility, not mine, but since I'm deploying my product in their network - and I need to remotely access it to provide maintenance - I have to advise them in the pros and cons of each configuration. They worry that an internet-facing server will be more vulnerable than one only (directly) accessible from their internal network, but I suspected (and the feedback below confirms it) that it's not always the case.

I can't properly secure the clients, they will be running a variety of programs outside my control - including a mandatory remote desktop, TeamViewer or other - so the "natural" choice would be disallow SSH connections between clients and server. OTOH, a compromised client does not automatically give access to the server, since you'd still need to authenticate to it (for instance, using key authentication and storing the key offline, in a USB flash drive). But I agree it's not a good idea.

Another option would be setting up a very secure client and using it as a proxy to the server (disallowing everyone else). However, my original question pops up again: isn't it pointless to do so, instead of just having an internet-facing server?

mgibsonbr
  • 2,905
  • 2
  • 20
  • 35
  • 2
    setup a firewall to refuse all connections except for ssh connections from designated machines (and of course don't run ssh on the standard port). With your current setup, the customer's client computer becomes the "firewall" for the server; it's not a very good idea if the "firewall" is not more secure than the computer it's protecting. – Lie Ryan Jan 31 '12 at 15:39
  • @LieRyan yeah, that's exacly my point, and my doubt: does having another machine serve as a "proxy" to the server increases/decreases its security? See my update for more info. – mgibsonbr Jan 31 '12 at 19:17

1 Answers1

5

If the the customer's client is security critical do not setup TeamView to connect to it. If breaching the customer's intranet puts the eclient's server at greater risk, then do not user TeamView.

A cursory reading shows that TeamView can use UPnP (Universal Plug and Play).

There are *29 CVE*s (Common Vulnerabilities and Exposures listed for uPnP!

If you do not know exactly how the authentication and routing of a product works, do not use it for security critical activities or infrastructure.

Anything that is more complex has the risk of having more bugs, issues, and vulnerabilities. So when you mentioned that ssh was simpler you had the right idea.

If you are using ssh to access security critical infrastructure please use key authentication instead of password authentication.

this.josh
  • 8,843
  • 2
  • 29
  • 51
  • TeamViewer is only connected to the client, not server. – Lie Ryan Jan 31 '12 at 07:01
  • 1
    @LieRyan: ...and the client is connected to the server. Break into TeamViewer, and you control the client, which gives you access to the server. – tdammers Jan 31 '12 at 12:34
  • Ok, I'm convinced that TeamViewer (or other remote desktops, for that matter) might not offer proper security, and I found your other tips very useful. But my doubt remains (see the update), although I'm already favouring a simpler setup. – mgibsonbr Jan 31 '12 at 19:29
  • 3
    Sorry but I've got to say that that bit of the answer on uPNP feels a bit like FUD to me. Just saying that "x" can use "y", "y" has security problems, therefore "x" is insecure doesn't follow. TeamViewer *can* use uPNP but it can also be disabled. Also uPNP is very unlikely to be enabled on any corporate firewall (and if it is you've got much bigger problems than Remote Control Software). – Rory McCune Feb 28 '12 at 21:02
  • @this.josh, Why do you say that teamviewer is insecure? [Another answer](http://security.stackexchange.com/a/12246/2379) seems to state the opposite. – Pacerier Feb 16 '15 at 10:54