1024未満のポートへのバインドがUnixシステムのrootに対してのみ許可される理由はまだありますか？
Unixシステムでは、root権限のないプロセスからtcpポート<1024へのバインドは拒否されます。
最初の理由は何でしたか、それはまだ有効ですか？
たとえば、httpサーバーはhtmlページを提供するためにroot権限を必要としません。
Unixのユーザーがroot特権で実行されることを確認するために必要なプロセス/プロトコルは何ですか？
ありがとう
そのポート範囲は、プログラマーが定義するものではありません。
それは IANAによって予約されています 、
よく知られているポートは、0から1023までのポートです。
DCCPの既知のポートはIANA登録なしで使用すべきではありません。登録手順は、[RFC4340]のセクション19.9で定義されています。
意見の違いについては、
linuxquestionsスレッド から（詳細についてはリンクを読んでください）
ポート1024の制限は、実際にはテールに食い込んでいます。これは、セキュリティ対策として制限を無効にするセキュリティホールを開く可能性のあるデーモンの実行を強制します。
- SANS Top-20 Vulnerabilities notes
コアシステムサービスのいくつかは、リモートプロシージャコール（RPC）を介してクライアントコンポーネントにリモートインターフェイスを提供します。これらは主に、Common Internet File System（CIFS）プロトコル、よく知られているTCP/UDPポート、場合によっては一時的なTCP/UDPポートを介してアクセスできる名前付きパイプエンドポイントを介して公開されます。歴史的に、匿名ユーザーが悪用できるサービスには多くの脆弱性がありました。これらの脆弱性が悪用されると、攻撃者はサービスがホストに対して持っていたのと同じ特権を得ることができます。
- SANS Top-20 Vulnerabilities notes
最近、 BitTorrent や Skype のようなプロトコルは、エフェメラルポートを介して予約されていないスペースに移動し、ルートアクセスを気にしません。ターゲットは この古い予約ポートセキュリティをバイパスするだけではありません;今日のプロトコルは ネットワーク境界もバイパスします （Skypeはその良い例です）。ネットワークの帯域幅と可用性が向上するにつれて、すべてのコンピューターユーザーがおそらく Webサーバーを自分で実行する -および 多分 、 無意識のうちに 、 be aの一部botnet 。
これらの古い方法で望まれるセキュリティが必要です
しかし、今は新しい方法で行う必要があります。
さて、BSD Unixの時代から私が思い出した当初の考えは、1024未満のポートは「よく知られたサービス」のために予約されると予想され、サーバーは比較的まれであり、root特権を持つ人々は何らかの形で「信頼されている」と推定されます。したがって、他のユーザーがアクセスするネットワークサービスを表すポートでリッスンするために、ソケットをバインドする特権が必要でした。
ポート1024〜4999は、TCP接続のクライアント側を表す「エフェメラル」ポートとして使用することを目的としていました。ポート5000+は、非ルートサーバーを対象としていました。
明らかに、これらの仮定はすべて、すぐにウィンドウから消えました。 IANA TCPポート番号予約リストをチェックして、どれだけ高くなったかを確認してください。
この問題の1つの解決策は、RPCポートマッパーのアイデアでした。サービスごとにTCPポートを予約する代わりに、サービスはランダムなポートで起動し、ポートマッパーデーモンにリッスンしている場所を通知します。クライアントはポートマッパーに「サービスXはどこですか」と尋ねます。よく知られているRPCサービスを偽装から保護するためにどのようなセキュリティメカニズムが導入されていたか思い出せません。
最近、これらすべてに正当な理由があるかどうかはわかりませんが、ほとんどの* nixの世界と同様に、完全に再発明されるのではなく、蓄積される傾向があります。
ヴァーナーヴィンジを読んだ人はいますか？彼が遠い未来のコンピューターシステムについて小説の1つに書いたのを覚えています。この小説には、古代の過去のコードのレイヤーとレイヤーが組み込まれており、時間は古代の日付（1970年1月1日）からの秒数で表されています。正確には）。彼はおそらく遠くないです。
昔は、通常のユーザーはUnixマシンにログインしていました。したがって、平均的なユーザーが偽のftpサービスなどを設定することは望ましくありません。
最近の一般的な使用法では、管理者と他の数人の信頼できる人だけがサーバーにログインしているため、モデルを今日やり直した場合、1024未満の制限が存在しない可能性があります。
これは歴史的な慣習です。
昔は、システムの数ははるかに少なかった。 DNSもありませんでした、FTPサイトはあなたの匿名のパスワードをあなたの電子メールアドレスにするように頼みました、そしてスパムはありませんでした。
それは本質的に暗黙の「紳士協定」でした。システムは適切に管理されていました。誰かがこれを台無しにした場合、誰と話をするかを知っていた、または彼らが不機嫌だった場合、ネットワークから追い出されることはほとんどオフラインのままでいることを意味しました。
今日、すべてにTCP/IPが搭載されているため、これはもはやセキュリティを提供しません。
システムパスワードを受け入れるサービスが特権ポートで実行されていることは理にかなっています。つまり、シェルアカウントを持つユーザーは、同じポートに「偽の」サービスを設定してユーザーのログイン情報を取得したり、同じポートに機能しないサービスを設定してアクセスを拒否したりすることはできません。
マルチユーザーボックスがあり、特権のないユーザーが不正なsshデーモンを設定できた場合、他のユーザーのパスワードを取得して自分のアカウントにアクセスできる可能性があります（もちろん、正当なsshデーモンがダウンしていた、おそらくメンテナンス中、またはシステムの起動時またはシャットダウン中）
システムパスワードを受け入れないものはそれほど重要ではありませんが、マルチユーザーボックス上のユーザー間でWebサーバーなどを共有することには大きなセキュリティ問題があります（共有ホスティングプロバイダーが発見したように）