AWSに立てたサーバが攻撃されたログをSplunkで少し見てみた

# はじめに
Splunkに取り込んだsecureログをもう少し深く追ってみたら、思いのほか怖いことが分かった。

# やってみた
## IPアドレスをリストアップ

ログから抜き出したIPアドレスにiplocationをかけてCountryなどを付与し、statsコマンドでIPと国ごとの件数をカウントして、件数降順に並べてみた

```:stats
index=xxx sourcetype="linux_secure"  
| rex field="_raw" "^.* (?P<ip_addr>[1-9][0-9]{0,2}\.[1-9][0-9]{0,2}\.[1-9][0-9]{0,2}\.[1-9][0-9]{0,2}) .*" 
| iplocation ip_addr
| stats count by ip_addr,Country
| sort - count
```
ついでに「where `Country`="Japan"」を入れて日本だけのものもリストアップしてみた。

![qiita_20200226_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/552413/0db3798f-a9fb-839d-20a1-c06222ae5c77.png)


せっかく？なので日本のものを上から見てみる

## (その前に)ドリルダウン設定
毎回、サーチ画面からIPアドレスを検索する・・・のはかったるいので、パネル(表)のIPアドレスをクリックしたら新しいタブが開いて、IPアドレスでサーチをかける設定をした。

![qiita_20200226_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/552413/816b129d-920d-fd22-5519-5c812ffd9c12.png)

1. ダッシュボードを開いたら、右上の「編集」ボタンをクリック
2. パネルの右上に並んでいるボタンのうち、一番右の「:」(その他のアクション)をクリックし、「ドリルダウンを編集」をクリック
3. ドリルダウンエディタが開いたら、クリック時「サーチにリンク」「カスタム」を選ぶ
4. サーチ文字列に「index=xxx sourcetype="linux_secure" "\$click.value\$"」を設定
5. 時間範囲は「タイムピッカーの使用」「全時間」を選択
6. 新しいタブで開くにチェックを付けて「適用」をクリック

![qiita_20200226_3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/552413/a95221c9-4d65-a37c-2441-0e84b59e358a.png)

そうすると表の文字が黒から水色に変わり、クリックできるようになる。

上記で「\$click.value\$」としているが、これは「表をクリックしたときに一番左に表示されている値」を取得できる「トークン名」である。この他にもフィールド名やタイムピッカーの時間などを取得できるトークンもあるので、詳しいことは下記ドキュメントを参照のこと。

Dashboards and Visualizations - Token usage in dashboards -
https://docs.splunk.com/Documentation/Splunk/8.0.2/Viz/tokens

## 調べてみた
どんな攻撃をしてくるものなのか？

日本で一番多かったログは１回につき以下の３行が出力されていた。

Connection closed by 139.xxx.xxx.xxx port 40062 [preauth]
Invalid user  from 139.xxx.xxx.xxx port 40062
Connection closed by 139.xxx.xxx.xxx port 39862 [preauth]

いきなりCloseが出たあと、不正ユーザ(と言ってもユーザ名なし)が出て、またCloseといういかにも怪しい動きをしている。数日に１回、不規則なタイミングだけど、同じようなログがずらずらと、ポート番号を変えてやってきていた。

---
２番目のIPはこんなだった。

Disconnected from 118.xxx.xxx.xxx port 36129 [preauth]
Received disconnect from 118.xxx.xxx.xxx port 36129:11: Bye Bye [preauth]
Invalid user srvadmin from 118.xxx.xxx.xxx port 36129
reverse mapping checking getaddrinfo for ip999999.ap.xxxx.jp [118.xxx.xxx.xxx] failed - POSSIBLE BREAK-IN ATTEMPT!

「reverse～」のログ自体は攻撃を示すものではないけれど、srvadminユーザでSSHログインを試みようとしているのは確かなので、何か意図をもってやってきているのだろう。この４行が１セットとなり、これも数日に１回不規則なタイミングで出ていた。

---
３番目のIPはこんなだった。

Disconnected from 133.xxx.xxx.xxx port 40629 [preauth]
Received disconnect from 133.xxx.xxx.xxx port 40629:11: Bye Bye [preauth]
Invalid user jboss from 133.xxx.xxx.xxx port 40629

２番目と違い「reverse～」のログは出ていないが、不正ユーザでログインしようとして失敗してコネクション切断しているというもので、この３行が１セットで６回、１０日間ほどの間隔でやってきていた。

だが、決定的に違うのが、６回ともユーザ名が毎回違うのだ。
上はjbossになっているが、almacen、chloe、jboss、maccounts、smb、zabbixとどれも製品名などありそうなものでやってきていた。

---
４番目のIPはこんなだった。

Invalid user admin from 61.xxx.xxx.xxx port 38183
error: maximum authentication attempts exceeded for root from 61.xxx.xxx.xxx port 38175 ssh2 [preauth]

今度は認証回数を超えているというログなので、「ブルートフォース攻撃」を仕掛けてきている可能性が高いものである。ユーザも上記は「root」だが、adminやsupportといった、こちらもありがちなユーザで試してきていた。

幸いにも4/3と4/9の２回だけだったが、errorログはいくつも出ていたので執拗に攻撃してきていたのだろう。ウーム、恐ろしい。

---
５～１０番目のIPの攻撃は３番目と同じもので、ユーザ名を変えながらログインを試しているログだった。ただ、ユーザ名は本当にバラバラで、installとかbotとかあったので、ユーザ名の辞書もあるんだろうな、と思った次第。

## じゃあ一番多いIPは？

一番多かったIPが記録されているログの件数は「44,271件」なのだが、これは4/11と5/2のたった二日で記録している、まさに「攻撃」である。しかも、今回見返し気づいたのだが、4/11は22,135件、5/2は22,136件とほぼ同一件数ということのがなんとも恐ろしい限り。

全部見切れてはいないが、ログ自体は以下の２行がセットで延々と出ていて、１分辺り600行程度のログが50分ほど出力されていたことから、これだけの間、攻撃にさらされていたことになるわけで。

Disconnected from 129.xxx.xxx.xxx port 49147 [preauth]
Received disconnect from 129.xxx.xxx.xxx port 49147:11: Bye Bye [preauth]

ああああ、おそろしいぃぃぃ。

# まとめ
たった11件のIPアドレスを確認して見えたのは攻撃手法は6種類。他にもいろんなことを仕掛けられていたのだと思うが、インターネットというのは攻撃が渦巻いているんだなーと感心するやら恐ろしくなるやら。

Splunkのダッシュボードとドリルダウンで簡単にみることができたので、こうして記事にするのは簡単でした。これを手でやるのは辛いな、と実感した次第です。