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

Question

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

解決済

回答 2

投稿 2017/02/10 16:30 ・編集 2017/02/11 12:49

評価
クリップ 3
VIEW 2,940

ruuusaamarki

score 452

前提・実現したいこと

タイトルに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を大量に浴びてしまった場合通信量（パケット料金）は比例して増えてしまうのでしょうか。

気になる質問をクリップする

クリップした質問は、後からいつでもマイページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

クリップを取り消します
良い質問の評価を上げる

以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します

評価を下げられる数の上限に達しました

評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる

teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します

この機能は開放されていません

評価を下げる条件を満たしてません

評価を下げる理由を選択してください
プログラミングに関係のない質問やってほしいことだけを記載した丸投げの質問問題・課題が含まれていない質問意図的に内容が抹消された質問過去に投稿した質問と同じ内容の質問広告と受け取られるような投稿
詳細な説明はこちら

上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。
質問の評価を下げる機能の利用条件

この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
- メールアドレスの認証
  メールアドレスの認証
- 質問評価に関するヘルプページの閲覧
  質問評価に関するヘルプページの閲覧

回答 2 件

評価が高い順
新着順
古い順

0

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

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

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

投稿 2017/02/12 17:07

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

2017/02/15 11:55

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

ご提示いただいた情報をもとに色々調べてみたところ
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のロードバランサがしばらくすると自動で復旧してくれるようになってますので一応情報をシェアしておきます。

確認が遅くなりまして申し訳ありません。ご回答ありがとうございます！ご提示いただいた情報をもとに色々調べてみたところ 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のロードバランサがしばらくすると自動で復旧してくれるようになってますので一応情報をシェアしておきます。

キャンセル
2017/02/20 19:28

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

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

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

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

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

DDoS 対策で有効なのは、インターネット側で絞ること（サーバまでアクセスを届かせないこと）です。一般的には FW より外側で何らかの処置をすること（海外アドレスのフィルタやトラフィックの分散化等々）が有効です。それより内側だと、コストにもハネてきます。ただ、今回の場合は、サイト閲覧者、更新者が f5 キーを連打しているということなので、アプリケーションでの対応をオススメしました。私が自身のサイトでやった対応は、・サイト情報の自動更新（ajax で疑似 push 通信）・1分間のアクセスログを確認し、アクセス回数が一定数を超えた IP アドレスからの更新要求は、「警告ページ」へリダイレクトの2点です。実装するとなると、WordPress での対応になると思います。が、使われかたから見て、シングルページのアプリケーションサイトみたいなものですよね？もしそうなのであれば、WordPress はあまり得意な分野では無い気がします。設計から見直したほうが、結局は色々コストがかからないかと。警告ページには、自動更新を利用するように注意書きを置いたことで、自動更新を使用する人が増えました。更新情報のみをデータとして配信するので、サイトとしては負荷がかなり軽減されました。

キャンセル
2017/02/20 21:42

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

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

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

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

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

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

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

度々のコメントありがとうございます！＞それより内側だと、コストにもハネてきます。貴重な経験談ありがとうございます。このあたりも手探りで結構不安があります。色々なサイトや書籍を見ると割とnginxをリバースプロキシとしてという構成が多いのですがクラウドだとロードバランサ以下にトラフィックが流れると課金がかさむようなイメージと AWSがcloudfrontという専用のキャッシュシステムを用意してくれているのでそちらのほうが便利で簡単なんだろう。というなんとなくな理由で現在cloudfrontのほうもいじっています。＞ただ、今回の場合は、サイト閲覧者、更新者が f5 キーを連打しているということなので、＞アプリケーションでの対応をオススメしました。 1点確認させていただきたいのですがこちらは利用者にやめてねということを伝えるという意味で警告ページを表示したほうがいいということでしょうか。システム的、コスト的なメリットはありますでしょうか。このあたりも総合的に考えていかなければならないと私も考えています。＞私が自身のサイトでやった対応は、具体的な対応策ありがとうございます。参考にさせていただきます。今回はポータルサイトのテストとして行っている状況（仮運用しています）です。想定しているのはアクセスの突発的増加（yahoo砲など）、サイトの拡大に伴う継続的なアクセス増を想定しているのですがそれ以前にインスタンスタイプを下げたら今回の問題があぶりだされたので質問させていただいている次第です。wordpressを使っているのも汎用性と導入コストの低さからですが後々のことを考えるとやはりもっといい方法もありそうですね。注意書きやデザインでユーザーを誘導するのも大事ですね。結局はいろいろな手段を使って目的を達成するところからずれないように気を付けないといけませんね。すみません、お恥ずかしながら現在cloudfrontの設定のところで躓きまたこちらにお世話になっている次第です。 cloudfrontでおそらくf5連打のところは解消できると思いますが導入できたらこちらにも結果を書いてみます。ユーザー心理も考えてAjaxでの対応もできるよう勉強してみます。色々なご経験談ありがとうございます！

キャンセル
2017/02/20 22:01

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

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

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

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

がんばってください。

> 1点確認させていただきたいのですがこちらは利用者にやめてねということを伝えるという意味で警告ページを表示したほうがいいということでしょうか「代替手段を用意したから、そっちを使ってね」といったメッセージですね。運用しているサービスが、数秒~1分程度でコンテンツが更新されるものであったため、リロードより負荷の少なそうなデータのみの配信に切り替えました。他にも対策を同時期に行ったため、この対策による負荷軽減の指標に関しては不明ですが、リロード負荷で問題が発生していたサーバが、3倍のユーザが使用しても問題を起こしていないので、それなりのものがあったと思っています。ただ、バーストトラフィックに対しての対策ではないので、そちらを想定しているのであれば、CDN（CloudFront等）で対策するのが正しいかと。 F5 の対策と、バーストトラフィック対策は、発生する理由が違うので、対策もちょっと分けて考えたほうが良いと思います。がんばってください。

キャンセル
2017/02/20 22:12

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

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

>運用しているサービスが、数秒~1分程度でコンテンツが更新されるものであったため、 >リロードより負荷の少なそうなデータのみの配信に切り替えました。そうなんですね！イメージがわきました。ありがとうございます！ 3倍のユーザーに耐えているのはすごいですね！＞F5 の対策と、バーストトラフィック対策は、発生する理由が違うので、＞対策もちょっと分けて考えたほうが良いと思います。このあたりは自分でもよくわかっていないですが今回いただいた情報で少し理解が進んだ気がします！また状況書かせていただきます。

キャンセル
2017/09/01 15:28

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

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

キャンセル

同じタグがついた質問を見る

score 1 · Accepted Answer · 2017-09-01T15:42

ベストアンサー

+1

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

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

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

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

投稿 2017/09/01 15:42

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

2017/09/14 23:02

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

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

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

キャンセル

質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう！

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

前提・実現したいこと

環境、アプリケーション

試したこと

疑問点

関連した質問

同じタグがついた質問を見る

質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう！

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

前提・実現したいこと

環境、アプリケーション

試したこと

疑問点

15分調べてもわからないことは、teratailで質問しよう！

関連した質問

同じタグがついた質問を見る

SNSアカウントでログイン

teratailアカウントでログイン