本番Linuxサーバーで実行されたセキュリティ監査中に誰も使用しないアプリケーションがある場合は、noneユーザーを削除するように求められました。
確認してみると、「nobody」ユーザーが所有するファイルはありません。
find / -path /proc -prune -o -user nobody -ls
「nobody」ユーザーはシェルにログインしません。同様に、ログインしていないユーザーにもセキュリティの脅威がありますか？ログインシェルなしでこれらのユーザーを削除することをお勧めしますか？
# grep nobody /etc/passwd
nobody:x:99:99:Nobody:/:/sbin/nologin
あなたの考えを教えてください。
ベストアンサー1
システムアカウント（ルート、sys、なし、bin、デーモンなど）の存在は、私が長年にわたって経験した多くのセキュリティ監査の対象であり、実際にはいくつかの点にまとめられています。
はい、このタイプのアカウントは、特にシェルが有効になっている場合にセキュリティホールになる可能性があります。
悪い
bin:x:1:1:bin:/bin:/bin/shいいね
bin:x:1:1:bin:/bin:/sbin/nologin
構成されている/sbin/nologinか、/bin/false時々これらのアカウントはログインできませんが、まだプロセスを所有できます。文書を所有することもできます。
ファイルの所有権
どちらも簡単なので、まずファイルの所有権を取得します。
これらのエントリをファイルの所有権に含め/etc/passwdて関連付けるリスクはありません。/etc/groupこの容量でこれらの機能がある場合、ツールの出力はls次のように表示されます。
/etc/passwdにエントリがあります。
$ ls -l woof -rwxrwxr-x 1 saml saml 20284 May 31 2012 woof/etc/passwdにアクセスできません。
$ ls -n woof -rwxrwxr-x 1 500 501 20284 May 31 2012 woof
したがって、この観点からは、管理者がディスクに書き込まれたUID / GIDで所有者名を表示できるようにする方が良いでしょう。ただし、これらの項目は、システムでUID / GIDを生成するための追加の適用を提供しません。たとえば、次のようになります。
$ touch afile && chown 10000:10000 afile
$ ls -l | grep afile
-rw-r--r-- 1 10000 10000 0 Jun 11 05:11 afile
これらのエントリが存在する場合に発生する唯一の実際のリスクは、潜在的な攻撃者がファイルシステムからファイルを隠し、ファイルに本当の所有権を付与することで、そのファイルがそのファイルに属しているように見える可能性があること/etc/passwdです。/etc/group
プロセス所有権
これは、実際にはほとんどの監査人が監査を実行する際に困難に遭遇する問題です。システムアカウントの項目です/etc/passwd。彼らはファイルのエントリが範囲を制限するという印象を受けました。しかし、ここに問題があります。同様に、/etc/passwd断片化されたUID / GIDを持つファイルを生成する機能は制限されず、プロセスが目的のUID / GIDを使用して実行することを強制しません。
次のQ&Aをご覧ください。setuidは非常に大きな数を設定します。。
UNIXには、プロセス所有者を制御する4つのC関数があります。
setuid()- ユーザーIDの設定seteuid()- 有効なユーザーIDの設定setgid()- グループIDの設定setegid()- 有効グループIDの設定
より高い権限を持つアカウントで実行している場合は、必要に応じてこれらの機能を呼び出すことができます。たとえば、
setuid(500); setuid(0);回答：500/500（最初の呼び出しは500/500を生成し、2番目の呼び出しは失敗します）seteuid(500); setuid(0);答え：0/500（最初の呼び出しは500/500を生成し、2番目の呼び出しは0/500を生成します）。seteuid(600); setuid(500);回答：500/500（最初の呼び出しは600/500を生成し、2番目の呼び出しは500/500を生成します）。seteuid(600); setuid(500);setuid(0);答え：0/500（最初の呼び出しは600/500を生成し、2番目の呼び出しは500/500を生成し、3番目の呼び出しは0/500を生成します）。
上記のコードはここで借りました：Set-UID特権プログラム - 配布資料。
したがって、ユーザーの立場を考慮して誰も昇格された権限（例sudo：）がない場合、サーバー/サービスを次のように実行するオプションはありません。誰も以下を除くすべての子プロセスを作成できます。誰も。このサーバー/サービスが誰も実行していない場合、所有しているファイルだけが破損します。誰も危険があります。
提供する
システム保護にアクセスする際に集中する必要がある最も重要な分野は、特定のシステムで実行されているサービスとそのシステムにインストールされているソフトウェアです。
本番システムの場合、インストールにはgcc / g ++などの開発ツールは含まれてはならず、基本サービスのみを実行する必要があります。システムにインストールされているソフトウェアを定期的に更新するための更新戦略を開発する必要があります。
まとめると、これはファイル内のシステム関連アクティビティの他のアカウントの存在とは関係ありません/etc/passwd。
Windows
ここで言及する理由は、最終的に10人の監査人のうち9人がWindowsセキュリティに精通しており、UNIXセキュリティにはあまり慣れていないからです。
Windowsシステムを見ると、特定のユーザーに直接関連付けられていない12のユーザーアカウントを表示できます。これはシステムアカウントであり、その目的は次のアカウントと同じです。誰も供給。この機能が無効または無効になっていると、Windowsシステムは効率的に実行されません。 UNIXシステムでも同様です。
一般に、このように説明すると、ほとんどの監査人は、これらのアカウントが必要な特定のシステムで維持される可能性があるか、または維持されるべき理由を理解できます。