先週にAWS Summit in Tokyo 2019が開催されましたね！
私は今年も参加しましたので、時間があれば記事にしたい所です。
様々な知識を得られてとても有意義でした。

　さて、今回はセキュリティに関する調査とまとめを記事にします。
AWSを使っていれば安全というわけではありません。AWSでは責任共有モデルを採用しており、基本的にサービスの安全は我々ユーザーが担保しなければなりません。

　今回はAWSだからこそ狙われやすいIP帯への攻撃について検証と対策を載せていきます。

攻撃を受けているか調べる

　「うちのサーバーは攻撃を受けていないだろう」なんて思っていませんか？
結論から言うと外部公開をしているWebサーバーは必ず攻撃を受けていると言っても過言ではありません。
　早速その実態を確認してみましょう。

囮サーバーを立てて攻撃の実態を確認する

　攻撃の実態と手法を確認してもらうために、EC2 + ALB構成のApacheサーバーを立てます。
どのような攻撃が来るのか、是非とも最後まで読んでみてください。

◆EC2インスタンスを立てる

　まずはAmazonLinux2のAMIからEC2インスタンスを起動します。今回はあえてパブリックサブネットに起動しました。

◆Apacheを起動

　Apacheをインストールして起動します。

　ブラウザにEC2インスタンスのパブリックIPアドレスを入力して、Apacheのテストページが表示されることを確認します。

◆ロードバランサーを立てる

　EC2単体で使用するケースは少ないと思いますので、ALBを作成しました。

　ALBが起動したことを確認します。

◆ドメインを割り当てる

　ドメインを割り当てないWebサーバーの運用はほぼあり得ないと思います。そのためRoute 53にて先ほどのALBへドメインの割り当てを行いました。

　ALBに割り当てられているIPアドレスも控えておきます。

◆アクセス可能なURL

　この時点で囮サーバーにアクセスするためのURLは6パターンできました。

＜EC2に直接アクセス＞
http://52.193.37.121
http://ec2-52-193-37-121.ap-northeast-1.compute.amazonaws.com

＜ALBに直接アクセス＞
http://Attack-confirmation-server-ALB-1854904319.ap-northeast-1.elb.amazonaws.com
http://52.68.39.83
http://52.198.107.156

＜ドメイン経由でアクセス＞
http://attack.noname.work

ApacheとALBのログ収集を有効にして2~3日程度寝かせます。

攻撃を検知

　検証用の囮サーバーを設置してわずか数時間後。
検索エンジンにインデックスされていないはずの囮サーバーに大量のアクセスが確認できました。

ALBのログを確認

　ALBのログを確認すると、存在しそうなファイルを指定してアクセスを試みていることがわかります。

"GET http://52.198.107.156:80/phpMyAdmin-4.4.0/index.php HTTP/1.1"
"GET http://52.198.107.156:80/myadmin/index.php HTTP/1.1"
"GET http://52.198.107.156:80/myadmin2/index.php HTTP/1.1"
"GET http://52.198.107.156:80/xampp/phpmyadmin/index.php HTTP/1.1"
"GET http://52.198.107.156:80/phpMyadmin_bak/index.php HTTP/1.1"
"GET http://52.198.107.156:80/www/phpMyAdmin/index.php HTTP/1.1"

　アクセス先の部分だけ抜粋するとこんな感じです。
ドメインを指定した攻撃ではなく、IP帯を指定した攻撃であることが分かります。

EC2のログを確認

172.31.15.132 - - [20/Jun/2019:13:32:28 +0000] "POST /mz.php HTTP/1.1" 404 204 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:28 +0000] "POST /yumo.php HTTP/1.1" 404 206 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:28 +0000] "POST /min.php HTTP/1.1" 404 205 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:28 +0000] "POST /wan.php HTTP/1.1" 404 205 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:28 +0000] "POST /wanan.php HTTP/1.1" 404 207 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:28 +0000] "POST /ssaa.php HTTP/1.1" 404 206 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:28 +0000] "POST /ssaa.php HTTP/1.1" 404 206 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:28 +0000] "POST /qq.php HTTP/1.1" 404 204 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:28 +0000] "POST /aw.php HTTP/1.1" 404 204 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:28 +0000] "POST /12.php HTTP/1.1" 404 204 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:29 +0000] "POST /hh.php HTTP/1.1" 404 204 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:29 +0000] "POST /ak.php HTTP/1.1" 404 204 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
172.31.15.132 - - [20/Jun/2019:13:32:30 +0000] "POST /ip.php HTTP/1.1" 404 204 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"

EC2側にも同様のログが残っていました。ログに残っているアクセス元のIPアドレスはALBのものです。
とはいえ、今回の囮サーバーはEC2インスタンスもパブリックに作成してあり80番ポートが解放してあるので、ALBを経由せずに攻撃を受ける可能性もあります。
　ログの内容を見るとありそうなファイル名を指定して大量のアクセスを行なっていることが分かりますね。

Basic認証も狙われる

user "admin" was not found in "/etc/nginx/.htpasswd"
user "admin" was not found in "/etc/nginx/.htpasswd"
user "user" was not found in "/etc/nginx/.htpasswd"
user "admin" was not found in "/etc/nginx/.htpasswd"
user "user" was not found in "/etc/nginx/.htpasswd"
user "admin" was not found in "/etc/nginx/.htpasswd"

　これは今回の囮サーバーではないのですが、Basic認証に対して突破を試みるパターンも確認できました。
そのため、Basic認証を導入しているから安心と言うわけではありません。単純なID/PWなら突破されてしまうでしょう。

ELBのリスナールールで対策ができる

　今回のケースの攻撃は、3日に1回くらいのペースで襲ってきます。
よほど脆弱性がない限りは何事もなく通過するのですが、放置しておくのも気持ちが悪いです。
そのため簡単にできる対策例をひとつ上げておきたいと思います。
それがELBのリスナールール設定です。

　※ 前提としてEC2インスタンスには直接攻撃されないようにセキュリティグループで80ポートを限定したり、プライベートサブネットにおいてください。

　まずはロードバランサーのリスナーを開きます。「ルールの表示/編集」でルールを編集できます。

　「+」マークでルールを追加できるので、新規のルールを追加します。

　「ホストヘッダー」が「*.com」または「*.work」の場合には正しいターゲットグループに送信されるように設定しました。
こうすることで、ドメイン指定のアクセスの場合はルールID1のものが適用されます。

　このままでは「その他」の条件にヒットした場合も正しいターゲットグループに転送されてしまうため、その他の条件を変更する必要があります。

　今回は「その他」の条件にヒットした場合(ドメインがない場合)のアクセスは403の固定レスポンスを返すようにしました。
これでIPアドレスを直接指定したアクセスは全て拒否できるようになります。

Forbidden
You don't have permission to access on this server.

その他の対策案

　その他の対策案について数分考えて思いつく限りを洗い出してみました。
やりようはいくらでもあるので、ケースにあった選択を行えば良いかなと思います。
　・EC2インスタンスに直接アクセスされないようにプライベートサブネットに置く。
　・社内ツールなどの場合はセキュリティグループでIPを制御する。
　・社内ツールなどの場合はVPNを利用する。
　・そもそも80ポートを開放しない。
　・IP制御が難しい場合には少なくともBasic認証くらいは入れておく。
　・Webサーバー側の設定で弾く。
　・WAFで海外からのアクセスを弾く。(ただし国内IPからの攻撃もあった)
　・WAFで一定アクセスの検知があればブロックする設定を入れ込む。

終わりに

　IPアドレスを指定してWebサーバーへの無差別攻撃の対策としてELBのリスナールールを使う方法を紹介しました。
今回のケースの攻撃は、攻撃のたびにIPアドレスが代わりますのでWAFだけでの対策は難しいかなという印象です。
　攻撃元のIPアドレスはヨーロッパや中国が多かったのですが、古い日本のサーバーからも攻撃がありました。

　対策方法は今回の紹介した方法以外にもあると思いますので、保守する環境によって使い分けできれば良いと思います。