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

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

ただいまの
回答率

89.97%

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

解決済

回答 2

投稿 編集

  • 評価
  • クリップ 3
  • VIEW 1,912

ruuusaamarki

score 435

前提・実現したいこと

タイトルに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

checkベストアンサー

+1

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/09/14 23:02

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

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

    キャンセル

0

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/02/20 22:01

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

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

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

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

    がんばってください。

    キャンセル

  • 2017/02/20 22:12

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

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

    キャンセル

  • 2017/09/01 15:28

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

    キャンセル

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

  • ただいまの回答率 89.97%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる