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?

Improve this question
2
  • 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
    Commented Jan 31, 2012 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
    Commented Jan 31, 2012 at 19:17

1 Answer 1

Reset to default
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.

Improve this answer
5
  • TeamViewer is only connected to the client, not server.
    – Lie Ryan
    Commented Jan 31, 2012 at 7: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
    Commented Jan 31, 2012 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
    Commented Jan 31, 2012 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
    Commented Feb 28, 2012 at 21:02
  • @this.josh, Why do you say that teamviewer is insecure? Another answer seems to state the opposite.
    – Pacerier
    Commented Feb 16, 2015 at 10:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .