Was ist a privileged port on a Mac / Darwin?

Hinweis: Dieser Artikel wurde ursprünglich veröffentlicht in 2014 and has been updated with modern macOS approaches. Überprüfen Sie die aktuelle Dokumentation von Apple für die neuesten Informationen.

If you have ever tried to start a web server, SSH tunnel, or any network service on a port below 1024 on your Mac, you have likely encountered the “Permission denied” or “Privileged ports can only be forwarded by root” error. This restriction is fundamental to how Unix-based operating systems (including macOS/Darwin) handle network security. This guide explains why the restriction exists, what privileged ports are, and provides every practical solution for working with them on macOS.

What Are Privileged Ports?

In the TCP/IP networking model, port numbers range from 0 to 65535. These are divided into three ranges:

Range	Name	Description
0 - 1023	Well-known (privileged) ports	Reserved for system services. Binding requires root privileges.
1024 - 49151	Registered ports	Assigned by IANA for specific applications. Any user can bind.
49152 - 65535	Dynamic/ephemeral ports	Used for temporary client-side connections. Any user can bind.

The well-known ports (0-1023) are called “privileged” because only the root user (UID 0) or processes with the appropriate privileges can bind a socket to them. This is a security mechanism inherited from the original BSD Unix networking implementation.

Common Well-Known Ports

Port	Service	Protocol
22	SSH	TCP
25	SMTP	TCP
53	DNS	TCP/UDP
80	HTTP	TCP
110	POP3	TCP
143	IMAP	TCP
443	HTTPS	TCP
993	IMAPS	TCP

Why Does This Restriction Exist?

The privileged port restriction serves a specific security purpose: it prevents unprivileged users on a multi-user system from impersonating system services.

Consider a scenario without this restriction: a regular user could start a process listening on port 22 (SSH). When other users or remote systems attempt to connect via SSH, they would connect to the malicious process instead of the real SSH daemon. The attacker could then capture credentials or perform man-in-the-middle attacks.

By restricting ports below 1024 to root, the operating system ensures that only the system administrator can run services on these well-known ports. Clients connecting to a well-known port have a reasonable assurance that they are communicating with a legitimate service.

The Error in Practice

When you encounter this restriction on macOS, the error messages vary depending on the context:

SSH tunnel forwarding:

Privileged ports can only be forwarded by root.

Python/Node.js/other server:

OSError: [Errno 13] Permission denied
Error: listen EACCES: permission denied 0.0.0.0:80

Go program:

listen tcp :443: bind: permission denied

Lösung 1: Use a Port Above 1024 (Simplest)

The most straightforward solution is to avoid privileged ports entirely. Run your service on a high port:

# Instead of port 80, use port 8080
python3 -m http.server 8080

# Instead of port 443, use port 8443
node server.js --port 8443

# SSH tunnel on a high port
ssh -L 8080:remote-server:80 user@jump-host

For development environments, this is almost always the best approach. Modern web browsers, API clients, and tools handle non-standard ports without issues. Simply append the port to the URL:

http://localhost:8080
https://localhost:8443

Lösung 2: Port Forwarding with pfctl

macOS includes pf (Packet Filter), a powerful firewall originally from OpenBSD. You can use it to redirect traffic from a privileged port to a high port where your application listens. This way, your application runs as a regular user while clients connect on the standard port.

Redirect Port 80 to 8080

Create a pf anchor file:

# Create the port forwarding rules file
sudo nano /etc/pf.anchors/com.myapp.forwarding

Add the following rules:

# Redirect port 80 to 8080 on the loopback interface
rdr pass on lo0 inet proto tcp from any to any port 80 -> 127.0.0.1 port 8080

# Redirect port 80 to 8080 on all network interfaces
rdr pass on en0 inet proto tcp from any to any port 80 -> 127.0.0.1 port 8080

Load the anchor into the pf configuration. Edit /etc/pf.conf:

sudo nano /etc/pf.conf

Add these lines after the existing content:

# Load custom port forwarding rules
rdr-anchor "com.myapp.forwarding"
load anchor "com.myapp.forwarding" from "/etc/pf.anchors/com.myapp.forwarding"

Enable and reload pf:

# Enable the packet filter
sudo pfctl -e

# Load the updated configuration
sudo pfctl -f /etc/pf.conf

# Verify the rules are loaded
sudo pfctl -s nat

Now start your application on port 8080, and connections to port 80 will be transparently forwarded.

Redirect Both 80 and 443

For a web server that needs both HTTP and HTTPS:

rdr pass on lo0 inet proto tcp from any to any port 80 -> 127.0.0.1 port 8080
rdr pass on lo0 inet proto tcp from any to any port 443 -> 127.0.0.1 port 8443
rdr pass on en0 inet proto tcp from any to any port 80 -> 127.0.0.1 port 8080
rdr pass on en0 inet proto tcp from any to any port 443 -> 127.0.0.1 port 8443

Removing the Redirect

To remove the port forwarding:

# Disable pf entirely (if nothing else uses it)
sudo pfctl -d

# Or flush the nat/redirect rules
sudo pfctl -F nat

Lösung 3: launchd Socket Activation

macOS’s launchd system can listen on a privileged port and pass the socket to your application. This is the Apple-recommended way to run services on low ports. The launchd process runs as root, handles the port binding, and then hands the file descriptor to your process which runs as a regular user.

Create a launchd plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.myapp.webserver</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/local/bin/myapp</string>
        <string>--use-launchd-socket</string>
    </array>
    <key>UserName</key>
    <string>myuser</string>
    <key>Sockets</key>
    <dict>
        <key>Listeners</key>
        <dict>
            <key>SockServiceName</key>
            <string>http</string>
            <key>SockType</key>
            <string>stream</string>
            <key>SockFamily</key>
            <string>IPv4</string>
        </dict>
    </dict>
    <key>inetdCompatibility</key>
    <dict>
        <key>Wait</key>
        <false/>
    </dict>
</dict>
</plist>

Save this file as /Library/LaunchDaemons/com.myapp.webserver.plist and load it:

sudo launchctl load /Library/LaunchDaemons/com.myapp.webserver.plist

Your application must be written to accept the socket file descriptor from launchd. In most languages, this means using the launch_activate_socket API or reading the file descriptor from the LAUNCH_DAEMON_SOCKET_NAME environment variable.

Lösung 4: Running with sudo (Use with Caution)

You can use sudo to run your application as root, which grants permission to bind to any port:

sudo python3 -m http.server 80
sudo node server.js --port 443

This approach is generally not recommended for several reasons:

1. Sicherheit risk — your application runs with full root privileges. Any vulnerability in the application (or its dependencies) can be exploited to gain root access to the system.
2. File ownership — files created by the application will be owned by root, potentially causing permission issues later.
3. Development friction — requires entering your password for each restart during development.

If you must use this approach, some applications support privilege dropping: they bind to the privileged port as root, then switch to a non-privileged user for normal operation. Nginx and Apache both do this — they start as root, bind to ports 80 and 443, and then fork worker processes running as www or nobody.

Lösung 5: SSH Tunnel with sudo

For the specific case of SSH tunnel port forwarding (the original scenario in this article), you need to use sudo to forward a local privileged port:

# This fails for ports below 1024:
ssh -L 80:internal-server:80 user@jump-host

# This works:
sudo ssh -L 80:internal-server:80 user@jump-host

# Better approach -- forward to a high port instead:
ssh -L 8080:internal-server:80 user@jump-host

The better approach is almost always to use a high local port. The remote port (the one on internal-server) can be any port regardless of your local privileges.

macOS vs Linux: Key Differences

Linux and macOS handle this restriction differently:

Feature	macOS (Darwin)	Linux
Privileged port threshold	1024 (fixed)	Configurable via net.ipv4.ip_unprivileged_port_start (since kernel 4.11)
Capability-based access	Not supported	CAP_NET_BIND_SERVICE capability allows non-root binding
Port forwarding tool	pfctl (pf)	iptables / nftables
Socket activation	launchd	systemd

On Linux, you can grant a specific binary the ability to bind to privileged ports without running as root:

# Linux only -- does NOT work on macOS
sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/myapp

macOS does not support POSIX capabilities, so this approach is not available. The pfctl and launchd solutions described above are the macOS equivalents.

Quick Reference

Scenario	Recommended Lösung
Local development	Use a port above 1024
Production web server on Mac	pfctl port forwarding
System service on macOS	launchd socket activation
SSH tunnel local forwarding	Use a high local port
One-off quick test	sudo (with awareness of risks)

Verwandte Artikel

• How to: Clear or Flush DNS cache on a Mac OS X computer
• How to: Clear the history on your Mac’s terminal (command prompt)
• How to: Print a screenshot on a Mac
• How to: Run a command with elevated admin credentials on a Mac