News for hackers. Stuff that matters.
Re:Avoiding Complexity with Systemd by GuidoW on Sunday June 27, 2021 @12:36PM (#27652986)
Agreed.

One point is that processes other than root cannot start services on ports < 1024. That was a sensible precaution computers where big and multiuser, like in a university setting.

However, with single-serving services (e.g. in vm/container/vps/cloud), there is no need for it.

BSD lets you configure it with a sysctl option. But Linux defends that option like it is still 1990.

On NixOS, I patch it like this:

   boot.kernelPatches = [ { name = "no-reserved-ports";  patch = path/to/no-reserved-ports.patch; } ];
With the patch just as big:

  --- a/include/net/sock.h
  +++ b/include/net/sock.h
  @@ -1331,7 +1331,7 @@
  #define SOCK_DESTROY_TIME (10*HZ)

  /* Sockets 0-1023 can't be bound to unless you ares uperuser */
  -#define PROT_SOCK      1024
  +#define PROT_SOCK      24

  #define SHUTDOWN_MASK  3
  #define RCV_SHUTDOWN   1
Re:Avoiding Complexity with Systemd by forgotpwd16 on Sunday June 27, 2021 @12:53PM (#27653106)
Does it really change anything running something on port 90 rather port 1090?
Re:Avoiding Complexity with Systemd by e12e on Sunday June 27, 2021 @03:05PM (#27654267)
If you get unprpivileged access to a system, and somehow manage to crash sshd, or win a race to bind port 22 when sshd restarts, you can intercept other logins.

If you can bind port 80,you can gets ssl certs via let's encrypt (which could let you intercept not just web, but also smtp/imap etc).

So yes, it can make a difference. Of course - it's better if the user doesn't have access to begin with.

This might be more interesting for classical multi-user servers than "single use" servers that don't allow "regular" users to login via ssh.