对我的开发框有这个限制是非常烦人的，因为除了我之外永远不会有任何用户。
我知道标准的解决方法，但没有一个完全符合我的要求：
是否有一些简单sysctl的变量允许非 root 进程绑定到 Linux 上的“特权”端口（端口小于 1024），或者我只是运气不好？
编辑：在某些情况下，您可以使用功能来执行此操作。
好的，感谢指出能力系统和CAP_NET_BIND_SERVICE能力的人。如果你有一个最近的内核，确实可以使用它来以非 root 身份启动服务，但绑定低端口。简短的回答是你这样做：
setcap 'cap_net_bind_service=+ep' /path/to/program
然后任何时候program执行，之后它就会有CAP_NET_BIND_SERVICE能力。setcap在 debian 包libcap2-bin中。
现在注意事项：
program具有提升权限（如setcap或suid. 因此，如果您program使用它自己的.../lib/，您可能需要考虑其他选项，例如端口转发。资源：
setcap.您可以进行端口重定向。这就是我为在 Linux 机器上运行的 Silverlight 策略服务器所做的
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 943 -j REDIRECT --to-port 1300
标准的方法是让它们成为“setuid”，以便它们以 root 身份启动，然后在它们绑定到端口但开始接受到它的连接之前丢弃该 root 特权。您可以在 Apache 和 INN 的源代码中看到很好的示例。我听说 Lighttpd 是另一个很好的例子。
另一个例子是 Postfix，它使用多个通过管道进行通信的守护进程，其中只有一个或两个（除了接受或发出字节之外几乎不做任何事情）以 root 身份运行，其余的以较低权限运行。
2017 年更新：
安装：apt-get install authbind
为所有用户和组配置对相关端口的访问，例如 80 和 443：
sudo touch /etc/authbind/byport/80
sudo touch /etc/authbind/byport/443
sudo chmod 777 /etc/authbind/byport/80
sudo chmod 777 /etc/authbind/byport/443
authbind
通过（可选地指定--deep或其他参数，请参阅手册页）执行您的命令：
authbind --deep /path/to/binary command line args
e.g.
authbind --deep java -jar SomeServer.jar
作为 Joshua 关于破解内核的绝妙（=除非您知道自己在做什么，否则不推荐）建议的后续行动：
我先把它贴在这里。
简单的。使用普通或旧内核，您不需要。
正如其他人指出的那样，iptables 可以转发端口。
正如其他人所指出的， CAP_NET_BIND_SERVICE 也可以完成这项工作。
当然，如果您从脚本启动程序，CAP_NET_BIND_SERVICE 将失败，除非您在 shell 解释器上设置上限，这是没有意义的，您也可以以 root 身份运行您的服务......
例如对于 Java，您必须应用它到 JAVA JVM
sudo /sbin/setcap 'cap_net_bind_service=ep' /usr/lib/jvm/java-8-openjdk/jre/bin/java
显然，这意味着任何 Java 程序都可以绑定系统端口。
用于单声道/.NET 的 Dito。
我也很确定 xinetd 不是最好的想法。
但是既然这两种方法都是hack，为什么不通过解除限制来解除限制呢？
没有人说你必须运行一个普通的内核，所以你可以运行你自己的。
您只需下载最新内核（或您当前拥有的内核）的源代码。之后，你去：
/usr/src/linux-<version_number>/include/net/sock.h:
你在那里寻找这条线
/* Sockets 0-1023 can't be bound to unless you are superuser */
#define PROT_SOCK 1024
并将其更改为
#define PROT_SOCK 0
如果您不想遇到不安全的 ssh 情况，请将其更改为：#define PROT_SOCK 24
通常，我会使用您需要的最低设置，例如 79 用于 http，或 24 在端口 25 上使用 SMTP 时。
这已经是全部了。
编译内核并安装它。
重启。
完成了——那个愚蠢的限制已经消失了，这也适用于脚本。
以下是编译内核的方法：
https://help.ubuntu.com/community/Kernel/Compile
# You can get the kernel-source via package linux-source, no manual download required
apt-get install linux-source fakeroot
mkdir ~/src
cd ~/src
tar xjvf /usr/src/linux-source-<version>.tar.bz2
cd linux-source-<version>
# Apply the changes to PROT_SOCK define in /include/net/sock.h
# Copy the kernel config file you are currently using
cp -vi /boot/config-`uname -r` .config
# Install ncurses libary, if you want to run menuconfig
apt-get install libncurses5 libncurses5-dev
# Run menuconfig (optional)
make menuconfig
# Define the number of threads you wanna use when compiling (should be <number CPU cores> - 1), e.g. for quad-core
export CONCURRENCY_LEVEL=3
# Now compile the custom kernel
fakeroot make-kpkg --initrd --append-to-version=custom kernel-image kernel-headers
# And wait a long long time
cd ..
简而言之，如果您想保持安全，请使用 iptables，如果您想确保此限制不再困扰您，请编译内核。
注意：最近，不再需要更新内核。
您现在可以设置
sysctl net.ipv4.ip_unprivileged_port_start=80
或者坚持
sysctl -w net.ipv4.ip_unprivileged_port_start=80.
如果这产生错误，只需使用 nano 编辑 /etc/sysctl.conf 并在此处设置参数以在重新启动后保持持久性。
或通过 procfs
echo 80 | sudo tee /proc/sys/net/ipv4/ip_unprivileged_port_start
或修补您的内核并删除检查。
（最后的选择，不推荐）。
在net/ipv4/af_inet.c中，删除读取的两行
if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
goto out;
并且内核将不再检查特权端口。
由于某种原因，没有人提到将 sysctl net.ipv4.ip_unprivileged_port_start 降低到您需要的值。示例：我们需要将我们的应用绑定到 443 端口。
sysctl net.ipv4.ip_unprivileged_port_start=443
有人可能会说，存在潜在的安全问题：非特权用户现在可能会绑定到其他特权端口（444-1024）。但是你可以用 iptables 轻松解决这个问题，通过阻塞其他端口：
iptables -I INPUT -p tcp --dport 444:1024 -j DROP
iptables -I INPUT -p udp --dport 444:1024 -j DROP
与其他方法的比较。这种方法：
根据具体情况，我会在 sysctl、CAP、authbind 和 iptables-redirect 之间进行选择。我们有这么多选择真是太好了。
您可以设置本地 SSH 隧道，例如，如果您希望端口 80 访问绑定到 3000 的应用程序：
sudo ssh $USERNAME@localhost -L 80:localhost:3000 -N
这具有使用脚本服务器的优点，并且非常简单。
现代 Linux 支持/sbin/sysctl -w net.ipv4.ip_unprivileged_port_start=0.
我知道这是一个老问题，但现在有了最近的（> = 4.3）内核，终于有了一个很好的答案——环境功能。
快速的答案是从 git获取最新（尚未发布）版本的 libcap 的副本并编译它。将生成的progs/capsh二进制文件复制到某处（/usr/local/bin是一个不错的选择）。然后，以 root 身份启动您的程序
/usr/local/bin/capsh --keep=1 --user='your-service-user-name' \
--inh='cap_net_bind_service' --addamb='cap_net_bind_service' \
-- -c 'your-program'
按顺序，我们是
cap_net_bind_service功能添加到继承和环境集bash -c 'your-command'（因为capsh使用 after 的参数自动启动 bash --）这里有很多事情要做。
首先，我们以 root 身份运行，因此默认情况下，我们获得了全套功能。setuid其中包括使用和setgid系统调用切换 uid 和 gid 的能力。然而，通常当一个程序这样做时，它会失去它的一组功能——这使得删除 root 的旧方法setuid仍然有效。该--keep=1标志告诉capsh发出prctl(PR_SET_KEEPCAPS)系统调用，这会在更改用户时禁用功能的删除。用户的实际更改capsh发生在--user运行setuidand的标志上setgid。
我们需要解决的下一个问题是如何以一种在exec我们孩子之后进行的方式设置能力。能力系统一直有一个“继承”的能力集，即“在 execve(2) 中保留的一组能力”[能力(7) ]。虽然这听起来像是解决了我们的问题（只是将cap_net_bind_service功能设置为继承，对吗？），但这实际上只适用于特权进程 - 我们的进程不再具有特权，因为我们已经更改了用户（使用--user标志）。
新的环境能力集解决了这个问题——它是“在非特权程序的 execve(2) 中保留的一组能力”。通过放入cap_net_bind_service环境集，当capshexec 是我们的服务器程序时，我们的程序将继承此功能并能够将侦听器绑定到低端口。
如果您有兴趣了解更多信息，功能手册页对此进行了详细说明。跑capsh通strace也很有信息量！
文件功能并不理想，因为它们可能会在包更新后中断。
恕我直言，理想的解决方案应该是能够创建具有可继承CAP_NET_BIND_SERVICE集的外壳。
这是一种有点复杂的方法：
sg $DAEMONUSER "capsh --keep=1 --uid=`id -u $DAEMONUSER` \
--caps='cap_net_bind_service+pei' -- \
YOUR_COMMAND_GOES_HERE"
capsh实用程序可以在 Debian/Ubuntu 发行版的 libcap2-bin 包中找到。这是发生的事情：
sg将有效组 ID 更改为守护程序用户的 ID。这是必要的，因为capshGID 保持不变，我们绝对不想要它。$DAEMONUSER--keep=1），除了可继承cap_net_bind_service结果是具有指定用户和组以及cap_net_bind_service特权的进程。
例如，ejabberd启动脚本中的一行：
sg $EJABBERDUSER "capsh --keep=1 --uid=`id -u $EJABBERDUSER` --caps='cap_net_bind_service+pei' -- $EJABBERD --noshell -detached"
另外两个简单的可能性：
对于“绑定在低端口并将控制权交给您的守护程序的守护程序”，有一个旧的（过时的）解决方案。它被称为inetd（或xinetd）。缺点是：
优点：
另一种选择：从特权端口到可以运行目标守护程序的任意高编号端口的黑客代理（netcat 甚至更强大的东西）。（Netcat 显然不是生产解决方案，而是“只是我的开发箱”，对吧？）。这样，您可以继续使用支持网络的服务器版本，只需要 root/sudo 来启动代理（在启动时），不会依赖复杂/可能脆弱的功能。
我的“标准解决方法”使用 socat 作为用户空间重定向器：
socat tcp6-listen:80,fork tcp6:8080
请注意，这不会扩展，分叉很昂贵，但这是 socat 的工作方式。
systemd是 sysvinit 的替代品，它可以选择启动具有特定功能的守护程序。选项 Capabilities=, CapabilityBoundingSet= 在systemd.exec(5) 手册页中。
TLDR：对于“答案”（如我所见），请跳至此答案中的 >>TLDR<< 部分。
好的，我已经想通了（这次是真的），这个问题的答案，我的这个答案也是为推广另一个我认为是“最好的答案”的答案（在这里和推特上）道歉的一种方式”，但在尝试之后，发现我错了。孩子们从我的错误中吸取教训：在您自己实际尝试之前，不要宣传某些东西！
再次，我在这里查看了所有答案。我已经尝试了其中的一些（并选择不尝试其他的，因为我根本不喜欢这些解决方案）。我认为解决方案是使用systemd它的Capabilities=和CapabilitiesBindingSet=设置。经过一段时间的努力，我发现这不是解决方案，因为：
功能旨在限制根进程！
正如 OP 明智地指出的那样，最好避免这种情况（如果可能的话，对于所有的守护进程！）。
您不能在单元文件中User=和单元文件中使用与功能相关的选项，因为在调用（或任何函数）时总是会重置功能。换句话说，当分叉并删除它的权限时，这些功能会被重置。没有办法解决这个问题，内核中的所有绑定逻辑都是围绕 uid=0 的，而不是功能。这意味着能力不太可能成为这个问题的正确答案（至少在短期内）。顺便说一句，正如其他人所提到的，这不是一个解决方案。它对我不起作用，它不能很好地与脚本一起使用，而且只要文件更改，它们就会被重置。Group=systemdexecevsystemdsetcap
在我微薄的辩护中，我确实声明（在我现在已删除的评论中）詹姆斯的iptables建议（OP 也提到）是“第二好的解决方案”。:-P
>>TLDR<<
解决方案是结合动态命令，如下所示（取自 DNSChainsystemd）：iptables
[Unit]
Description=dnschain
After=network.target
Wants=namecoin.service
[Service]
ExecStart=/usr/local/bin/dnschain
Environment=DNSCHAIN_SYSD_VER=0.0.1
PermissionsStartOnly=true
ExecStartPre=/sbin/sysctl -w net.ipv4.ip_forward=1
ExecStartPre=-/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=-/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStartPre=/sbin/iptables -A INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=/sbin/iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStopPost=/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStopPost=/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
User=dns
Group=dns
Restart=always
RestartSec=5
WorkingDirectory=/home/dns
PrivateTmp=true
NoNewPrivileges=true
ReadOnlyDirectories=/etc
# Unfortunately, capabilities are basically worthless because they're designed to restrict root daemons. Instead, we use iptables to listen on privileged ports.
# Capabilities=cap_net_bind_service+pei
# SecureBits=keep-caps
[Install]
WantedBy=multi-user.target
在这里，我们完成以下工作：
iptablessystemd为我们清理防火墙规则，确保在守护进程未运行时将其删除。systemd声称如此），即使守护进程被破坏并设置uid=0.iptables不幸的是，它仍然是一个丑陋且难以使用的实用程序。例如，如果守护程序正在侦听eth0:0而不是eth0，则命令会略有不同。
使用 systemd，您只需稍微修改您的服务以接受预激活的套接字。
您可以稍后使用systemd socket activate。
不需要任何功能、iptables 或其他技巧。
这是此简单python http 服务器示例中相关 systemd 文件的内容
文件httpd-true.service
[Unit]
Description=Httpd true
[Service]
ExecStart=/usr/local/bin/httpd-true
User=subsonic
PrivateTmp=yes
文件httpd-true.socket
[Unit]
Description=HTTPD true
[Socket]
ListenStream=80
[Install]
WantedBy=default.target
端口重定向对我们来说最有意义，但是我们遇到了一个问题，即我们的应用程序会在本地解析一个也需要重新路由的 url；（这意味着你shindig）。
这也将允许您在访问本地计算机上的 url 时被重定向。
iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -A OUTPUT -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080
启动时：
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
然后您可以绑定到您转发到的端口。
还有“djb 方式”。您可以使用此方法在 tcpserver 下的任何端口上以 root 身份启动您的进程，然后它将在进程启动后立即将进程控制权交给您指定的用户。
#!/bin/sh
UID=$(id -u username)
GID=$(id -g username)
exec tcpserver -u "${UID}" -g "${GID}" -RHl0 0 port /path/to/binary &
有关详细信息，请参阅：http ://thedjbway.b0llix.net/daemontools/uidgid.html
使用privbind实用程序：它允许非特权应用程序绑定到保留端口。
将 8080 端口绑定到 80 并打开 80 端口：
sudo iptables -t nat -A OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
然后以普通用户身份在 8080 端口上运行程序。
然后您将能够访问http://127.0.0.1端口80
由于 OP 只是开发/测试，因此不太时尚的解决方案可能会有所帮助：
setcap 可用于脚本的解释器以授予脚本功能。如果全局解释器二进制文件上的 setcaps 不可接受，请制作二进制文件的本地副本（任何用户都可以）并让 root 访问此副本上的 setcap。Python2（至少）与脚本开发树中解释器的本地副本一起正常工作。不需要 suid，因此 root 用户可以控制用户可以访问的功能。
如果您需要跟踪解释器的系统范围更新，请使用如下所示的 shell 脚本来运行您的脚本：
#!/bin/sh
#
# Watch for updates to the Python2 interpreter
PRG=python_net_raw
PRG_ORIG=/usr/bin/python2.7
cmp $PRG_ORIG $PRG || {
echo ""
echo "***** $PRG_ORIG has been updated *****"
echo "Run the following commands to refresh $PRG:"
echo ""
echo " $ cp $PRG_ORIG $PRG"
echo " # setcap cap_net_raw+ep $PRG"
echo ""
exit
}
./$PRG $*
我尝试了 iptables PREROUTING REDIRECT 方法。在较旧的内核中，似乎IPv6 不支持这种类型的规则。但显然它现在在 ip6tables v1.4.18 和 Linux 内核 v3.8 中得到支持。
我还发现 PREROUTING REDIRECT 不适用于机器内启动的连接。要处理来自本地机器的连接，还需要添加一个 OUTPUT 规则 - 请参阅iptables port redirect not working for localhost。例如：
iptables -t nat -I OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080
我还发现 PREROUTING REDIRECT也会影响转发的数据包。也就是说，如果机器也在接口之间转发数据包（例如，如果它充当连接到以太网的 Wi-Fi 接入点），那么 iptables 规则也会捕获连接的客户端到 Internet 目的地的连接，并将它们重定向到机器。这不是我想要的——我只想重定向指向机器本身的连接。我发现我可以让它只影响发往盒子的数据包，方法是添加-m addrtype --dst-type LOCAL. 例如：
iptables -A PREROUTING -t nat -p tcp --dport 80 -m addrtype --dst-type LOCAL -j REDIRECT --to-port 8080
另一种可能性是使用 TCP 端口转发。例如使用socat：
socat TCP4-LISTEN:www,reuseaddr,fork TCP4:localhost:8080
然而，该方法的一个缺点是，侦听端口 8080 的应用程序不知道传入连接的源地址（例如，用于记录或其他识别目的）。
2015 年 9 月的回答：
ip6tables 现在支持 IPV6 NAT： http: //www.netfilter.org/projects/iptables/files/changes-iptables-1.4.17.txt
您将需要内核 3.7+
证明：
[09:09:23] root@X:~ ip6tables -t nat -vnL
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REDIRECT tcp eth0 * ::/0 ::/0 tcp dpt:80 redir ports 8080
0 0 REDIRECT tcp eth0 * ::/0 ::/0 tcp dpt:443 redir ports 1443
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 6148 packets, 534K bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 6148 packets, 534K bytes)
pkts bytes target prot opt in out source destination
在libcap网站上有一个使用文件共享库链接到非特权应用程序的工作示例。最近在回答有关向共享库添加功能的问题时提到了这一点。