Splunk BOSS of the SOCv1をログ分析してみた

## 目次
- [初めに](#初めに)
- [SplunkBOSSoftheSOCとは](#SplunkBOSSoftheSOCとは)
- [蛇足](#蛇足)
- [Netis製ルータ53413番ポート](#Netis製ルータ53413番ポート)
- [ApacheLog4j8089番ポート](#ApacheLog4j8089番ポート)
- [MemcachedDDoS攻撃11211番ポート](#MemcachedDDoS攻撃11211番ポート)
- [5000番ポート](#5000番ポート)

### 初めに
ログ分析の授業の一環でbotv1のログを3人チーム調べて報告書を作成しました。
最後の授業で企業の方に見せて結構褒めてもらいました。(多分お世辞)
せっかくなのでQiitaの記事にしときます。誰でもいいので一人でもこの記事が役に立ったと思ってもらえれば本望です。

担任の先生とチームメンバーには許可を取って載せています。先生、チームメンバーのみんなありがとう！
また、Qiita記事では私が担当した資料のみを載せますが、GitHubに本番用の資料を置いておきます。
GitHubの資料にはチームメンバーが作成した資料も含まれているので、よければご覧ください。

https://github.com/Kei-Adachi0709/BOTSv1_report

### SplunkBOSSoftheSOCとは

>**Splunk BOSS of the SOC BOTS**は、Splunkが主催する**セキュリティ運用センター(SOC)向けのハンズオン競技イベント**です。これは、サイバーセキュリティの専門家や初心者が、実際のSOC業務に関連する課題を解決することでスキルを向上させることを目的としています。

###### **BOSS of the SOCの特徴**

>1. **CTF（Capture The Flag）形式の競技**
    - 参加者は、Splunkを活用してインシデント調査や脅威ハンティングを行い、問題を解決します。
    - 各課題にはフラグ（正解）があり、正しい回答を提出するとポイントを獲得します。
>2. **実際のSOC業務を模擬したシナリオ**
    - **マルウェア感染の調査**
    - **フィッシング攻撃の分析**
    - **不審なネットワークトラフィックの検出**
    - **内部不正行為の特定**  
        など、実際のセキュリティインシデントを想定した問題が出題されます。
>3. **Splunkの活用スキルを向上できる**
    - **Splunk Search Processing Language SPL**を使ったログ分析の練習ができる。
    - SOCアナリストとして必要なスキル（インシデント対応、脅威ハンティングなど）を実践的に学べる。
>4. - **個人またはチームで参加可能**
    - SOCの実務担当者、セキュリティエンジニア、初心者など、さまざまなレベルの参加者が楽しめる。
    - 競技形式で楽しみながら学べるため、セキュリティ教育にも適している。

###### **開催情報**

>Splunk BOTSは、**Splunk主催のカンファレンス（.confやSplunkLive!）などで定期的に開催**されます。企業向けにカスタマイズされたBOTSイベントもあります。
>もし参加を検討している場合は、最新の開催情報を公式サイトで確認すると良いでしょう！

↑全部ChatGPTに聞きました。BOTSの概要が分かる日本語サイトなかったので...
大きく間違ったことも言ってなさそうなので大丈夫だと思います。
一応参考になりそうなサイトも載せておきます。

> [Splunk BOSS of the SOCについて（その１　概要とreconnaissance） #Security - Qiita](https://qiita.com/toshikawa/items/403aaf0901e778629e6d)

### 蛇足
Obsidianで書い報告書をPDFと出力して発表しました。PDF出力もめちゃくちゃ綺麗にできるので、<font color="blue";>Googleドキュメント</font>や<font color="blue";>Word</font>などを文書のPDFに使っている方は是非<font color="red";>Obsidian</font>を使ってみてください！！！
何個かObsidianのチュートリアルになるような記事を書いているのでリンクを貼っておきます。

> [Obsidianとマークダウン記法を使い快適なメモ生活を！ #初心者 - Qiita](https://qiita.com/Kei_Adachi/items/3c471fbcf11b064b28ba)
> [Obsidianをプラグインでもっと便利に！ #初心者 - Qiita](https://qiita.com/Kei_Adachi/items/1f5d01230334574f2e26)
> [コードブロックでサポートされているPrism.jsについて #JavaScript - Qiita](https://qiita.com/Kei_Adachi/items/fd532414ffb1859c39a3)

また、GitHubに置いてあるような見た目のPDFの出力はできないと思います。
CSSスニペットを変更したり、Code Stylerというプラグインをかなりいじっているからです。見出しのh1、h2、h3ごとに色を変えるCSSとかめちゃくちゃ便利でおすすめです。
テーマをデフォルトから変えると、重くなったり挙動がおかしくなるので、自力でCSSを書いた方がいいと思います。


### Netis製ルータ53413番ポート

##### 脆弱性についての説明

Netis製\(中国製)のルータに関する脆弱性を発見した。
デフォルトで UDP の 53413ポートが開放されています。
このポートはパスワードで保護されていますが、すべての製品で共通であり、パスワードを入手すれば誰でも簡単に不正アクセスが可能になります。

>本ブログでも既報の通り、「Netis」は中国国内で人気のネットワーク機器メーカ「Netcore」社の中国国外向けのブランド名です。ほとんどの Netis製ルータにはデフォルトで UDP の 53413ポートが開放されており、WAN側から接続可能になっています。この 53413ポートはファームウェア上でハードコードされた単体のパスワードで「保護」されていますが、それこそが脆弱性の本体です。すでにこのパスワードは明らかになっており、パスワードを入手した人物は誰でも外部から Netis製ルータに接続し不正アクセスが可能です。JPCERT／CC によれば、この 6月に観測された日本における 53413ポートへの通信増加は、まさにこのルータの脆弱性を狙い遠隔操作のためのボットを感染させる目的の攻撃であったようです。
>
>[インターネット定点観測レポート(2015年 10～12月)](https://www.jpcert.or.jp/tsubame/report/report201510-12.html)
>[ルータの脆弱性を狙う通信の増加をJPCERT/CCが報告 |](https://blog.trendmicro.co.jp/archives/12040)

<br>

##### source_typeごとの件数を調べる

```sql
index=botsv1 dest_port=53413
| stats count by sourcetype
| sort -count
```

**実行結果**
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/3796ee29-dd02-1c28-6937-e50e2cc8a2f5.png" width="50%"><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/040fe067-bfcf-7ca1-00ab-3526e898d708.png" width="50%">

##### fortigate_trafficのactionフィールドを調べる
actionフィールドを見ることでリクエストが拒否されたかどうかがわかる。
よって<font color="blue";>sourcetype=fortigate_traffic</font>であるログの数と<font color="blue";>action=blocked</font>の数が同じであればすべてのリクエストが拒否されていることがわかる。

**実行したSPL**
```sql
index=botsv1 dest_port=53413 sourcetype=fortigate_traffic
```

```sql
index=botsv1 dest_port=53413 sourcetype=fortigate_traffic action=blocked
```

**実行結果**
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/07c94545-7012-a535-5bb7-bb67ee117890.png" width="50%"><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/de3ffb18-32a0-2844-5ce6-22bc2e561d75.png" width="50%">

source_typeが<font color="blue";>fortigate_traffic</font>であるログはすべてactionが<font color="blue";>blocked</font>である。
よってsource_typeが<font color="blue";>fortigate_traffic</font>のログに関しては、53413番ポートに対する攻撃は防がれていることが分かる。

##### suricataのログを調べる

**実行したSPL**
```sql
index=botsv1 dest_port=53413 sourcetype=suricata
```
上記のSPLでログが2件合致し、日付は<font color="blue";>2016/8/11</font>と<font color="blue";>2016/8/25</font>でした。

- **2016/8/11のログ**
```log
{"timestamp":"2016-08-10T15:58:23.791919-0600","flow_id":3724372038,"in_iface":"eth1","event_type":"dns","src_ip":"8.8.8.8","src_port":53,"dest_ip":"192.168.250.20","dest_port":53413,"proto":"UDP","dns":{"type":"answer","id":41232,"rcode":"NOERROR","rrname":"55.58.203.23.in-addr.arpa","rrtype":"PTR","ttl":18660,"rdata":"a23-203-58-55.deploy.static.akamaitechnologies.com"}}
```

<font color="blue";>src_ip</font>: <font color="blue";>8.8.8.8</font>や<font color="blue";>src_port</font>: <font color="blue";>53</font>とあります。
このIPアドレスとポート番号からGoogle Public DNSサーバーからクエリを送っていることがわかります。
<font color="blue";>rcode</font>: <font color="blue";>"NOERROR"</font>:や<font color="blue";>rrname</font>: <font color="blue";>"55.58.203.23.in-addr.arpa"</font>:とあります。
これらからリバースDNSクエリ\(IPアドレスからホスト名を引く)であり、対象のIPアドレスは <font color="blue";>23.203.58.55</font>である。

<font color="blue";>rdata</font>: <font color="blue";>"a23-203-58-55.deploy.static.akamaitechnologies.com"</font>
rdata\(Resource Data)は、DNS\(Domain Name System)でリソースレコード\(RR: Resource Record)のデータ部分を指します。

rdataの内容からIPアドレス<font color="blue";>23.203.58.55</font>の逆引きを行い、それがAkamaiの静的コンテンツ配信サーバーであることがわかりました。
Akamai Technologiesは、世界的なCDNのリーダー企業でありWAFなどを提供しています。
これらの要素からAkamaiの静的コンテンツ配信サーバーに対する正常な通信であると思われます。


- **2016/8/25のログ**
```log
{"timestamp":"2016-08-24T10:49:57.043008-0600","flow_id":3724372038,"in_iface":"eth1","event_type":"dns","src_ip":"8.8.8.8","src_port":53,"dest_ip":"192.168.250.20","dest_port":53413,"proto":"UDP","dns":{"type":"answer","id":6010,"rcode":"NOERROR","rrname":"147.24.93.85.in-addr.arpa","rrtype":"PTR","ttl":21599,"rdata":"dashmallicy.xyz"}}
```

8/11のログと同じく<font color="blue";>src_ip</font>: <font color="blue";>8.8.8.8</font>や<font color="blue";>src_port</font>: <font color="blue";>53</font>とあり、Google Public DNSサーバーからクエリを送っていることがわかります。

<font color="blue";>rrname</font>: <font color="blue";>"147.24.93.85.in-addr.arpa"</font>:
とあるので、リバースDNSクエリ\(IPアドレスからホスト名を引く)で対象のIPアドレスは<font color="blue";>85.93.24.147</font>であることがわかります。
<font color="blue";>rdata</font>: <font color="blue";>"dashmallicy.xyz"</font>:
なのでIPアドレス <font color="blue";>85.93.24.147</font> のP逆引きレコードに対応するホスト名です。

このドメイン<font color="blue";>"dashmallicy.xyz"</font>を[VirusTotal - Home](https://www.virustotal.com/gui/home/upload)で調べてみた結果危険だという報告はありませんでした。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/d322bdd9-5d03-3468-cba4-0587890f743d.png" width="100%">

##### サイバーキルチェーン
ここまでの情報から、ポートスキャンを行っており、サイバーキルチェーンの偵察段階のログであることが分かります。

##### 対策
このメーカーのルータにしかない脆弱性なので別製品に乗り換える。
ポートフィルタリングの設定を見直す。

### ApacheLog4j8089番ポート

##### 実行したSPL
1つ目と同様に、宛先ポートが怪しいログを調べ8089番に辿り着いた。

下記のSPLで一意にログを特定できました。
```sql
index=botsv1 src_port=61746 dest_port=8089 flow_id=948947464
```


```log
{"timestamp":"2016-08-28T12:00:37.000085-0600","flow_id":948947464,"event_type":"flow","src_ip":"192.168.225.173","src_port":61746,"dest_ip":"192.168.224.33","dest_port":8089,"proto":"TCP","app_proto":"tls","flow":{"pkts_toserver":20,"pkts_toclient":20,"bytes_toserver":3604,"bytes_toclient":6198,"start":"2016-08-28T12:00:37.504637-0600","end":"2016-08-28T12:00:37.525520-0600","age":28,"state":"closed","reason":"timeout"},"tcp":{"tcp_flags":"1f","tcp_flags_ts":"1f","tcp_flags_tc":"1b","syn":true,"fin":true,"rst":true,"psh":true,"ack":true,"state":"closed"}}
```

##### 脆弱性についての説明
宛先ポート番号が8089であるログが多くあり、不審な点が見つかった。

><font color="blue";>ポート8089</font>について参考記事
>[検証用AWSアカウントでGuardDutyと闘う話 〜不用意にポート開けるな編〜 #EC2 - Qiita](https://qiita.com/kikeyama/items/8d694725a43272bed3e8)
>[【セキュリティ ニュース】「Log4Shell」攻撃、対象ポートが拡大中 - 警察庁観測（1ページ目 / 全1ページ）：Security NEXT](https://www.security-next.com/132541)

8089ポートに関連する脆弱性がないか調べてみたところ、「CVE-2021-44228」や「CVE-2021-45046」が見つかった。
この脆弱性は「Apache Log4j」により、リモート攻撃が可能となるものである。

>Log4jはApacheソフトウェア財団のプロジェクトである「Apache Logging」で開発されたオープンソースソフトウェアの1つであり、Javaで開発したプログラムに対してログを記録・出力するための機能を提供します。

><font color="blue";>Apache Log4j</font>について参考記事
>[Apache Log4jに見つかった脆弱性「Log4Shell」とは \| ドコモビジネス \| NTTコミュニケーションズ 法人のお客さま](https://www.ntt.com/business/services/xmanaged/lp/column/apache-log4j.html)
>[初心者でも分かるLog4jとその脆弱性、影響範囲から対策方法のすべて - ペンタPRO：ペンタセキュリティが提供するセキュリティ情報まとめサイト](https://www.pentasecurity.co.jp/pentapro/entry/log4J)

**攻撃の仕組み**
>1. 攻撃者は脆弱性を利用できるようにするため、特殊な文字列を含ませたhttpリクエスト（データ）をサーバに送信する
>2. サーバに脆弱性がある場合、Javaアプリケーションは送られてきたデータを処理した結果を、そのままログに書き込んでしまう
>3. ログに書き込まれたデータに特殊な変数が含まれていると、JDNI Lookup機能がそれを実行してしまう
>4. Log4j が、ダウンロードした悪意のあるプログラムを読み込み、実行してしまう
>
>
>この文字列がログに書き込まれ、JNDI Lookup機能により実行された場合、アクセスを受けたLDAPサーバ（ldap://xxxxx.com/a）は、悪意のあるJava ClassファイルのURLを応答します。するとLog4jは、応答されたURLに配置されている悪意のあるJava Classファイルをダウンロード、メモリ内に読み込み実行してしまうというわけです。
>
>[初心者でも分かるLog4jとその脆弱性、影響範囲から対策方法のすべて - ペンタPRO：ペンタセキュリティが提供するセキュリティ情報まとめサイト](https://www.pentasecurity.co.jp/pentapro/entry/log4J)


>Log4jに見つかった深刻な脆弱性であるLog4Shellを利用すれば、任意のコードをリモートで実行する、RCE（Remote Code Execution：リモートコード実行）が可能です。背景にあるのはLookupと呼ばれる機能やJNDI（Java Naming and Directory Interface）と呼ばれる仕組みの処理にある問題で、攻撃者が送信した文字列をLog4jがログとして記録すると、その文字列に記述された通信先やサーバー内部のファイルからjava classファイルと呼ばれるファイルを読み込んで実行してしまうというものです。
>[Apache Log4jに見つかった脆弱性「Log4Shell」とは \| ドコモビジネス \| NTTコミュニケーションズ 法人のお客さま](https://www.ntt.com/business/services/xmanaged/lp/column/apache-log4j.html)


<br>

##### TCPのフラグについて

先程示したログのフィールドに<font color="blue";>tcp_flags</font>:<font color="blue";>1f</font>\(0001.1111)というものがあります。これはTCPヘッダのフラグを示すものです。

| 10ビット目   | 9ビット目        | 8ビット目      | 7ビット目    | 6ビット目  |
| -------- | ------------ | ---------- | -------- | ------ |
| Reserved | Accurate ECN | Congestion | ECN-Echo | Urgent |

| 5ビット目          | 4ビット目 | 3ビット目 | 2ビット目 | 1ビット目 |
| -------------- | ----- | ----- | ----- | ----- |
| Acknowledgment | Push  | Reset | SYN   | FIN   |

- <font color="blue";>tcp_flags</font>:<font color="blue";>1f</font>\(0001.1111)がどういう意味なのか

| 立っていたフラグ          | 説明                            |
| ----------------- | ----------------------------- |
| FIN\(Finish)      | 接続の終了を要求するフラグ。通信を終了する際に使用される。 |
| SYN\(Synchronize) | 接続の確立を要求するフラグ。シーケンス番号の同期に使用。  |
| RST\(Reset)       | 接続をリセットするフラグ。異常な接続やエラー時に使用。   |
| PSH\(Push)        | 即座にデータを受信側にプッシュすることを要求するフラグ。  |
| ACK               | データの受信確認を行うフラグ。               |

FIN、SYN、RSTが同時に立っているのは明らかにおかしいと感じたのでさらに調べるとクリスマスツリー攻撃であることが分かりました。

※クリスマスツリー攻撃とは
>TCPパケットの複数のフラグがオンになった異常ものを送り込むことで、プロトコルを適切に処理できないデバイスやコンフィグレーションに対して予期しない動作を誘発することが可能
>
>[クリスマスツリー攻撃とは？概要から対策まで徹底解説](https://www.digitalsales.alsok.co.jp/col_christmas-tree)


##### サイバーキルチェーン
ここまでの情報から、サイバーキルチェーンの偵察段階のログであることが分かります。

##### 対策
- Apache Log4j
	最新版へアップデートを行いましょう。
	バージョンアップしない場合の具体的な対策方法については、[JPCERT/CCのページ](https://www.jpcert.or.jp/at/2021/at210050.html)をご覧ください。

>参考:
>[Apache Log4j の脆弱性対策について(CVE-2021-44228) \| アーカイブ \| IPA 独立行政法人 情報処理推進機構](https://www.ipa.go.jp/archive/security/security-alert/2021/alert20211213.html)
>[「Log4j」の脆弱性とは？ リスクや対策など \| 株式会社 日立ソリューションズ・クリエイト](https://www.hitachi-solutions-create.co.jp/column/security/log4j.html#h2-3)
>[Apache Log4jの任意のコード実行の脆弱性（CVE-2021-44228）に関する注意喚起](https://www.jpcert.or.jp/at/2021/at210050.html)


- クリスマスツリー攻撃
	ファイアウォールの設定を見直し、適切なポートフィルタリングを行う

>参考:
>[クリスマスツリー攻撃とは？概要から対策まで徹底解説](https://www.digitalsales.alsok.co.jp/col_christmas-tree)


### MemcachedDDoS攻撃11211番ポート

##### 脆弱性についての説明
引き続き特定のポートに問題がないか調べると、11211番ポートに関連した製品の深刻な脆弱性を発見しました。
Memcachedサーバの脆弱性を利用したDDoS攻撃です。

>Memcached とは？
>
>Memcached は、オープンソースの高性能分散型のメモリー／データベースキャッシュシステムです。多くの場合にキー値を使用し、アクセスの多いデータをメモリーにキャッシュすることで、動的な Web サイトや Web アプリケーションを高速化します。Memcached は、Facebook、Twitter、YouTube などの企業で広く使用されています。UDP もサポートされ、 [攻撃ベクトル](https://www.akamai.com/ja/glossary/what-is-attack-vector)に利用される大きな要因となっています。
>
>[Memcached DDoS 攻撃とは？\| Akamai](https://www.akamai.com/ja/glossary/what-is-a-memcached-ddos-attack)

**攻撃の仕組み**
>memcached攻撃は次の4つのステップで発生します：
 1.攻撃者は公開されたmemcachedサーバーにデータの大きなペイロード*を埋め込みます。
 2.次に、攻撃者は標的となる被害者の[IPアドレス](https://www.cloudflare.com/learning/dns/glossary/what-is-my-ip-address/)で [HTTP GET](https://www.cloudflare.com/learning/ddos/glossary/hypertext-transfer-protocol-http/)リクエストを偽装します。
 3.リクエストを受信する脆弱なmemcachedサーバーは、応答することで役立てようとしているため、標的に大量の応答を送信します。
 4.標的のサーバーまたはその周囲のインフラストラクチャは、memcachedサーバーから送信された大量のデータを処理できないため、正当なリクエストに対する過負荷とサービス拒否が発生します。
>
>[memchachedを利用したDDoS攻撃 \| Cloudflare](https://www.cloudflare.com/ja-jp/learning/ddos/memcached-ddos-attack/)

##### 実行したSPL

- ポート番号だけで絞り込み
```sql
index=botsv1 dstport=11211
| sort _time
```

- DDos攻撃が疑われるので、1分以内に10件以上のトラフィックが存在するログを絞り込む
```sql
index=botsv1
dstport=11211 
| bin _time span=1m
| stats count by _time, srcip, dstip, srcport, dstport
| where count > 10
```

**実行結果**
それぞれの実行結果を見てみると、どちらも623件です。
通信を試みたログが短時間に集中していることがわかります。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/54954bf4-cacd-761e-27d0-9729a2f7b53c.png" width="50%"><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/e9ef1d26-56c4-109a-c48c-adfe05eb3e6d.png" width="50%">

```sql
index=botsv1 dstport=11211 action=blocked
| sort _time
```

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/b4bb9dd0-d989-1b1f-2c86-d9a2e2ba73f8.png" width="100%">

623件であり、すべて防がれていることがわかります。

##### サイバーキルチェーン
Memcached DDoS 攻撃を行うための準備としてポートスキャンを行っており、サイバーキルチェーンでは偵察段階に当たります。

##### 対策
不要なポートである場合は閉じる。

>- **Memcached DDoS の直接のターゲット**: この種の攻撃には、クラウド型の DDoS 対策を活用します。増幅係数が高く、オープンな Memcached サーバーが多いことから、データセンターのローカルな対策では、キャパシティの問題が生じる可能性があります。
>
>[Memcached DDoS 攻撃とは？\| Akamai](https://www.akamai.com/ja/glossary/what-is-a-memcached-ddos-attack#accordion-3a7152bcb1-item-5eb3a9601f)

### 5000番ポート

##### 脆弱性についての説明

Windows XPでUPnPの実装に問題があり、UPnPサービスの脆弱性を突くものです。

>5000番ポートはそのような[ポート番号](https://e-words.jp/w/%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7.html)の一つで、いくつかの用途に用いられる。よく知られる用途の一つとして、[コンピュータ](https://e-words.jp/w/%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF.html)から[ネットワーク](https://e-words.jp/w/%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF.html)上の機器の検知や設定を行うための[UPnP](https://e-words.jp/w/UPnP.html)（[Universal Plug and Play](https://e-words.jp/w/UPnP.html)）で用いられる[プロトコル](https://e-words.jp/w/%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB.html)の一つである[SSDP](https://e-words.jp/w/SSDP.html)（[Simple Service Discovery Protocol](https://e-words.jp/w/SSDP.html)）が利用していた。
>
>[コンピュータ](https://e-words.jp/w/%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF.html)が[周辺機器](https://e-words.jp/w/%E5%91%A8%E8%BE%BA%E6%A9%9F%E5%99%A8.html)からの[イベント](https://e-words.jp/w/%E3%82%A4%E3%83%99%E3%83%B3%E3%83%88.html)通知を受け付ける[ポート番号](https://e-words.jp/w/%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7.html)として[TCP](https://e-words.jp/w/TCP.html)の5000番が用いられ、[Windows XP](https://e-words.jp/w/Windows_XP.html)では[UPnP](https://e-words.jp/w/UPnP.html)の[実装](https://e-words.jp/w/%E5%AE%9F%E8%A3%85.html)に問題があったため5000番ポートが攻撃の標的となった。現在ではこの用途（SSDP Event Notification）は[TCP](https://e-words.jp/w/TCP.html)の[2869](https://e-words.jp/w/2869%E7%95%AA%E3%83%9D%E3%83%BC%E3%83%88.html)番が標準の[ポート](https://e-words.jp/w/%E3%83%9D%E3%83%BC%E3%83%88.html)とされる。
>
>[5000番ポート（ポート5000 / TCP5000番）とは - IT用語辞典 e-Words](https://e-words.jp/w/5000%E7%95%AA%E3%83%9D%E3%83%BC%E3%83%88.html)
>[TCP 5000番ポートへのアクセスが急増，原因は2種類の新種ワーム \| 日経クロステック（xTECH）](https://xtech.nikkei.com/it/free/ITPro/NEWS/20040518/144341/)

また、Docker Remote APIやWebサーバー、カスタムサービスで使用されることが多く、特にFlaskサーバのポートとしてよく使われる。
認証が構成されていないDocker APIの場合、コンテナを自由に操作されるリスクがあり危険です。

>**Flask**（フラスク）は、プログラミング言語[Python](https://ja.wikipedia.org/wiki/Python "Python")用の、軽量な[ウェブアプリケーションフレームワーク](https://ja.wikipedia.org/wiki/%E3%82%A6%E3%82%A7%E3%83%96%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF "ウェブアプリケーションフレームワーク")である
>
>参考:
>[Flask - Wikipedia](https://ja.wikipedia.org/wiki/Flask)


##### sourcetypeごとの件数を調べる

```sql
index=botsv1 dest_port=5000
| stats count by sourcetype
| sort -count
```
上記のSPLで検出されるログは、suricataが5件、stream:tcpが5件、fortigate_trafficが223件ありました。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/005f2ed9-1984-3b14-7d24-6248c5862e63.png" width="50%"><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/a87e4d32-b830-0c26-932b-074254f6de6d.png" width="50%">

##### suricataのログを調べる

```sql
index=botsv1 dest_port=5000 sourcetype=suricata
| sort time
```

suricataでのログは5件であり、5件のログのフィールドについて調べたものを表にしてまとめました。

| ログ番号 | 宛先IP           | 応答  | 状態       | 終了理由    | 送信バイト数 | 受信バイト数 |
| ---- | -------------- | --- | -------- | ------- | ------ | ------ |
| 1    | 192.168.250.70 | なし  | syn_sent | timeout | 124    | 0      |
| 2    | 192.168.250.70 | なし  | syn_sent | timeout | 124    | 0      |
| 3    | 192.168.250.70 | なし  | syn_sent | timeout | 124    | 0      |
| 4    | 192.168.250.41 | あり  | closed   | timeout | 124    | 120    |
| 5    | 192.168.250.40 | あり  | closed   | timeout | 124    | 120    |

1つ目~3つ目は<font color="blue";>syn_sent</font>状態なのでSYNを受信済みであることが分かります。

4つ目、5つ目のログではSYN,ACK,RSTのフラグが立っており<font color="blue";>closed</font>状態なのでコネクション確立段階でないことが分かります。

>参考:
>[TCPの状態遷移 #Network - Qiita](https://qiita.com/mogulla3/items/196124b9fb36578e5c80)
##### stream:tcpのログを調べる

```sql
index=botsv1 dest_port=5000 sourcetype=stream:tcp
| sort time
```

| ログ番号 | 接続先                 | 状態 (tcp_status) | 拒否 (refused) | 処理時間 (ms) | 送信バイト | 受信バイト | 接続  |
| ---- | ------------------- | --------------- | ------------ | --------- | ----- | ----- | --- |
| 1    | 192.168.250.40:5000 | 拒否 (1)          | 1            | 6         | 60    | 124   | 拒否  |
| 2    | 192.168.250.41:5000 | 拒否 (1)          | 1            | 237       | 60    | 124   | 拒否  |
| 3    | 192.168.250.70:5000 | 成功 (2)          | 0            | 1         | 0     | 124   | 成功  |
| 4    | 192.168.250.70:5000 | 成功 (2)          | 0            | 5         | 0     | 124   | 成功  |
| 5    | 192.168.250.70:5000 | 成功 (2)          | 0            | 2         | 0     | 124   | 成功  |

それぞれのログを表にまとめると上記のようになりました。

また、3~4つ目のログでは接続が成功しているので更なる調査が必要だと思われます。


##### fortigate_trafficのactionフィールドを調べる

```sql
index=botsv1 dest_port=5000 sourcetype=fortigate_traffic
```
上記のSPLで233件のログが検出された


```sql
index=botsv1 dest_port=5000 sourcetype=fortigate_traffic action=blocked
```
先程のSPLで検出された通信が成功していないログがどれだけの数なのかを調べると、<font color="blue";>sourcetype=fortigate_traffic</font>であるログはすべて<font color="blue";>action=blocked</font>であった。
よって通信は成功していなことが分かります。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/1effe969-ae53-4436-4707-b3f70589693f.png" width="50%"><img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3853726/e3d20f84-a1ae-fab1-12a7-8475cb1cfcae.png" width="50%">

##### サイバーキルチェーン
ここまでの情報から、サイバーキルチェーンの偵察段階のログであることが分かります。
##### 対策
UPnPを使う場合は2869番ポートを使う。
ポートフィルタリングの設定を見直す。