AWSでお勧めのF5アタック対策

Question

###前提・実現したいこと
タイトルにf5アタックとしたのは今回想定しているのは
いわゆるプログラムなどの攻撃ではなく通常の閲覧や
サイト更新者の操作で問題が発生している可能性が高いためです。
AWSでサイトを表示させるところまではできたのですが
f5キーを連打するとロードバランサの状態がOut Of Serviceになり
サイト自体も応答しませんとなります。
EC2のインスタンスの状態、ステータスチェックはOK（緑のチェック）です。
そこで以下のような構成の場合どのように、どの部分で対策を取るのがお勧めでしょうか。

###環境、アプリケーション
route53→ELB→EC2→nginx→phpfpm→RDSの構成でwordpressを動かしています。
centosは7です。
EC2、RDS共にインスタンスタイプ（CPUスペック）は一番低いものに設定しております。
DNSでのキャッシュ、wordpressプラグインを用いたサーバ側でのキャッシュも
まだ設定していない状態です。（将来的にはcloudfront,s3も絡めたキャッシュを予定しています）

###試したこと
【1】nginxのconfファイルでDDos対策として紹介されていた以下の設定をしてみました。
リロードを連打するときちんと503を返してくれるものの
ページ読み込み速度が10倍近く遅くなりました。
（複数読み込んでいる画像のロード時間が顕著に遅くなっていました。）

http {
    limit_req_zone $binary_remote_addr zone=limit_req_by_ip:10m rate=1r/s;
    limit_req_log_level error;
    limit_req_status 503;
}
server {
    location / {
        limit_req zone=limit_req_by_ip burst=10;
        ...
    }
}

【2】linuxの/etc/sysctl.confファイルに以下を設定しましたがこちらも効果はありませんでした。

net.ipv4.tcp_fin_timeout=15

追記後以下実行
sysctl -p

【3】route53のRouting Policyのgeolocationでjapanの設定をしてみましたがgoogleのボットがはじかれてしまいやめました。

###疑問点
・現在cloudfrontの導入も検討しており調査しておりますが情報が見つけられませんでした。
こちらで上記nginxのような設定が可能なのでしょうか。またroute53等でも可能なものなのでしょうか。

・上記nginxでも実現はできたのでページが遅くならない方法がありましたらご教授願います。

・nginxで設定した場合、もし仮にDDOSを大量に浴びてしまった場合通信量（パケット料金）は比例して増えてしまうのでしょうか。

Answer 1

通常の閲覧やサイト更新者の操作

攻撃ではなく通常の観閲、操作でヘルスチェックが失敗する原因は以下が考えられます。

1.nofileが不足
2.各M/Wの同時接続数(nginx, mysql)
3.アプリが動作するのにEC2のスペックが不足(1コネクションあたりの処理が遅くなり、詰まっている)

ログ等を確認し、ヘルスチェックに失敗している原因をまず確認してから対策について検討すべきです。

Comments

[ruuusaamarki]

moonphaseさんご回答ありがとうございます！

アドバイスいただきました項目につきまして
nofileというのは初めて聞きました、またその他の項目に関しても
調査が必要という認識も薄かったためあらためて調査してみます。
ログの見方も現在独学で勉強中という状況で
linuxに関してもまだまだ初心者の域を出られず少し時間がかかりそうですので
また不明点が出てきた際はご質問させていただきたいと思います。
参考になりました！ありがとうございました！

Answer 2

通常の閲覧やサイト更新者の操作で問題が発生している可能性が高い

ユーザビリティを考えると、アプリケーションで対応するのが良いのではないでしょうか？
連続アクセスをアプリケーションでカウントして、一定時間内のアクセスが想定するものより多すぎる場合、警告ページに飛ばすことで対応できるかと思います。

故意の攻撃を防ぎたいのであれば、別の対策が必要かと思いますが。
どちらの対応が必要なのか整理して下さい。

Comments

[ruuusaamarki]

確認が遅くなりまして申し訳ありません。
ご回答ありがとうございます！

ご提示いただいた情報をもとに色々調べてみたところ
etc/nginx/nginx.confで以下の設定をしてみました。

http {
#毎秒40の新規リクエスト受付可能
limit_req_zone $binary_remote_addr zone=one:10m rate=40r/s;
server {
#同時に100リクエスト受付可能
limit_req zone=one burst=100 nodelay;
}
}

が結果はf5を連打すると機能していませんという表示が出てしまいます。
間違いなどあれば突っ込んでいただけましたら幸いです。

またアプリケーションでの対応といいますとwordpress,php,での対応するということでしょうか。
こちらはスキル的に時間がかかりそうですが調べてみます。

今回想定しているのはサイト閲覧者、更新者がf5キーを連打している状態です。
（他のリスクもおいおい対応できればと思いますがサーバ立ち上げてまずはこんな設定することが多いよなど教えていただけましたらうれしいです。）
またコストもかけられない状態ですので
現在回避案としてcloudfrontの導入で今回の問題とコスト部分が解消されるかを検証しています。

ddosに関しては色々な状況や想定しなければならないことが
多岐にわたることが調べてみてわかりました。
ふわっとした質問になってしまい恐縮ですが
一つ一つ整理して調べてみたいと思います。
また何かお気づきの点がありましたら書き込みをお願いいたします。

余談ですが最近AWSのロードバランサがしばらくすると自動で復旧してくれるようになってますので一応情報をシェアしておきます。

[退会済みユーザー]

DDoS 対策で有効なのは、インターネット側で絞ること（サーバまでアクセスを届かせないこと）です。一般的には FW より外側で何らかの処置をすること（海外アドレスのフィルタやトラフィックの分散化等々）が有効です。
それより内側だと、コストにもハネてきます。

ただ、今回の場合は、サイト閲覧者、更新者が f5 キーを連打しているということなので、アプリケーションでの対応をオススメしました。

私が自身のサイトでやった対応は、
・サイト情報の自動更新（ajax で疑似 push 通信）
・1分間のアクセスログを確認し、アクセス回数が一定数を超えた IP アドレス からの更新要求は、「警告ページ」へリダイレクト
の2点です。

実装するとなると、WordPress での対応になると思います。が、使われかたから見て、シングルページのアプリケーションサイトみたいなものですよね？もしそうなのであれば、WordPress はあまり得意な分野では無い気がします。
設計から見直したほうが、結局は色々コストがかからないかと。

警告ページには、自動更新を利用するように注意書きを置いたことで、自動更新を使用する人が増えました。更新情報のみをデータとして配信するので、サイトとしては負荷がかなり軽減されました。

[ruuusaamarki]

度々のコメントありがとうございます！

＞それより内側だと、コストにもハネてきます。
貴重な経験談ありがとうございます。このあたりも手探りで結構不安があります。
色々なサイトや書籍を見ると割とnginxをリバースプロキシとしてという構成が多いのですが
クラウドだとロードバランサ以下にトラフィックが流れると課金がかさむようなイメージと
AWSがcloudfrontという専用のキャッシュシステムを用意してくれているのでそちらのほうが
便利で簡単なんだろう。というなんとなくな理由で現在cloudfrontのほうもいじっています。

＞ただ、今回の場合は、サイト閲覧者、更新者が f5 キーを連打しているということなので、
＞アプリケーションでの対応をオススメしました。
1点確認させていただきたいのですがこちらは利用者にやめてねということを伝えるという意味で警告ページを表示したほうがいいということでしょうか。システム的、コスト的なメリットはありますでしょうか。このあたりも総合的に考えていかなければならないと私も考えています。

＞私が自身のサイトでやった対応は、
具体的な対応策ありがとうございます。参考にさせていただきます。

今回はポータルサイトのテストとして行っている状況（仮運用しています）です。想定しているのはアクセスの突発的増加（yahoo砲など）、サイトの拡大に伴う継続的なアクセス増を想定しているのですがそれ以前にインスタンスタイプを下げたら今回の問題があぶりだされたので質問させていただいている次第です。wordpressを使っているのも汎用性と導入コストの低さからですが後々のことを考えるとやはりもっといい方法もありそうですね。

注意書きやデザインでユーザーを誘導するのも大事ですね。
結局はいろいろな手段を使って目的を達成するところからずれないように気を付けないといけませんね。

すみません、お恥ずかしながら現在cloudfrontの設定のところで躓き
またこちらにお世話になっている次第です。
cloudfrontでおそらくf5連打のところは解消できると思いますが
導入できたらこちらにも結果を書いてみます。
ユーザー心理も考えてAjaxでの対応もできるよう勉強してみます。
色々なご経験談ありがとうございます！

[退会済みユーザー]

> 1点確認させていただきたいのですがこちらは利用者にやめてねということを伝えるという意味で警告ページを表示したほうがいいということでしょうか

「代替手段を用意したから、そっちを使ってね」といったメッセージですね。
運用しているサービスが、数秒~1分程度でコンテンツが更新されるものであったため、リロードより負荷の少なそうなデータのみの配信に切り替えました。
他にも対策を同時期に行ったため、この対策による負荷軽減の指標に関しては不明ですが、リロード負荷で問題が発生していたサーバが、3倍のユーザが使用しても問題を起こしていないので、それなりのものがあったと思っています。

ただ、バーストトラフィックに対しての対策ではないので、そちらを想定しているのであれば、CDN（CloudFront等）で対策するのが正しいかと。

F5 の対策と、バーストトラフィック対策は、発生する理由が違うので、対策もちょっと分けて考えたほうが良いと思います。

がんばってください。

[ruuusaamarki]

>運用しているサービスが、数秒~1分程度でコンテンツが更新されるものであったため、
>リロードより負荷の少なそうなデータのみの配信に切り替えました。
そうなんですね！イメージがわきました。ありがとうございます！
3倍のユーザーに耐えているのはすごいですね！

＞F5 の対策と、バーストトラフィック対策は、発生する理由が違うので、
＞対策もちょっと分けて考えたほうが良いと思います。
このあたりは自分でもよくわかっていないですが
今回いただいた情報で少し理解が進んだ気がします！
また状況書かせていただきます。

[ruuusaamarki]

その後WAFにレートベースでのルールが
設定できるようななったとの情報を聞き導入しています。
（同一IPから2000アクセス/5分　以上アクセスがあると
そのIPをはじくというようなイメージ）
金額も私の環境では9ドルと手ごろでした。
今回はcloudfrontに設置するような形で
ログも直近のものはAWSの管理画面にわかりやすく
表示してくれるのでいい感じだと思います。
現在ロードバランサを外してしまい
EC2インスタンスのタイプを1段階上げた状態で
F5連打でも落ちない状態までとりあえず持ってこれています。