web-dev-qa-db-ja.com

rootとしてログインしているユーザーを確認するにはどうすればよいですか?

大規模な管理者グループによって管理されているサーバーがいくつかあります。彼らは通常、サービスユーザー(たとえばhudson)としてログインし、次にrootに切り替えて小さな修正を行います。これは、人に加えられた変更をマッピングできないことが多いことを意味します。

どのユーザーがrootとしてログインしたかを教えてくれるUnix/Linux用のスクリプトを持っている人はいますか?ログインは、ローカルLAN上のすべてのコンピューターから行うことができます。 rootとしてLANの外部からリモートアクセスすることはできません。管理者は最初にLANユーザーでログインする必要があり、次に自分自身をrootに昇格させることができます(すべてSSHを使用します)。

私が欲しいのは、(ローカルLANでの)リモートログインを追跡し、一定時間ユーザー名を出力するスクリプトです。スクリプトは、パスワードを要求されることなく、rootとしてローカルLAN上の任意のコンピューターにssh経由でログインできると想定できます。

背景:rootによって編集されたすべてのファイルのバックアップコピーを保存するスクリプトがあります。問題は、誰が実際に変更を加えたかを調べることです。

セキュリティは問題ではありません。これは、wtmpをクリーンアップした可能性のあるハッカーを見つけることではなく、誰がフィードバックを間違えたかを見つけることです。

[EDIT]いくつかのポインタ:コマンドlastは次のことに役立ちます。

> last -t 20101029174200 root
root     pts/26       :0.0             Wed Oct 20 15:36 - 15:03  (23:27)    

wtmp begins Fri Oct  1 16:34:36 2010

したがって、rootpts/26を介してログインしました。他に誰がその疑似TTYに座っていましたか?

> last -t 20101029174200 pts/26
adigulla pts/26       :0               Mon Oct 25 09:45   still logged in   
adigulla pts/26       :0               Fri Oct 22 14:00 - 17:29  (03:29)    
adigulla pts/26       :0               Thu Oct 21 15:04 - 16:05  (01:01)    
root     pts/26       :0.0             Wed Oct 20 15:36 - 15:03  (23:27)    
adigulla pts/26       :0.0             Fri Oct 15 15:57 - 15:57  (00:00)    

wtmp begins Fri Oct  1 16:34:36 2010

うーん...私に違いない。そのため、ローカルマシンでユーザーの変更を追跡できます。リモートマシンにログインする場合:

$ last -1 hudson 
hudson   pts/0        192.168.0.51     Fri Oct 29 17:52   still logged in   

だから私は私が来たPTYとIPアドレスを取得します。 lasthudsonの出力から192.168.0.51のユーザーに接続するにはどうすればよいですか?

[EDIT2]通常、ユーザーはsshSudoではなく、suで変更されることに注意してください。これにより、シングルサインオンが可能になり、管理者にパスワードを通知する必要がなくなります。何かへのアクセスを許可/取り消す場合は、サービスアカウントから公開鍵を追加/削除するだけです。 sshがsyslogにログを記録することも知っていますが、メッセージはどのユーザーがrootに切り替えたかを教えてくれません。

sshd[7460]: Accepted publickey for root from ::1 port 36689 ssh2
6
Aaron Digulla

Rootとして誤ってログインした管理者にフィードバックを提供する最善の方法は、suとSudoを許可したままrootログインを無効にすることだと思います。または、rootの.profileに適切なフィードバックメッセージを表示させ、オプションで終了します。

管理者以外の誰かが誤ってrootとしてログインしている場合は、少なくともrootのパスワードを変更する必要があります:-)


OK、あなたはそれが何を達成したいのかを明確にするために質問を修正しました。ログインを許可するサービスの数を最小限に抑え、すべてのサービスが正常なログインを記録するようにする必要があります。 SSHは、syslogを介して成功したログインを記録します。

「ハドソン」としてログインしている人が何人かいる場合は、それを停止する必要があります。一意のユーザーIDを使用して各ログインを管理するサイトポリシーである必要があります。

ログファイルのローテーションが調整されていることを確認して、必要に応じて古いログを検索できるようにする必要があります。

確かに、syslogから毎日ログインを取得し、重要な構成ファイルのタイムスタンプもチェックするスクリプトをcronによってスケジュールすることができます。

さらに、構成ファイルの変更を監視するためのツールがたくさんあります。多くのUnixシステムには、有効にでき、また役立つ可能性のある監査サブシステムがあります。

個人的には、間違いがあった場合にフィードバックを提供する最善の方法は、誰かに責任を負わせるのではなく、グループ全体に問題を説明し、変更が間違いだった理由を説明し、間違いを防ぐためのアイデアを求めることだと思います。 。

3
RedGrittyBrick

_/var/log/auth.log_を解析することで、誰がルートになっているのかを判断できるはずです。

たとえば、自分のボックスをルートにすると、次のような行が_/var/log/auth.log_に入力されます。

Oct 29 20:10:33 localhost su: pam_unix(su:session): session opened for user root by (uid=1000)

_/etc/passwd_を見ると、次のように表示されます。

_brad:x:1000:100:brad clawsie,,,:/home/brad:/bin/zsh_

これにより、uid1000を名前に関連付けることができます。これを行うためのPerlスクリプトの記述は非常に簡単です。特定の時間範囲、つまり調査しているファイルのmtimeにわたって_/var/log/auth.log_と_/etc/passwd_にわたってuidを結合するだけです。

もちろん、誰かがrootになって、調査しているファイルに対してtouchコマンドを実行した場合、そのmtimeが設定され、ファイルを編集したのはその人であると誤って信じてしまいます。

そもそも問題を回避するためのベストプラクティスを推奨する場合は、すべてスクリプト、cron、構成ファイル...すべてをファイルとして保存することです。実際のユーザーが編集し、何らかの展開ツール(make、aptなど)を使用してライブシステムに適用する必要があるバージョン管理システム。人々が物事を壊し続ける場合は、展開する前に、より上級の開発者に変更を承認してもらいます。

適切なタイミングでコピーを作成できなかった場合、バックアップが役に立たない可能性があります...バージョン管理システムを使用すると、必要な数の編集を元に戻すことができます。

ライブプロダクションシステム上のファイルがルートによってその場で編集されているときはいつでも、それは大きな問題です。 hudsonがシステム上の実在の人物なのか、サービス(つまり、ハドソンサービス)の合成ユーザーなのか、質問ではわかりません。合成ユーザーの場合、このuidが「実際の」ログインシェルを取得する理由を尋ねます。

3
Brad Clawsie

Suの名前をlog_suに変更してから、実際のsu(現在はlog_su)呼び出しをsuという名前のラッパー内に配置します

#!/usr/bin/env bash
$SU_LOG=<path to log file>
echo "User: $USER running su at $(date)" >> $SU_LOG
log_su
1
Jay

使用すると、Sudo suSudo bash、またはSudo -iを使用した場合に、rootとしてログインしたユーザーを通知する小さなプログラムを作成しました。私はそれをより良くそしてより効率的にするためにあちこちに小さなものを追加しているので、私はそれをかなり最近更新していることを知っておいてください。ただし、使用に興味がある場合は、次のリンクにアクセスしてください: https://github.com/StrangeRanger/monitor/tree/master/RLSpy 。プログラムの目的とその機能/障害を説明するREADME.mdファイルがあります。スクリプトは、過去7日以内にrootにログインしたユーザーのみを通知することを知っておいてください。

1
StrangeRanger

SuコマンドとSudoコマンドの両方をパラメーター化して、ログを保持できます。

(1)rootに移動することは頻繁なアクションではなく、(2)通常は同時に複数の管理者がrootになることはなく、ファイル変更のタイムスタンプが与えられているとすると、スクリプトはsu /で簡単に検索できますSudoは、その時点でrootであった管理者を見つけるためにログを記録します。

Sshを使用している場合は、管理者ごとに 認証キーを生成 にして、パスワードメカニズムではなく、ログイン時に使用させることができます。

現在のauthorized_keys sshキーのコメントを取得するにはどうすればよいですか で説明されているように、キーファイルのコメントフィールドを使用して、ログインしている人を識別できます。

残りは同じです。auth.logに対してファイル変更タイムスタンプを使用して、そのファイルを編集したと推定されるsshセッションを識別します。

0
harrymc

また、通常、Sudoやsuではなくsshでユーザーを変更することにも注意してください。これにより、シングルサインオンが可能になり、管理者にパスワードを通知する必要がなくなります。

これはかなりばかげているようです。 Sudoを単純にパスワードを要求しないに構成する代わりに、ローカルホストへのssh-ingのリソース使用(ネットワークバッファー、tty割り当て、無用な暗号化と復号化など)を許容します。 ?

gandalf     ALL = NOPASSWD: ALL

何かへのアクセスを許可/取り消す場合は、サービスアカウントから公開鍵を追加/削除するだけです。

代わりに、対応するエントリを/etc/sudoersから削除することもできます。

Sshがsyslogにログを記録することも知っていますが、メッセージはどのユーザーがrootに切り替えたかを教えてくれません

また、すべての管理者の~/.history(または~/.bash_history)で、sshdによってログに記録された時間の前後のssh呼び出しを確認することもできます。もちろん、これは適度に決定されたnogoodnickが回避するのに十分簡単ですが、rootアクセスを持つ人にとっては何でもです。

それでも、適切に構成されたSudoを使用する方がはるかに優れたオプションです。最新バージョンは/etc/sudoers.d/もサポートしているため、単一の(大きい)/etc/sudoersを編集する代わりに、(小さい)ファイルをサブディレクトリにドロップ/削除できます。

0
Mikhail T.

Linuxには高度な監査システムが含まれており、特定のファイルへのすべての変更を追跡するように設定できます。

From Linux監査について ファイルの変更に加えてSSHログインも追跡するように設定できるので、問題の解決策になる可能性があります。

0
harrymc