11

I know one systems administrator who runs SSH Server on his workstation to push files to it and check things from a phone but I think it is a bad idea for several reasons:

  • An operations workstation is a sweet spot for the adversary. Once she is in, she won't find a better place to get access to other places.
  • If you get hacked anywhere then you don't know which other systems got affected - you have to check everything. How do you check? Maybe walk over to the server room with a Live CD. Maybe your data center is too large. Analyze logs, recent snapshots, start logging in to places. But very likely, at some point your workstation will be involved.

Lets only assume that there is nothing stopping the systems admin from performing all remote management tasks from the workstation. The admin would need to type in passwords and/or use certificates that are stored on the workstation. No two-factor authentication is being used.

What is the risk in running an sshd on an operations workstation?

(Shouldn't that workstation have a no-incoming-connections firewall?)

Billy ONeal
  • 2,688
  • 4
  • 15
  • 15
Aleksandr Levchuk
  • 221
  • 1
  • 5
  • 1
    Please explain the capabilites of the operations workstation. – this.josh Jul 14 '11 at 05:20
  • @this.josh, lets only assume that there is nothing stopping the systems admin from performing all remote management tasks from the workstation. The admin would need to type in passwords and/or use certificates that are stored on the workstation. No two-factor authentication is being used. – Aleksandr Levchuk Jul 14 '11 at 06:47
  • 2
    Holy &^%&^! Disconnect that machine from the network immediatly! Are you saying a machine with complete network control capabilites is accessible directly from the internet? – this.josh Jul 14 '11 at 07:28
  • 6
    @Aleksandr: Rory's answer states quite clearly why a SSH server on a workstation is worrying. But I want to add that if the sysadmin runs a SSH server on his workstation, this is probably because it allows some functionality which he could not obtain through more "normal" tunnels. So I daresay that closing that sshd is not enough; you should also try to see how to make said functionality available in a more controlled way. – Thomas Pornin Jul 14 '11 at 12:30

3 Answers3

11

Very frightening! As a risk, this should be raised to the board - effectively an attacker on the internet only needs to find out that username and password (or an SSH 0-day) and your entire corporate network should be considered compromised. Could the business run without it? Is there anything sensitive on it?

This is a bad idea in so many ways:

It bypasses perimeter controls

  • It may be impossible to monitor the activities of this administrator - from a governance perspective this is not good. If the company is in a regulated industry this may breach rules. You should build systems so you don't have to trust people 100% - this would help persuade folks not to try something malicious, as they will get caught.
  • Prevention of attack from outside the perimeter relies entirely on the configuration of that SSH server, as opposed to a defence in depth scenario with firewalls and IDS

It is a key target

  • A system administrator's workstation can be the crown jewels for an attacker - these should be protected accordingly. If an attacker can get access to it, escalating to the rest of the network is likely to be much easier

It is unnecessary

Large organisations already have a range of options open to them for this sort of functionality. Usually it comes down to access through the normal Remote Access Solution under their domain account to a 'stepping stone' machine inside the network which has an SSH client, then a logon to the admin workstation, then an 'su' equivalent to raise privileges if necessary.

Each step can then have strong controls and logging enforced - a little bit more annoying for the admin (an extra couple of minutes to log in) but much more difficult for an attacker to get through unnoticed.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
  • 2
    I mostly disagree. Perimeter security still applies. Most networks only allow inbound ssh to specific (non-workstation) gateway systems. Key target? Yes maybe, but the - *by far* - most vulnerabilities are in your browser and mail client, not in your ssh server. Unnecessary? I use it quite often. – pepe Jul 14 '11 at 22:59
  • Its not only about stepping stones, ssh is very flexible and allows to bundle services like file transfer, status feeds or imap into a single service that is relatively secure compared to setting up additional cgi/php stuff. Who says that this workstation does not have any secure auditing running? I am also not convinced that a compromised server is much more confined than that compromised workstation. Think X11 forwarding. I think there was also something on printing control chars interpreted by the terminal.. – pepe Jul 14 '11 at 23:21
  • +1 A stepping stone is a better solution but SSHD-on-a workstation is unnecessary in a more fundamental sense. The workstations only purposes should be to let a human sit down in front of it and connect out. Everything else can be done on a server which has very limited/server-specific capabilities (e.g. push files to the server and then pull them once you are physically at the workstation; use dedicated VMs on the server for tasks such as monitoring). Please consider editing and fortifying the **It is unnecessary** section. – Aleksandr Levchuk Jul 16 '11 at 23:14
  • I haven't seen enough context, nor seen anyone address Thomas' question about how to replace the presumed functionality of the ssh server. Perhaps because I'm puzzled by your description of the "usual" option involving RAS, domain accounts and stepping stone machines. It sounds like you are also describing ssh access to the workstation, which requires a server to be running there - right? And who says RAS or domain accounts are more secure than ssh - I'd say it is the other way around. – nealmcb Jul 17 '11 at 05:10
  • @nealmcb - the issue is around the SSH server being exposed externally. Maybe I didn't articulate it well. The stepping stone idea is that you still need to pass perimeter controls on remote access. Then priv users can use a specific stepping stone (that only they get access to) to then SSH to their workstation. – Rory Alsop Jul 17 '11 at 10:21
  • 2
    The original question is about running an ssh server, and doesn't say it is connected to the Internet. For the latter, restricting access to be thru stepping stones makes sense. But that can be done via ssh proxies without introducing other protocols that involve GUIs and the magnified risks associated with that. – nealmcb Jul 17 '11 at 13:24
  • 1
    @nealmcb - y'know - in re-reading it, you are right. I read it far more as the risk from outside. Which does mean that although my points are valid generally, that first one may not apply here at all. – Rory Alsop Jul 17 '11 at 13:41
  • @nealmcb, @Rory, I'm not sure your original reading was wrong: he *does* `check things from a phone`... Now, while there might be ways to do this, not via Internet, I think it's highly likely that it is the case after all. 'Course, the OP would know better.... – AviD Jul 17 '11 at 22:02
  • 1
    @avid Yes, you can argue that. But when I log in to my internal machines on my tiny network from my phone, I do it via an ssh proxy, and it would actually surprise me to hear that the workstation had an ssh port open on a routeable IP address, if they are in a big enterprise. At any rate I'd love clarifications from @Aleksandr, but for now the thrust of the question is just about running a server, and it would make sense anyway to separate out those two issues. – nealmcb Jul 18 '11 at 02:38
8

It all comes down to the threat model. It depends on the risks and the likelihood of an attack. It depends on what the workstation does. It depends on the clients involved.

How is this any different from running SSH on an actual server? If the service account doesn't have permissions to do much then the attack can't get very far. If the service account is running with high privileges, then it really doesn't matter if it's running on a workstation or a server. If the client is just his phone then there is a less of a risk of the credentials getting compromised than say having hundreds of people connecting to it. If the SSH server is designed to only accept connections from a particular IP then that reduces the risk even further.

If the workstation has permissions to manage systems then it's probably not a good thing to run an SSH server on it for some of the reasons you mentioned. Better yet, it shouldn't have any connection to the outside world. If it's a non-admin workstation then the worst that could be breached is whatever it has admin access to -- very little if anything.

Mark Davidson
  • 9,367
  • 6
  • 43
  • 61
Steve
  • 15,155
  • 3
  • 37
  • 66
  • The difference in this case would be that passwords are not typed and not stored in any way on the servers (only on the dedicated authentication servers). On the workstation the admin types a lot of different interesting things as he or she manages the data center. – Aleksandr Levchuk Jul 14 '11 at 03:46
  • 3
    Sounds like a perfect time to generalize your security standards to include workstations, institute desktop management, and figure out a remote access policy. – Scott Pack Jul 14 '11 at 04:01
6

On one hand, it increases the attack surface, on the other it increases manageability. So, it could be a net positive for the risk profile if that's what's being used to manage systems and apply updates.

In this particular case, it's just for convenience, and it's on a high risk target. The questions here need to be:

  • Is the risk worth it for the convenience gained?
  • Can business need be demonstrated?
  • Can the risk be mitigated in part by access restrictions, least privilege, etc?
  • Can the risk be mitigated in part for essentially the same convenience with another machine or even a virtual machine?
  • Can the risk be mitigated in part by a VPN solution?
  • After applying all reasonable mitigation steps, does the benefit outweigh the risk?
Stephanie
  • 543
  • 3
  • 10