Linux – Ports below 1024

linuxnetworkingpermissionsportroot

DISCLAIMER: I know how to run daemons that either listen on ports <1024 by using privbind or some iptables REDIRECT. Or more generally spoken, how to make daemons available on priviliged ports that usually don't run there.

The question itself is kind of a meta question.

QUESTION: Why on earth is it that ports <1024 are generally reserved to the root user. From a pragmatic point of view I'd love to be able to just tell a daemon under which port to lisen on and not have to care about root privileges. The more I think about it the more I come to the conclusion that specifically this kind of "security" is just historical bloat.

A sysctl along the lines of sysctl -w net.ipv[46].conf.port.80=www-data (something like that, I hope the idea is what comes trhough) would be what I'd really desire.

This way it would be possible to maintain the "current level of security" but still allow arbitrary users to listen on lower ports. Linux capabilities (CAP_NET_BIND_SERVICE) are a first step in the right direction – at least in my mind – but given that I'm used to ports <1024 being something special I hesitate dropping the restriction completely. I just can't see an objective reason why that is the case.

Someone please enlighten me 🙂

Note: Yes I read some of the similiar titles but I'm not quite satisfied with a "You shouldn't be doing it". Having to jump through hoops to get apache listen on port 80 where all it does is starting up with root and then dropping privileges is unnecessary (at least I think that). Why can't I just let it run as a normal user and do it's work. That way a privilege escalation bug wouldn't even allow for root privileges. All there is are privileges of www-data (or whatever the user on the distro of choice is)

Best Answer

As far as I know this is, indeed, mainly just an historical convention; the idea being that when accessing a port under 1024 you can be sure you're accessing whatever the administrator of the server configured to run on the server. This made more sense back when servers where few and huge and you needed an easy way to authenticate, or at least judge the reliability of a service, by such basic means.

By the way, you may find that Capabilities do what you want. See this SO question for more information on the alternatives, but here's the sample use:

setcap 'cap_net_bind_service=+ep' /path/to/program

1.

Strictly IPv4 speaking, is port exhaustion actually possible?

Yes. Take, for example, a load balancing router sending all connections to a NAT IP address. This is likely to happen when you have many SRC IPs connecting to the bottleneck of a single DST IP.

This means that your webserver could have a bunch of connections like:

root@buglab:~# netstat -pnt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 173.200.1.18:80      10.100.1.100:49923        ESTABLISHED 13939/nginx: worker
tcp        0      0 173.200.1.18:80      10.200.1.200:10155        ESTABLISHED 13939/nginx: worker
tcp        0      0 173.200.1.18:80      10.10.1.10:14400        ESTABLISHED 13939/nginx: worker
tcp        0      0 173.200.1.18:80      10.10.1.10:50652        ESTABLISHED 13939/nginx: worker
tcp        0      0 173.200.1.18:80      10.20.1.20:57554        ESTABLISHED 13939/nginx: worker

and that's perfectly fine. However, if all the 'Foreign Addresses' were the same, this can cause an issue (e.g. 'big router that performs NAT <---> server with one IP address').

If I had to postulate as to why ephemeral port exhaustion isn't a common issue, I'd suggest it's because every port requires a listening service and enough resources to respond -- another resource (memory, cpu) is normally a bottleneck first.

However, I've personally come across a few port exhaustion issues when working at a load balancing company.

2. Why can a used port present an issue for a listening service?

"Which allows the use of ephemeral ports from 1024-65535, that if I have services that bind on port 3306 (mySQL, for example), they will sometimes fail to start because the port is in use."

The mySQL server cannot bind to that port if it's in use - say by localhost:3306 or on all interfaces. For example, see the 0.0.0.0:80 line in the following netstat output?

root@buglab:~# netstat -lnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      PID/Program name
tcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTEN      964/php-fpm.conf)
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1660/mysqld     
tcp        0      0 0.0.0.0:842             0.0.0.0:*               LISTEN      1317/inetd      
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      13938/nginx

That means that port 80 is listening across all interfaces local to the server. If another process holds port 80 before my nginx server starts, nginx will not be able to take control of that port and will likely fail its startup procedure.

Normally, port 3306 is fine because listening services have pre-defined ports (or ranges) that are requested from the host machine - e.g. port 80 and 443 for webservers.

Best Answer

Related Solutions

Linux – Custom www-data user in Ubuntu

Linux networking port exhaustion

1.

2. Why can a used port present an issue for a listening service?

Related Topic