4 ms·

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 the

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
- devishard 10y ago
  > My point was correct to the specific attack you broadly described. But you didn't correct it, you proposed a solution that didn't address the attack I 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). The XSS attack is just an example of a vulnerability that wouldn't be addressed by hardening SSH. There are plenty of other vulnerabilities that wouldn't be addressed by hardening SSH. > 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). There's a good reason to demonstrate SSH access even if they have root access: they might want to show their capabilities without exposing how they gained those capabilities (because knowing how they gained those capabilities would allow the OP to fix the problem). > This is not a mistake, this is something I've done in practice when auditing security at work. Just because you've made mistakes in practice when auditing security at work doesn't mean they aren't mistakes. This isn't even time for a security audit. OP first really needs to do some forensics. A security audit should happen, but it can wait until the vulnerability has been found and fixed.
  - laumars 10y ago
    > The XSS attack is just an example of a vulnerability that wouldn't be addressed by hardening SSH. There are plenty of other vulnerabilities that wouldn't be addressed by hardening SSH. Well durr! We could be here all night listing things that SSH hardening wouldn't secure against. I never suggested it was a silver bullet to fix all security needs (which seems to be the faux argument you're accusing me off). I'm loving all the personal attacks too. You cannot compete on an intellectual level so you make baseless accusations about my professional capabilities instead. God bless Internet message boards....
    - devishard 10y ago
      > Well durr! We could be here all night listing things that SSH hardening wouldn't secure against. I never suggested it was a silver bullet to fix all security needs (which seems to be the faux argument you're accusing me off). That's not what I accused you of--people can read our previous discussion and see both what I actually accused you of saying, and also that you said what I accused you of saying. > You cannot compete on an intellectual level so you make baseless accusations about my professional capabilities instead. I did call your course of action a mistake, but that's not an attack on your professional capabilities. Everyone makes mistakes. I'm sure you're reasonably skilled at your job. I think you'd enjoy this conversation a lot more if you didn't take my disagreement with your strategy as a personal attack. But if that's what you want to do I can't stop you.

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

devishard 10y ago
> My point was correct to the specific attack you broadly described. But you didn't correct it, you proposed a solution that didn't address the attack I 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). The XSS attack is just an example of a vulnerability that wouldn't be addressed by hardening SSH. There are plenty of other vulnerabilities that wouldn't be addressed by hardening SSH. > 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). There's a good reason to demonstrate SSH access even if they have root access: they might want to show their capabilities without exposing how they gained those capabilities (because knowing how they gained those capabilities would allow the OP to fix the problem). > This is not a mistake, this is something I've done in practice when auditing security at work. Just because you've made mistakes in practice when auditing security at work doesn't mean they aren't mistakes. This isn't even time for a security audit. OP first really needs to do some forensics. A security audit should happen, but it can wait until the vulnerability has been found and fixed.
- laumars 10y ago
  > The XSS attack is just an example of a vulnerability that wouldn't be addressed by hardening SSH. There are plenty of other vulnerabilities that wouldn't be addressed by hardening SSH. Well durr! We could be here all night listing things that SSH hardening wouldn't secure against. I never suggested it was a silver bullet to fix all security needs (which seems to be the faux argument you're accusing me off). I'm loving all the personal attacks too. You cannot compete on an intellectual level so you make baseless accusations about my professional capabilities instead. God bless Internet message boards....
  - devishard 10y ago
    > Well durr! We could be here all night listing things that SSH hardening wouldn't secure against. I never suggested it was a silver bullet to fix all security needs (which seems to be the faux argument you're accusing me off). That's not what I accused you of--people can read our previous discussion and see both what I actually accused you of saying, and also that you said what I accused you of saying. > You cannot compete on an intellectual level so you make baseless accusations about my professional capabilities instead. I did call your course of action a mistake, but that's not an attack on your professional capabilities. Everyone makes mistakes. I'm sure you're reasonably skilled at your job. I think you'd enjoy this conversation a lot more if you didn't take my disagreement with your strategy as a personal attack. But if that's what you want to do I can't stop you.