コマンドXを実行したroot権限を持つsudoerユーザーを発見しますか？
私はシステムのメインのシステム管理者です。システムには、rootの権限を持つ3人のsudoersユーザーがいます。
システムはバックグラウンドでスクリプトを実行し、システムのユーティリティのハッシュをチェックして、悪意のある変更の可能性を検出します。今日、sshユーティリティのハッシュが変更されたという警告を受けました。
これまで更新はありませんでしたが、これはsudoersの1人が担当していると思います。どのsudoerがsshユーティリティを変更したかを検出することは可能ですか？
RHELを念頭に置いて回答を書きますが、SuSEまたはDebianベースのディストリビューションを使用している場合は、私が説明する内容に類似したものがあることを知っておいてください。
まず、それがシステムアップデートであり、マシンをルートキットしようとしている人ではないことを確認したい場合は、次のようにopenssh-clientsパッケージを「確認」できます。
[root@hypervisor scsd]# rpm -V openssh-clients
[root@hypervisor scsd]#
[root@hypervisor scsd]# rpm -V openssh-server
S.5....T. c /etc/pam.d/sshd
S.5....T. c /etc/ssh/sshd_config
[root@hypervisor scsd]#
openssh-serverも行ったので、何かが変わったときにどのように見えるかを確認できます。重要な部分は「5」で、ファイルのmd5sumがRPMデータベースに存在するものとは異なることを示しています。それがチェックアウトする場合、それはおそらくシステムアップデートが原因でした。
彼らがyumを使用した場合（可能性が高い）、そのRPMの/var/log/yum.logエントリが更新されます。これは、後でyum historyを使用して確認するために、更新が発生した特定の時刻を取得するのに役立ちます。
彼らがrpmを直接使用した場合は、queryformatマジックまたはrpm -q openssh-clients --lastを実行して、発生した日付を取得できます（ただし、その情報はすでに知っているようです）。
呼び出し側ユーザーのauid/loginuidを記録するyumと呼ばれるhistoryサブコマンドがあります。
[root@hypervisor scsd]# yum history
Loaded plugins: product-id, refresh-packagekit, rhnplugin, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
This system is receiving updates from RHN Classic or RHN Satellite.
ID | Login user | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
54 | <jadavis6> | 2013-07-15 09:03 | Install | 2
53 | <jadavis6> | 2013-07-09 17:25 | Update | 23
52 | <jadavis6> | 2013-06-24 10:10 | Install | 3 <
51 | <jadavis6> | 2013-06-14 22:33 | Install | 1 >
50 | <jadavis6> | 2013-06-14 07:47 | E, I, U | 90
49 | root <root> | 2013-06-14 00:58 | Update | 1
48 | <jadavis6> | 2013-06-03 08:28 | Install | 3
47 | <jadavis6> | 2013-05-28 11:57 | Install | 3 <
46 | <jadavis6> | 2013-05-20 18:25 | Install | 1 >
45 | <jadavis6> | 2013-05-20 12:00 | Install | 1
44 | <jadavis6> | 2013-05-19 15:29 | Install | 6
43 | <jadavis6> | 2013-05-18 20:16 | Install | 3
42 | <jadavis6> | 2013-05-16 16:21 | Install | 2 <
41 | <jadavis6> | 2013-05-16 12:48 | Install | 1 >
40 | <jadavis6> | 2013-05-10 09:28 | Install | 1
39 | <jadavis6> | 2013-05-10 09:28 | Install | 1
38 | <jadavis6> | 2013-04-29 19:45 | Install | 2 <
37 | <jadavis6> | 2013-04-29 18:51 | Install | 8 >
36 | <jadavis6> | 2013-04-29 18:35 | Update | 11
35 | <jadavis6> | 2013-04-27 15:44 | E, I, O, U | 429 EE
history list
[root@hypervisor scsd]#
Initの子がスピンオフされると、-1（負の値）のloginuidで始まるため、loginuidは許されません。 ttyまたはsshd pam_loginuid（これを行う他のモジュールもあります）を介してログインすると、認証されたユーザーのUIDに設定されます。 -1以外に設定すると、rootでもこの値を変更できません （ただし、新しいカーネルでのみ）機能しない/アカウンティングのみであり、次のことを考慮する必要があるためです。攻撃者がルートを取得した可能性があります。すべての子は親のloginuidを継承するため、SudoがEUIDがゼロ（またはいずれかのユーザー）のプログラムを生成したとしても、同じloginuidを使用することになります。
これをテストするには、Sudoを共有し、suまたはSudoの呼び出しの数に関係なく、最初にログインしたユーザーがログインするたびにcat /proc/self/loginuidを実行します。それ以来行ってきました。これは、私がrootユーザーとしてすべてを実行したにもかかわらず、yum historyがjadavis6がyum updateを実行したことを知っている方法です。
2つのyumトランザクションの間にあいまいさが存在する場合は、最後のトランザクションについて詳しく知りたい場合と同様に、yum history info <transID>を実行できます。
[root@hypervisor scsd]# yum history info 35
Loaded plugins: product-id, refresh-packagekit, rhnplugin, security,
: subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
This system is receiving updates from RHN Classic or RHN Satellite.
Transaction ID : 35
Begin time : Sat Apr 27 15:44:57 2013
Begin rpmdb : 959:3d300ae2e8dc239f9f972306ba2406bd22ba29bc
End time : 15:50:39 2013 (5 minutes)
End rpmdb : 972:381cb76592ea2f779ee4521a4e7221196520486a
User : <jadavis6>
Return-Code : Success
Command Line : update -y
Transaction performed with:
Updated rpm-4.8.0-27.el6.x86_64 @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Updated subscription-manager-0.99.19.4-1.el6_3.x86_64 @rhel-x86_64-server-6
Updated yum-3.2.29-30.el6.noarch @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Installed yum-metadata-parser-1.1.2-16.el6.x86_64 @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Packages Altered:
Updated NetworkManager-glib-1:0.8.1-34.el6_3.x86_64 @rhel-x86_64-server-6
Update 1:0.8.1-43.el6.x86_64 @rhel-x86_64-server-6
Updated PackageKit-0.5.8-20.el6.x86_64 @rhel-x86_64-server-6
Update 0.5.8-21.el6.x86_64 @rhel-x86_64-server-6
Updated PackageKit-device-rebind-0.5.8-20.el6.x86_64 @rhel-x86_64-server-6
[...snip...]
Updated yum-3.2.29-30.el6.noarch @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Update 3.2.29-40.el6.noarch @rhel-x86_64-server-6
Updated yum-rhn-plugin-0.9.1-40.el6.noarch @anaconda-RedHatEnterpriseLinux-201206132210.x86_64/6.3
Update 0.9.1-43.el6.noarch @rhel-x86_64-server-6
Scriptlet output:
1 warning: /etc/shadow created as /etc/shadow.rpmnew
2 No input from event server.
3 warning: %postun(wdaemon-0.17-2.el6.x86_64) scriptlet failed, exit status 1
history info
これはかなり長いシステムアップデートだったように見えるので、切り捨てました。
AFAIKは、RPMデータベースファイルへの変更を監視するためにrpmを構成する以外に、auditdを介して更新された場合にそれを追跡する方法はありません。そうすることで、ausearchを実行して、変更を加えたPIDと関連付けられたloginuid（auidとして表示されます）のリストを表示できます。
RPMの外部で直接変更した場合は、変更を行う前に、変更を監視する各ファイルを監視する必要があります。事後、多くのことはできませんが、auditdを使用して何かを実行し、ルートキットのターゲットであると思われるファイルを監視することを検討してください。やりすぎると、システムがダウンする可能性があります。悪意のある改ざんを防ぐために、これらのログをサーバーのどこかに出荷する必要があることにも言及する価値があります。
お役に立てば幸いです。
編集：
注意すべき点の1つは、rootがCAP_SYS_AUDITCONTROL（loginuidが現在-1の場合は不要）がある場合、loginuidを変更できるように見えますが、システムのバウンディングセットからその機能を削除できるため、攻撃者はその機能を取得するためにシステムを再起動する必要があります。これは、監査可能なイベントをあちこちに残すため、ノイズが多く、その可能性は低いです。
/var/log/audit/audit.logファイルを調べると、sudoers権限を持つ3人のユーザーの1人がログインしたときにsshファイルが変更された日時を並べることができるはずです。
audit.logファイルには、次のような行が含まれています。
type=USER_START msg=audit(1374006520.730:480): user pid=28303 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/Sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'
type=CRED_ACQ msg=audit(1374006535.446:488): user pid=28352 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: setcred acct="root" : exe="/usr/bin/Sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'
type=USER_START msg=audit(1374006535.448:489): user pid=28352 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/Sudo" (hostname=?, addr=?, terminal=/dev/pts/7 res=success)'
AUID（Affective User ID-別名、Sudoコマンドを実行したユーザー）をバックトラックできます。
したがって、AUID500は私のシステムのこの男です：
$ grep 500 /etc/passwd
sam:x:500:500:Sam M.:/home/sam:/bin/bash
これで、audit.logをgrepできるようになりましたが、ツールausearchを使用してスキャンする方がはるかに簡単です。 1つには、監査ログのタイムスタンプをより人間が読める形式で出力します。
$ ausearch -x /usr/bin/Sudo
...
time->Thu Jul 18 14:41:48 2013
type=CRED_ACQ msg=audit(1374172908.936:45): user pid=21252 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: setcred acct="root" : exe="/usr/bin/Sudo" (hostname=?, addr=?, terminal=/dev/pts/5 res=success)'
----
time->Thu Jul 18 14:41:48 2013
type=USER_START msg=audit(1374172908.937:46): user pid=21252 uid=0 auid=500 subj=user_u:system_r:unconfined_t:s0 msg='PAM: session open acct="root" : exe="/usr/bin/Sudo" (hostname=?, addr=?, terminal=/dev/pts/5 res=success)'
ここでは、ログファイルを検索して、実行可能ファイル（-x /usr/bin/Sudo）を含む一致を探しています。
syslogをチェックしましたか？による man Sudo：Sudoは、成功した試行と失敗した試行の両方（およびエラー）をsyslog（3）、ログファイル、またはその両方に記録できます。デフォルトでは、Sudoはsyslog（3）を介してログに記録しますが、これは構成時に、またはsudoersファイルを介して変更できます。
彼らが意図的にログファイルを削除していない限り、そこに情報を取得できるはずだと思います。時間枠を絞り込むために、SSHユーティリティで変更された日付スタンプを確認できます。