sudoを強化するためのベストプラクティスは？

Question

私が読んだすべての強化ガイドでは、ルートアカウントへのログインを禁止し、代わりにSudoを使用することを推奨しています。各グループとユーザーに必要なコマンドのみを有効にする厳密なsudoersファイルを設定すると、これを理解できます。しかし、私が足を踏み入れたすべてのサーバーで、制限のないSudo構成だけを目撃しました。それが良い習慣であるかどうか、またその理由を知りたいのですが（それでも、トレーサビリティの理由はわかっています）？

だからここに私の質問があります：

管理者のアクションの追跡可能性を維持するために、suを禁止し、Sudoを許可するだけで十分ですか？（ユーザーがbash_historyを削除する前に多くのSudoアクションを実行するシナリオを想像できます）
.bash_historyの他に、トレーサビリティを維持するのに役立つ別のソースはありますか？このようなファイルは管理者が（Sudoを使用して）更新できますか？
構成でSudo -iおよびSudo -sを制限することは可能ですか？
Sudo commandは、強力なsudoers設定なしでユーティリティを使用できますか？はいの場合、どれですか？

さらに、単一のユーザーの場合、Sudoを禁止してsuを有効にすることの利点のみがわかります。実際、同じパスワードを使用してrootと通常のユーザーでログオンすることは悪い習慣のようです。

Bryan Field · Accepted Answer

あなたの質問はかなり広範囲で、いくつかの異なる主題に触れています。詳細の一部を取り、それらを別の質問に入れる方が良い場合があります。

管理者のアクションの追跡可能性を維持するために、suを禁止し、Sudoを許可するだけで十分ですか？

... Sudoコマンドは、強力なsudoer設定なしでユーティリティを持つことができますか？どれ？

無制限Sudoには、suに比べていくつかの利点があります。

各sudoerは自分の個人パスワードを使用できます。これにより、変更されたrootパスワードを再配布する必要がなくなります。
Sudoは、アクティビティをログに記録するように構成できます。 syslog構成がリモートの場所に書き込むと、誰かがトラックをカバーすることが困難になります。

ただし、無制限のrootアクセスは引き続き「無制限」です。

リモートsyslogサーバーを使用しない場合は、トラックを簡単にカバーできます。
便宜上、人々はしばしばSudo -sを使用してインタラクティブなシェルを取得します。これにより、制限されたディレクトリでbashオートコンプリートを取得できます。残念ながら、ユーザーがSudo -sの実行を許可されている場合、syslogの特典は無効になります。また、特定のログを記録せずにコマンドを実行できるようにするSudo -sの多くの代替手段があります。

（ユーザーがbash_historyを削除する前に多くのSudoアクションを実行するシナリオを想像できます）

bash_historyは、履歴追跡ツールとして使用されません。これはユーザーの便宜のためだけです。

.bash_historyの他に、トレーサビリティを維持するのに役立つ別のソースはありますか？そのようなファイルは管理者が（Sudoで）更新できますか？

サーバー上のファイルは、rootに無制限にアクセスできるユーザーが更新できます。（Sudoまたはsuを介して）

rootユーザーのアクティビティを追跡する方法は、別の質問の対象となる場合があります。 SELinuxの高度な構成でこれができると思いますが、おそらく実用的ではありません。 rootユーザーのアクティビティを追跡する他の方法は知りません。

私が言ったように、それらが攻撃者によって消去されないようにするためにリモートログサーバーに書き込まれる必要があるログがある場合。

構成でSudo -iとSudo -sを制限することは可能ですか？

逐語的に回答することは可能かもしれませんが、この投稿の範囲を超えています。新しい質問を作成することを検討してください。

ただし、これで問題が解決することはありません。たとえば、Sudo suの代わりにSudo -sを使用できます。 Sudo sudoersを使用したり、crontabを更新したりできます。

これを解決する唯一の方法は、ホワイトリストを使用してSudo機能を「制限」することです。あなたが言ったように、これはそれほど一般的ではありませんが、どんな詳細レベルでも信頼できるトレーサビリティの目標を達成する唯一の方法です。

お役に立てれば。私の回答について説明を求めたり、これまでに学習した内容に基づいて新しい質問がある場合は、より具体的な質問を投稿してください。

Dmitry Grigoryev · Answer

あなたの最後の文章に対処するために、私は実際に私の精神で何かを私のSSHサーバーで行います。そこに2人のユーザーがいます：ssh_userとSudo_user。ログインが許可されているのはssh_userのみですが、彼はsudoersにいないため、su Sudo_userコマンドを発行して作業を完了する必要があります。これにより追加の防御線が提供されます。攻撃者がssh_userの資格情報を取得した場合でも（たとえば、PuTTY構成ファイルを盗むことにより）、Sudoまたは/etc/shadowにすぐにはアクセスできませんサーバー上でSudo_userのパスワードを総当たりにするか、システムでエクスプロイトを実行してrootアクセスを取得する必要があります。

もちろん、攻撃者がssh_userアカウントにアクセスできるようになると、サーバーは危険にさらされますが、実際の被害が発生する前に、このトリックが反応するまでに少し時間がかかると思います。

ilkkachu · Answer

これについては：

同じパスワードを使用してrootと通常のユーザーでログオンすることは悪い習慣のようです。

Sudoは、実行中のユーザーのパスワードの代わりに、「ターゲット」ユーザーのパスワード、またはrootパスワードを要求するように構成できます。したがって、1人のユーザーに対して、個別の非特権パスワードと管理者パスワードを設定できます。非特権アクセスと管理アクセス用に異なるパスワードをすべて持つべき複数の管理者にとって、それは難しく、おそらくuid 0で追加のユーザーを作成するのが最も簡単です。

sudoers（5）から：

[sudo]は、ターゲットユーザー（またはルート）の資格情報ではなく、呼び出しユーザーの資格情報を検証します。これは、後で説明するrootpw、targetpw、runaspwフラグを使用して変更できます。