LoggingサービスによるOCIでAuditdのログを利用 (2022/08/29)

LoggingサービスによるOCIでAuditdのログを利用 (2022/08/29)

https://learnoci.cloud/use-auditd-logs-in-oci-with-logging-service-5caa13719315

投稿者:Birzu Alexandru-Adrian


ログは重要です。ログが適切に設定されていれば、通常は見逃す可能性のある情報を提供することができるからです。Windowsインスタンスでは、通常のイベントの他に、Windowsログを充実させるためにSysmonを使用するのが私のお気に入りです。


auditdとOCI Loggingの設定を始める前に読むことをお勧めするブログの1つは、.NET Frameworkを提供しています。


  •     Linux監査システムのクイック・イントロダクション
  •     監査ルールを作成する際のヒント
  •     セキュリティ監視のための設定
  •     auditdで何を記録するか
  •     ノイズを管理するためのヒント


Linux auditd for Threat Hunting [パート1]|IzyKnows|Medium|


監視できるAuditdのイベントに関連して、以下のリストを確認することができます。


Audit Event Fields - bfuzzy/auditd-attack Wiki - GitHub



とredhat OS Audit Record Typesの2種類があります。


B.2. 監査記録の種類 Red Hat Enterprise Linux 6|Red Hat Customer Portal


第7章 システム監査 システム監査 Red Hat Enterprise Linux 7 | Red Hat Customer Portal


第14章 システムの監査 システムの監査 Red Hat Enterprise Linux 8 | Red Hat Customer Portal


第12章 システムの監査 システムの監査 Red Hat Enterprise Linux 9 | Red Hat Customer Portal


OracleLinux (OL) は Redhat と同じカーネルを持っているので、上記のドキュメントは OL にも適用されます。


すでにOLインスタンスがあり、Auditdが存在しない場合は、この手順でインストールすることができます。


Auditdを使ったOracle Linuxの監査


では、ステップバイステップで進めていきます。OCIでOL 8インスタンスをプロビジョニングし、カスタムログを有効にし、auditdのログを読むためのAgentの設定も作成しました。









Advanced Parced Options を選択します。



NONEからAuditdに変更し、保存します。



さて、OCI Custom Logs が適切に設定され、動的グループ が対象のインスタンスにアクセスできれば、インスタンスから収集したログを見ることができるはずです。



カスタムログを展開すると、OCI ParserがLoggingで複数の変数を作成できることがわかります。ここから、必要に応じて、または OCI Cloud Guard Insight Log Rules で使用するさまざまな検索を作成することができます。



さて、auditdの基本設定では、Redhatのドキュメントで定義されている、OSからの設定済みのログがすべて表示されます。


もし、OCI LoggingでOSからのログが表示されない場合は、Auditdサービスがインストール/起動されていないことを意味します。これを確認するには、以下を実行します。


    sudo systemctl status auditd



サービスが実行されたら、OCI Loggingサービス のパーミッションを確認します。


auditd サービスで OS からより多くの情報を収集するために、カスタムルールを設定することができます。


OEL 8 を実行している新規作成インスタンスでは、auditd はデフォルトで有効になっており、高度なルールは有効になっていません。監査ルールを確認するには、以下を実行します。


    sudo cat /etc/audit/audit.rules


    sudo cat /etc/audit/rules.d/audit.rules



    sudo auditctl -l


基本的な監視ルールをテストするには、次のコマンドを実行して、ssh 設定ファイルへの アクセスを探します。


    sudo auditctl -w /etc/ssh/sshd_config -p rwxa -k sshd_config


コマンドを実行すると、ルールが処理され使用されていることがわかります。



auditctl によって作成されたルールは、audit.rules ファイルに追加されません。したがって、これらの変更は一時的なものであり、システムのリブートには耐えられません。


etc/audit/rules.d/my.rules にあるカスタム ルールセット ファイルに追加して、ルールを恒久的にします。追加したルールのフォーマットは、auditctl を使用しない場合の auditctl コマンドの構文と一致します。ルールは1行ごとに記述し、パフォーマンスを最適化するために結合する必要があります。


追加できる別のテストルールは次のとおりです。


    sudo auditctl -w /etc/passwd -p wra -k passwd

    sudo auditctl -a exit,always -F arch=b64 -S clock_settime -k changetime







ログを全部見てみると、多すぎて手動で探すのは大変です。



そのため、exclude-records.ruleを使用しています。ルールを確認し、監視に必要なものを削除してください。


linux-audit/exclude-records.rules at main - izysec/linux-audit - GitHub

-a never,exclude -F msgtype=ADD_GROUP -F msgtype=ANOM_ABEND -F msgtype=ANOM_ACCESS_FS -F msgtype=ANOM_ADD_ACCT -F msgtype=ANOM_AMTU_FAIL -F msgtype=ANOM_CRYPTO_FAIL -F msgtype=ANOM_DEL_ACCT -F msgtype=ANOM_EXEC -F msgtype=ANOM_LOGIN_ACCT -F msgtype=ANOM_LOGIN_FAILURES -F msgtype=ANOM_LOGIN_LOCATION -F msgtype=ANOM_LOGIN_SESSIONS -F msgtype=ANOM_LOGIN_TIME -F msgtype=ANOM_MAX_DAC -F msgtype=ANOM_MAX_MAC -F msgtype=ANOM_MK_EXEC -F msgtype=ANOM_PROMISCUOUS -F msgtype=ANOM_MOD_ACCT -F msgtype=ANOM_RBAC_FAIL -F msgtype=ANOM_RBAC_INTEGRITY_FAIL -F msgtype=ANOM_ROOT_TRANS -F msgtype=AVC -F msgtype=AVC_PATH -F msgtype=BPRM_FCAPS -F msgtype=CAPSET -F msgtype=CHGRP_ID -F msgtype=CHUSER_ID -F msgtype=CONFIG_CHANGE -F msgtype=CRED_ACQ -F msgtype=CRED_DISP -F msgtype=CRED_REFR -F msgtype=CRYPTO_FAILURE_USER -F msgtype=CRYPTO_KEY_USER -F msgtype=CRYPTO_LOGIN -F msgtype=CRYPTO_LOGOUT -F msgtype=CRYPTO_PARAM_CHANGE_USER -F msgtype=CRYPTO_REPLAY_USER -F msgtype=CRYPTO_SESSION -F msgtype=CRYPTO_TEST_USER -F msgtype=CWD -F msgtype=DAC_CHECK -F msgtype=DAEMON_ABORT -F msgtype=DAEMON_ACCEPT -F msgtype=DAEMON_CLOSE -F msgtype=DAEMON_CONFIG -F msgtype=DAEMON_RESUME -F msgtype=DAEMON_ROTATE -F msgtype=DEL_GROUP -F msgtype=DEL_USER -F msgtype=DEV_ALLOC -F msgtype=DEV_DEALLOC -F msgtype=EOE -F msgtype=FD_PAIR -F msgtype=FS_RELABEL -F msgtype=GRP_AUTH -F msgtype=INTEGRITY_DATA -F msgtype=INTEGRITY_METADATA -F msgtype=INTEGRITY_HASH -F msgtype=INTEGRITY_PCR -F msgtype=INTEGRITY_RULE -F msgtype=INTEGRITY_STATUS -F msgtype=IPC -F msgtype=IPC_SET_PERM -F msgtype=KERNEL -F msgtype=LABEL_LEVEL_CHANGE -F msgtype=KERNEL_OTHER -F msgtype=LABEL_OVERRIDE -F msgtype=MAC_CIPSOV4_ADD -F msgtype=MAC_CIPSOV4_DEL -F msgtype=MAC_CONFIG_CHANGE -F msgtype=MAC_IPSEC_EVENT -F msgtype=MAC_MAP_ADD -F msgtype=MAC_MAP_DEL -F msgtype=MAC_POLICY_LOAD -F msgtype=MAC_STATUS -F msgtype=MAC_UNLBL_ALLOW -F msgtype=MAC_UNLBL_STCADD -F msgtype=MAC_UNLBL_STCDEL -F msgtype=MMAP -F msgtype=MQ_GETSETATTR -F msgtype=MQ_NOTIFY -F msgtype=MQ_OPEN -F msgtype=MQ_SENDRECV -F msgtype=NETFILTER_CFG -F msgtype=NETFILTER_PKT -F msgtype=OBJ_PID -F msgtype=PATH -F msgtype=RESP_ACCT_LOCK -F msgtype=RESP_ACCT_LOCK_TIMED -F msgtype=RESP_ACCT_REMOTE -F msgtype=RESP_ACCT_UNLOCK_TIMED -F msgtype=RESP_ALERT -F msgtype=RESP_ANOMALY -F msgtype=RESP_EXEC -F msgtype=RESP_HALT -F msgtype=RESP_KILL_PROC -F msgtype=RESP_SEBOOL -F msgtype=RESP_SINGLE -F msgtype=RESP_TERM_ACCESS -F msgtype=RESP_TERM_LOCK -F msgtype=ROLE_ASSIGN -F msgtype=ROLE_MODIFY -F msgtype=ROLE_REMOVE -F msgtype=SELINUX_ERR -F msgtype=SERVICE_START -F msgtype=SERVICE_STOP -F msgtype=SOCKETCALL -F msgtype=SYSTEM_BOOT -F msgtype=SYSTEM_RUNLEVEL -F msgtype=SYSTEM_SHUTDOWN -F msgtype=TEST -F msgtype=TRUSTED_APP -F msgtype=TTY -F msgtype=USER_ACCT -F msgtype=USER_AVC -F msgtype=USER_CHAUTHTOK -F msgtype=USER_CMD -F msgtype=USER_END -F msgtype=USER_ERR -F msgtype=USER_LABELED_EXPORT -F msgtype=USER_LOGOUT -F msgtype=USER_MAC_POLICY_LOAD -F msgtype=USER_MGMT -F msgtype=USER_ROLE_CHANGE -F msgtype=USER_SELINUX_ERR -F msgtype=USER_TTY -F msgtype=USER_UNLABELED_EXPORT -F msgtype=USYS_CONFIG -F msgtype=VIRT_CONTROL -F msgtype=VIRT_MACHINE_ID -F msgtype=VIRT_RESOURCE




MITRE ATT&CK Frameworkを使用したスレットハンティングでは、ここからあらかじめ定義された検出ルールを使用することもできますし、より詳細な粒度を必要とする場合はそれを作成することもできます。


auditd-attack


上記リポジトリからルールをコピーし、正しく有効化されているか確認します。


auditd-attack.rules


ファイルを作成し、ルールを追加した後、ルールが有効になっていないことを確認できます。



これを行うには、実行し、デモのためにエラーを無視することができます。


    augenrules — load



これで、作成したルールファイルのルールが読み込まれ、Key Variableが正しくパースされたかどうかを確認することができます。



このように、data.body.keyフィールドが入力されましたので、次回のブログでは、これを検索に使用できるようにします。


おめでとうございます。これで、OCIでAuditdのログを収集し、正しい方法で解析できるようになりました。


コメント

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

Oracle Enterprise Manager 24aiの概要 (2024/12/18)