26 ms·

I wouldn't really consider port knocking to be that effective of a way to block connections. It is really only obscure, but port knocking software is very acces

I wouldn't really consider port knocking to be that effective of a way to block connections. It is really only obscure, but port knocking software is very accessible. So if you know a port needs to be knocked, it's not hard for an attacker to get to it. The main benefit of port knocking is that it allows you to present your ports as normally closed. If you have a system and you are worried about it getting port scanned for whatever reason, it makes sense to have a scheme where the ports are closed unless it receives a knock. So if someone gets access they shouldn't for whatever reason and pulls a portscan off, the information they get about your system is somewhat limited. In this scheme, it would be much better to have an access point you authenticate with and then that handles the port knocking for the other devices. So it is a kind of obscure method that is really only useful in a specific use case. As far as SSH keys go, I would argue that SSH support is so ubiquitous, and SSH access is so powerful that it is a reasonable security tradeoff. I also don't think that SSH ports should be exposed to the internet, unless it is a specific use case where that is the whole point, like GitHub. I'm very down on connecting directly through SSH without network access. The xz situation has validated this opinion. I personally don't know any application where you really need supreme admin access to every device, from any device, from anywhere in the world, while at the same time it has extreme security requirements. That's a pretty big task. At that point, constructing a dedicated, hardened access point that faces the internet and grants access to other devices is probably the way to go.

delusional 3y ago
> I'm very down on connecting directly through SSH without network access. The xz situation has validated this opinion. Did it? At the point an attacker has remote code execution, couldn't they just as easily pivot into an outgoing connection to some command and control server? I don't see how some intermediary access point would have alleviated this problem. If the call is coming from inside the house, the gig is already up.
- deepbreath 3y ago
  > At the point an attacker has remote code execution The attacker doesn't have remote code execution in the xz case unless they can speak to your port 22. Port knocking prevents them from doing so, provided they don't know how to knock.
  - delusional 3y ago
    Assuming they have injected code into the sshd executable, couldn't that code just do the exploit without a connection? What I'm saying is that the structure of this payload is the way it is because sshd is accessible. Had it not been accessible, the payload just wouldn't have required an external connection.
    - GabeIsko 3y ago
      I mean, this is the twisting logic. xy hack put's a backdoor in sshd. You need to access sshd port to go through the back door and get RCE. Hacker could have put something even more nefarious that could phone home somewhere. We would like to think that would have been a little easier to spot, but who knows. To me, that is what makes this hack so noteworthy. Hacker got access, and then kept playing the long game. Very spooky. And yes, someone capable of this probably has a plan for gaining network access if they had a target in mind. Even with best security practice, this rabbit hole goes pretty deep.

delusional 3y ago

> I'm very down on connecting directly through SSH without network access. The xz situation has validated this opinion. Did it? At the point an attacker has remote code execution, couldn't they just as easily pivot into an outgoing connection to some command and control server? I don't see how some intermediary access point would have alleviated this problem. If the call is coming from inside the house, the gig is already up.

deepbreath 3y ago
> At the point an attacker has remote code execution The attacker doesn't have remote code execution in the xz case unless they can speak to your port 22. Port knocking prevents them from doing so, provided they don't know how to knock.
- delusional 3y ago
  Assuming they have injected code into the sshd executable, couldn't that code just do the exploit without a connection? What I'm saying is that the structure of this payload is the way it is because sshd is accessible. Had it not been accessible, the payload just wouldn't have required an external connection.
  - GabeIsko 3y ago
    I mean, this is the twisting logic. xy hack put's a backdoor in sshd. You need to access sshd port to go through the back door and get RCE. Hacker could have put something even more nefarious that could phone home somewhere. We would like to think that would have been a little easier to spot, but who knows. To me, that is what makes this hack so noteworthy. Hacker got access, and then kept playing the long game. Very spooky. And yes, someone capable of this probably has a plan for gaining network access if they had a target in mind. Even with best security practice, this rabbit hole goes pretty deep.