セキュリティ上の理由から、/ etc / passwdおよび/ etc / shadowの名前を変更します[終了]

サーバーがあります。私のサーバーは安全ですが、のはに入る良いハッカーを想像してみましょう。彼は今に見ることができる/etc/passwdと/etc/shadow。私は、そのファイルの名前を変更したい/etc/passwdのようなものに/etc/xxanoda。

リンクはできると思ったのですが、ハッカーなら簡単にできますls -l。

これらのファイルの名前を変更しても、互換性の問題なしにOSを実行できますか、それともまったく役に立ちませんか？知識を求めるためだけに。

UNIXライクなシステム用のファイルシステム階層標準は/etc/passwd、固定された場所に含まれており、その結果、通常、ツールはハードコードされてそこを探します。理論的には、関連するすべてのユーティリティを再コンパイルして新しい場所を探すことができますが、攻撃者は常にバイナリ内の文字列を探して新しいファイルを見つけるか、正規表現を使用して-のpasswdような内容のファイルを見つけることができます。

shadowファイルは、に読めるだけでなければなりませんroot（おそらくと呼ばれるグループにshadow）。攻撃者がシステムへのrootアクセス権を取得できた場合、攻撃者は完全に制御でき、passwd / shadowファイルを読み取ることができるかどうかはその時点ではほとんど関係ありません。

たとえば、誰かがリクエストできるように構成が適切に行われていないウェブサーバーがある場合など、いくつかの状況でファイルが予期しない場所にあると問題が解決する可能性がありますhttp://myserver/../../etc/passwdが、一般的にこの種の間接化では、最小限のセキュリティ上の利点で多くの作業が必要になります。

あなたがそれを置くようにあるだろう最高のことは「完全に役に立たない」です。（それは侵入者に追加のハードルを提供しません）

/etc/passwd アカウント名は含まれていますが、システムへのシェルアクセス権を持つユーザーはだれでもそれらを見つけることができます。

/etc/shadow機密情報（パスワードハッシュ）が含まれていますが、rootだけが読み取ることができます。侵入者がroot権限を取得できた場合、どのようにして災害を綴りますか？

最近のUnices（およびUbuntuを含むUnixライク）に/etc/passwdは、秘密は含まれていません。新しい場所で検索するために再構築する必要のあるユーティリティの数を考えると、名前を変更することは、その価値よりも厄介です。

/etc/shadowそのファイルには秘密があるので別の問題ですが、名前を変更しても役に立ちません。rootだけが読み取ることができるため、ハッカーが他のユーザーとしてシステムに侵入したとしても、ファイルにアクセスするには不十分です。これが、パスワードが/etc/passwd最初に取り出された理由です。すべてのユーザーが読み取り可能/etc/passwdである必要がありますが、実際のパスワードを取得できる必要があるのはrootだけなので、パスワードはrootだけが読み取れるファイルに移動されました。

ハッカーがルートを取得した場合、名前を変更しても保存されません。単純な再帰grepにより、ハッカーはの/etc/shadowような形式のファイルのリストを取得でき、ハッカーはファイルを調べて必要なデータを見つけるだけで済みます。あなたは彼をせいぜい数時間、おそらくはそれ以下に遅らせました：繰り返しますが、/etc/shadowの場所に依存するすべてのユーティリティを変更して再コンパイルするのにかかる時間の価値はありません。

これらのファイルの名前を変更することはできません。これはLinuxシステムの標準であるため、多くのプロセスとプログラムがそれらを検索します。あなたができることは適切な方法であなたのサーバーを保護することです。

/etc/passwdと/etc/shadowファイルの名前を変更することはおそらく役に立たないでしょうが、セキュリティを追加したい場合は、PAM（プラグ可能な認証モジュール）とNSS（ネームサービススイッチ）を確認することをお勧めします。ここのように。

PAMを使用して、標準モジュールから認証情報を読み取る代わりに、LDAPやデータベースなどの他のソースから読み取る認証モジュールを追加できます。それを使用することは、/etc/shadowほぼ完全に排除できることを意味します。

NSSは、名前解決の一部（このユーザーが所属するグループ/etc/passwdなど/etc/groups）を標準ファイル（、）から独立させることにより、PAMを補完します。これを使用すると、passwdファイルにはルートのフォールバックオプションのみが含まれる可能性があり、それ以外は含まれません。SSHキーを使用してrootログインを検証すると、シャドウファイル内にrootパスワードを設定する必要もなくなります（ただし、SSH接続が切断された場合は望ましい場合があります）。

または、別のデータベースまたはLDAPホストを介してユーザーを認証したくない場合は、独自のPAMおよびNSSモジュールを作成して、非標準ファイルからデータを読み取ることもできますが、このオプションはお勧めしません。

それらを使用したい場合は、既知の有効な認証レイヤーへのフォールバックのようなものを維持することを忘れないでください。そうしないと、rootであってもシステムからロックアウトできます。

すべてのアプリケーションがPAMをサポートしているわけではないことに注意してください（ただし、多くのアプリケーションがPAMをサポートしています）。ただし、NSSを使用して、PAMをサポートしないアプリの認証を実装することができます。NSSについて読んだいくつかのサイトでは、実際にこのアプローチを提案しています。ただし、これはNSSモジュールがNSS認証レイヤーにアクセスできるすべてのユーザーに（潜在的に）ハッシュされたパスワードを提供することを意味します。 ）！したがって、このアプローチをとる場合は、常にNSSがユーザーに基本データ（のコンテンツなど/etc/passwd）を提供するためにのみ使用され、PAMが認証レイヤーとして使用されることを確認してください。