Wazuhを触ってみた

# この記事について
Wazuhでどんなことができるのかと自分の手で確かめてみたかったので、公式マニュアルを見ながら何ができるのかをいじった記録として残す。
公式マニュアルが充実してるのでWazuh自体は割と簡単にいじることができるが、背景としてLinuxやセキュリティやらの知識がある程度必要。

## Wazuhとは何か？
OSSのセキュリティ監査基盤、という位置づけらしい。ossecにElasticSearchとKibanaをかぶせたもの、と言ってもいいかもしれない。（ossecは廃れたと思ったらこんな形で復活していたとは）
アーキテクチャやらなんやらは公式マニュアルに書いてある。
https://documentation.wazuh.com/current/getting-started/architecture.html

# Wazuhセットアップ
2021年3月時点での記録。

## Wazuh Serverのインストール
All-in-one構成で構築。
VirtualBoxでVMたててCentOS7.9をいれてWazuh Serverをインストールする。
VMは下記スペック。

|  |  |
|:-:|:-:|
| OS | CentOS7.9 |
| CPUコア | 1 |
| メモリ | 4G |
| ディスク | 20G |
| NW | NATとホストオンリーアダプタ |

CPUやメモリがカツカツだがこれでも動く。
VMたててOS入れたら、下記手順に従って淡々と手を動かせばインストールできる。
https://documentation.wazuh.com/current/installation-guide/open-distro/all-in-one-deployment/all_in_one.html
Wazuhのバージョンは4.1.1でインストールされた。
多分現時点の安定板の最新なんだろう。

一気にインストールするスクリプトもあるみたいだが、step-by-stepでインストールしたほうが、何を入れてるのか自分で納得しながらできるので良い。
入れるもの入れたらhttps://＜WazuhサーバのIP＞/でアクセスし、Kibanaログイン画面でadmin/adminと入れればダッシュボードが見れるようになる。

![dashboard.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/367048/aab2ea99-e3c5-e7a6-be93-80667634e537.png)

上記画像でTotal agentsやActive agentsが1になってるのは下記手順でAgent入れたから・・・

## Wazuh Agentのインストール
Wazuh Severには自分自身監視用のAgentが入っているが、せっかくなので他のVMにAgentを入れて監視できるかを見る。
Serverと同様に監視対象となるVMを適当にたてる。OSはUbuntu20にした。

|  |  |
|:-:|:-:|
| OS | Ubuntu20 |
| CPUコア | 1 |
| メモリ | 1G |
| ディスク | 10G |
| NW | NATとホストオンリーアダプタ |

この環境に対してWazuh agentをインストールする。
WAZUHアイコンの横の矢印クリックしてメニューを開き「Agents」を選択してAgent管理画面に移動。

![menu.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/367048/5c0265d7-acd6-d7fa-6fb6-a76b9ffc0958.png)

Agent管理画面で「Deploy new Agent」をクリックするとOSやらなんやら指定する画面が出てくるので適当に選択する。Wazuh server addressのところはさっき立てたWazuh Serverのアドレスをいれる。グループはdefaultが最初からあるので、それを選択。「Install and enroll the agent」のところでインストールに必要なコマンドが出てくるので、それをコピって監視対象のVMにagentインストール。

インストールしたらwazuh-agentサービス起動する。
AgentがServerにうまく接続するようになったら一覧で下記のように確認できる。

![agent-list.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/367048/dd6edc7c-31ba-b9d1-9e17-08c16437a6d1.png)

監視対象であるUbuntuノード側で適当にsshを失敗してみたり、何かパッケージを入れてみたりするとManager側にいろいろとイベントが飛んでダッシュボードの画面に表示される。（ModulesのSecurity Evnet画面とか）


# カスタマイズ
Wazuhの機能一覧は下記にある通り。
https://documentation.wazuh.com/current/user-manual/capabilities/index.html

大雑把に言えば、ルール設定に基づいたログ集めと可視化、アラート通知といったところか。あとOpenSCAPを使った構成監査がある。
とにかく機能が豊富すぎるので、これを全部使いこなすのは非常に大変。
自分が欲しいもの以外は適当に切り捨てながらカスタマイズしていかないと素では使えない。
主にいじるのは/var/ossecの中となる。

```
[root@wazuh-manager ossec]# pwd
/var/ossec
[root@wazuh-manager ossec]# ls
active-response  agentless  api  backup  bin  etc  framework  integrations  lib  logs  queue  ruleset  stats  tmp  var  wodles
[root@wazuh-manager ossec]# 
```

## 閾値設定
雑魚イベントを集めて表示していてもうるさいだけなのでレベルを調整する。
https://documentation.wazuh.com/current/user-manual/manager/alert-threshold.html

/var/ossec/etc/ossec.confの下記のあたりの数字をいじる。

```
  <alerts>
    <log_alert_level>7</log_alert_level>
  </alerts>
```

設定が終わったらsystemctl restart wazuh-managerで再起動。

## Slackに通知
メールはだるいので一定の閾値超えたアラートをSlackに飛ばしたい。
ということでSlack通知設定。Slack側でIncoming Webhookを作り、Wazuh側でIntegration設定する。
下記のような感じの内容でossec.confに追記する。

```/var/ossec/etc/ossec.conf
  <integration>
    <name>slack</name>
    <hook_url>https://hooks.slack.com/services/XXXX/XXXX/XXXXX</hook_url>
    <alert_format>json</alert_format>
    <level>10</level>
  </integration>
```

うまく設定できていれば、Slackに通知が飛ぶはず。
ほかにもPagerDutyやらViruaTotalやらと連携できるらしい。
https://documentation.wazuh.com/current/user-manual/manager/manual-integration.html

## ルール設定
まずはossecのルールを最新に更新。

```
[root@wazuh-manager ~]# /var/ossec/bin/update_ruleset
```

更新したルールは下記の場所に格納されている。

```
[root@wazuh-manager ruleset]# pwd
/var/ossec/ruleset
[root@wazuh-manager ruleset]# ls
decoders  rules  sca  VERSION
[root@wazuh-manager ruleset]# cd rules
[root@wazuh-manager rules]# ls
0010-rules_config.xml            0230-ms-se_rules.xml             0470-vshell_rules.xml
0015-ossec_rules.xml             0235-vmware_rules.xml            0475-suricata_rules.xml
0016-wazuh_rules.xml             0240-ids_rules.xml               0480-qualysguard_rules.xml
0020-syslog_rules.xml            0245-web_rules.xml               0485-cylance_rules.xml
0025-sendmail_rules.xml          0250-apache_rules.xml            0490-virustotal_rules.xml
0030-postfix_rules.xml           0255-zeus_rules.xml              0495-proxmox-ve_rules.xml
0035-spamd_rules.xml             0260-nginx_rules.xml             0500-owncloud_rules.xml
0040-imapd_rules.xml             0265-php_rules.xml               0505-vuls_rules.xml
0045-mailscanner_rules.xml       0270-web_appsec_rules.xml        0510-ciscat_rules.xml
0050-ms-exchange_rules.xml       0275-squid_rules.xml             0515-exim_rules.xml
0055-courier_rules.xml           0280-attack_rules.xml            0520-vulnerability-detector_rules.xml
0060-firewall_rules.xml          0285-systemd_rules.xml           0525-openvas_rules.xml
0065-pix_rules.xml               0290-firewalld_rules.xml         0530-mysql_audit_rules.xml
0070-netscreenfw_rules.xml       0295-mysql_rules.xml             0535-mariadb_rules.xml
0075-cisco-ios_rules.xml         0300-postgresql_rules.xml        0540-pfsense_rules.xml
0080-sonicwall_rules.xml         0305-dropbear_rules.xml          0545-osquery_rules.xml
0085-pam_rules.xml               0310-openbsd_rules.xml           0550-kaspersky_rules.xml
0090-telnetd_rules.xml           0315-apparmor_rules.xml          0555-azure_rules.xml
0095-sshd_rules.xml              0320-clam_av_rules.xml           0560-docker_integration_rules.xml
0100-solaris_bsm_rules.xml       0325-opensmtpd_rules.xml         0565-ms_ipsec_rules.xml
0105-asterisk_rules.xml          0330-sysmon_rules.xml            0570-sca_rules.xml
0110-ms_dhcp_rules.xml           0335-unbound_rules.xml           0575-win-base_rules.xml
0115-arpwatch_rules.xml          0340-puppet_rules.xml            0580-win-security_rules.xml
0120-symantec-av_rules.xml       0345-netscaler_rules.xml         0585-win-application_rules.xml
0125-symantec-ws_rules.xml       0350-amazon_rules.xml            0590-win-system_rules.xml
0130-trend-osce_rules.xml        0360-serv-u_rules.xml            0595-win-sysmon_rules.xml
0135-hordeimp_rules.xml          0365-auditd_rules.xml            0600-win-wdefender_rules.xml
0140-roundcube_rules.xml         0375-usb_rules.xml               0601-win-vipre_rules.xml
0145-wordpress_rules.xml         0380-redis_rules.xml             0602-win-wfirewall_rules.xml
0150-cimserver_rules.xml         0385-oscap_rules.xml             0605-win-mcafee_rules.xml
0155-dovecot_rules.xml           0390-fortigate_rules.xml         0610-win-ms_logs_rules.xml
0160-vmpop3d_rules.xml           0395-hp_rules.xml                0615-win-ms-se_rules.xml
0165-vpopmail_rules.xml          0400-openvpn_rules.xml           0620-win-generic_rules.xml
0170-ftpd_rules.xml              0405-rsa-auth-manager_rules.xml  0625-cisco-asa_rules.xml
0175-proftpd_rules.xml           0410-imperva_rules.xml           0625-mcafee_epo_rules.xml
0180-pure-ftpd_rules.xml         0415-sophos_rules.xml            0630-nextcloud_rules.xml
0185-vsftpd_rules.xml            0420-freeipa_rules.xml           0635-owlh-zeek_rules.xml
0190-ms_ftpd_rules.xml           0425-cisco-estreamer_rules.xml   0640-junos_rules.xml
0195-named_rules.xml             0430-ms_wdefender_rules.xml      0675-panda-paps_rules.xml
0200-smbd_rules.xml              0435-ms_logs_rules.xml           0680-checkpoint-smart1_rules.xml
0205-racoon_rules.xml            0440-ms_sqlserver_rules.xml      0685-macos-sshd_rules.xml
0210-vpn_concentrator_rules.xml  0445-identity_guard_rules.xml    0690-gcp_rules.xml
0215-policy_rules.xml            0450-mongodb_rules.xml           0700-paloalto_rules.xml
0220-msauth_rules.xml            0455-docker_rules.xml
0225-mcafee_av_rules.xml         0460-jenkins_rules.xml
[root@wazuh-manager rules]# 
```

ここの内容は更新されてしまうものであるため、ルールをカスタマイズする場合は以下のlocal_rules.xmlファイルをいじることになる。

```
[root@wazuh-manager rules]# pwd
/var/ossec/etc/rules
[root@wazuh-manager rules]# ls 
local_rules.xml
[root@wazuh-manager rules]# 
```

下記のマニュアルに従いルールをカスタマイズ。
https://documentation.wazuh.com/current/user-manual/ruleset/custom.html

基本は既存ルールをコピってルールを上書きするような使い方となる。
例えば、SCAの19007のルールがうるさい！レベル下げてやる！と思った場合は下記のような手順をとる。
まず、対象のルールが書かれたxmlファイルを特定し、内容を見る。
/var/ossec/ruleset/rules/0570-sca_rules.xml 

```/var/ossec/ruleset/rules/0570-sca_rules.xml 
  <rule id="19007" level="7">
    <if_sid>19006</if_sid>
    <field name="sca.check.result">^failed</field>
    <options>no_full_log</options>
    <description>$(sca.policy): $(sca.check.title)</description>
  </rule>
```

この内容をコピって下記のような内容をlocal_rules.xmlに追記する。

```/var/ossec/etc/rules/local_rules.xml
<group name="sca,gdpr_IV_35.7.d,pci_dss_2.2,nist_800_53_CM.1,tsc_CC7.1,tsc_CC7.2,">
  <rule id="19007" level="5" overwrite="yes">
    <if_sid>19006</if_sid>
    <field name="sca.check.result">^failed</field>
    <options>no_full_log</options>
    <description>$(sca.policy): $(sca.check.title)</description>
  </rule>
</group>
```

変更点はlevelを5にしたところとoverwrite="yes"にしたところ。
特にoverwrite="yes"が大事。これがないとエラーになる。

# 具体的に何が検知できるのか
下記の内容をつまみ食いする。
https://documentation.wazuh.com/current/learning-wazuh/index.html

## SSH Bruteforce Attackの検知
下記の内容に従って試してみる。
https://documentation.wazuh.com/current/learning-wazuh/ssh-brute-force.html

### 攻撃の準備
Bruteforce Attackの道具としてhydraを使う。まずはインストール。

```
[root@wazuh-manager ~]# yum install https://forensics.cert.org/cert-forensics-tools-release-el7.rpm
[root@wazuh-manager ~]# yum install hydra crunch -y
```

crunchで適当にパスワードリストを作る。

```
[root@wazuh-manager ~]# crunch 2 2 -o password.txt
```

Wazuhのアラートログで何が出るか見るためにtail -fをしておく。

```
[root@wazuh-manager ~]# tail -f /var/ossec/logs/alerts/alerts.log 
```

### 攻撃開始
さあ攻撃だ！
下記のような内容を実行すれば、パスワードリストを使ってsshしまくる。

```
[root@wazuh-manager ~]# hydra -l logintest -P password.txt 192.168.56.101 ssh
```

しばらくするとドバドバとアラートが出てくるのが見れるはず。
ダッシュボードでは下記のように表示される。

![bruteforce_event.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/367048/dd3ea5c6-d486-1060-5af0-e7a365fcbc66.png)

`syslog: User missed the password more than one time`というLevel 7のメッセージが大半だが`sshd: brute force trying to get access to the system`というLevel 10のメッセージも入っているはず。
Searchのところで`NOT rule.level: 7`といれてやればフィルタ出来るので探しやすい。

Slackにも通知が飛んでいる。
![ssh_slack.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/367048/4295c138-eab5-a513-cb53-12d789537214.png)

メールなり、Slackなりで通知を受け取った人がWazuhのダッシュボード見てさらに調べる、といった運用が可能だと思う。

### Active Responseの設定
SSH Bruteforceのような凶悪なものは検知したら即防ぎたいもの。
ZabbixのトリガーのようにWazuhもアラートに応じたアクションが行えて、Active Responseという。
概要は下記のあたりに記載されている。
https://documentation.wazuh.com/current/user-manual/capabilities/active-response/how-it-works.html

Active Responseとして実行されるスクリプト類は`/var/ossec/active-response/bin`に置くことになっている。

```
[root@wazuh-manager bin]# pwd
/var/ossec/active-response/bin
[root@wazuh-manager bin]# ls 
default-firewall-drop.sh  firewall-drop.sh   ipfw_mac.sh   kaspersky.sh    ossec-tweeter.sh  restart.sh
disable-account.sh        host-deny.sh       ipfw.sh       npf.sh          pf.sh             route-null.sh
firewalld-drop.sh         ip-customblock.sh  kaspersky.py  ossec-slack.sh  restart-ossec.sh
```

Active Responseとして実行されるコマンド定義等はossec.confの中でずらずらと設定されているcommandタグの部分で、以下のような感じで設定されている。

```
  <command>
    <name>host-deny</name>
    <executable>host-deny.sh</executable>
    <expect>srcip</expect>
    <timeout_allowed>yes</timeout_allowed>
  </command>
```

Active Responceが仕事するか確認する。
今回のBruteforceで検知される5712のルールに対して反応するように、サーバ側のossec.confでactive-responseタグを以下のように追記する。

```/var/ossec/etc/ossec.conf 
  <!-- Active Response --> 
  <active-response>
    <command>host-deny</command>
    <location>local</location>
    <rules_id>5712</rules_id>
    <timeout>60</timeout>
  </active-response>
```

設定が終わったらwazuh-managerを再起動。
hydraで攻撃してしばらくすると、Active Responseが動いて/etc/hosts.denyに攻撃元IPが追記される。
Wazuh Agent側で下記のようなログがでる。

```/var/ossec/logs/active-responses.log 
root@mypc:~# tail /var/ossec/logs/active-responses.log 
2021年  3月  8日 月曜日 20:31:16 JST /var/ossec/active-response/bin/host-deny.sh add - 192.168.56.102 1615203076.5570 5712
2021年  3月  8日 月曜日 20:32:17 JST /var/ossec/active-response/bin/host-deny.sh delete - 192.168.56.102 1615203076.5570 5712
```

timeoutを60にしていたので60秒たったら/etc/hosts.denyから対象のIPが自動削除される。

## 特定コマンド実行の検知
auditdを使ったコマンド実行検知をためす。
https://documentation.wazuh.com/current/learning-wazuh/audit-commands.html

### サーバ側設定
まず、local_rules.xmlに設定を追加してwazuh-manager再起動。

```/var/ossec/etc/rules/local_rules.xml
<group name="audit">
  <rule id="100200" level="12">
      <if_sid>80792</if_sid>
      <list field="audit.command" lookup="match_key">etc/lists/suspicious-programs</list>
      <description>Audit: Suspicious Command: $(audit.exe)</description>
      <group>audit_command,</group>
  </rule>
</group>
```

/var/ossec/etc/lists/audit-keysの内容を下記のように編集。

```/var/ossec/etc/lists/audit-keys
audit-wazuh-w:write
audit-wazuh-r:read
audit-wazuh-a:attribute
audit-wazuh-x:execute
audit-wazuh-c:command
```

監視対象となるコマンドを設定

```/var/ossec/etc/lists/suspicious-programs
ncat:
nc:
tcpdump:
ping:
```

上記に設定したコマンドが実行されると発生するアラートをlocal_rules.xmlに設定。

```/var/ossec/etc/rules/local_rules.xml
<group name="audit">
  <rule id="100200" level="10">
      <if_sid>80792</if_sid>
      <list field="audit.command" lookup="match_key">etc/lists/suspicious-programs</list>
      <description>Audit: Suspicious Command: $(audit.exe)</description>
      <group>audit_command,</group>
  </rule>
</group>
```

Slackに飛ばす設定をlevel 10にしてたからこのアラートもLevel 10にしてみた。
上記設定が完了したらwazuh-managerを再起動。

### 監視対象側設定

監視対象側のauditdのルール設定をいじる。

```/etc/audit/rules.d/audit.rules
-a exit,always -F egid!=994 -F auid!=-1 -F arch=b64 -S execve -k audit-wazuh-c
```

ルール反映。

```
root@mypc:~# auditctl -R /etc/audit/rules.d/audit.rules
エラーが出なければOK
root@mypc:~# auditctl -l
-a always,exit -F arch=b64 -S execve -F egid!=994 -F auid!=-1 -F key=audit-wazuh-c
```

### 実験
監視対象側でpingを実行してみる。

```
root@mypc:~# ping 8.8.8.8
```

すると、サーバ側のalerts.logに下記のようなログがでる。

```/var/ossec/logs/alerts/alerts.log 
** Alert 1615106851.59733: - auditaudit_command,
2021 Mar 07 03:47:31 (mypc) any->/var/log/audit/audit.log
Rule: 100200 (level 10) -> 'Audit: Suspicious Command: /usr/bin/ping'
type=SYSCALL msg=audit(1615106850.098:85): arch=c000003e syscall=59 success=yes exit=0 a0=55706846a980 a1=5570685a89e0 a2=557068561540 a3=8 items=2 ppid=6938 pid=7125 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=16 comm="ping" exe="/usr/bin/ping" subj=unconfined key="audit-wazuh-c" type=EXECVE msg=audit(1615106850.098:85): argc=2 a0="ping" a1="8.8.8.8" type=CWD msg=audit(1615106850.098:85): cwd="/root" type=PATH msg=audit(1615106850.098:85): item=0 name="/usr/bin/ping" inode=393365 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0000000000002000 cap_fi=0 cap_fe=1 cap_fver=2 cap_frootid=0 type=PATH msg=audit(1615106850.098:85): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=394609 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1615106850.098:85): proctitle=70696E6700382E382E382E38
audit.type: SYSCALL
audit.id: 85
audit.arch: c000003e
audit.syscall: 59
audit.success: yes
audit.exit: 0
audit.ppid: 6938
audit.pid: 7125
audit.auid: 0
audit.uid: 0
audit.gid: 0
audit.euid: 0
audit.suid: 0
audit.fsuid: 0
audit.egid: 0
audit.sgid: 0
audit.fsgid: 0
audit.tty: pts0
audit.session: 16
audit.command: ping
audit.exe: /usr/bin/ping
audit.key: audit-wazuh-c
audit.execve.a0: ping
audit.execve.a1: 8.8.8.8
audit.cwd: /root
audit.file.name: /usr/bin/ping
audit.file.inode: 393365
audit.file.mode: 0100755
```

Slackにも通知がいってる。

![cmd_slack.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/367048/fad77070-776e-d5a1-4bef-665aa49589d3.png)

もちろんダッシュボードでもこのイベントは確認できる。

## ファイル変更の検知
下記を参考にファイル変更を検知する設定を入れる。
https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/fim-configuration.html
ファイル監視は一定周期でのスキャンとリアルタイム検知がある。
たとえば、/root直下をリアルタイム検知しようとした場合はossec.confのsyscheckの中で下記のように書く。

```/var/ossec/etc/ossec.conf
  <!-- File integrity monitoring -->
  <syscheck>
    <directories check_all="yes" realtime="yes" report_changes="yes">/root</directories>
```

この設定を監視対象側で行い、wazuh-agentの再起動を行う。
監視できているか適当なファイルを作って確認する。

```
root@mypc:~# echo "test1" > test
root@mypc:~# echo "test2" > test
root@mypc:~# rm test
```

サーバ側のalerts.logで下記のようなログが出てくる

```/var/ossec/logs/alerts/alerts.log 

** Alert 1615114239.186321: - ossec,syscheck,syscheck_entry_modified,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,
2021 Mar 07 05:50:39 (mypc) any->syscheck
Rule: 550 (level 7) -> 'Integrity checksum changed.'
File '/root/test' modified
Mode: realtime
Changed attributes: mtime,md5,sha1,sha256
Old modification time was: '1615114235', now it is '1615114239'
Old md5sum was: '3e7705498e8be60520841409ebc69bc1'
New md5sum is : '126a8a51b9d1bbd07fddc65819a542c3'
Old sha1sum was: 'dba7673010f19a94af4345453005933fd511bea9'
New sha1sum is : '9054fbe0b622c638224d50d20824d2ff6782e308'
Old sha256sum was: '634b027b1b69e1242d40d53e312b3b4ac7710f55be81f289b549446ef6778bee'
New sha256sum is : '7d6fd7774f0d87624da6dcf16d0d3d104c3191e771fbe2f39c86aed4b2bf1a0f'

Attributes:
 - Size: 6
 - Permissions: rw-r--r--
 - Date: Sun Mar  7 05:50:39 2021
 - Inode: 131348
 - User: root (0)
 - Group: root (0)
 - MD5: 126a8a51b9d1bbd07fddc65819a542c3
 - SHA1: 9054fbe0b622c638224d50d20824d2ff6782e308
 - SHA256: 7d6fd7774f0d87624da6dcf16d0d3d104c3191e771fbe2f39c86aed4b2bf1a0f

What changed:
1c1
< test1
---
> test2


** Alert 1615114245.187539: - ossec,syscheck,syscheck_entry_deleted,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,
2021 Mar 07 05:50:45 (mypc) any->syscheck
Rule: 553 (level 7) -> 'File deleted.'
File '/root/test' deleted
Mode: realtime

Attributes:
 - Size: 6
 - Permissions: rw-r--r--
 - Date: Sun Mar  7 05:50:39 2021
 - Inode: 131348
 - User: root (0)
 - Group: root (0)
 - MD5: 126a8a51b9d1bbd07fddc65819a542c3
 - SHA1: 9054fbe0b622c638224d50d20824d2ff6782e308
 - SHA256: 7d6fd7774f0d87624da6dcf16d0d3d104c3191e771fbe2f39c86aed4b2bf1a0f
```

ファイル追加のログが出てないなと思ったが、元のルール設定を見たらファイル追加のルールはLevel 5で設定されていた。ファイル追加を監視したい場合はルールの上書きでLevelを上げるか、監視の閾値Levelを下げるかが必要。
ちなみにファイル変更監視のルールは0015-ossec_rules.xmlに記載されている下記の内容。

```/var/ossec/ruleset/rules/0015-ossec_rules.xml

  <rule id="550" level="7">
    <category>ossec</category>
    <decoded_as>syscheck_integrity_changed</decoded_as>
    <description>Integrity checksum changed.</description>
    <mitre>
      <id>T1492</id>
    </mitre>
    <group>syscheck,syscheck_entry_modified,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>

  <rule id="553" level="7">
    <category>ossec</category>
    <decoded_as>syscheck_deleted</decoded_as>
    <description>File deleted.</description>
    <mitre>
      <id>T1107</id>
      <id>T1485</id>
    </mitre>
    <group>syscheck,syscheck_entry_deleted,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>

  <rule id="554" level="5">
    <category>ossec</category>
    <decoded_as>syscheck_new_entry</decoded_as>
    <description>File added to the system.</description>
    <group>syscheck,syscheck_entry_added,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>
```

# 続きはまた今度書く