3 ms·

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.