当我之外再也没有其他用户时，在我的开发箱上有这个限制是非常烦人的。

我知道标准的解决方法，但是它们都不能完全满足我的要求：

1. authbind（Debian测试版1.0版仅支持IPv4）
2. 使用iptables REDIRECT目标将低端口重定向到高端口（iptable的IPv6版本ip6tables尚未实现“ nat”表）
3. sudo（以root用户身份运行是我要避免的操作）
4. SELinux（或类似版本）。（这只是我的开发箱，我不想引入很多额外的复杂性。）

是否有一些简单的sysctl变量允许非根进程绑定到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。

现在需要注意的是：

1. 您将至少需要2.6.24内核
2. 如果您的文件是脚本，则无法使用。（即，使用＃！行启动解释器）。据我所知，在这种情况下，您必须将功能应用于解释器可执行文件本身，这当然是安全的噩梦，因为使用该解释器的任何程序都将具有该功能。我找不到解决此问题的任何简单明了的方法。
3. Linux将在program具有更高特权的任何磁盘上禁用LD_LIBRARY_PATH，例如setcap或suid。因此，如果您program使用自己的.../lib/，则可能必须考虑其他选项，例如端口转发。

资源：

• 功能（7）手册页。如果要在生产环境中使用功能，请仔细阅读本章。关于如何在exec（）调用之间继承功能的方式，确实存在一些非常棘手的细节，在此进行详细介绍。
• setcap手册页
• “绑定低于1024的端口，而在GNU / Linux上没有root”：该文档首先将我指向setcap。

注意：RHEL首先在v6中添加了它。

您可以进行端口重定向。这是我对在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身份运行，其余的则以较低的特​​权运行。

或修补内核并删除检查。

（不建议使用最后的选择）。

在中net/ipv4/af_inet.c，删除读取的两行

      if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
              goto out;

并且内核将不再检查特权端口。

您可以设置本地SSH隧道，例如，如果您希望端口80命中绑定到3000的应用程序：

sudo ssh $USERNAME@localhost -L 80:localhost:3000 -N

这具有使用脚本服务器的优势，并且非常简单。

2017年更新：

使用身份验证

• CAP_NET_BIND_SERVICE将信任授予二进制文件，但不提供对每个端口访问的控制。
  

• Authbind授予用户/组信任，并提供对每个端口访问的控制，并支持IPv4和IPv6（最近已添加了IPv6支持）。

  1. 安装： apt-get install authbind

  2. 为所有用户和组配置对相关端口的访问，例如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
     

  3. 通过authbind
     （可选地指定--deep或其他参数，请参见手册页）执行命令：

     authbind --deep /path/to/binary command line args
     

     例如

     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程序都可以绑定系统端口。
Dito for mono / .NET。

我也很确定xinetd并不是最好的主意。
但是由于这两种方法都是骇客，为什么不通过解除限制来解除限制呢？
没有人说您必须运行普通的内核，因此您可以运行自己的内核。

您只需下载最新内核的源代码（或当前使用的源代码）。之后，您将转到：

/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

通常，我会使用所需的最低设置，例如，http设置为79，端口25上使用SMTP时设置为24。

已经足够了。
编译内核，然后安装它。
重启。
完成-该愚蠢的限制已消失，它也适用于脚本。

这是编译内核的方法：

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；如果要确保此限制永远不会再困扰您，请编译内核。

文件功能不是理想的，因为它们在软件包更新后可能会中断。

理想的解决方案，恕我直言，应该具有创建具有可继承外壳的能力 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保持不变，我们绝对不希望这样做。
• 设置位“ UID更改保持功能”。
• 将UID更改为 $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"

由于某种原因，没有人提及将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

与其他方法的比较。此方法：

• 从某种意义上讲，（IMO）比设置CAP_NET_BIND_SERVICE / setuid更安全，因为应用程序根本不设置setuid，甚至部分不设置setuid（实际上是功能）。例如，要捕获已启用功能的应用程序的核心转储，您将需要更改sysctl fs.suid_dumpable（这会导致另一个潜在的安全问题）。此外，设置CAP / suid时，/ proc / PID目录归根目录所有，因此您的非root用户将不具有正在运行的进程的完整信息/控制权，例如，该用户将无法（通常）通过/ proc / PID / fd /（netstat -aptn | grep）来确定哪些连接属于应用程序PID）。
• 具有安全性劣势：当您的应用程序（或使用端口443-1024的任何应用程序）由于某种原因而关闭时，另一个应用程序可能占用该端口。但是这个问题也可能适用于CAP / suid（以防您在解释器上设置它，例如java / nodejs）和iptables-redirect。使用systemd-socket方法可以排除此问题。使用authbind方法仅允许特殊的用户绑定。
• 不需要在每次部署新版本的应用程序时都设置CAP / suid。
• 不需要系统支持/修改，例如systemd-socket方法。
• 不需要内核重建（如果运行版本支持此sysctl设置）
• 不会像authbind / privbind方法那样执行LD_PRELOAD，这可能会影响性能，安全性，行为（是吗？尚未测试）。其余的authbind确实是灵活和安全的方法。
• 因为它不需要地址转换，连接状态跟踪等，所以它的性能优于iptables REDIRECT / DNAT方法。这仅在高负载系统上才明显。

根据情况，我将在sysctl，CAP，authbind和iptables-redirect之间进行选择。太好了，我们有很多选择。

另外两种简单的可能性：

对于“绑定在低端口上并将控制权交给您的守护程序的守护程序”，有一个旧的（不流行的）解决方案。它称为inetd（或xinetd）。缺点是：

• 您的守护程序需要在stdin / stdout上进行交谈（如果您不控制该守护程序-如果您没有源代码-则这可能是一个放映机，尽管某些服务可能具有inetd-compatibility标志）
• 每个连接都有一个新的守护进程
• 这是链中的一个额外链接

优点：

• 在任何旧的UNIX上可用
• 一旦您的系统管理员设置好配置，您就可以进行开发了（重新构建守护程序时，可能会失去setcap功能吗？然后您必须回到管理员位置，“先生。 。”）
• 守护进程不必担心网络问题，只需要在stdin / stdout上进行讨论即可
• 可以根据要求配置为以非root用户身份执行守护程序

另一种选择是：从特权端口到任意高编号端口（可以在其中运行目标守护程序）使用黑客入侵的代理（netcat或什至更强大的代理）。（Netcat显然不是生产解决方案，而是“只是我的开发箱”，对吧？）。这样，您可以继续使用具有网络功能的服务器版本，只需要root / sudo即可启动代理（在启动时），而不必依赖复杂/潜在的脆弱功能。

我的“标准解决方法”将socat用作用户空间重定向器：

socat tcp6-listen:80,fork tcp6:8080

注意这不会扩展，分叉很昂贵，但这是socat的工作方式。

Linux支持的功能不只是“此应用程序以root身份运行”，还支持更细粒度的权限。这些功能之一是CAP_NET_BIND_SERVICE与绑定到特权端口（<1024）有关。

不幸的是，我不知道如何利用它来以非root身份运行应用程序，同时仍然提供它CAP_NET_BIND_SERVICE（可能使用setcap，但是肯定有一个现有的解决方案）。

我知道这是一个老问题，但是现在有了最新的（> = 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使用后面的参数自动启动bash --）

这里有很多事情要做。

首先，我们以root用户身份运行，因此默认情况下，我们获得了一整套功能。这包括使用setuid和setgid调用系统切换uid和gid的功能。但是，通常程序在执行此操作时会失去其功能集-这样一来，setuid仍然可以使用删除根目录的旧方法。该--keep=1标志指示capsh发出prctl(PR_SET_KEEPCAPS)syscall，这将在更改用户时禁用功能下降。通过用户的实际变化capsh情况与--user标志，它运行setuid和setgid。

我们需要解决的下一个问题是如何以一种在我们exec孩子之后继续进行的方式来设置能力。功能系统始终具有“继承的”功能集，即“在execve（2）上保留的一组功能” [ capabilities（7） ]。虽然这听起来像解决了我们的问题（只需将cap_net_bind_service功能设置为继承，对吗？），但这实际上仅适用于特权进程-并且我们的进程不再具有特权，因为我们已经更改了用户（带有--user标志）。

新的环境功能集可解决此问题-它是“在没有特权的程序的execve（2）中保留的一组功能”。通过放入cap_net_bind_service环境集，当capshexec成为我们的服务器程序时，我们的程序将继承此功能，并能够将侦听器绑定到低端端口。

如果您想了解更多信息，功能手册页将对此进行详细说明。运行capsh经过strace也非常丰富！

TLDR：对于“答案”（如我所见），请跳至该答案中的>> TLDR <<部分。

好的，我已经弄清楚了（这一次是真的），这个问题的答案，而我的这个答案也是道歉的一种方式，以推广另一个我认为是“最好的答案”（在这里和在Twitter上） ”，但尝试之后发现我误会了。向我的错误孩子们学习：在您自己亲自尝试之前，不要推广任何东西！

我再次在这里查看了所有答案。我尝试了其中的一些（并选择不尝试其他方法，因为我根本不喜欢这些解决方案）。我认为解决方案是使用systemd其Capabilities=和CapabilitiesBindingSet=设置。经过一段时间的努力，我发现这不是解决方案，因为：

功能旨在限制根进程！

正如OP明智地指出的那样，始终最好避免这种情况（如果可能，对于所有守护程序！）。

您不能在单元文件中User=和Group=在systemd单元文件中使用“功能”相关的选项，因为在调用（或调用任何功能）时始终会重置execev功能。换句话说，当systemd分叉和删除其权限时，功能将重置。没有办法解决这个问题，内核中所有绑定逻辑都是基于uid = 0，而不是功能。这意味着能力不可能永远是该问题的正确答案（至少在不久的将来）。偶然，setcap正如其他人提到的那样，这不是解决方案。它对我不起作用，它不能与脚本很好地配合使用，并且无论文件何时更改，这些脚本都将被重置。

在我微不足道的辩护中，我确实声明（在我现在删除的评论中）詹姆斯的iptables建议（OP也提到）是“第二最佳解决方案”。:-P

>> TLDR <<

解决方案是systemd与即时iptables命令结合，例如（从DNSChain中获取）：

[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

在这里，我们完成以下任务：

• 守护程序在5333上侦听，但在53上成功连接成功，原因是 iptables
• 我们可以将命令包含在单位文件本身中，因此可以免去人们的麻烦。systemd为我们清理防火墙规则，确保在守护程序未运行时将其删除。
• 我们永远不会以root用户身份运行，并且systemd即使在守护进程已被破坏和设置的情况下，我们也无法使特权升级（至少要求这样做）uid=0。

iptables不幸的是，它仍然是一个丑陋且难以使用的实用程序。例如，如果守护进程正在监听eth0:0而不是监听eth0，则命令会略有不同。

systemd是sysvinit的替代品，它可以选择启动具有特定功能的守护程序。systemd.exec（5）联机帮助页中的选项Capabilities =，CapabilityBoundingSet = 。

端口重定向对我们来说最有意义，但是我们遇到了一个问题，即我们的应用程序将在本地解析一个url，该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

现代Linux支持/sbin/sysctl -w net.ipv4.ip_unprivileged_port_start=0。

使用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

在启动时：

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

然后，您可以绑定到转发到的端口。

使用privbind实用程序：它允许无特权的应用程序绑定到保留的端口。

还有“ djb方式”。您可以使用此方法以root用户身份在tcpserver下的任何端口上运行来启动进程，然后它将在进程启动后立即将进程的控制权交给您指定的用户。

#!/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

由于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端口重定向不适用于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