スーパーユーザーのアクティビティを追跡する方法
Linux環境でスーパーユーザーのアクティビティを追跡するための最良の方法を教えてください。
具体的には、次の機能を探しています。
- A）安全なsyslogサーバーへのキーストロークのロギング
- B）シェルセッションを再生する機能（scriptreplayのようなもの）
- C）理想的には、これはサーバーに物理的にアクセスすることなしに回避することは不可能（または非常に困難）なはずです。
異なるシステム管理者（またはサードパーティ）がサーバーで特権操作を実行できるようにする必要がある環境で、セキュリティ/監査の観点からこれについて考えてください。
すべての管理者は自分の名目上のアカウントを持ち、すべての対話型セッションは完全にログに記録される必要があります。たとえば、誰かがmcを使用して重要なファイルを削除または変更した場合、それだけでは十分ではありません。その人がmcコマンドを発行したことを知ってください。mcを起動した後に何が行われたかを正確に確認する方法がなければなりません。
追加メモ：
- Wombleが指摘したように、サーバーで変更を実行するためにroot特権でログインする人を持たず、代わりに構成管理システムを介してそれを行うのが最善のオプションかもしれません。したがって、このようなシステムがなく、同じサーバー上の異なるユーザーにルートレベルのアクセス権を付与する必要がある状況を想定しましょう。
- 私はこれをこっそり行うことにまったく興味がありません。root権限でサーバーにログインするすべての人は、セッションが記録されることを完全に認識します（たとえば、コールセンターのオペレーターが会話を知っているのと同じ方法で）記録されている）
- 誰も汎用スーパーユーザーアカウント（ "root"）を使用しない
- 私は ttyrpld を認識しており、私が探していることを実行しているようです。しかし、その前に、変更されていないカーネルを使用することでこれを解決できるかどうかを知りたいと思います。シェルやカーネルにパッチを適用せずにスーパーユーザーアカウントの完全な監査を可能にする特定のDebian（またはLinux全般）用のツールがあるかどうかを知りたいです。
複数の管理者がいる環境では、可能であればrootを使用しないでください。
すべてにSudoを使用-Sudoは非常に構成可能で、簡単にログに記録できます。
Rootまたはすべてのログインまたはsuをログに記録し、確立されたルールを誰かが行っているときにそれらを調査します。
まず、どのタイプのrootユーザーアクセスを監視したいですか？愚かな管理ミスや悪意のある内部関係者？前者-すでに提案されているように、優れた構成管理ソリューションが必要です。後者-彼らが何をしているのかを彼らが知っているなら、調査する価値がある何かが起こったことを示すのに十分なだけを捕まえることを期待することができるだけです。何らかの不正な活動が開始されたことを知り、その事実について警告を受けたいだけです。それらが賢い場合、（サーバーの状態を変更するか、独自のツールを組み込むことによって）組み込みのログのほとんどを無効にしますが、できればインシデントの始まりをキャッチできます。
そうは言っても、私はあなたが使用できるいくつかのツールを提案します。まず、良いSudoポリシー（既に提案されている）から始めます。次に、これらの管理者にrootシェルアクセスを付与する必要がある場合は、sudoshellを確認してください。 3番目に、おそらく最善の策（最も集中的ですが）で、Linuxカーネル監査を調べます。
あなたができるかもしれないことは、Sudoに this ライブラリを使用し、すべてのユーザーに自分のユーザーアカウントを与え、Sudo -iをEveryoneプロファイルに追加することです。このようにして、彼らは即座にルートにアクセスでき、彼らが使用するすべてのコマンドはログに記録されます。
彼らは根を持っています。あなたが期待できる最高のことは、少なくとも彼らがあなたの小さな監視ユートピアから脱却することを決定したときを見ることですが、それ以上に彼らがしたことは誰かの推測です。
私が考えることができる「最良の」オプションは、広範な構成の自動化と管理の使用を義務付け、リビジョン管理システムを使用してマニフェストを管理し、それを介して更新を展開することです。次に、サーバーへの実際のrootログインを防止します。 （緊急の「ああ、私が何かを壊した」アクセスは、配布されていない、または使用後に変更されたパスワードまたはSSHキーによって提供できます。誰もが、ねじ込まれたシステム管理者を監視して、それらが実行されないようにします。何かを変更します）。
はい、これは不便で面倒ですが、あなたがこの程度までみんなの行動を監視したいほど偏執狂であるなら、私はあなたが不便で、これが勝つ他の点で十分に迷惑な環境にいると思います大きな問題ではないようです。
他の人が言ったように、完全なrootアクセスでユーザーを無効にできない方法でログに記録する方法はほとんどありませんが、debian/ubuntuを実行している場合は snoopy を見てください。あなたが望むものに近い
snoopyは、syslog（authpriv）へのすべての呼び出しを記録するためにlibcによって提供されるexecve（）関数のラッパーとして使用される共有ライブラリにすぎません。システム管理者は、システムの軽い/重いシステム監視、他の管理者のアクションの追跡、システムで何が起こっているかについての良い「感じ」（たとえば、Apacheがcgiスクリプトを実行している）を取得するなどのタスクでスヌーピーが役立つことに気付くでしょう。
Sudoをすべてに使用することについてのdisabledleopardのコメントに同意します。確かに、記録が少し簡単になります。
また、bash履歴ファイルのバックアップを定期的に追加します。見過ごされがちですが、時には素晴らしい情報源になることもあります...ゴールドマンサックスに聞いてください。 ;-)
http://www.guardian.co.uk/business/2009/jul/12/goldman-sachs-sergey-aleynikov
それは難しいでしょう...
rootは注意深くテストされたスクリプトを実行して、すべてのセキュリティ対策（キルモニタリングプロセス）に違反したり、ログファイルを細断処理したり、トリミングしたりできます。
Root権限を与えられた複数の管理者がチームとして働いていると仮定します。また、rootは監視プロセスも強制終了できます。そして残念ながら、そのログイン/パスワードは公開されます。または、彼らは不要な会社を取得します。
UID 0で複数のrootアカウントを作成することはお勧めしませんが、ここで適用できる場合があります。
/ etc/ssh/sshd_configの行を次のように変更します：PermitRootLogin no
がおすすめ。そのため、ここでは、ユーザーが自分の通常のアカウントを使用してログインします（日付時刻スタンプが（偽装されたIPアドレスと一緒に）記録されます）。その後、ルートに切り替えます。 suコマンドの使用
そして、ルートとしての直接ログインはこのように防止されます。
ここでrootができないことを考えなければなりません。
須藤はいいはずです。/etcディレクトリの構成ファイルのバックアップは適切です。/var /ディレクトリログファイルは定期的にメールで送信するか、別のNFSに保存する必要があります。
SMSすべてのrootユーザーの携帯電話、その1つは家にいることができないため、グループに所属するモバイルゲートウェイ会社のAPIを統合するスクリプトを作成するのはどうでしょうか。
SSHの破壊はほとんど問題外です。
お客様のサイトには次の設定があります。
- 同様にオープンして、AD（個人アカウント）のKerberosで認証する
- Unix管理者の特定のADグループのみへの承認
- sudoersグループ== ADグループ
- OSSEC HIDS すべてのサーバー上のエージェントと強化されたサーバー上のマネージャー
- OSSEC Web UI
- Splunk 3 with Splunk-for-OSSEC
サーバーでのすべてのSudoの使用を記録し、ファイルへの変更、パッケージのインストール、疑わしいプロセスなども追跡します。
これまでのところ、これは私が持っているものです：
- sudosh ：AとBをサポートしているようです（ただし、Aについては完全にはわかりません）。
- Sudoscript ：Bをサポートしているようです（Sudoscriptにはsudoshellと呼ばれるコンポーネントがあり、それがromandaが示唆するものである場合は、ヒントをありがとう）
- Snoopy Logger または Sudo_exetrace ：私が探しているものとは異なりますが、良い補足になる可能性があります（これらのリンクについては、theotherreceiveおよびblauwblaatjeに感謝します）。
カーネルや他のシステムコンポーネントにパッチを適用する必要のない他の同様のツールを知っていますか？
すべての機器にアクセスできるターミナルサーバーがいくつかあります。つまり、ターミナルサーバーからでも、物理的にアクセスできる場合でも、何でもログに記録できます。
ターミナルサーバーのSshdには、 http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html がパッチされており、正常に動作しますが、長い間更新されていませんでした。 openssh 4.7で動作するように少し変更しましたが、5.1ではできませんでした。パッチを当てたsshd segfaults、そしてそれを修正するのに十分な時間がない限り、私はttyrpldにほぼ切り替えました。