私以外のユーザーがいないときに、私の開発ボックスにこの制限があるのは非常に面倒です。
私は標準的な回避策を知っていますが、どれも私が望むことを正確に行うものではありません:
sysctl非ルート プロセスが Linux の「特権」ポート (1024 未満のポート) にバインドできるようにする簡単な変数はありますか?
編集:場合によっては、機能を使用してこれを行うことができます。
さて、能力システムと能力を指摘してくれた人々に感謝しCAP_NET_BIND_SERVICEます。最近のカーネルを使用している場合、これを使用してサービスを非ルートとして開始し、低ポートをバインドすることが実際に可能です。簡単な答えは、あなたがすることです：
setcap 'cap_net_bind_service=+ep' /path/to/program
そして、その後いつでもprogram実行され、それは機能を持ちCAP_NET_BIND_SERVICEます。setcapdebian パッケージに含まれていますlibcap2-bin。
ここで、注意事項について説明します。
programの昇格された権限を持つすべての LD_LIBRARY_PATH を無効にします。したがって、独自の を使用している場合は、ポート転送などの別のオプションを検討する必要がある場合があります。setcapsuidprogram.../lib/資力：
setcap.ポートリダイレクトを行うことができます。これは、Linuxボックスで実行されているSilverlightポリシーサーバーに対して行うことです。
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 943 -j REDIRECT --to-port 1300
更新 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またはその他の引数を指定します。man ページを参照してください)。
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 は失敗します。シェル インタープリターにキャップを設定しない限り、これは無意味です。サービスを root として実行することもできます。
たとえば、Java の場合は、それを適用する必要があります。 JAVA JVMに
sudo /sbin/setcap 'cap_net_bind_service=ep' /usr/lib/jvm/java-8-openjdk/jre/bin/java
明らかに、これはどの Java プログラムもシステム ポートをバインドできることを意味します。
mono/.NET 用の Dito。
また、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 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
標準的な方法は、それらを「setuid」にして root として起動し、ポートにバインドするとすぐにその root 権限を破棄しますが、ポートへの接続を受け入れ始める前です。Apache と INN のソース コードで、その良い例を見ることができます。Lighttpd も良い例だと言われています。
もう 1 つの例は Postfix です。これは、パイプを介して通信する複数のデーモンを使用し、そのうちの 1 つまたは 2 つ (バイトの受け入れまたは送信以外はほとんど何もしません) のみが root として実行され、残りはより低い権限で実行されます。
または、カーネルにパッチを適用してチェックを削除します。
(最後の手段のオプションであり、推奨されません)。
でnet/ipv4/af_inet.c、次の 2 行を削除します。
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 のいずれかを選択します。そして、これは非常に多くのオプションがあることです。
たとえば、ポート 80 を 3000 にバインドされたアプリにヒットさせたい場合は、ローカル SSH トンネルをセットアップできます。
sudo ssh $USERNAME@localhost -L 80:localhost:3000 -N
これには、スクリプト サーバーを使用できるという利点があり、非常に単純です。
これは古い質問であることは知っていますが、最近の (>= 4.3) カーネルでは、最終的にこれに対する良い答えがあります - アンビエント機能です。
簡単な答えは、git からlibcap の最新 (まだリリースされていない) バージョンのコピーを取得してコンパイルすることです。progs/capsh結果のバイナリをどこかにコピーします(/usr/local/bin良い選択です)。次に、ルートとして、プログラムを開始します
/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 が自動的に開始されるため--)ここでは、ボンネットの下で多くのことが行われています。
まず、ルートとして実行しているため、デフォルトですべての機能を利用できます。setuidこれには、およびsyscallsを使用して uid と gid を切り替える機能が含まれていますsetgid。ただし、通常、プログラムがこれを行うと、一連の機能が失われます。これは、ルートを削除する古い方法がsetuidまだ機能するためです。--keep=1フラグは、 syscallcapshを発行するように指示します。これにより、ユーザーの変更時に機能の削除が無効になります。prctl(PR_SET_KEEPCAPS)によるユーザーの実際の変更は、およびを実行capshする--userフラグで行われます。setuidsetgid
私たちが解決しなければならない次の問題は、exec私たちの子供の後に続く方法で機能を設定する方法です。ケーパビリティ システムには常に、「継承された」一連のケーパビリティがありました。これは、「execve(2) 全体で保持される一連のケーパビリティ」[ capabilities(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"
他の2つの単純な可能性：
「ローポートにバインドし、デーモンに制御を渡すデーモン」には、古い（ファッショナブルではない）ソリューションがあります。これはinetd（またはxinetd）と呼ばれます。短所は次のとおりです。
長所：
別の方法：特権ポートからターゲットデーモンを実行できる任意の番号の大きいポートへのハッキングされたプロキシ（netcatまたはさらに堅牢なもの）。（Netcatは明らかに本番ソリューションではありませんが、「私の開発ボックス」ですよね？）このようにして、ネットワーク対応バージョンのサーバーを引き続き使用でき、プロキシを起動するためにroot / sudoのみが必要であり（起動時）、複雑で脆弱な可能性のある機能に依存しません。
私の「標準的な回避策」では、socat をユーザー空間リダイレクタとして使用します。
socat tcp6-listen:80,fork tcp6:8080
これはスケーリングしないことに注意してください。分岐にはコストがかかりますが、それが socat の仕組みです。
Linux は、「このアプリケーションをルートとして実行する」だけでなく、よりきめ細かいパーミッションをサポートする機能をサポートしています。これらの機能の 1 つはCAP_NET_BIND_SERVICE、特権ポート (<1024) へのバインドに関するものです。
残念ながら、それを利用して、アプリケーションを提供しながら非ルートとしてアプリケーションを実行する方法はわかりませんCAP_NET_BIND_SERVICE(おそらく を使用setcapしますが、これには既存のソリューションがあるはずです)。
systemdはsysvinitの代替品であり、特定の機能を備えたデーモンを起動するオプションがあります。systemd.exec（5）のマンページにあるオプションCapabilities =、CapabilityBoundingSet= 。
TLDR：「答え」については（私が見ているように）、この回答の >>TLDR<< 部分にジャンプしてください。
OK、私はそれを理解しました（今回は実際に）、この質問に対する答え、そしてこの私の答えは、私が「最高だと思った別の答え（こことツイッターの両方）を宣伝したことに対する謝罪の方法でもあります。 」ですが、試してみると、それが間違っていることがわかりました。私の過ちから学んでください。実際に自分で試してみるまで宣伝しないでください。
繰り返しますが、ここですべての回答を確認しました。私はそれらのいくつかを試しました（そして、単に解決策が気に入らなかったので、他のものを試さないことにしました）。systemd解決策は、その設定Capabilities=で使用することだと思いましたCapabilitiesBindingSet=。しばらくこれに取り組んだ後、次の理由により、これが解決策ではないことがわかりました。
機能は、ルート プロセスを制限することを目的としています。
OPが賢明に述べたように、それを避けるのが常に最善です（可能であればすべてのデーモンに対して！）。
ケイパビリティ関連のオプションをユニット ファイルと一緒に使用しUser=たりGroup=、ユニット ファイル内で使用したりすることはできません。つまり、perm を fork してドロップすると、機能がリセットされます。これを回避する方法はありません。カーネル内のバインディング ロジックはすべて、機能ではなく、uid=0 に関する基本的なものです。これは、機能がこの質問に対する正しい答えになる可能性が低いことを意味します (少なくとも近いうちに)。ちなみに、他の人が述べたように、解決策ではありません。それは私にとってはうまくいきませんでした.スクリプトではうまく機能しません.ファイルが変更されるたびにスクリプトはとにかくリセットされます.systemdexecevsystemdsetcap
私の貧弱な弁護では、Jamesのiptablesの提案（OPも言及している）が「2番目に良い解決策」であると述べました（コメントで削除しました） 。:-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
ここでは、次のことを行います。
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
起動時：
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ユーティリティを使用します。特権のないアプリケーションが予約済みポートにバインドできるようにします。
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 ルールは、接続されたクライアントのインターネットの宛先への接続もキャッチし、それらを次の場所にリダイレクトします。この機械。それは私が望んでいたことではありません。マシン自体に向けられた接続をリダイレクトしたかっただけです。を追加することで、ボックス宛てのパケットのみに影響を与えることができることがわかりました-m addrtype --dst-type LOCAL。例：
iptables -A PREROUTING -t nat -p tcp --dport 80 -m addrtype --dst-type LOCAL -j REDIRECT --to-port 8080
もう 1 つの可能性は、TCP ポート転送を使用することです。例socat：
socat TCP4-LISTEN:www,reuseaddr,fork TCP4:localhost:8080
ただし、この方法の欠点の 1 つは、ポート 8080 でリッスンしているアプリケーションが、着信接続の送信元アドレスを知らないことです (たとえば、ログ記録やその他の識別目的で)。