5 ms·

Do you think there's any benefit in reduced log noise making a serious attacker more obvious to SoC analysts? I.e. if I run SSH on 24956/TCP and start seeing a

Do you think there's any benefit in reduced log noise making a serious attacker more obvious to SoC analysts? I.e. if I run SSH on 24956/TCP and start seeing attacks, it's a fair bet this is targeted (someone has taken the time to do 65K port scans, not common for untargeted attackers), so it's a stronger signal for the blue team to look at that activity more closely than the noise on 22/TCP.

akerl_ 9y ago
It’s worth noting that running sshd above port 1024 on most systems adds the risk that non-root users can bind their own process to its port if they can crash it or wait for it to crash, and if you break into the ephemeral range, you’re risking non malicious conflicts as well.
- raesene6 9y ago
  malicious local user is a slightly different threat model though with a number of other possible controls.
  - akerl_ 9y ago
    There are a number of controls available for pretty much every threat model, so I’m not sure what you’re claiming about my point that using an non-privileged port adds risk to the system that would need to be accepted or dealt with.
    - raesene6 9y ago
      So to elaborate. Many Internet facing systems are application servers (e.g. web servers). They typically have very few local users, administrative/Ops staff are the primary users. At that point an attack requiring the ability to execute arbitary code on the host as a local user is possibly less relavant as, if an attacker is in that position, they likely have a number of other options to further their goals. The reason I made the comment about alternate controls, is that the original discussion and point I was making revolved around Internet focused attackers, rather than local attackers, so it's not too surprising that I didn't try to cover that case :) No sinister intent, honest! Heck however if we want to then lets theorize that I can just use some form of firewall to port forward the high port that's presented externally to 22/TCP internally to get the best of both worlds, both a less visible external service and an internal port that requires root to bind.
      - akerl_ 9y ago
        Gotcha. All valid points, and I’m a big fan of firewall-based port rerouting like you describe. I agree that an attacker who gets code exec on an app server is in a pretty fun spot already, and has a lot of different paths to escalate/persist/etc that don’t involve misuse of your ssh daemons port.
- tedunangst 9y ago
  Run sshd on port 22, use pf to redirect a high port down.

akerl_ 9y ago

It’s worth noting that running sshd above port 1024 on most systems adds the risk that non-root users can bind their own process to its port if they can crash it or wait for it to crash, and if you break into the ephemeral range, you’re risking non malicious conflicts as well.

raesene6 9y ago
malicious local user is a slightly different threat model though with a number of other possible controls.
- akerl_ 9y ago
  There are a number of controls available for pretty much every threat model, so I’m not sure what you’re claiming about my point that using an non-privileged port adds risk to the system that would need to be accepted or dealt with.
  - raesene6 9y ago
    So to elaborate. Many Internet facing systems are application servers (e.g. web servers). They typically have very few local users, administrative/Ops staff are the primary users. At that point an attack requiring the ability to execute arbitary code on the host as a local user is possibly less relavant as, if an attacker is in that position, they likely have a number of other options to further their goals. The reason I made the comment about alternate controls, is that the original discussion and point I was making revolved around Internet focused attackers, rather than local attackers, so it's not too surprising that I didn't try to cover that case :) No sinister intent, honest! Heck however if we want to then lets theorize that I can just use some form of firewall to port forward the high port that's presented externally to 22/TCP internally to get the best of both worlds, both a less visible external service and an internal port that requires root to bind.
    - akerl_ 9y ago
      Gotcha. All valid points, and I’m a big fan of firewall-based port rerouting like you describe. I agree that an attacker who gets code exec on an app server is in a pretty fun spot already, and has a lot of different paths to escalate/persist/etc that don’t involve misuse of your ssh daemons port.
tedunangst 9y ago
Run sshd on port 22, use pf to redirect a high port down.