sudoインシデントはどこに報告されますか?
1. 概要
Linuxでsudoコマンドを使用すると、rootアクセスを取得して特定のアクティビティを実行できます。 ただし、すべてのユーザーがこのアクセス権を持っているわけではありません。
誰かが許可なくアクセスレベルを上げようとすると、レポートが作成されます。 これらのレポートをカスタマイズまたは確認することをお勧めします。
このチュートリアルでは、 sudo レポートの場所、それらをカスタマイズする方法、および電子メールで送信する方法について説明します。
2. 典型的なsudoインシデントレポート
実行に失敗したイベントに対してシステムがどのように反応するかを見てみましょう。 ユーザーが適切な権限なしでsudoを試したとしましょう。
[unprivileged_user@host ~]$ sudo ls /root
[sudo] password for unprivileged_user:
unprivileged_user is not in the sudoers file. This incident will be reported.
ここでは、システムがアクセスを拒否し、イベントが報告されていることを警告していることがわかります。
ログで試行の詳細を見つけることが期待されます。
Mar 22 21:51:07 fedora sudo[2866]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/ls /root
したがって、管理者として、誰が sudo にアクセスしようとしたのか、いつ、どのようにアクセスしたのかを知ることができます。
3. sudoログレポート
失敗したsudo試行のログを見つけるには、journalctlサービスとrsyslog標準ログファイルの2つの場所があります。
3.1. journalctlコマンド
Linuxは、さまざまなリソースやサービスからログデータを収集します。 systemd-journald.serviceの一部であるjournalctlコマンドを使用してアクセスできます。
パラメータなしでコマンドを呼び出して、すべてのログを検索できます。 ただし、この目的のために、関心のあるコマンドの絶対ファイルパスを指定してフィルターを適用しましょう。
$ journalctl /usb/bin/sudo
Apr 08 07:07:59 fedora sudo[3567]: unprivileged_user : TTY=pts/0 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/less /etc/shadow
May 11 16:53:11 ubuntu sudo[22373]: tester : TTY=pts/0 ; PWD=/home/tester ; USER=root ; COMMAND=/etc/init.d/apache2 start
このフィルターを使用しても、 journalctl コマンドは、関心のないイベントを表示する場合があります。 したがって、エラーに焦点を当てるために、値3(エラーステータス)の優先度フラグ-pを追加しましょう。
$ journalctl -p 3 /usr/bin/sudo
Mar 22 20:08:28 fedora sudo[3944]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/less /etc/shadow
Mar 22 23:25:20 fedora sudo[3944]: unprivileged_user : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/unprivileged_user ; USER=root ; COMMAND=/usr/bin/service httpd stop
3.2. sudoログファイル
sudo インシデントを含むデフォルトのログファイルは、特定のLinuxディストリビューションによって異なります。 より具体的には、最も一般的なLinuxオペレーティングシステムの場合、ログファイルはさまざまなファイルにあります。
- RPMフレーバー(CentOS、Fedora)– / var / log / secure
- Debian-Ubuntuフレーバー(Ubuntu)– /var/log/auth.log
- openSUSE – / var / log / messages
これらのログファイルは、 / etc /sudoersとrsyslogdシステム構成ファイルを編集することでカスタマイズできます。
次のコマンドを呼び出して、構成ファイルの編集を開始します。
$ sudo visudo
次に、次の行を挿入して、代替のイベントログファイルを設定します。
Defaults syslog=local1
次に、好みのテキストエディタを使用して、 /etc/rsyslog.conf ファイル(UbuntuOSの場合は/etc/rsyslog.d/50-default.conf )を編集します。 。 local1ファシリティディレクティブを目的の新しいログファイルに関連付ける必要があります。 このために、他の定義されたロギング機能の上部に次の行を追加します。
local1.* /var/log/sudo.log
最後に、変更をアクティブ化するために、rsyslogdサービスを再起動します。
$ sudo systemctl restart rsyslog
4. sudo電子メールによるレポート
必要に応じて、sudoの警告と一般的な情報を電子メールで通知できます。 / etc / sudoers 構成ファイルを編集することで、これをカスタマイズできます。
4.1. メールオプション
電子メールでレポートを作成するようにシステムを構成してみましょう。 まず、いくつかのディレクティブを追加して、最終レポートを収集する電子メールアカウントを定義します。
Defaults mailto="ubuntu@localhost"
Defaults env_reset
Defaults mail_no_user
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
ここで、非特権ユーザーtesterがcrontabジョブをセットアップしようとするとどうなるか見てみましょう。
$ sudo crontab -e
[sudo] password for tester:
tester is not in the sudoers file. This incident will be reported.
ユーザーとしてテスターそのようなアクションを実行することが許可されていない場合、システムは電子メールを介して警告を起動します mailto 電子メールアドレス
ubuntuユーザーのローカルメールボックスにアクセスする場合:
$ mail
次に、ログに記録された警告を読み取ることができます。
N 7 tester@ubuntu Wed May 11 19:16 16/581 *** SECURITY information for ubuntu ***
このメールでは、このイベントに関連する完全なログを読むことができます。
& 7
Message 7:
From tester@ubuntu Wed May 11 19:16:06 2022
X-Original-To: ubuntu@localhost
To: ubuntu@localhost
From: tester@ubuntu
Auto-Submitted: auto-generated
Subject: *** SECURITY information for ubuntu ***
Date: Wed, 11 May 2022 19:16:06 +0000 (UTC)
ubuntu : May 11 19:16:06 : tester : user NOT in sudoers ; TTY=pts/0 ; PWD=/home/tester ; USER=root ; COMMAND=/usr/bin/crontab -e
同様に、ユーザーが誤ったパスワード( Defaults mail_badpass )を使用して sudo コマンドを実行した場合や、 sudo の場合など、代替オプションを使用して電子メールトリガーをカスタマイズできます。 ]ユーザーがsudoersファイルエントリにリストされていない、または明示的に拒否されたコマンドを実行します(デフォルトのmail_no_perms )。
5. 結論
この記事では、許可なしでsudoを使用しようとしているユーザーについて通知するログエントリを見つける方法を説明しました。
journalctlの使用方法とログファイルの検索方法を確認しました。 また、ロギングを構成する方法と、sudoポリシーの違反時に電子メールメッセージをトリガーする方法についても説明しました。