5 ms·

> I mentioned firewalling sshd to a subset of trusted IPs - which would still secure you against the above attack. No, it doesn't secure you against the above

> I mentioned firewalling sshd to a subset of trusted IPs - which would still secure you against the above attack. No, it doesn't secure you against the above attack. If they can use an XSS to get full access to the server and get the SSH key, then hardening SSH does pretty much nothing, they just whitelist their IP and continue accessing the server. We don't know that they got SSH access via SSH. Until we understand how they gained access to the server, blocking off other means of access that might have nothing to do with how they gained access does nothing. > I also love how you can take genuinely helpful posts - after all, it's better to harden SSH regardless of whether this specific attack initially came directly from SSH - and somehow turn those contributions into something negative. God bless internet messageboards. Sure, hardening SSH is always a good idea, but until we actually understand how the SSH access was obtained, we don't know that it fixes the immediate problem. It absolutely is negative to give people information that persuades them their problem has been solved when it hasn't been solved. I don't see any reason for you to take my post personally. It's not an attack on you, it's just pointing out that we need more understanding of the problem to actually solve it. Don't shoot the messenger.

laumars 10y ago
> No, it doesn't secure you against the above attack. If they can use an XSS to get full access to the server and get the SSH key, then hardening SSH does pretty much nothing, they just whitelist their IP and continue accessing the server. Someone else suggested that and my reply was that if they already have access to remotely execute code as root then they can easily gain root shell access with much less effort than having to do the above workarounds to enable the systems default OpenSSH server (and there are plentiful other ways to execute remote shells without needing SSH) > Sure, hardening SSH is always a good idea, but until we actually understand how the SSH access was obtained, we don't know that it fixes the immediate problem. Since you agree that hardening SSH is a good idea, then it doesn't matter how the attacker gained access to SSH, you'd recommend they review the security of their SSH server regardless. So your latter statement becomes irrelevant to the former statement. > It absolutely is negative to give people information that persuades them their problem has been solved when it hasn't been solved. I never once suggested this would fix their problems. In fact my language was very clear that my advice would harden against SSH attacks, specifically. However they have asked for next steps and while other people have rightfully focused on the forensics side of the investigation, I have complimented their advice with tips on hardening SSH. One recommendation doesn't have to override another :) > I don't see any reason for you to take my post personally. It's not an attack on you, it's just pointing out that we need more understanding of the problem to actually solve it. Don't shoot the messenger. The server is compromised thus it's already too late to "solve". However that doesn't mean people cannot offer advice on hardening against potential future attacks on new or existing infrastructure in conjunction with analyzing the point of attack on the compromised (and hopefully now isolated) equipment. The snarky tone of my replies are because you have not offered tips that take precedence over my own recommendations, which if you had then I would have taken your criticisms seriously. But as it stands you're currently just disagreeing for the sake of disagreeing. Which is something I see far too often online and often just from people who want to seem knowledgeable but without imparting any actual knowledge and thus mitigate the risk of themselves looking stupid. Which is also why so many experienced individuals tire of contributing to public forums. You say my advice doesn't solve the OP issues, well neither do your posts. So what was the point in posting them? I just see it as an odd kind of cyclic logic.
- devishard 10y ago
  Okay sure. They can figure out how the attacker got access and fix that, AND harden SSH. They should also audit their logs, install updates, use a linter on their JavaScript, use version control, use a library to sanitize SQL inputs, force HTTPS, do code reviews, and 100 other good development practices that have nothing to do with the problem at hand. I'm glad we agree on that. Given that the OP doesn't know how to address their immediate problem, however, posting a bunch of random good practices is probably not very helpful. I contributed something constructive: I recommended figuring out what the vulnerability is and fixing that over fixing random things and hoping you fix the problem by chance. > I never once suggested this would fix their problems. In fact my language was very clear that my advice would harden against SSH attacks, specifically. However they have asked for next steps and while other people have rightfully focused on the forensics side of the investigation, I have complimented their advice with tips on hardening SSH. One recommendation doesn't have to override another :) You said, "I was one of the people offering advice on hardening SSH. I mentioned firewalling sshd to a subset of trusted IPs - which would still secure you against the above attack." If you want to claim you didn't say anything wrong and you were intending to suggest your solution in addition to the solution that actually solves the problem, that's your prerogative, but people can read the post history which shows that isn't true, so it would be more dignified to just admit you made a mistake. Nobody cares that you made a mistake--I'm not attacking you for that. I'm just trying to put up the correct information, since you didn't. It's not about you, so there's not much reason to take it personally, and you're not making yourself look good by claiming you didn't make mistakes that everyone can read.
  - deleted 10y ago
    [deleted]
  - laumars 10y ago
    My point was correct to the specific attack you broadly described. Your example required a web server attack that allowed arbitrary code execution and privladge elevation; which is a hugely specific attack and it's pretty fair to say it's unlikely (in the case of gaining root access and then choosing to enable SSH, which I'll get to). Furthermore, and at risk of sounding like a broken record, if an attacker can remotely execute code as root then they have absolutely no need to enable SSH for they already have far easier methods of firing off a remote shell. (To be honest they don't even need root to accomplish this). This is not a mistake, this is something I've done in practice when auditing security at work. (Preventative pen testing rather than post breach forensics such as this situation calls for. But as I said before, that doesn't mean you cannot take lessons from the former in conjunction with the latter. Anyhow, we really are just arguing about arguing now, which is an utterly pointless waste of both our time

laumars 10y ago

> No, it doesn't secure you against the above attack. If they can use an XSS to get full access to the server and get the SSH key, then hardening SSH does pretty much nothing, they just whitelist their IP and continue accessing the server. Someone else suggested that and my reply was that if they already have access to remotely execute code as root then they can easily gain root shell access with much less effort than having to do the above workarounds to enable the systems default OpenSSH server (and there are plentiful other ways to execute remote shells without needing SSH) > Sure, hardening SSH is always a good idea, but until we actually understand how the SSH access was obtained, we don't know that it fixes the immediate problem. Since you agree that hardening SSH is a good idea, then it doesn't matter how the attacker gained access to SSH, you'd recommend they review the security of their SSH server regardless. So your latter statement becomes irrelevant to the former statement. > It absolutely is negative to give people information that persuades them their problem has been solved when it hasn't been solved. I never once suggested this would fix their problems. In fact my language was very clear that my advice would harden against SSH attacks, specifically. However they have asked for next steps and while other people have rightfully focused on the forensics side of the investigation, I have complimented their advice with tips on hardening SSH. One recommendation doesn't have to override another :) > I don't see any reason for you to take my post personally. It's not an attack on you, it's just pointing out that we need more understanding of the problem to actually solve it. Don't shoot the messenger. The server is compromised thus it's already too late to "solve". However that doesn't mean people cannot offer advice on hardening against potential future attacks on new or existing infrastructure in conjunction with analyzing the point of attack on the compromised (and hopefully now isolated) equipment. The snarky tone of my replies are because you have not offered tips that take precedence over my own recommendations, which if you had then I would have taken your criticisms seriously. But as it stands you're currently just disagreeing for the sake of disagreeing. Which is something I see far too often online and often just from people who want to seem knowledgeable but without imparting any actual knowledge and thus mitigate the risk of themselves looking stupid. Which is also why so many experienced individuals tire of contributing to public forums. You say my advice doesn't solve the OP issues, well neither do your posts. So what was the point in posting them? I just see it as an odd kind of cyclic logic.

devishard 10y ago
Okay sure. They can figure out how the attacker got access and fix that, AND harden SSH. They should also audit their logs, install updates, use a linter on their JavaScript, use version control, use a library to sanitize SQL inputs, force HTTPS, do code reviews, and 100 other good development practices that have nothing to do with the problem at hand. I'm glad we agree on that. Given that the OP doesn't know how to address their immediate problem, however, posting a bunch of random good practices is probably not very helpful. I contributed something constructive: I recommended figuring out what the vulnerability is and fixing that over fixing random things and hoping you fix the problem by chance. > I never once suggested this would fix their problems. In fact my language was very clear that my advice would harden against SSH attacks, specifically. However they have asked for next steps and while other people have rightfully focused on the forensics side of the investigation, I have complimented their advice with tips on hardening SSH. One recommendation doesn't have to override another :) You said, "I was one of the people offering advice on hardening SSH. I mentioned firewalling sshd to a subset of trusted IPs - which would still secure you against the above attack." If you want to claim you didn't say anything wrong and you were intending to suggest your solution in addition to the solution that actually solves the problem, that's your prerogative, but people can read the post history which shows that isn't true, so it would be more dignified to just admit you made a mistake. Nobody cares that you made a mistake--I'm not attacking you for that. I'm just trying to put up the correct information, since you didn't. It's not about you, so there's not much reason to take it personally, and you're not making yourself look good by claiming you didn't make mistakes that everyone can read.
- deleted 10y ago
  [deleted]
- laumars 10y ago
  My point was correct to the specific attack you broadly described. Your example required a web server attack that allowed arbitrary code execution and privladge elevation; which is a hugely specific attack and it's pretty fair to say it's unlikely (in the case of gaining root access and then choosing to enable SSH, which I'll get to). Furthermore, and at risk of sounding like a broken record, if an attacker can remotely execute code as root then they have absolutely no need to enable SSH for they already have far easier methods of firing off a remote shell. (To be honest they don't even need root to accomplish this). This is not a mistake, this is something I've done in practice when auditing security at work. (Preventative pen testing rather than post breach forensics such as this situation calls for. But as I said before, that doesn't mean you cannot take lessons from the former in conjunction with the latter. Anyhow, we really are just arguing about arguing now, which is an utterly pointless waste of both our time