7 ms·

If you have random people spinning up daemons on your servers then you don't have an SSH problem.

djcapelis 13y ago
UNIX is built as a multi-user operating system. You may not use that ability very much, but there's a reason the operating system was built this way and there's a reason these things work the way they do. It is completely valid to point that out. You're free to say you don't care, but it isn't really valid to brush aside the point by pretending a security model that's there for a reason isn't there. Also it isn't uncommon at all for an attacker on a server to get access to a regular account and not a root account in their initial vector. It is often too easy to escalate, but do you really want to help them out more?
- fragsworth 13y ago
  In fairness, multi-user linux systems have been losing popularity for a long time, with KVM/xen-based VPS services taking over for having significant advantages in security and software compatibility. A young software engineer in today's environment can easily never have any exposure to a truly multi-user OS.
  - akl 13y ago
    I think you're misunderstanding - GNU/Linux is a multi-user OS regardless of if it is run in a kvm/xen/etc container or on bare metal. Even if only one person (or no persons) ever log in, the machine is capable of running processes under multiple users and it is best practice to maintain this so that all users do not share the same level of privilege.
    - cdcarter 13y ago
      Yes, but he's noting that a younger engineer may have never encountered a system with multiple users, so wouldn't think that being able to open a privileged port is more terrifying than being able to spin up netcat on 10032.
  - djcapelis 13y ago
    This is absolutely true. But unless people have started to also run their webapps and other daemons as root, the boundaries still cling to relevancy. But maybe I just miss computers where finger, write, wall and talk were all useful commands. And people say things are more social now? The growth of hypervisors made our operating systems desolate and lonely! :)
derefr 13y ago
The ability for someone to "spin up a daemon on your server" would also be called an unprivileged exploit. The ability to spin up a daemon on port 22 on your server, however, would be called a privilege-escalation exploit waiting to happen. If a zero-day gets discovered in the kernel that allows the former, you'll be hoping that it isn't also the latter. This is why trusting unprivileged ports is a bad idea. (...until, you know, we finally start using DNS service-records for this sort of thing.)
- GalacticDomin8r 13y ago
  > The ability for someone to "spin up a daemon on your server" would also be called an unprivileged exploit. No, that is very, very wrong. This is SOP for an account on a system nc -l 9000 <- spinning up a daemon on your server
  - derefr 13y ago
    Rather, the ability for someone who isn't considered to have an account on your server, to spin up a daemon on your server.
mb0 13y ago
Something as simple as an exploit against a php script could lead to unprivileged code execution & something as minimal as memory exhaustion could kill off your sshd process. If the sshd process is killed, and the attacker knows what port it was on (netstat -na | grep LISTEN), the attacker could spawn their own daemon on the unprivileged port that was previously being used for sshd, and that daemon could be used to collect plain-text passwords that people try to use when logging in. Heck, they could craft their daemon to log all keystrokes & which could grab the local root password.
- telephonetemp 13y ago
  This is a very valid point and a good reason to choose a port in the privileged range if you use an alternative port for SSH. I wonder, though, what is the worst it can do if you don't use password authentication? E.g., to offer you a fake shell and try to capture your sudo password a rogue daemon would have to have access to your public key, which as an unprivileged user it shouldn't.

UNIX is built as a multi-user operating system. You may not use that ability very much, but there's a reason the operating system was built this way and there's a reason these things work the way they do. It is completely valid to point that out. You're free to say you don't care, but it isn't really valid to brush aside the point by pretending a security model that's there for a reason isn't there. Also it isn't uncommon at all for an attacker on a server to get access to a regular account and not a root account in their initial vector. It is often too easy to escalate, but do you really want to help them out more?

fragsworth 13y ago
In fairness, multi-user linux systems have been losing popularity for a long time, with KVM/xen-based VPS services taking over for having significant advantages in security and software compatibility. A young software engineer in today's environment can easily never have any exposure to a truly multi-user OS.
- akl 13y ago
  I think you're misunderstanding - GNU/Linux is a multi-user OS regardless of if it is run in a kvm/xen/etc container or on bare metal. Even if only one person (or no persons) ever log in, the machine is capable of running processes under multiple users and it is best practice to maintain this so that all users do not share the same level of privilege.
  - cdcarter 13y ago
    Yes, but he's noting that a younger engineer may have never encountered a system with multiple users, so wouldn't think that being able to open a privileged port is more terrifying than being able to spin up netcat on 10032.
- djcapelis 13y ago
  This is absolutely true. But unless people have started to also run their webapps and other daemons as root, the boundaries still cling to relevancy. But maybe I just miss computers where finger, write, wall and talk were all useful commands. And people say things are more social now? The growth of hypervisors made our operating systems desolate and lonely! :)

derefr 13y ago

The ability for someone to "spin up a daemon on your server" would also be called an unprivileged exploit. The ability to spin up a daemon on port 22 on your server, however, would be called a privilege-escalation exploit waiting to happen. If a zero-day gets discovered in the kernel that allows the former, you'll be hoping that it isn't also the latter. This is why trusting unprivileged ports is a bad idea. (...until, you know, we finally start using DNS service-records for this sort of thing.)

GalacticDomin8r 13y ago
> The ability for someone to "spin up a daemon on your server" would also be called an unprivileged exploit. No, that is very, very wrong. This is SOP for an account on a system nc -l 9000 <- spinning up a daemon on your server
- derefr 13y ago
  Rather, the ability for someone who isn't considered to have an account on your server, to spin up a daemon on your server.

mb0 13y ago

Something as simple as an exploit against a php script could lead to unprivileged code execution & something as minimal as memory exhaustion could kill off your sshd process. If the sshd process is killed, and the attacker knows what port it was on (netstat -na | grep LISTEN), the attacker could spawn their own daemon on the unprivileged port that was previously being used for sshd, and that daemon could be used to collect plain-text passwords that people try to use when logging in. Heck, they could craft their daemon to log all keystrokes & which could grab the local root password.

telephonetemp 13y ago
This is a very valid point and a good reason to choose a port in the privileged range if you use an alternative port for SSH. I wonder, though, what is the worst it can do if you don't use password authentication? E.g., to offer you a fake shell and try to capture your sudo password a rogue daemon would have to have access to your public key, which as an unprivileged user it shouldn't.