Windows/Linux

テキストマッチングを利用したAudit.logの監視について

この記事は投稿日から3年以上経過しています。

当記事では、LogStare Collector(以下、LSCと記載)の機能を利用して、LinuxのAudit.logを監視する方法について設定例を交えた説明を記載します。

前提条件

当記事内の説明は下記前提にて検証した内容になります。

# yum list installed | grep audit
audit.x86_64                         2.8.5-4.el7
audit-libs.x86_64                    2.8.5-4.el7
# cat /etc/redhat-release
CentOS Linux release 7.8.2003 (Core)

設定(Linux側)

Auditルールの追加方法

Auditルールの追加方法には、ルール追加後にauditdサービスを再起動すると追加したルールが消失する一時的なルール追加方法と、auditdサービスを再起動しても追加したルールが消失しない永続的なルール追加方法の2種類ございます。

一時的なAuditルール追加方法

auditctlコマンドを使用します。auditctlに続けて追加したいルールを記述しエンターキーを押下します。
下記は/etc/sudoersファイルに対して属性変更があった場合、ログとして記録するルールをauditctlコマンドにて追加する方法です。

  • auditctlにて現在のAuditルールを確認します。※現在の設定によってコマンドの実行結果は下記内容と異なります。
# auditctl -l
No rules
  • auditctlにて追加したいルールを設定します。
# auditctl -w /etc/sudoers -p a
  • auditctlにて追加されたルールを確認します。
# auditctl -l
-w /etc/sudoers -p a

永続的なAuditルール追加方法

OS再起動後も追加したAuditルール設定を永続的に反映させるには、/etc/audit/rules.d/配下のファイルにて設定したいAuditルールを追記し、augenrulesコマンドにてルールを読み込む必要があります。
下記はシステムコール「execve」が呼び出された場合、ログとして記録するルールを/etc/audit/rules.d/配下のファイルに追記してaugenrulesコマンドにてルールを読み込むための方法です。

  • /etc/audit/rules.d/配下のファイルを確認します。
# ls /etc/audit/rules.d/
audit.rules
  • audit.rulesファイルのバックアップを取得します。
# cp /etc/audit/rules.d/audit.rules /etc/audit/rules.d/audit.rules.org
  • auditctlにて現在のAuditルールを確認します。
    ※現在の設定によってコマンドの実行結果は下記内容と異なります。
# auditctl -l
No rules
  • audit.rulesファイルに追加したいルールを追記します。※バージョンによってファイルの中身は異なります。

変更前

# vi /etc/audit/rules.d/audit.rules
## First rule - delete all
-D

## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192

## Set failure mode to syslog
-f 1

変更後

# vi /etc/audit/rules.d/audit.rules
## First rule - delete all
-D

## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192

## Set failure mode to syslog
-f 1

## Rule01
-a always,exit -F arch=b64 -S execve
  • augenrulesにて追加したルールを読み込みます。
# augenrules --load
  • auditctlにて追加されたルールを確認します。
# auditctl -l
-a always,exit -F arch=b64 -S execve

ファイル/ディレクトリアクセス監視のルール設定

特定のファイルまたはディレクトリへのアクセスを監視するためのルール設定について説明します。ファイル/ディレクトリアクセス監視のルールを定義するためには下記の構文を使用します。

-w path_to_file -p permissions -k key_name

構文内の各設定について

-w path_to_file : 監視対象としたディレクトリもしくはファイルパスをpath_to_fileの部分に記載します。
下記は/etc/sudoersを監視対象とする場合の設定例です。

-w /etc/sudoers

-p permissions : ログ出力対象とするパーミッションを設定します。パーミッションは下記の4種類から選択できます。

  • r : ファイルまたはディレクトリーへの読み取りアクセス。
  • w : ファイルまたはディレクトリーへの書き込みアクセス。
  • x : ファイルまたはディレクトリーへの実行アクセス。
  • a : ファイルまたはディレクトリーへの属性変更。

下記は監視対象とした/etc/sudoersに対して読み取りもしくは属性変更が場合、ログとして記録する設定例です。

-w /etc/sudoers -p ra

-k key_name : どのルールにてログが記録されたかを特定する際に役立つオプションです。
下記は監視対象とした/etc/sudoersに対して読み取りもしくは属性変更が発生した場合、記録されるログメッセージ内に「key=sudoers」という文字列を含ませる設定例です。

-w /etc/sudoers -p ra -k sudoers

システムコール監視のルール設定

特定のシステムコールが発生した時にログ出力するためのルール設定について説明します。システムコール監視のルールを定義するためには下記の構文を使用します。

-a action,filter -S system_call -F field=value -k key_name

構文内の各設定について

-a action,filter : 特定のイベントについてログを記録するかどうか、タイミングを指定します。

action:ログ記録の有無を設定できます。下記の2種類より選択します。

  • always : ログを記録します。
  • never : ログを記録しません。

filter:フィルターは、「task」「exit」「user」「exclude」の4種類から選択できます。通常、「exit」を選択します。
下記は特定のシステムコールを監視する場合の設定例です。

-a always,exit

-S system_call : ログに記録するシステムコールを選択します。複数のシステムコールを指定する場合、一つのシステムコール毎に-Sを記載します。すべてのシステムコールを対象とする場合、「-S all」と記載します。
下記はシステムコール「execve」「clone」を監視対象とする場合の設定例です。
※システムコールは英字もしくは数字にて指定します。

-a always,exit -S execve -S 56

-F field=value : 当項目にて設定した要素と合致したイベントのみログに記録されます。
下記はシステムコール「execve」「clone」かつユーザIDが1000以上のイベントを監視対象とする場合、ログとして記録する設定例です。
※システムコール監視のルールを設定する際、エラーメッセージとして、「WARNING - 32/64 bit syscall mismatch in line XX, you should specify an arch」と出力される場合があります。その場合、-Sの前に「-F arch=b32」もしくは「-F arch=b64」を挿入する必要があります。

-a always,exit -F arch=b64 -S execve,56 -F uid>=1000

-k key_name : どのルールにてログが記録されたかを特定する際に役立つオプションです。
下記はシステムコールが「execve」「clone」で、ユーザIDが1000以上のイベントが発生した場合、記録されるログメッセージ内に「key=actions」という文字列を含ませる設定例です。

-a always,exit -F arch=b64 -S execve,56 -F uid>=1000 -k actions

Audit.logのLSCへの出力方法

設定方法についての詳細は以下の記事をご参照ください。
Audit.logをsyslogを利用して収集する方法

その他

SELinux有効時のログについて

SELinux有効時と無効時ではログメッセージの中身が異なります。
下記はSELinux有効時のログサンプルです。

Oct 26 18:11:12 localhost audispd: type=SYSCALL msg=audit(1603703472.072:784): arch=c000003e syscall=2 success=no exit=-13 a0=7fff4dfa27f7 a1=0 a2=1fffffffffff0000 a3=7fff4dfa14e0 items=1 ppid=5588 pid=5607 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=2 comm="cat" exe="/usr/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) ARCH=x86_64 SYSCALL=open AUID="test02" UID="test02" GID="test02" EUID="test02" SUID="test02" FSUID="test02" EGID="test02" SGID="test02" FSGID="test02"

下記はSELinux無効時のログサンプルです。

Oct 26 18:16:16 localhost audispd: type=SYSCALL msg=audit(1603703776.754:690): arch=c000003e syscall=2 success=no exit=-13 a0=7ffe17688843 a1=0 a2=1fffffffffff0000 a3=7ffe17687720 items=1 ppid=5466 pid=5485 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=2 comm="cat" exe="/usr/bin/cat" key=(null) ARCH=x86_64 SYSCALL=open AUID="test02" UID="test02" GID="test02" EUID="test02" SUID="test02" FSUID="test02" EGID="test02" SGID="test02" FSGID="test02"

違いとしてSELinux有効時のみログメッセージ内に追加される項目が存在することが挙げられます。

ログフォーマットの変更方法について

Audit.logのログフォーマットには「RAW」と「ENRICHED」があります。初期設定では「RAW」が選択されています。
下記はログフォーマット「RAW」のログサンプルです。

Oct 26 18:28:34 localhost audispd: node=localhost.localdomain type=SYSCALL msg=audit(1603704514.417:755): arch=c000003e syscall=2 success=no exit=-13 a0=7fffbf773843 a1=0 a2=1fffffffffff0000 a3=7fffbf7724e0 items=1 ppid=5466 pid=5555 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=2 comm="cat" exe="/usr/bin/cat" key=(null)

下記はログフォーマット「ENRICHED」のログサンプルです。

Oct 26 18:31:29 localhost audispd: type=SYSCALL msg=audit(1603704689.827:796): arch=c000003e syscall=2 success=no exit=-13 a0=7ffd2d03a843 a1=0 a2=1fffffffffff0000 a3=7ffd2d038ee0 items=1 ppid=5466 pid=5606 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts1 ses=2 comm="cat" exe="/usr/bin/cat" key=(null) ARCH=x86_64 SYSCALL=open AUID="test02" UID="test02" GID="test02" EUID="test02" SUID="test02" FSUID="test02" EGID="test02" SGID="test02" FSGID="test02"

違いとしてログフォーマット「RAW」にはフィールド「type」の前にフィールド「node」という項目が含まれますが、ログフォーマット「ENRICHED」にフィールド「node」という項目は含まれません。また、ログフォーマット「ENRICHED」では、ユーザIDやグループID等が数字からテキストに変換された形式のメッセージが付与されています。

下記はAudit.logのログフォーマットの変更方法についての説明となります。

  • auditd.confファイルのバックアップを取得します。
# cp /etc/audit/auditd.conf /etc/audit/auditd.conf.org
  • 「RAW」を「ENRICHED」へ変更します。変更箇所は「log_format」です。

変更前

# vi /etc/audit/auditd.conf

local_events = yes
write_logs = yes
log_file = /var/log/audit/audit.log
log_group = root
log_format = RAW
~~省略~~
##krb5_key_file = /etc/audit/audit.key
distribute_network = no

変更後

# vi /etc/audit/auditd.conf

local_events = yes
write_logs = yes
log_file = /var/log/audit/audit.log
log_group = root
log_format = ENRICHED
~~省略~~
##krb5_key_file = /etc/audit/audit.key
distribute_network = no
  • サービスを再起動します。
# service auditd restart

設定(LSC側)

基本設定

設定方法についての詳細は以下の記事をご参照ください。
Audit.logをsyslogを利用して収集する方法

ログ監視設定

監視・収集より監視したい機器を選択し、テキストマッチング文字列の欄に通知を受けたいログで使用される文字列を、設定名欄に説明を設定します。
設定方法についての詳細は下記の記事をご参照ください。
テキストマッチングについて

以下は「ログイン失敗」と「sudoコマンド使用」のログを検知する場合の設定例になります。

 

以下はテキストマッチングにて設定した文字列を検知して、「ログイン失敗」としてアラートメールにて通知されたものです。

以下はテキストマッチングにて設定した文字列を検知して、「sudoコマンドの使用」としてアラートメールにて通知されたものです。

以上でテキストマッチングを利用したAudit.logの監視についての説明は終了となります。

 

記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。

当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。

監視項目データベース更新案内(201008_01)前のページ

FortiGateにおけるTLS通信を利用したSYSLOG送信方法次のページ

ピックアップ記事

  1. Zabbixヒストリデータのレポート生成について
  2. IoT機器「Raspberry pi」とLogStare Collectorで温…
  3. ログフォワーダー「okurun.jar」について
  4. 自社製品をAMIにしてAWSマーケットプレイスへ出品

関連記事

  1. Windows/Linux

    監視対象デバイスのWindows Server 2016 (2019,2012) / Windows…

    当記事では、LogStare Collector にて、Windows…

  2. NW機器

    VMware ESXiにおけるSNMPサービス有効化手順

    当記事では、VMware ESXiにおけるSNMPサービスの有効化方法…

  3. NW機器

    Allied Telesis(インテリジェント・エッジ・スイッチ)にSNMP v1/SNMPv2c設…

    当記事では、Allied Telesis社のインテリジェント・エッジ・…

  4. Windows/Linux

    LogStare CollectorにてUbuntuをSNMP(v1, v2c) で監視するための設…

    当記事では、LogStare CollectorにてUbuntuをSN…

  5. Windows/Linux

    Windowsイベントログの監視について

    当記事では、LogStare Collector(以下、LSCと記載)…

月額200円でM356の監査ログの運用レベルUP LogStare M365

AWSのログ分析・モニタリングに 次世代のマネージド・セキュリティ・プラットフォーム LogStare

  1. NW機器

    PaloAltoのIPsec IKEv1 Phase1におけるトラブルシューティ…
  2. 実践記事

    DNSキャッシュポイズニングやってみた
  3. SNMPを触ってみた

    ログ分析・監視テクニック

    SNMPとは?新入社員が生まれてはじめて触ってみた!
  4. ログ分析・監視テクニック

    nProbeであらゆる通信をログに記録し可視化する
  5. NW機器

    SonicWall UTMにSyslog送信設定を追加する方法について
PAGE TOP