另外两种简单的可能性:Daemon和Proxy

守护进程

对于“一个绑定在低端口上的守护进程并将控制权交给您的守护进程”，有一个旧的(不流行的)解决方案。它被称为inetd(或xinetd)。

缺点是:

你的守护进程需要在stdin/stdout上对话(如果你不控制守护进程——如果你没有源代码——那么这可能是一个showstopper，尽管一些服务可能有inetd兼容性标志) 每个连接都会生成一个新的守护进程 这是链条上的一环

优点:

可以在任何旧的UNIX上使用 一旦系统管理员设置了配置，就可以开始开发了(当重新构建守护进程时，可能会失去setcap功能吗?然后你就得回到你的管理员那里，“请，先生……”) Daemon不需要担心网络的问题，只需要在stdin/stdout上进行对话 是否可以按照请求配置为以非根用户执行守护进程

代理

另一种替代方案:从特权端口到任意高编号端口(您可以在其中运行目标守护进程)的经过修改的代理(netcat或更健壮的代理)。(Netcat显然不是一个生产解决方案，但“只是我的开发盒”，对吧?)通过这种方式，您可以继续使用服务器的网络支持版本，只需要root/sudo启动代理(在引导时)，而不依赖复杂/潜在的脆弱功能。

TLDR:对于“答案”(如我所见)，跳到这个答案中的>>TLDR<<部分。

好吧，我已经想明白了(这次是真的)，这个问题的答案，我的这个答案也是一种道歉的方式，因为我推广了另一个我认为是“最好的”的答案(在这里和推特上)，但在尝试之后，发现我错了。孩子们，从我的错误中吸取教训吧:在你自己真正尝试过之前，不要推销任何东西!

我在这里复习了所有的答案。我已经尝试了其中的一些(而选择不尝试其他的，因为我不喜欢这些解决方案)。我认为解决方案是使用systemd及其Capabilities=和capactiesbindingset = settings。在思考了一段时间后，我发现这不是解决方案，因为:

功能旨在限制根进程!

正如OP所明智地指出的那样，最好避免这种情况(如果可能的话，对于所有守护进程!)。

You cannot use the Capabilities related options with User= and Group= in systemd unit files, because capabilities are ALWAYS reset when execev (or whatever the function is) is called. In other words, when systemd forks and drops its perms, the capabilities are reset. There is no way around this, and all that binding logic in the kernel is basic around uid=0, not capabilities. This means that it is unlikely that Capabilities will ever be the right answer to this question (at least any time soon). Incidentally, setcap, as others have mentioned, is not a solution. It didn't work for me, it doesn't work nicely with scripts, and those are reset anyways whenever the file changes.

在我微薄的辩护中，我确实说过(在我现在删除的评论中)，詹姆斯的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，但是由于iptables，连接成功地在53上被接受 我们可以将命令包含在单元文件本身中，从而为人们省去了麻烦。Systemd为我们清理防火墙规则，确保在守护进程未运行时删除它们。 我们从不以根用户身份运行，并且使特权升级成为不可能(至少systemd声称是这样)，即使守护进程被破坏并设置uid=0。

不幸的是，Iptables仍然是一个相当丑陋且难以使用的实用工具。例如，如果守护进程正在侦听eth0:0而不是eth0，则命令略有不同。

Linux支持支持更细粒度权限的功能，而不仅仅是“此应用程序以根用户身份运行”。其中一个功能是CAP_NET_BIND_SERVICE，它是关于绑定到特权端口(<1024)的。

不幸的是，我不知道如何利用它来运行一个应用程序作为非根，同时仍然给它CAP_NET_BIND_SERVICE(可能使用setcap，但肯定有一个现有的解决方案)。

2017年更新:

使用authbind

免责声明(2021年更新):请注意，authbind通过LD_PRELOAD工作，这只在你的程序使用libc时使用，如果你的程序用GO编译，或任何其他避免使用c的编译器，这是(或可能)不是情况。如果你使用GO，为受保护的端口范围设置内核参数，请参阅post底部。< / EndUpdate > Authbind比CAP_NET_BIND_SERVICE或自定义内核好得多。

CAP_NET_BIND_SERVICE授予二进制文件信任，但不提供 控制每个端口的访问。 Authbind向对象授予信任 用户/组，并提供对每个端口访问的控制 支持IPv4和IPv6 (IPv6支持已添加到后期)。

安装:apt-get Install authbind 为所有用户和组配置访问相关端口，例如80和443: 触摸/etc/authbind/byport/80 触摸/etc/authbind/byport/443 Sudo chmod 777 /etc/authbind/byport/80 Sudo chmod 777 /etc/authbind/byport/443 .使用实例 通过authbind执行命令 (可选地指定——deep或其他参数，参见man authbind): Authbind——deep /path/to/binary命令行参数 如。 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程序都可以绑定系统端口。 对于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， 如果您想确保这个限制不再困扰您，请编译内核。

---

sysctl方法

注意: 到目前为止，不再需要更新内核。 你现在可以设置

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

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

出于某种原因，没有人提到降低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

与其他方法的比较。这个方法:

from some point is (IMO) even more secure than setting CAP_NET_BIND_SERVICE/setuid, since an application doesn't setuid at all, even partly (capabilities actually are). For example, to catch a coredump of capability-enabled application you will need to change sysctl fs.suid_dumpable (which leads to another potential security problems) Also, when CAP/suid is set, /proc/PID directory is owned by root, so your non-root user will not have full information/control of running process, for example, user will not be able (in common case) to determine which connections belong to application via /proc/PID/fd/ (netstat -aptn | grep PID). has security disadvantage: while your app (or any app that uses ports 443-1024) is down for some reason, another app could take the port. But this problem could also be applied to CAP/suid (in case you set it on interpreter, e.g. java/nodejs) and iptables-redirect. Use systemd-socket method to exclude this problem. Use authbind method to only allow special user binding. doesn't require setting CAP/suid every time you deploy new version of application. doesn't require application support/modification, like systemd-socket method. doesn't require kernel rebuild (if running version supports this sysctl setting) doesn't do LD_PRELOAD like authbind/privbind method, this could potentially affect performance, security, behavior (does it? haven't tested). In the rest authbind is really flexible and secure method. over-performs iptables REDIRECT/DNAT method, since it doesn't require address translation, connection state tracking, etc. This only noticeable on high-load systems.

根据具体情况，我将在sysctl、CAP、authbind和iptables-redirect之间进行选择。我们有这么多选择真是太好了。