Unix システムでは、ルート権限のないプロセスからの TCP ポート < 1024 へのバインドは拒否されます。
当初の理由は何でしたか？またそれは今でも有効ですか？
たとえば、http サーバーでは、HTML ページを提供するために root 権限は必要ありません。
Unix のユーザーが root 権限で実行されていることを確認するために必要なプロセス/プロトコルは何ですか?
ありがとう
答え1
そのポート範囲はプログラマーが定義するものではありません
。IANAによって予約済み、
よく知られているポートは 0 から 1023 までのポートです。
DCCP の Well Known ポートは、IANA 登録なしでは使用しないでください。登録手順は [RFC4340] のセクション 19.9 で定義されています。
異なる意見については、
からlinuxquestions スレッド(詳細についてはリンク先をご覧ください)
ポート 1024 の制限は、実際には自らを苦しめます。この制限は、セキュリティ対策としての制限を無効にするセキュリティ ホールを開く可能性のあるデーモン プラクティスを強制します。
- のSANS トップ 20 の脆弱性ノート
いくつかのコア システム サービスは、リモート プロシージャ コール (RPC) を通じてクライアント コンポーネントへのリモート インターフェイスを提供します。これらは主に、共通インターネット ファイル システム (CIFS) プロトコル、よく知られている TCP/UDP ポート、場合によっては一時的な TCP/UDP ポートを通じてアクセスできる名前付きパイプ エンドポイントを通じて公開されます。これまで、匿名ユーザーが悪用できる脆弱性がサービスに数多く存在してきました。これらの脆弱性が悪用されると、攻撃者はホスト上でサービスが持っていたのと同じ権限を取得できます。
- のSANS トップ 20 の脆弱性ノート
最近では、次のようなプロトコルがビットトレントそしてスカイプ一時的なポートを経由して予約されていないスペースに移動し、ルートアクセスを気にする必要はありません。ターゲットはこの古い予約ポートのセキュリティを回避するだけでなく; 今日のプロトコルはネットワーク境界さえもバイパスする（Skypeはその良い例です）。ネットワークの帯域幅と可用性が増すと、すべてのコンピュータユーザーがおそらく自分でウェブサーバーを運営する- そして多分、知らないうちに、 なれの一部 ボットネット。
私たちはこれらの古い方法で望まれるセキュリティを必要としています
が、今はより新しい方法でそれを行う必要があります。
答え2
そうですね、私が覚えている限りでは、BSD Unix の時代から当初考えられていたのは、1024 未満のポートは「よく知られたサービス」用に予約されているはずで、サーバーは比較的まれであり、ルート権限を持つ人々は何らかの形で「信頼されている」とみなされるという前提でした。そのため、他のユーザーがアクセスするネットワーク サービスを表すポートをリッスンするためにソケットをバインドするには、特権が必要でした。
ポート 1024 ～ 4999 は、TCP 接続のクライアント側を表す「一時」ポートとして使用することを目的としていました。ポート 5000 以上は、非ルート サーバー用です。
明らかに、これらの想定はすべてすぐに崩れ去りました。IANA TCP ポート番号予約リストをチェックして、状況がどれほど悪化したかを確認してください。
この問題の解決策の 1 つは、RPC ポートマッパーというアイデアでした。各サービスに TCP ポートを予約する代わりに、サービスはランダムなポートで起動し、ポートマッパー デーモンにリッスンしている場所を伝えます。クライアントはポートマッパーに「サービス X はどこでリッスンしているか」を尋ね、そこから処理を進めます。よく知られている RPC サービスを偽装から保護するためにどのようなセキュリティ メカニズムが導入されていたかは思い出せません。
最近ではこれらすべてに正当な理由があるかどうかはわかりませんが、ほとんどの *nix の世界と同様に、完全に再発明されるのではなく、蓄積される傾向があります。
ヴァーナー・ヴィンジを読んだ人はいますか? ヴィンジが小説の中で、遠い未来のコンピューター システムについて書いていたのを覚えています。そのコンピューター システムには、太古の昔から何層にも重なったコードが組み込まれており、時間は今でも太古の日付 (正確には 1970 年 1 月 1 日) からの秒数で表されています。おそらく、ヴィンジの考えは的外れではないでしょう。
答え3
昔は、一般ユーザーが Unix マシンにログインしていました。そのため、一般ユーザーが偽の FTP サービスなどを設定することは望ましくありません。
最近の一般的な使用法では、管理者と他の信頼できる数人だけがサーバーにログインできるため、今日モデルが作り直された場合、< 1024 制限は存在しない可能性があります。
答え4
システムパスワードを受け入れるサービスを特権ポートで実行することは理にかなっています。つまり、シェル アカウントを持つユーザーは、同じポートで「偽の」サービスを設定してユーザーのログイン詳細を取得したり、同じポートで機能しないサービスを設定してアクセスを拒否したりすることはできません。
マルチユーザー ボックスがあり、権限のないユーザーが不正な ssh デーモンを設定できる場合、他のユーザーのパスワードをキャプチャしてアカウントにアクセスできる可能性があります (もちろん、正当な ssh デーモンが停止しているとき、たとえばメンテナンス中やシステムの起動またはシャットダウン中にこれを行う必要があります)。
システムパスワードを受け入れないものはそれほど問題ではありませんが、マルチユーザーボックス上のユーザー間でウェブサーバーなどを共有すると、大きなセキュリティ上の問題が発生します（共有ホスティングプロバイダーが発見したように）。