Linuxサーバのセキュリティ監視プラクティス (概要編)

### はじめに
- 近年Linux環境を狙った攻撃（ランサムウェアなど）も増えている
>「ランサムウェア：Windowsに比べれば少ないものの、Linux向けのランサムウェアも存在します。2022年初旬から2023年までに、Linux向けランサムウェアの攻撃が62%増加したことが、2023年上半期セキュリティレポートで報告されています。例として、金融機関を対象としたKillDisk というランサムウェアがあります.」 
>> 引用元：[増加するLinux向けランサムウェア攻撃：2022年年間のLinuxにおける脅威動向分析
](https://www.trendmicro.com/ja_jp/research/23/i/the-linux-threat-landscape-report.html?utm_source=chatgpt.com)
- MITRE ATT&CKの対応OSの中にも[Linux](https://attack.mitre.org/matrices/enterprise/linux/)環境の戦略と戦術が当然のようにある
- Splunk Security Contentsにも[Linux関連のルール](https://research.splunk.com/stories/)が充実してきた
![スクリーンショット 2024-12-15 21.47.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/70837d06-c2a7-f2c2-2912-5c1b4dc9f6f0.png)

- Windowsでおなじみの[Sysmon](https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon)にLinux OS用のモジュールが出ている
    - 数年前は[osquery](https://osquery.io/)を使いましょうと言っていたが、windowsでも慣れているsysmonは統一して監視もしやすいと個人的には思っている 
- 以上の背景からLinuxサーバのセキュリティ監視ベストプラクティスをまとめていくシリーズを始める（まずは概要編）
    - **Sysmon for Linux 導入編**は[こちら](https://qiita.com/odorusatoshi/items/db5269b4e08049e59598)

---
### Linux環境のセキュリティ監視代表ログソース
- 監視に有用なログソース選別の方法として、Splunk Security ContentsからLinuxに関するAnalytics Storyを元に必要なデータおよびルールを見繕ってみた
- というのもMITRE ATT&CKのLinuxにおけるDetection方法を見てみるとざっと以下の様なログソースが必要と出てくる
    - **Chatgptに要約してもらったので全件網羅されているかは不明**
![スクリーンショット 2024-12-15 22.01.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/95678a07-b43d-bcca-3c40-683339fc341b.png)
- この中でも**sysmon**と**auditd**が比較的各ステップで出てくることに気づく
- Splunk Security ContentsのLinux環境における検知ルールを見ても、**sysmon**と**auditd**が大半を占めている事がわかる
- 例：[Compromised Linux Host](https://research.splunk.com/stories/compromised_linux_host/)ルールパックはAuditdを使う
![スクリーンショット 2024-12-15 22.15.50.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/6f26c01c-c6ab-b625-8c59-5e9b530712f1.png)
- 例：[Linux livong off the land](https://research.splunk.com/stories/linux_living_off_the_land/)ルールパックはSysmonも使っている
![スクリーンショット 2024-12-15 22.17.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/82bf0720-1c7c-ed0e-dba2-3fde08ffbe05.png)

- 以上の事から、まず検知ルールが用意されているauditdとsysmonを中心に調査をしてみる
    - **取り込み方法、ログ量、検知テスト**など

---
### 検証環境
![スクリーンショット 2024-12-16 21.26.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/40f77988-4489-f81d-a4c6-a91f0c37ce0a.png)

### auth.log /secure.log
- 概要
    - いきなり上記で全く触れていないデータソースの紹介だが、もっとも簡単に収集ができる定番ログとしてこの2種は紹介しておきたい
    - Authログは主にubuntu、SecureログはRHEL系で出力される
![スクリーンショット 2024-12-15 22.22.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/3873ea91-3471-aef4-4d39-70cd89251608.png)

- 取り込み方法
    - secure.logの場合
        - [Splunk Add-on for Unix and Linux](https://docs.splunk.com/Documentation/AddOns/released/UnixLinux/Sourcetypes)を使ってsourcetype=linux_secureを利用すればOK
    - auth.logの場合
        - 専用のTAは無いが、secure.logと同じでsourcetype=linux_secureを利用すればパースしてくれる。データ構造は近い模様
![スクリーンショット 2024-12-16 18.14.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/8825d2e4-b24f-9640-cd61-31775e739b62.png)

-　容量： 1ホスト 数MB未満/day程度（※ラボ環境）
![スクリーンショット 2024-12-16 15.58.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/8f372b5f-bc17-e8f5-9fa4-f5f630464248.png)


---
### Auditd
- 概要
    - Linuxカーネルの監査フレームワーク（Audit Framework）の一部で、セキュリティ監査ログを収集・管理するデーモン
- **Auditdのインストールと設定**は次回別記事で紹介します
- 取り込み方法
    - [Splunk Add-on for Linux](https://splunkbase.splunk.com/app/3412?)を使ってsourcetype=linux:auditを利用
        - ※昔からある[Splunk Add-on for Unix and Linux](https://docs.splunk.com/Documentation/AddOns/released/UnixLinux/Sourcetypes)の場合、sourcetype=linux_auditとなっており、Security Contentsのサーチがそのまま使えないので注意
- 容量:
    - 1ホスト 2-3GB/day程度（※ラボ環境）
        - **Splunk IndexerサーバのためSplunk関連の挙動を記録しすぎている可能性が高いので、後日Forwaderを入れたubuntuでテスト予定**
![スクリーンショット 2024-12-16 18.23.16のコピー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/acdd11fe-17d9-0f19-b5a0-bfcc8f8bd787.png)


---
### Sysmon for Linux
- 概要
    - Microsoftが開発した[簡易EDR](https://qiita.com/odorusatoshi/items/cb9e1cad00b5eb9efe9b)のLinux版です
- Sysmon for Linuxの導入
    - [github](https://github.com/microsoft/SysmonForLinux)からモジュールを手に入れてインストール
    - ロギング条件をまとめた[Config](https://github.com/splunk/attack_range/blob/develop/configs/SysMonLinux-CatchAll.xml)をインポート
        - schmaversionはインストール時に適用されたdefault値を利用してください
```bash
vi config.xml 

<Sysmon schemaversion="4.81">
<EventFiltering>
    <!-- Event ID 1 == ProcessCreate. Log all newly created processes -->
    <RuleGroup name="" groupRelation="or">
      <ProcessCreate onmatch="exclude"/>
    </RuleGroup>
    <!-- Event ID 3 == NetworkConnect Detected. Log all network connections -->
    <RuleGroup name="" groupRelation="or">
      <NetworkConnect onmatch="exclude"/>
    </RuleGroup>
    <!-- Event ID 5 == ProcessTerminate. Log all processes terminated -->
    <RuleGroup name="" groupRelation="or">
      <ProcessTerminate onmatch="exclude"/>
    </RuleGroup>
    <!-- Event ID 9 == RawAccessRead. Log all raw access read -->
    <RuleGroup name="" groupRelation="or">
      <RawAccessRead onmatch="exclude"/>
    </RuleGroup>
    <!-- Event ID 10 == ProcessAccess. Log all open process operations -->
    <RuleGroup name="" groupRelation="or">
      <ProcessAccess onmatch="exclude"/>
    </RuleGroup>
    <!-- Event ID 11 == FileCreate. Log every file creation -->
    <RuleGroup name="" groupRelation="or">
      <FileCreate onmatch="exclude">
            <TargetFilename condition="begin with">/opt/splunkforwarder/var/lib/splunk/modinputs/journald</TargetFilename> <!--Exclude Splunk Modinput Journal-->
      </FileCreate>
    </RuleGroup>
    <!--Event ID 23 == FileDelete. Log all files being deleted -->
    <RuleGroup name="" groupRelation="or">
      <FileDelete onmatch="exclude"/>
    </RuleGroup>
  </EventFiltering>
</Sysmon>
```

- 取り込み方法
    - [Splunk Add-on for Sysmon for Linux](https://splunkbase.splunk.com/app/6652)を使うとCIMにもマッピングしてくれる
    - inputs設定はlinuxのjournaldをモニタリングする設定がdefaultで有効になっている
```bash
cat /opt/splunk/etc/apps/Splunk_TA_sysmon-for-linux/local/inputs.conf

[journald://sysmon]
index = linuxsysmon
```

- btoolでinputs設定を確認してみると、30秒間隔でjournaldに書きがしていることが分かる
```bash
/opt/splunk/etc/apps/Splunk_TA_sysmon-for-linux/local# /opt/splunk/bin/splunk btool inputs list --debug --app=Splunk_TA_sysmon-for-linux

/opt/splunk/etc/apps/Splunk_TA_sysmon-for-linux/local/inputs.conf   [journald://sysmon]
/opt/splunk/etc/apps/Splunk_TA_sysmon-for-linux/local/inputs.conf   index = linuxsysmon
/opt/splunk/etc/apps/Splunk_TA_sysmon-for-linux/default/inputs.conf interval = 30
/opt/splunk/etc/apps/Splunk_TA_sysmon-for-linux/default/inputs.conf journalctl-exclude-fields = __MONOTONIC_TIMESTAMP,__SOURCE_REALTIME_TIMESTAMP
/opt/splunk/etc/apps/Splunk_TA_sysmon-for-linux/default/inputs.conf journalctl-filter = _SYSTEMD_UNIT=sysmon.service
/opt/splunk/etc/apps/Splunk_TA_sysmon-for-linux/default/inputs.conf journalctl-include-fields = PRIORITY,_SYSTEMD_UNIT,_SYSTEMD_CGROUP,_TRANSPORT,_PID,_UID,_MACHINE_ID,_GID,_COMM,_EXE
/opt/splunk/etc/apps/Splunk_TA_sysmon-for-linux/default/inputs.conf journalctl-quiet = true
/opt/splunk/etc/apps/Splunk_TA_sysmon-for-linux/default/inputs.conf sourcetype = sysmon:linux
```

- 容量
    - 1ホスト 3-4GB/day程度（※ラボ環境）
        -  **Splunk IndexerサーバのためSplunk関連の挙動を記録しすぎている可能性が高いので、後日Forwaderを入れたubuntuでテスト予定**
![スクリーンショット 2024-12-16 18.23.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/a16e9db3-7d62-2c95-cc10-e76dfacf59cd.png)


- **TIPS**: journaldから明示的にsyslog転送をNOにする
    - syslogファイルがsysmonログで溢れます。。。私のubuntu環境の場合、defaultでsyslogにも書き出してしまう設定になっていたため、syslog転送を無効にしました

```bash
sudo nano /etc/systemd/journald.conf
ForwardToSyslog=no

sudo systemctl restart systemd-journald
```

---
### AuditdとSysmonの違い

- Chatgptに「Linux環境のセキュリティ監視におけるauditd とsysmonの用途の違いは？」聞いた際の回答サマリ
![スクリーンショット 2024-12-16 19.00.20.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/89c783ca-f6a0-1d0b-afeb-59c95c3fb92b.png)

- 実際にMITRE ATT&CK の[T1548.003](https://attack.mitre.org/techniques/T1548/003/)で使われるsudoコマンドを叩いてどのように記録されるか検証してみた

![スクリーンショット 2024-12-16 21.03.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/044458ed-d926-608b-23b0-68b403a64575.png)

- 結果、auditdもsysmon両方とも記録されていることがわかった
![スクリーンショット 2024-12-16 21.02.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/e18a102f-6e32-0947-2c19-4ca7993287a0.png)

- 更にSplunk Security Contentsの[Detection: Linux APT Privilege Escalation](https://research.splunk.com/endpoint/4d5a05fa-77d9-4fd0-af9c-05704f9f9a88/)も試してみる

:::note warn
(Detection: Linux APT Privilege Escalationの解説)
Linux システム上で sudo を介して昇格した権限による Advanced Package Tool (APT) の使用を検出します。この分析では、EDR（Endpoint Detection and Response）テレメトリを活用して、APTコマンドがsudo権限で実行されるプロセスを特定します。このアクティビティは、ユーザがrootとしてシステムコマンドを実行できることを示しており、rootシェルへの不正アクセスにつながる可能性があるため、重要な意味を持ちます。悪意があると確認された場合、攻撃者は特権を昇格させ、任意のコマンドを実行し、影響を受けたシステムを完全に制御できるようになり、深刻なセキュリティリスクを引き起こす可能性があります。
:::

- ページ下段にテスト用のDatasetが公開されている
![スクリーンショット 2024-12-16 21.10.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/96fe0787-4329-a1e2-952a-039aff185fea.png)
- datasetのイベントを見てみるとコマンドサンプルがあるので試してみる
![スクリーンショット 2024-12-16 21.11.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/4ce15b4f-de92-1e33-7400-240806261aff.png)
```bash
sudo apt-get update -o APT::Update::Pre-Invoke::=/bin/sh
```

- Security ContentsのSearchを実行
```bash
| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Processes where Processes.process="*apt*" AND Processes.process="*APT::Update::Pre-Invoke::*" AND Processes.process="*sudo*" by Processes.dest Processes.user Processes.parent_process_name Processes.process_name Processes.process Processes.process_id Processes.parent_process_id Processes.process_guid 
| `drop_dm_object_name(Processes)` 
| `security_content_ctime(firstTime)` 
| `security_content_ctime(lastTime)` 
| `linux_apt_privilege_escalation_filter`
```

- 結果、sysmonで記録されている捉えられることがわかりました
![スクリーンショット 2024-12-16 21.09.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/159c88e5-e844-1d18-217b-a48e55f19838.png)


---
### 参考設定
- Splunk謹製のAttack Rangeから参考にする
    - **Sysmon**
        - https://github.com/splunk/attack_range/blob/develop/configs/SysMonLinux-CatchAll.xml
        -  Splunk Add-on for Sysmon for Linuxのマニュアルにも推薦文がある
![スクリーンショット 2024-12-16 18.41.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/185759/91a40dd6-4af0-455b-2573-e8ef2c7346fa.png)

    - **Auditd**
        - https://raw.githubusercontent.com/Neo23x0/auditd/master/audit.rules
        - Attack Range内でもNeo23x0作成のbest practiceを採用していた
            - https://github.com/splunk/attack_range/blob/develop/terraform/ansible/roles/linux_install_auditd/tasks/install_auditd.yml

---
### 次回の記事ネタ
- Auditdの有効化及び設定方法
- Sysmon for Linuxのチューニング方法 (2024.12.22リリース)
    - [Sysmon for Linux 導入編](https://qiita.com/odorusatoshi/items/db5269b4e08049e59598)