5 ms·
I didn't see any explanation why it was so important his server run on port 80. Allowing any user level process to listen on any of the common ports will resul
by gmiller123456 4y ago
I didn't see any explanation why it was so important his server run on port 80.
Allowing any user level process to listen on any of the common ports will result in security holes. E.g. A process could constantly attempt to bind to port 22 (SSH). If the SSH process dies or is restarted for any reason, the user level process can harvest usernames and passwords.
- philsnow 4y ago> If the SSH process dies or is restarted for any reason, the user level process can harvest usernames and passwords. That wouldn't work because the user level process wouldn't have read access to the machine's host keys in /etc/ssh/*_key, so when things connect, they would get known_hosts warnings and nobody clicks through those
- kevincox 4y agoIt is still a DoS attack. And of course SSH is usually TOFU so that isn't a strong defense. Imagine this at a company network. 1. The attacker compromises an application process on one machine and manages to get code execution. 2. They wait for SSH to restart (updates, trigger a crash, OOM?) then bind port 22. 3. Wait for some developer to connect to this machine for the first time. They (unexpectedly) see a new host key so accept it. Now if that developer has forwarding enabled you can log into other machines (probably with root/sudo access). You have just escalated your privileges from a non-root user on one machine to the entire network.
- Dwedit 4y agoNot related, but I've seen some restrictive firewalls that block outgoing connections to most ports. But it did allow connections to http or https.